- Pharo-dev - lists.pharo.org

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

On Sep 23, 2008, at 10:26 AM, David RÃ¶thlisberger wrote: > Hi Lukas, > >> - I don't want to see part of the "contents" of a method as an icon. >> The super-icon is useless, it only hides valuable information (for >> example that there is a sub-implementation). > > What if we show the super icon only if there's no sub-implementation > and otherwise the sub-implementation icon? no this is terrible because we cannot rely on the consistency of the information > Or one containing both information, but I guess you won't like > that. ;) I think that this is what we should have >> - The same is for abstract method icon. When browsing the >> protocol/interface I don't need to know that. I am more interested if >> any of the subclasses override it. > > ok, I agree here. I disagree there. Browse stream and collection. >> - The same for extension methods. I see that, because it is in a >> different protocol and because its name is in italic (the same as >> with >> the extension classes). I don't need yet another icon. > > The name of an extension method is normally not in italic, only if > you are browsing it directly in the package, and then only if it's > an extension of this package. > Furthermore, you don't see to which protocol a method belongs when > browsing all methods of a class (I do that often...). Hence this > icon quickly provides important information that you otherwise have > to access with several clicks. I agree. The icon is ugly but it is important (see other mail) > And even worse, at least me I often forget to check whether a method > is implemented as an extension and tend to assume that it's a > standard method of this class, so I might use it as such, but then > other people might not have this extension loaded. With this > extension icon, this doesn't happen to me anymore. > >> This would greatly improve the interface. The browser starts to be >> really messy. > > I personally don't agree with this as I can't see why this icons > should hurt any developer, in particular as you now also get an > explanation label when placing the mouse over it, so everybody > should be able to quickly understand the meaning of each icon. Of > course, not everybody needs all of those icons, but why should their > presence make the browser messy? > With a little bit of "fine-tuning" (referring to your first two > points), the "mess" should be addressed well. > > >> Furthermore I would like to define my own icons for classes, for >> example Seaside component should have its own icon. So instead of >> hardcoding this into OB itself why not asking the class for an icon, >> as this is done in VW for example. > > Isn't that wish somehow contradictory to what you said above? I > guess I can also see with one or two clicks whether a class is a > Seaside component or not... > But otherwise I agree, I will impl. means to let the entities decide > on the icon they will get. Yes this is important that the class get its word

Sept. 23, 2008

Re: [Pharo-project] Re: Re: Re: [ANN] Demo with both Truetype +Polymorph

by Norbert Hartl

On Tue, 2008-09-23 at 10:01 +0200, Marcus Denker wrote: > On 23.09.2008, at 09:09, Andrew Tween wrote: > > > Note that with a one-click app distribution, it isn't necessary to > > embed the fonts in the image. > > FreeType Plus looks for a folder named Fonts relative to the .image > > file, and loads any fonts it finds from there. > > > > Putting the font file(s) into the Fonts folder has these advantages... > > > > 1.The image isn't bloated. (embedding a 20Mb font file would grow > > the image by 20Mb) > > So, the default font could be a large Unicode one, for example > > > > 2.Easier to create a one-click app for distribution. > > > > 3.Easier to install the font files into the OS so that other > > applications can also use them. > > > > 4. Free fonts that don't allow embedding can be used (e.g. > > Bitstream). This widens the choice of available free fonts. > > > > The advantage to embedding the font file in the image is that it > > moves around with the .image file. > > Which for a one-click app isn't really an advantage at all :) > > Cool! > > We should actually think about moving more data into files... for > example, there are huge literal arrays > in UCSTable's class side initialize methods that are only there for > initializing the class a long time ago. > These would not even be needed to be read on startup. > > Of course, this is violently against the "everything in the image" > philosophy of Squeak... but I guess > that any device one would want to run it on would have a filesystem of > some sort. > Or there could be a call that reads it in and keeps it in the image. Easy for people they want to have it in their image. Norbert

