- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Improving the GUI

by Damien Cassou

On Sun, Jul 20, 2008 at 5:41 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Someone told me (damien probably) that nicefont was touching a lot of place > in the system. Ideally I would like to avoid to depend on a pluggin for > things as essential as font rendering (at least in a basic image). That's why I chose NiceFonts (http://www.jvuletich.org/NiceFonts.html) it is easy to install and use. However, it is a set of patches which touch a lot of places. > Did somebody check a bit the code of niceFont? I think it is needed before inclusion. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 20, 2008

Re: [Pharo-project] about ensuring file closing

by Damien Cassou

On Sun, Jul 20, 2008 at 8:14 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > That sounds fine, but I would want Damien to be involved. I'm here :-) > I would also > like to discuss the pros and cons of a facade such as > > ReadStream class>>on:aCollection > ^aCollection readStream. > > which I _think_ can be readily adapted to instantiate Nile streams. > There would be a similar trick for write streams. I think it is necessary to have such a facade, at least temporarily. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 20, 2008

Re: [Pharo-project] Improving the GUI

by Bill Schwab

CÃ©drick, I respectfully disagree with opening full by default. Bigger, yes, full screen, no. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> cdrick65(a)gmail.com 07/20/08 1:36 PM >>> > Better menus > ------------------------------- > Current problems: > - bad organization menus only work when you have learned where > something is located > - duplicated entries e.g., Appearance is both in the top level world menu > and in the submenu Help > - useless entries e.g., set font, set style etc. in the > context menu are useless since code is never styled > - defective entries: e.g., "Make project link" in the context menu does > not work Would it be possible to have accordion effects? > > Larger windows > ------------------------------- > The default size of windows is usually too small. Often, after opening a > window I have to resize it. For example the hierarchy browser shows only the > 5 first classes. I always open them fullscreen. I think that would be a better default... I struggled but couldn't achieve that :( CÃ©drick

July 20, 2008

Re: [Pharo-project] about ensuring file closing

by Bill Schwab

