[Pharo-project] On Icons
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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
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
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
On 9/23/08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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.
I agree, that's nice to see. However now the plus hides information that is totally orthogonal to package extensions (inheritance).
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.
Yeah, we probably never agree. We need different modes for forward and backward engineering ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
- 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. ;)
I think that would already be better, because then the fact that there is also a sub implementation is not hidden.
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.
But it hides information that is totally orthogonal to packaging. I don't think these things should be mixed.
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.
Ok, I didn't know that. Thanks.
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.
No, this is something else. Classes have icons according to their kind, so that I immediately see what the class is all about. For example: collections, exceptions, magnitudes, seaside components, morphs, etc. should have distinct icons. That's information that is sometimes not easily visible without clicking around. Furthermore it is important that the kind is the only icon displayed with classes, it looses its focus when other things (class comment, lint erros, ...) are displayed at the same place. So to summarize I would like to see clear responsibilities for icons and labels for classes and methods: Class Icon: Kind Class Label: Package (extensions in italic) Method Icon: Sub, super implementation (if necessary maybe the super could have a stronger color if super is called); maybe show halts with a red flag because this is something that should catch attention over everything else Method Label: Package (in italic if it is not in the same package as the class, in red if it is an override) I think that would make more sense and would be understandable without having to explain much. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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.
I like clear responsibilities. If one column of icons would show inheritance related things, and the other packaging related things that would be already much better. The question is if really both are necessary. What I don't like if different things are mixed and have priorities over each other that are not really clear. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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
So we need an icon with a (green) up arrow (for super send) and a (yellow) triangle pointing down (for overriddes). Who could draw something 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.
I disagree there. Browse stream and collection.
I meant that the icon should show whether the abstract method is overridden or not. What about keeping the cyan icon for abstract methods, but as a triangle pointing south when the method is overridden and as a square when it's not? David
David I would love to know when browsing a class if the method comes from a trait :)
Right now you get these methods in italic (Juraj did it like that). If we change methods to be in italic when they are extension methods, then we get a conflict here. We could add an icon to denote trait methods. Would make sense to have icons for content or structure related stuff and different labels (italic, red, etc.) for package/extension related things. David
I didn't read the discussion fully, but here my 2 cents: it would be good to show methods which have no senders with special icon. Sometimes, when you designing a class, and hacking code to eventually improve its beauty and readiness, you can forget some methods left which never used anymore. I know, determining all senders could be a slow operation (especially when you need to scan a list of them), but maybe there can be used some kind of optimizations like lazy/background evaluation? 2008/9/23 David Röthlisberger <squeak@webcitas.ch>:
David I would love to know when browsing a class if the method comes from a trait :)
Right now you get these methods in italic (Juraj did it like that). If we change methods to be in italic when they are extension methods, then we get a conflict here. We could add an icon to denote trait methods. Would make sense to have icons for content or structure related stuff and different labels (italic, red, etc.) for package/extension related things.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
So to summarize I would like to see clear responsibilities for icons and labels for classes and methods:
Class Icon: Kind
Class Label: Package (extensions in italic)
Method Icon: Sub, super implementation (if necessary maybe the super could have a stronger color if super is called); maybe show halts with a red flag because this is something that should catch attention over everything else
Method Label: Package (in italic if it is not in the same package as the class, in red if it is an override)
I think that would make more sense and would be understandable without having to explain much.
Yes thie is good to have both label and iconic convention. Stef
yes priority is not good because it changes depending on the mixture. I think that we should experiment and build a conceptual model. Stef On Sep 23, 2008, at 11:10 AM, Lukas Renggli wrote:
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.
I like clear responsibilities. If one column of icons would show inheritance related things, and the other packaging related things that would be already much better. The question is if really both are necessary. What I don't like if different things are mixed and have priorities over each other that are not really clear.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
So we need an icon with a (green) up arrow (for super send) and a (yellow) triangle pointing down (for overriddes). Who could draw something like that? ;))
I can :) I will try. now I think that you should try also with inkscape. The icons do not have to look good for now. We should get them right. After somebody with talent can relook them.
- 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.
I meant that the icon should show whether the abstract method is overridden or not. What about keeping the cyan icon for abstract methods, but as a triangle pointing south when the method is overridden and as a square when it's not?
or nothing when it is not? Try to come up with a nice model. Then after we should see how we can sell it also as a paper.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 23, 2008, at 11:27 AM, David Röthlisberger wrote:
David I would love to know when browsing a class if the method comes from a trait :)
Right now you get these methods in italic (Juraj did it like that). If we change methods to be in italic when they are extension methods, then we get a conflict here.
Do you have the tree structure now?
We could add an icon to denote trait methods.
Would make sense to have icons for content or structure related stuff and different labels (italic, red, etc.) for package/extension related things.
Probably. Or we should have a set of icon that can be compose. Stef
So we need an icon with a (green) up arrow (for super send) and a (yellow) triangle pointing down (for overriddes). Who could draw something like that? ;))
I can :) I will try.
Great!
- 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.
I meant that the icon should show whether the abstract method is overridden or not. What about keeping the cyan icon for abstract methods, but as a triangle pointing south when the method is overridden and as a square when it's not? or nothing when it is not?
no, the case when it's not overridden is quite interesting as this might be a hint for a problem (not needed abstract method or missing override, etc.)
Try to come up with a nice model. Then after we should see how we can sell it also as a paper.
ok, alright. David
Right now you get these methods in italic (Juraj did it like that). If we change methods to be in italic when they are extension methods, then we get a conflict here. Do you have the tree structure now?
yes, I committed a working version just yesterday, but want to test it a bit more today. I will probably announce it later today. David
- 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.
I meant that the icon should show whether the abstract method is overridden or not. What about keeping the cyan icon for abstract methods, but as a triangle pointing south when the method is overridden and as a square when it's not? or nothing when it is not?
no, the case when it's not overridden is quite interesting as this might be a hint for a problem (not needed abstract method or missing override, etc.)
I meant that a cyan triangle alone should reveal that.
Try to come up with a nice model. Then after we should see how we can sell it also as a paper.
ok, alright.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
excellent! On Sep 23, 2008, at 2:44 PM, David Röthlisberger wrote:
Right now you get these methods in italic (Juraj did it like that). If we change methods to be in italic when they are extension methods, then we get a conflict here. Do you have the tree structure now?
yes, I committed a working version just yesterday, but want to test it a bit more today. I will probably announce it later today.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What about using the left *and* also the right side of the method list to show icons... If we could use the right side for "optionnal" icons, that would be still readable and we could have more icons. Just a thought. Cédrick
What about using the left *and* also the right side of the method list to show icons...
If we could use the right side for "optionnal" icons, that would be still readable and we could have more icons.
yes, but it gets very confusing when you have icons on the left and on the right. And when you only have icons on the right, then they are not getting the same attention as when they are on the left. It also depends whether you place the icons always directly after the method label, or in one vertical column whose position is decided by the longest method label in the list. The latter looks nicer, but has the problem that you don't see the icons when you have just one single very long method name in your list that takes more space than the column is width (which happens many times when browsing all methods of a class in my image). You then have to make your browser window bigger which is cumbersome. So I don't know whether this is a good solution. Icons should be easy to grasp visually and normally, as we read from left to right, this is achieved when they are on the left side. David
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
ok. You can now (as of OB-Enhancements-dr.211) implement a method #browserIcon on the class-side of any class you want and let this method return a symbol of the desired icon. This setting has the highest priority. example: OBNode class >> browserIcon ^#needsWork Cheers, David
Hi Igor,
I know, determining all senders could be a slow operation (especially when you need to scan a list of them), but maybe there can be used some kind of optimizations like lazy/background evaluation?
I like this idea, but indeed, performance is a big issue here. I haven't found a solution yet to make this efficient enough. Lazy/background evaluation would require us to store this information directly in the compiled method object, something that I would rather not like to do. In particular updating the information when suddendly a method gets or loses its sender(s) might get difficult. David
2008/9/25 David Röthlisberger <squeak@webcitas.ch>:
Hi Igor,
I know, determining all senders could be a slow operation (especially when you need to scan a list of them), but maybe there can be used some kind of optimizations like lazy/background evaluation?
I like this idea, but indeed, performance is a big issue here. I haven't found a solution yet to make this efficient enough. Lazy/background evaluation would require us to store this information directly in the compiled method object, something that I would rather not like to do. In particular updating the information when suddendly a method gets or loses its sender(s) might get difficult.
Not necessary in methods. OB can hold a set of selectors which have no senders and update it periodically (when system changed).
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Tue, Sep 23, 2008 at 10:54:08AM +0200, Lukas Renggli wrote:
On 9/23/08, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
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.
I agree, that's nice to see. However now the plus hides information that is totally orthogonal to package extensions (inheritance).
Perhaps OB could use composable icons, like MS Windows does with shortcuts: A little arrow icon representing "shortcut" superimposed on a big icon representing "content type" Many IDE's use an icon for every method or class. I think I don't like that, though. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
participants (6)
-
Cédrick Béler -
David Röthlisberger -
Igor Stasenko -
Lukas Renggli -
Matthew Fulmer -
Stéphane Ducasse