Re: [Pharo-project] OB annotation icons
"Icons that show different concepts (and calling super and overriding a method are entirely different concepts, as well as putting a breakpoint or deprecating a method) and that hide each other are evil."
Absolutely agree, hence that design. And in any case calling super is a stupid indicator, especially when you know that it doesn't check that the super call is a) to the same method or b) on every call path. The indicator actually means 'might call some method declared in a superclass', which of course you can easily do by calling a method that isn't overridden in the declaring class, so what the hell use is that?
Thank you for expressing it that clearly ;-)
OB is a good prototype, although IMO
I disagree. I exclusively use OB in productive development on a daily bases for over 2 years now.
b) shouldn't include any action abstraction because that's best handled in a completely different and system-wide fashion;
I disagree. OB provides this system-wide abstraction. It is the fault of the other tools that don't use these abstractions. For example, I've written a process browser, debugger, inspector and several other tools in OB and they all benefit from the commands that already exist and that other people write as extensions (e.g. open a hierarchy browser from within the debugger). I agree that the abstraction is not optimal in all cases (e.g. text commands, applicability tests, ...), but it is definitely better than anything else I've seen so far.
different and system-wide fashion; c) is too messily tied to Morphic, with a number of hacks; and relatedly, d) shouldn't extend existing Morphic controls (such as lists) because they come with too much baggage (i.e. being all things to all people).
Earlier versions of OB were entirely separated from Morphic. Unfortunately it was tied to morphic over time as more and more people joined the development. I guess this happend due to laziness and lack of documentation and knowledge. Along the same lines: Every line of the model and view used to be tested with in-depth SUnit-Tests. Unfortunately that is not the case anymore either. People add features without writing tests. This is what happens, when an appealing and widely adapted projects entirely lacks a form of leadership. At some point there was an AJAX based web view and a XUL interface. I think somebody even made GTK view. Earlier versions of OB run in GemStone, with the view running in Squeak Morphic. There is an ongoing port for GST. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Oct 22, 2008, at 4:36 PM, Lukas Renggli wrote:
"Icons that show different concepts (and calling super and overriding a method are entirely different concepts, as well as putting a breakpoint or deprecating a method) and that hide each other are evil."
Absolutely agree, hence that design. And in any case calling super is a stupid indicator, especially when you know that it doesn't check that the super call is a) to the same method or b) on every call path. The indicator actually means 'might call some method declared in a superclass', which of course you can easily do by calling a method that isn't overridden in the declaring class, so what the hell use is that?
would be nice to know do whom I'm replying. But still there is a value in knowing that the method is doing a super call or not. The indicator means that the method use the keyword "super". So this is valuable. I really think that you are really kind of criticizing. When I browse code this arrow helps me. This is the same with the requireemnts analysis nathanael did in the old traits image Download the OOPSLA refactoring image and you can see that using is browser you can ****see**** methods sending messages not implemented. just in front of your nose.
b) shouldn't include any action abstraction because that's best handled in a completely different and system-wide fashion;
I disagree. OB provides this system-wide abstraction. It is the fault of the other tools that don't use these abstractions. For example, I've written a process browser, debugger, inspector and several other tools in OB and they all benefit from the commands that already exist and that other people write as extensions (e.g. open a hierarchy browser from within the debugger).
I agree that the abstraction is not optimal in all cases (e.g. text commands, applicability tests, ...), but it is definitely better than anything else I've seen so far.
different and system-wide fashion; c) is too messily tied to Morphic, with a number of hacks; and relatedly, d) shouldn't extend existing Morphic controls (such as lists) because they come with too much baggage (i.e. being all things to all people).
Earlier versions of OB were entirely separated from Morphic. Unfortunately it was tied to morphic over time as more and more people joined the development. I guess this happend due to laziness and lack of documentation and knowledge.
Documentation more than anything else. I imagine that like most of colin code there is not one line of comments which is sad because people make mistakes.
Along the same lines: Every line of the model and view used to be tested with in-depth SUnit-Tests. Unfortunately that is not the case anymore either. People add features without writing tests.
this is sad too. The problem is that if the system does not offer incentive and that you do not see the immediate benefits then you do not do it. This is why I would really like to see a package manifesto supporting design, styles rules checking, test regressions results so that the incentive to write code with documentation and tests is raised.
This is what happens, when an appealing and widely adapted projects entirely lacks a form of leadership.
At some point there was an AJAX based web view and a XUL interface. I think somebody even made GTK view. Earlier versions of OB run in GemStone, with the view running in Squeak Morphic. There is an ongoing port for GST.
On 23/10/2008, at 7:19 AM, Stéphane Ducasse wrote:
would be nice to know do whom I'm replying.
Me.
But still there is a value in knowing that the method is doing a super call or not. The indicator means that the method use the keyword "super". So this is valuable.
I cannot see why it is valuable given all the contexts in which super is used. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry
On 23/10/2008, at 1:06 AM, Lukas Renggli wrote:
I disagree. I exclusively use OB in productive development on a daily bases for over 2 years now.
Decent selection support? Multiple selection? Dynamic filtering? Rich labels? Trees? Multiple 'definition' edges? OB is usable today, and I use it exclusively as well, but my point is that is should be a lot better. Why settle for 'great concept, ok realization'? I want something 'exceptional'. I think OB is a great start, and an excellent piece of work, but it doesn't stop it being a prototype that has been tested in the field and found to require structural modifications and some rethinking, as opposed to the hacks that have polluted what is a beautiful model.
b) shouldn't include any action abstraction because that's best handled in a completely different and system-wide fashion;
I disagree. OB provides this system-wide abstraction. It is the fault of the other tools that don't use these abstractions. For example, I've written a process browser, debugger, inspector and several other tools in OB and they all benefit from the commands that already exist and that other people write as extensions (e.g. open a hierarchy browser from within the debugger).
I agree that the abstraction is not optimal in all cases (e.g. text commands, applicability tests, ...), but it is definitely better than anything else I've seen so far.
I have (IMO) a better system, called Commando, implemented in VW and now in Squeak. It has the following advantages: 1. Not tied to OB. 2. Commands are trivially enumerable, so a selection and discovery interface is natural. 3. Commands are applicable not only to UI elements, but also across- domains where the UI exposes a semantic marker/object. Thus the concept of an action is separated from the presentation of objects representing command parameters. 5. Commands can be easily structured into menus in both a context- sensitive, per-window and global manner, including platform-standard- specific positioning, as well as allowing manual semantically/HUI- factors directed grouping/ordering/accelerators, orthogonal to their definition. A video of it in action in VW is here: http://www.cincomsmalltalk.com/userblogs/antony/blogView?showComments=true&p...
This is what happens, when an appealing and widely adapted projects entirely lacks a form of leadership.
IMO success is dependent on having either one, or a very few people who share a vision and taste, explicitly in control/gatekeeping, applying *their* taste and judgement (technical and aesthetic), and guiding a project in accordance with their specific vision. That's what I branched off on my own rather than joining a group, and naturally why no-one else has joined me :) I maybe completely out to lunch, but it's *my* lunch. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis
On 23/10/2008, at 9:40 AM, Antony Blakey wrote:
A video of it in action in VW is here: http://www.cincomsmalltalk.com/userblogs/antony/blogView?showComments=true&p...
I should point out that the VW version has none of the menu/ accelerator ordering/filtering etc. facilities. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine
participants (3)
-
Antony Blakey -
Lukas Renggli -
Stéphane Ducasse