Sept. 23, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

> > > I am horrified with all these colored icons on methods. That's worse > > > > > than in the old browser with the button that had 8 different colors > > depending on the state of the method. > > > > Uh? > Lukas I think that david is spending a lot of time on improving the browser > so I would suggest you to be less aggressive and more bringing suggestions. I am sorry, I did not intend to be aggressive. I tried to give a list of suggestions to improve and simplify the interface. I am only talking about my personal experience using the browser enhancements and how I am confused with all the method icons. The icons are not intuitive and their priority is unclear. I need to keep the wiki open to understand them. > > - I don't want to see part of the "contents" of a method as an icon. > > The super-icon is useless, it only hides valuable information (for > > example that there is a sub-implementation). If I want to know if a > > method calls super (and when) I need to look at the method anyway. > > No I'm sorry but I disagree. > Knowing that there is a supercall is as important as knowing that the > method > is specialized. I think it is misleading. There are methods that only call super under certain conditions or even call different super methods. This might lead to wrong assumptions. > Look at LimitedWriteStream you get instantanly the fact that the three > methods are doing a super send! > and this is really important to know. Again, I think it is most important to see at one glance if there are super and sub implementations. This is the only thing I can't find out with a single click and without loosing the context. In the current implementation this information is sometimes hidden. > > - The same is for abstract method icon. When browsing the > > protocol/interface I don't need to know that. I am more interested if > > any of the subclasses override it. > > No this is your point of view on that. But knowing that a method is > abstract > is useful too Maybe, but it should not hide more important information. > > - The same for extension methods. I see that, because it is in a > > different protocol and because its name is in italic (the same as with > > the extension classes). I don't need yet another icon. > > It depends on which browser you are. Reinforcing the information is often > good. What I am criticizing here is that information is duplicated (icon and category) and not consistently displayed (classes with extension methods are italic, methods have a special icon). > > The only valuable thing for me as a developer is to know if there is a > > super/sub implementation of a method. And maybe if there are halts > > inside. > > Sorry but knowing that there are self flag and halt is extremely valuable. I agree. > But we do not want that click. > I do not know to click on all the method of my class to see if they all do > a supercall. Then we should move to files where we see all the source at one glance ;-) An icon can only tell yes or no. In most cases (such as with super calls) the situation is more complicated. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 23, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

Hi Stef, > So may be we should have combination of the information. > => > this method is abstract and there are specialisation: > normally this should be quite rare that the method is not > overridden. yes. In that case maybe only showing the abstract icon when there's not specialization yet? > So conclusion having both information would be good. > May be we should get two icons because screen space is cheap. well, not too cheap... Having two icons might make matters even worse, at least for Lukas, right? ;) I would rather go for one icon containing both information, like the one for overridding methods that also override superclass methods. > David I found that > > add: newObject > self shouldNotImplement > > > is displayed in cyan as abstract but this is not the same. hm, CompiledMethod >> isAbstract is wrong then... CompiledMethod class >> abstractMarkers also contains #shouldNotImplement, that's why this happens. I will use my own method to check for abstract methods then. Cheers, David

Sept. 23, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