Stef, That sounds fine, but I would want Damien to be involved. I would also like to discuss the pros and cons of a facade such as ReadStream class>>on:aCollection ^aCollection readStream. which I _think_ can be readily adapted to instantiate Nile streams. There would be a similar trick for write streams. My thought was to patch things until streams came up on the milestones list. If you are finding streams are worse off than you thought and want to move it up, that's fine too. I'm happy to help. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 07/20/08 11:36 AM >>> On Jul 19, 2008, at 4:18 PM, Bill Schwab wrote: > Stef, > > The streams are a mess, and the more I work with them, the more I > understand the desire to replace them with Nile. For now, I am simply > inserting some methods that behave well (work when they should, raise > errors when they should) to allow me to begin doing some real work. So if you can I would suggest you to use Nile and to enhance it. We should not try to fix too much Stream. > My view is that I can always add helper classes and methods as needed. > Whether that gets around fragile design (#nextOne) or is a one-place > fix > for the myriad times I open a file, it can always be rewritten to work > with whatever we create. > > URIs make sense. I have never been happy with the ways I split and > combine paths, so those things will have to be rewritten, especially > since they are Windows-specific. Mike showed me the network cleaning he did. But we got problem to export and load it again (since the system needed itsefl to load it). Hence my remark on atomic loading. Stef > > > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 07/19/08 5:49 AM >>> > > On Jul 18, 2008, at 5:01 PM, Bill Schwab wrote: > >> Stef, >> >> I do not doubt that the image is littered with such problems. On >> several occasions, I lost 10-15 minutes tracking down errors that >> resulted from unopened files. It is all a continuation of my streams >> "rant" (a well-intentioned one, of course). >> >> Meaning no disrespect to the milestones (in particular, streams being >> slated for the future), I have undertaken an effort similar to what >> you >> propose: putting an end to silent failures and lack of protection. >> As a >> streams addict, I need stable semantics, and have thus embarked on my >> #nextOne, #nextMany:, etc. solution to reaching that goal. It also >> became clear that FileStream was quite unfriendly, so I started >> adding >> Dolphin-compatible methods, at least to a point. My primary goal is >> to >> have errors arise when appropriate vs. waiting for >> potentially/apparently disconnected collateral damage to occur. > > I have the impression that FileStream should be patched but also > just rewritten from scratch. I was discussing with mike about the > use of > URI in sophie. He told me that they got a really nice solution which > was offering > cross platform real portability >> >> Dolphin's semantics will not be completely appropriate for Squeak, >> because there are OS (in)dependencies to consider. I want that to >> work >> well so I can treat my Redmond allergy. >> >> I urge Smalltalkers to avoid #next and #next: like the plague, but >> one >> could always use my changes and ignore the replacements. A very >> incomplete but gradually evolving change set is available on request. > > ok good to know. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 20, 2008

Re: [Pharo-project] Improving the GUI

by cdrick

> Better menus > ------------------------------- > Current problems: > - bad organization menus only work when you have learned where > something is located > - duplicated entries e.g., Appearance is both in the top level world menu > and in the submenu Help > - useless entries e.g., set font, set style etc. in the > context menu are useless since code is never styled > - defective entries: e.g., "Make project link" in the context menu does > not work Would it be possible to have accordion effects? > > Larger windows > ------------------------------- > The default size of windows is usually too small. Often, after opening a > window I have to resize it. For example the hierarchy browser shows only the > 5 first classes. I always open them fullscreen. I think that would be a better default... I struggled but couldn't achieve that :( CÃ©drick

July 20, 2008

Re: [Pharo-project] Improving the GUI

by StÃ©phane Ducasse

Someone told me (damien probably) that nicefont was touching a lot of place in the system. Ideally I would like to avoid to depend on a pluggin for things as essential as font rendering (at least in a basic image). Did somebody check a bit the code of niceFont? Stef On Jul 20, 2008, at 11:51 AM, Norbert Hartl wrote: > +1 Very good point. I agree on all of them. > > Is it possible to choose any ttf font and make a NiceFont out > of it? I don't know the real name but the package on universe > is called this way. > > Or do you think we should make the trutetype plugin mandatory? > > Norbert > > On Sun, 2008-07-20 at 11:22 +0200, Adrian Lienhard wrote: >> Hi, >> >> I'd like to get your opinion about how we could improve the GUI. I >> believe that even a few small changes will make a significant >> difference, especially for new people that come to Pharo. Just the >> cleaned up world menu is such a relief... >> >> Here a three suggestions: >> >> Better fonts >> ---------------- >> I think the current code font is not a good one and it is too small >> (for today's screen resolutions). I like for example the font used in >> TextMate, which is Monaco 12, a monotype font. The page http://www.lowing.org/fonts/ >> gives some samples for good code fonts. I've tried out the other >> fonts in the Pharo image like the BitstreamVeraSansMono but they are >> all very blurry. Just not good enough. I'm not a font expert, so I >> don't know what the options for a better font are. >> >> Better menus >> ------------------------------- >> Current problems: >> - bad organization menus only work when you have learned where >> something is located >> - duplicated entries e.g., Appearance is both in the top level world >> menu and in the submenu Help >> - useless entries e.g., set font, set style etc. in the context menu >> are useless since code is never styled >> - defective entries: e.g., "Make project link" in the context menu >> does not work >> >> Larger windows >> ------------------------------- >> The default size of windows is usually too small. Often, after >> opening >> a window I have to resize it. For example the hierarchy browser shows >> only the 5 first classes. >> >> >> Any other ideas what could be improved in the short term? I'm looking >> for stuff that we can do now without having to rewrite the whole >> system... >> >> Cheers, >> Adrian >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 20, 2008

Re: [Pharo-project] Improving the GUI

by StÃ©phane Ducasse

Yes I like these ideas. This is what I started to do with the menu world cleaning. This is important that we continue. Bigger windows. Yes! Stef On Jul 20, 2008, at 11:22 AM, Adrian Lienhard wrote: > Hi, > > I'd like to get your opinion about how we could improve the GUI. I > believe that even a few small changes will make a significant > difference, especially for new people that come to Pharo. Just the > cleaned up world menu is such a relief... > > Here a three suggestions: > > Better fonts > ---------------- > I think the current code font is not a good one and it is too small > (for today's screen resolutions). I like for example the font used > in TextMate, which is Monaco 12, a monotype font. The page http://www.lowing.org/fonts/ > gives some samples for good code fonts. I've tried out the other > fonts in the Pharo image like the BitstreamVeraSansMono but they are > all very blurry. Just not good enough. I'm not a font expert, so I > don't know what the options for a better font are. > > Better menus > ------------------------------- > Current problems: > - bad organization menus only work when you have learned where > something is located > - duplicated entries e.g., Appearance is both in the top level world > menu and in the submenu Help > - useless entries e.g., set font, set style etc. in the context > menu are useless since code is never styled > - defective entries: e.g., "Make project link" in the context menu > does not work > > Larger windows > ------------------------------- > The default size of windows is usually too small. Often, after > opening a window I have to resize it. For example the hierarchy > browser shows only the 5 first classes. > > > Any other ideas what could be improved in the short term? I'm > looking for stuff that we can do now without having to rewrite the > whole system... > > Cheers, > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 20, 2008

Re: [Pharo-project] about ensuring file closing

by StÃ©phane Ducasse

On Jul 19, 2008, at 4:18 PM, Bill Schwab wrote: > Stef, > > The streams are a mess, and the more I work with them, the more I > understand the desire to replace them with Nile. For now, I am simply > inserting some methods that behave well (work when they should, raise > errors when they should) to allow me to begin doing some real work. So if you can I would suggest you to use Nile and to enhance it. We should not try to fix too much Stream. > My view is that I can always add helper classes and methods as needed. > Whether that gets around fragile design (#nextOne) or is a one-place > fix > for the myriad times I open a file, it can always be rewritten to work > with whatever we create. > > URIs make sense. I have never been happy with the ways I split and > combine paths, so those things will have to be rewritten, especially > since they are Windows-specific. Mike showed me the network cleaning he did. But we got problem to export and load it again (since the system needed itsefl to load it). Hence my remark on atomic loading. Stef > > > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 07/19/08 5:49 AM >>> > > On Jul 18, 2008, at 5:01 PM, Bill Schwab wrote: > >> Stef, >> >> I do not doubt that the image is littered with such problems. On >> several occasions, I lost 10-15 minutes tracking down errors that >> resulted from unopened files. It is all a continuation of my streams >> "rant" (a well-intentioned one, of course). >> >> Meaning no disrespect to the milestones (in particular, streams being >> slated for the future), I have undertaken an effort similar to what >> you >> propose: putting an end to silent failures and lack of protection. >> As a >> streams addict, I need stable semantics, and have thus embarked on my >> #nextOne, #nextMany:, etc. solution to reaching that goal. It also >> became clear that FileStream was quite unfriendly, so I started >> adding >> Dolphin-compatible methods, at least to a point. My primary goal is >> to >> have errors arise when appropriate vs. waiting for >> potentially/apparently disconnected collateral damage to occur. > > I have the impression that FileStream should be patched but also > just rewritten from scratch. I was discussing with mike about the > use of > URI in sophie. He told me that they got a really nice solution which > was offering > cross platform real portability >> >> Dolphin's semantics will not be completely appropriate for Squeak, >> because there are OS (in)dependencies to consider. I want that to >> work >> well so I can treat my Redmond allergy. >> >> I urge Smalltalkers to avoid #next and #next: like the plague, but >> one >> could always use my changes and ignore the replacements. A very >> incomplete but gradually evolving change set is available on request. > > ok good to know. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 20, 2008

Re: [Pharo-project] Improving the GUI

by Bill Schwab

Agreed. As an example, I would like to see the browse-it command grouped with do/inspect/explore. It also is not quite as flexible as Dolphin's verion - it should first evaluate the selected expression or current line and the browse the instance class of the result. I am a bit strange on fonts. For programming, I like them mono-spaced and a bit small. No guessing between letters and numbers, punctuation does not get kerned out of existence, etc. With those improvements, I can tolerate a slightly smaller font size than with kerned fonts. Regardless, options are good, especially when they are easy to change to one's personal preference. I would like to see better control over background colors. Editing a couple of methods makes me fairly happy with the results, but it should be preference based. I am happy to use code to set things, as that allows me to build a script to get what I want. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> adi(a)netstyle.ch 07/20/08 5:22 AM >>> Hi, I'd like to get your opinion about how we could improve the GUI. I believe that even a few small changes will make a significant difference, especially for new people that come to Pharo. Just the cleaned up world menu is such a relief... Here a three suggestions: Better fonts ---------------- I think the current code font is not a good one and it is too small (for today's screen resolutions). I like for example the font used in TextMate, which is Monaco 12, a monotype font. The page http://www.lowing.org/fonts/ gives some samples for good code fonts. I've tried out the other fonts in the Pharo image like the BitstreamVeraSansMono but they are all very blurry. Just not good enough. I'm not a font expert, so I don't know what the options for a better font are. Better menus ------------------------------- Current problems: - bad organization menus only work when you have learned where something is located - duplicated entries e.g., Appearance is both in the top level world menu and in the submenu Help - useless entries e.g., set font, set style etc. in the context menu are useless since code is never styled - defective entries: e.g., "Make project link" in the context menu does not work Larger windows ------------------------------- The default size of windows is usually too small. Often, after opening a window I have to resize it. For example the hierarchy browser shows only the 5 first classes. Any other ideas what could be improved in the short term? I'm looking for stuff that we can do now without having to rewrite the whole system... Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 20, 2008

Re: [Pharo-project] Improving the GUI

by David Mitchell

Be careful on licensing when creating bitmaps (StrikeFonts) or fonts and then redistributing. One nice thing about the Vera fonts is that they are open source. Many countries have weird rules about fonts. On Sun, Jul 20, 2008 at 4:51 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > +1 Very good point. I agree on all of them. > > Is it possible to choose any ttf font and make a NiceFont out > of it? I don't know the real name but the package on universe > is called this way. > > Or do you think we should make the trutetype plugin mandatory? > > Norbert > > On Sun, 2008-07-20 at 11:22 +0200, Adrian Lienhard wrote: >> Hi, >> >> I'd like to get your opinion about how we could improve the GUI. I >> believe that even a few small changes will make a significant >> difference, especially for new people that come to Pharo. Just the >> cleaned up world menu is such a relief... >> >> Here a three suggestions: >> >> Better fonts >> ---------------- >> I think the current code font is not a good one and it is too small >> (for today's screen resolutions). I like for example the font used in >> TextMate, which is Monaco 12, a monotype font. The page http://www.lowing.org/fonts/ >> gives some samples for good code fonts. I've tried out the other >> fonts in the Pharo image like the BitstreamVeraSansMono but they are >> all very blurry. Just not good enough. I'm not a font expert, so I >> don't know what the options for a better font are. >> >> Better menus >> ------------------------------- >> Current problems: >> - bad organization menus only work when you have learned where >> something is located >> - duplicated entries e.g., Appearance is both in the top level world >> menu and in the submenu Help >> - useless entries e.g., set font, set style etc. in the context menu >> are useless since code is never styled >> - defective entries: e.g., "Make project link" in the context menu >> does not work >> >> Larger windows >> ------------------------------- >> The default size of windows is usually too small. Often, after opening >> a window I have to resize it. For example the hierarchy browser shows >> only the 5 first classes. >> >> >> Any other ideas what could be improved in the short term? I'm looking >> for stuff that we can do now without having to rewrite the whole >> system... >> >> Cheers, >> Adrian >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 20, 2008