- Pharo-dev - lists.pharo.org

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 7:21 AM, StÃ©phane Ducasse wrote: > can you explain the icons The left arrow, which comes in three forms - up, down and up&down, indicates declared-in-super/subclass. It is not overloaded with any other meaning. To the left of that is space for a green '+' that indicates 'is an extension', which is also used in the instance/class list. The 'x' indicates a method containing a halt. Normally, shifting the left side of the label is a bad idea because it makes scanning the list more difficult - it forces the user to explicitly read the label - but in the case of a halt that doesn't matter as much because it is both transient and operationally very significant. Except in the case of the method that looks for #halt, because it contains the symbol without actually *being* a halt method. I am considering adding a marker-method or pragma to allow you to control those few (reflective) methods that have this problem i.e. a manual semantic annotation. The right boxed forms are: comes-from-trait, is-unfulfilled-trait- requirement and is-trait-method-conflict. One of my focusses is including better support for traits in the UI. I think the comes-from- trait is too strong in relation to it's meaning. The right downwards arrow means is-abstract e.g. #subclassResponsibility. The right red star means '#needsWork or #flag:'. Those icons horizontally accumulate to the right, so multiple icons can co-exist. Note that red always means 'attention required', and how much the red stands out is in proportion to the nature of the issue. But I always pair color with a shape change to deal with color-blindness - a poor example is in VW's SUnit fail/success markers. I use an ellipsis for labels that are truncated by virtue of having icons to the right. I also have a hover mechanism that shows the full label in-place when you hover over it iff it is truncated, either with an explicit ellipsis or simply because it is too wide for the list. Also note that the column widths can be adjusted independently, and don't have to start an equal width. Some columns will always have icon spaces, some not. I did these before I gave in and bought a copy of Fireworks, so I was limited in what I could do shape wise without manually pixel painting e.g AA embosses. Anyone who's done that knows what a fiddly PITA it is. I thing a circular badge (for the trait markers) would be less jarring in general, although it's important to maintain a consistent aesthetic in that sense across the entire product, and circular forms commit you to a reduced area for the semantic payload. Furthermore there is a significant pragmatic benefit to using simple rectlinear icons that can be done well a) with simple tools and b) by many developers, because it allows contributors to produce icons for integratable components that don't look out of place. Check out the class type icons in VW for an example of how not to do it. For a system that is *meant* to be extended by the user, this is IMO an important consideration. This is very much a work in progress. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti

Oct. 22, 2008

Re: [Pharo-project] OldSocket removal

by John M McIntosh

Ok, Michael R suggested I bundle these up, recheck them, so who would I send them to? On Oct 22, 2008, at 1:55 PM, StÃ©phane Ducasse wrote: > yes please john. > > Stef > > On Oct 21, 2008, at 6:55 PM, John M McIntosh wrote: > >> Actually the tests there are rather primitive, why don't you pickup >> the tests from >> http://www.smalltalkconsulting.com/html/OTNotes4.html -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by John M McIntosh

We used imageSegments in Sophie to store cached font information, we then attempted to store a few more binary objects that way but soon discovered it was flaky..... Flaky meaning when we loaded an image segment it would crash the VM, but not always. We didn't have time to figure out exactly what the problem and back out our usage of it. On Oct 22, 2008, at 1:26 PM, StÃ©phane Ducasse wrote: >>>>> Hi all >>>>> >>>>> if by any chance you have some code that could be turned into >>>>> tests, or >>>>> some tests or some time to write tests for image segments this >>>>> would be great >>>>> because etoy is really deep inside image segment and I would >>>>> really like to keep this >>>>> beautiful idea working :) >>>> >>>> yes please. We use this in production (like DabbleDB), and it >>>> works very well. I just hope to never really need to understand >>>> the code... >>> >>> really read the code because it is full of etoy related ugly hack >>> (really ugly) >> >> I know... > > I imagine :) >>> >> I'll add it to my todo list > I can help I would love to write a small chapter on imageSegment for > the Volume 2 > because I also found the idea so cool. > > stef > >> >> >> Adrian >> _______________________________________________ >> 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

Re: [Pharo-project] OldSocket removal

by StÃ©phane Ducasse

yes please john. Stef On Oct 21, 2008, at 6:55 PM, John M McIntosh wrote: > Actually the tests there are rather primitive, why don't you pickup > the tests from > http://www.smalltalkconsulting.com/html/OTNotes4.html > > I also have some changes Rob Withers made if someone wants those > files for integration > > On Oct 21, 2008, at 12:14 AM, Damien Cassou wrote: > >> I've started working on OldSocket removal: >> http://code.google.com/p/pharo/issues/detail?id=275. I need someone >> to >> review my first changes. >> >> -- >> 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) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