Hi Lukas, > - I don't want to see part of the "contents" of a method as an icon. > The super-icon is useless, it only hides valuable information (for > example that there is a sub-implementation). What if we show the super icon only if there's no sub-implementation and otherwise the sub-implementation icon? Or one containing both information, but I guess you won't like that. ;) > - The same is for abstract method icon. When browsing the > protocol/interface I don't need to know that. I am more interested if > any of the subclasses override it. ok, I agree here. > - The same for extension methods. I see that, because it is in a > different protocol and because its name is in italic (the same as with > the extension classes). I don't need yet another icon. The name of an extension method is normally not in italic, only if you are browsing it directly in the package, and then only if it's an extension of this package. Furthermore, you don't see to which protocol a method belongs when browsing all methods of a class (I do that often...). Hence this icon quickly provides important information that you otherwise have to access with several clicks. And even worse, at least me I often forget to check whether a method is implemented as an extension and tend to assume that it's a standard method of this class, so I might use it as such, but then other people might not have this extension loaded. With this extension icon, this doesn't happen to me anymore. > This would greatly improve the interface. The browser starts to be > really messy. I personally don't agree with this as I can't see why this icons should hurt any developer, in particular as you now also get an explanation label when placing the mouse over it, so everybody should be able to quickly understand the meaning of each icon. Of course, not everybody needs all of those icons, but why should their presence make the browser messy? With a little bit of "fine-tuning" (referring to your first two points), the "mess" should be addressed well. > Furthermore I would like to define my own icons for classes, for > example Seaside component should have its own icon. So instead of > hardcoding this into OB itself why not asking the class for an icon, > as this is done in VW for example. Isn't that wish somehow contradictory to what you said above? I guess I can also see with one or two clicks whether a class is a Seaside component or not... But otherwise I agree, I will impl. means to let the entities decide on the icon they will get. Cheers, David

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

Lukas another example: Here I was browsing some methods and suddenly there is cross: I said oops this method is an extension. And I did not have to click on *packageinfo-base because in the flow of my reading I was not looking for extensions per se. So I believe that if we carefully design icons there are much more important that you think. Note that I'm browsing code that is not mine and this makes a huge difference. On my code I know it most of the time. Stef

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

David I would love to know when browsing a class if the method comes from a trait :) Stef On Sep 23, 2008, at 9:04 AM, Lukas Renggli wrote: >> OB-Enhancements version 0.203 > > I am horrified with all these colored icons on methods. That's worse > than in the old browser with the button that had 8 different colors > depending on the state of the method. > > - I don't want to see part of the "contents" of a method as an icon. > The super-icon is useless, it only hides valuable information (for > example that there is a sub-implementation). If I want to know if a > method calls super (and when) I need to look at the method anyway. > > - The same is for abstract method icon. When browsing the > protocol/interface I don't need to know that. I am more interested if > any of the subclasses override it. > > - The same for extension methods. I see that, because it is in a > different protocol and because its name is in italic (the same as with > the extension classes). I don't need yet another icon. > > The only valuable thing for me as a developer is to know if there is a > super/sub implementation of a method. And maybe if there are halts > inside. The rest I can find out with one click or less, if necessary. > This would greatly improve the interface. The browser starts to be > really messy. > > Furthermore I would like to define my own icons for classes, for > example Seaside component should have its own icon. So instead of > hardcoding this into OB itself why not asking the class for an icon, > as this is done in VW for example. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

Hi lukas >> I am horrified with all these colored icons on methods. That's worse > than in the old browser with the button that had 8 different colors > depending on the state of the method. Uh? Lukas I think that david is spending a lot of time on improving the browser so I would suggest you to be less aggressive and more bringing suggestions. Having good icons is important. I go much faster with icons than without. May be we should build a study on that and evaluate what is good. > - I don't want to see part of the "contents" of a method as an icon. > The super-icon is useless, it only hides valuable information (for > example that there is a sub-implementation). If I want to know if a > method calls super (and when) I need to look at the method anyway. No I'm sorry but I disagree. Knowing that there is a supercall is as important as knowing that the method is specialized. Look at LimitedWriteStream you get instantanly the fact that the three methods are doing a super send! and this is really important to know. > - The same is for abstract method icon. When browsing the > protocol/interface I don't need to know that. I am more interested if > any of the subclasses override it. No this is your point of view on that. But knowing that a method is abstract is useful too So may be we should have combination of the information. => this method is abstract and there are specialisation: normally this should be quite rare that the method is not overridden. one icon for method doing a super-send and been specialized we can have the shape for one dimension and the color for the other one. I browsed contents on WriteStream and I would like to know whether there is a supercall. For me this is much more important than to know that there is a specialization because as you say I can know if I click on the subclasses. But to show you that when I use your argument I'm also wrong :) if you look at RWBinaryOrTextStream with the package view and not the inheritance hiearchy then you could say ok I just have to clik on the subclasses but you do know that there is one. So knowing that padToEndWith: is actually define in a subclass is a good information. As the supercall and abstract is. So conclusion having both information would be good. May be we should get two icons because screen space is cheap. > - The same for extension methods. I see that, because it is in a > different protocol and because its name is in italic (the same as with > the extension classes). I don't need yet another icon. It depends on which browser you are. Reinforcing the information is often good. > The only valuable thing for me as a developer is to know if there is a > super/sub implementation of a method. And maybe if there are halts > inside. Sorry but knowing that there are self flag and halt is extremely valuable. > The rest I can find out with one click or less, if necessary. But we do not want that click. I do not know to click on all the method of my class to see if they all do a supercall. > This would greatly improve the interface. The browser starts to be > really messy. > > Furthermore I would like to define my own icons for classes, for > example Seaside component should have its own icon. So instead of > hardcoding this into OB itself why not asking the class for an icon, > as this is done in VW for example. Yes this is a good suggestion! I would like to know the method performing exception handling. David I found that add: newObject self shouldNotImplement is displayed in cyan as abstract but this is not the same. Stef > > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2008

Re: [Pharo-project] Re: Re: Re: [ANN] Demo with both Truetype +Polymorph

by Marcus Denker

On 23.09.2008, at 09:09, Andrew Tween wrote: > Note that with a one-click app distribution, it isn't necessary to > embed the fonts in the image. > FreeType Plus looks for a folder named Fonts relative to the .image > file, and loads any fonts it finds from there. > > Putting the font file(s) into the Fonts folder has these advantages... > > 1.The image isn't bloated. (embedding a 20Mb font file would grow > the image by 20Mb) > So, the default font could be a large Unicode one, for example > > 2.Easier to create a one-click app for distribution. > > 3.Easier to install the font files into the OS so that other > applications can also use them. > > 4. Free fonts that don't allow embedding can be used (e.g. > Bitstream). This widens the choice of available free fonts. > > The advantage to embedding the font file in the image is that it > moves around with the .image file. > Which for a one-click app isn't really an advantage at all :) Cool! We should actually think about moving more data into files... for example, there are huge literal arrays in UCSTable's class side initialize methods that are only there for initializing the class a long time ago. These would not even be needed to be read on startup. Of course, this is violently against the "everything in the image" philosophy of Squeak... but I guess that any device one would want to run it on would have a filesystem of some sort. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 23, 2008

Re: [Pharo-project] Cannot load PolyMorph/UIEnhancements

by Marcus Denker

On 23.09.2008, at 09:49, Norbert Hartl wrote: > I tried to load the Polymorph package in a fresh pharo image > and I didn't succeed. I tried pharo 10044, 10070 and 10074 > image. And I tried loading from universes as well as via > monticello. The result is the same: When the Loading progress > bar appears it freezes after 10% of the bar is full. It > doesn't matter if I load it with 64bit or 32bit (binary) > vm. You need to uncomment so mc does not show a progress bar: Having trouble loading? Since the ui enhancements modify many existing methods, and the fact that Monticello doesn't do atomic loading, it is best to close any windows you can and make the remainder clear of the central area where the progress indicator appears. For guaranteed (as much as it can be) load you'll need to modify the MCPackageLoader>>basicLoad method, 3rd line, to read [[additions do: [:ea | self tryToLoad: ea]. instead of [[additions do: [:ea | self tryToLoad: ea] displayingProgress: 'Loading...'. http://wiki.squeak.org/squeak/6005 (this is again a problem of atomic loading: it changes the code of the progress bar while the bar is executing) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 23, 2008