hi antony can you explain the icons what the arrow up means ? and the others? Stef On Oct 22, 2008, at 10:27 AM, Antony Blakey wrote: > > On 22/10/2008, at 6:38 PM, Lukas Renggli wrote: > >> It is absolutely evil to display anything else than if there are >> super >> (up triangle) or sub implementations (down triangle) next to >> method. I >> just lost 10 minutes, because of these agressive green arrow that >> mark >> methods calling super. > > Whilst I agree that the 'calls super' is worse-than-useless, having > multiple annotations can be useful if they are appropriately > presented: http://linkuistics.com/ftp/Stardust-TraitAnnotation-2008-10-08.png > > A 'deprecated' marker would be useful in my environment. Then you'd > also want to find all senders of methods for which every > implementation is deprecated (or maybe just some?). > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Reflecting on W.H. Auden's contemplation of 'necessary murders' in > the Spanish Civil War, George Orwell wrote that such amorality was > only really possible, 'if you are the kind of person who is always > somewhere else when the trigger is pulled'. > -- John Birmingham, "Appeasing Jakarta" > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

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.

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

No please do not change the icons. No preference. We are building a visual vocabulary. Let us fix it instead. Stef On Oct 22, 2008, at 1:14 PM, David Roethlisberger wrote: > >>> I'm not a big defender of the super send icon, but what would >>> certainly have >>> helped in your use case is an icon that denotes whether you send >>> super to a >>> method with a different selector. Then you would have spotted this >>> problem >>> maybe even quicker than if it wouldn't have had any icon. >> Is it possible to put a configuration in the preferences so one can >> select what icons wants to be visible in the browser ? > > It is possible to do of course, but I'm not a friend of adding too > many preferences for this and that... > On the other hand, it seems to be impossible to find a set/ > configuration of icons that fits everyone's need and style. So maybe > it's indeed best to just let people configure the icons they want... > I will look into that. > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

Re: [Pharo-project] 10095: questions

by StÃ©phane Ducasse

Yo know this is really funny that I hear myself pronocing open... when I want to get mc browser and for a while I was looking for the open.... Stef On Oct 21, 2008, at 6:06 PM, Adrian Lienhard wrote: > The "recently logged changes" menu item has been reintroduced in the > world menu refactoring I did in a recent change (because as Lukas > said its a crucial feature). Please update, we currently are at > version 10101, so 10095 is already old ;) > > Also notice that the menu was redesigned from ground up. So the > organization is a bit different than the one in the previous menu > which may be strange for a moment for those of us that have > memorized the previous organization, but for newcomers it will be > much easier to understand. Also, the menu is optimized to make often > used tools accessible with only one click. > > Now, the previous item "recently logged changes" is in World->Tools- > >Recover lost changes... > > Cheers, > Adrian > > On Oct 21, 2008, at 16:21 , Gary Chambers wrote: > >> +1 on that... >> >> Gary. >> >> ----- Original Message ----- From: "Lukas Renggli" >> <renggli(a)gmail.com> >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, October 21, 2008 2:14 PM >> Subject: Re: [Pharo-project] 10095: questions >> >> >> Another thing I missed in recent versions is the possibility to >> open a >> changes-list on the recently logged changes. This is an absolutely >> crucial feature for an image based system, to be able to restore >> after >> a crash. >> >> Cheers, >> Lukas >> >> On Tue, Oct 21, 2008 at 1:24 PM, Alexandre Bergel <alexandre(a)bergel.eu >> > wrote: >>> Excellent! >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 21 Oct 2008, at 13:13, Damien Cassou wrote: >>> >>>> On Tue, Oct 21, 2008 at 1:02 PM, Alexandre Bergel >>>> <Alexandre.Bergel(a)inria.fr> wrote: >>>>> >>>>> Why is there only a simple change browser. Why not the double >>>>> one? I >>>>> always >>>>> found the simple one less useful. >>>> >>>> I think Adrian is aware of that and will replace the single one >>>> by the >>>> double one. In the meantime, you can still: DualChangeSorter open >>>> >>>>> How can I update Pharo ? Before the 'load update' in the left- >>>>> hand flap >>>>> provided it. >>>> >>>> World menu->system->uptade >>>> >>>> -- >>>> 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) >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 >> >> _______________________________________________ >> 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 >

Oct. 22, 2008

Re: [Pharo-project] New pharo dev [10101]

by StÃ©phane Ducasse

tx damien! Stef On Oct 21, 2008, at 8:12 PM, Damien Cassou wrote: > New pharo-dev available at http://code.google.com/p/pharo/wiki/Downloads?tm=2 > . > > It only contains the packages you want > (http://code.google.com/p/pharo/wiki/Packages) > > -- > 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by StÃ©phane Ducasse

>>>> Hi all >>>> >>>> if by any chance you have some code that could be turned into >>>> tests, or >>>> some tests or some time to write tests for image segments this >>>> would be great >>>> because etoy is really deep inside image segment and I would >>>> really like to keep this >>>> beautiful idea working :) >>> >>> yes please. We use this in production (like DabbleDB), and it >>> works very well. I just hope to never really need to understand >>> the code... >> >> really read the code because it is full of etoy related ugly hack >> (really ugly) > > I know... I imagine :) >> > I'll add it to my todo list I can help I would love to write a small chapter on imageSegment for the Volume 2 because I also found the idea so cool. stef > > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008