September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OB's icon support improved

by Stefan Schmiedl

On Mon, 29 Sep 2008 07:03:39 -0400 "Bill Schwab" <BSchwab(a)anest.ufl.edu> wrote: > (4) Do we have any color blind people among us? http://www.vischeck.com/vischeck/ s.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Bill Schwab

I apologize for not paying more attention to this thread. Visual feedback in the browser is very much appreciated, and you seem to be doing a very nice job! Had I been paying attention, I'd have said things like the following: (1) Red is probably not the best choice to have lurking on the screen. Maroon/purple/clay rose or just about any "muted" or muddy red IMHO is a much better choice for most things. It might help to add a small amount of blue to the greens too for the same reason. I recommend trying for the psychological benefit with as little eye strain potential as possible. (2) For collections, consider something like a circle drawn a few times from right to left to give an overlapping effect, maybe ... thrown in there if there is room. (3) For exceptions, I like the icon, but two concerns: it might be a little faint/bland; it might work better if its implied movement were upward. Dolphin 5 uses an explosion icon in some situations. That might work well for exceptions and errors. (4) Do we have any color blind people among us? IIRC, something around 12-14% of the population is affected to some degree, so we will encounter it. The test icons will be lost on some of the more extreme red/green sufferers. An alternative would be a boxed check, X or ?. The box (or other border shape) being the suggestion of the test, and the symbol indicating the state. It is fine to add color too, but we should give the red/green crowd a way to see what is going on. Not meaning to jab anyone in the eye, the Installer script is just the kind of thing I'd hope to be able to exchange in situations like this. I do not care so much that it is Installer that we use, but _something_ that can cope with the various publication methods and cope with the details is much needed. 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) 273-6785 FAX: (352) 392-7029

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Janko MivÅ¡ek

David, Very nice indeed! One quick suggestion: classes without a comment need to have an icon, and really really ugly one, for obvious reason: to get rid of it by writing a comment ASAP :) Janko David RÃ¶thlisberger wrote: > Hi there, > > taking the suggestions from the "On icons" thread, I have now changed > and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font for > the method > name label if it's a extension method and additionally red color if it's > an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef who > did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method sending > super is > redefined in subclasses or not (they get an additional triangle pointing > down if they > are redefined). > For a complete list of supported icons see: > http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you to > the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering a > symbol for the > icon name) to define the icon they will get in the class column themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and methods > (trait methods > are shown in italic right now, hence somehow conflicting with extension > methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Alexandre Bergel

This is an excellent news. Cheers, Alexandre On 29 Sep 2008, at 11:36, David RÃ¶thlisberger wrote: > Hi there, > > taking the suggestions from the "On icons" thread, I have now > changed and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font > for the method > name label if it's a extension method and additionally red color if > it's an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef > who did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method > sending super is > redefined in subclasses or not (they get an additional triangle > pointing down if they > are redefined). > For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you > to the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering > a symbol for the > icon name) to define the icon they will get in the class column > themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and > methods (trait methods > are shown in italic right now, hence somehow conflicting with > extension methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as > valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

this is cool! Works well. Stef > Hi there, > > taking the suggestions from the "On icons" thread, I have now > changed and extended > the icons in columns like this: > > - Removed icons for extension methods ('+'), instead use italic font > for the method > name label if it's a extension method and additionally red color if > it's an override > (as Lukas suggested) > > - Use new icons for abstract method and super send (credits to Stef > who did the hard > work of drawing them). > The new icons make clear whether an abstract method or a method > sending super is > redefined in subclasses or not (they get an additional triangle > pointing down if they > are redefined). > For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ > There are still some icons missing for rare situations, if someone > volunteers to draw > them, we'd be happy. ;) > > - Explaining labels for all icons (keep the mouse over them) > > - Most icons are clickable: Clicking on a super send icon brings you > to the method in > the superclass, clicking on a triangle down icon brings you to the > overridding method > in the subclass or gives you a list of candidates if there are several > sub-implementations. > This I consider as a very convenient extension. > > - Classes or Traits can implement the method #browserIcon (answering > a symbol for the > icon name) to define the icon they will get in the class column > themselves > > > If you have more suggestions or wishes concerning icons (or anything > else), let me know. > Current ideas include to introduce icons for trait classes and > methods (trait methods > are shown in italic right now, hence somehow conflicting with > extension methods), or > to have an icon for methods without any additional implementor. > I would be interested to know whether you consider these ideas as > valuable. > > > To load the latest version of OB, you can use this Installer script: > > > Installer wiresong > project: 'ob'; > install: 'OmniBrowser-dr.419'; > install: 'OB-Standard-dr.355'; > install: 'OB-Morphic-dr.57'; > install: 'OB-Enhancements-dr.217'. > > > Cheers, > David > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2008

[Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

Hi there, taking the suggestions from the "On icons" thread, I have now changed and extended the icons in columns like this: - Removed icons for extension methods ('+'), instead use italic font for the method name label if it's a extension method and additionally red color if it's an override (as Lukas suggested) - Use new icons for abstract method and super send (credits to Stef who did the hard work of drawing them). The new icons make clear whether an abstract method or a method sending super is redefined in subclasses or not (they get an additional triangle pointing down if they are redefined). For a complete list of supported icons see: http://smallwiki.unibe.ch/hermion/icons/ There are still some icons missing for rare situations, if someone volunteers to draw them, we'd be happy. ;) - Explaining labels for all icons (keep the mouse over them) - Most icons are clickable: Clicking on a super send icon brings you to the method in the superclass, clicking on a triangle down icon brings you to the overridding method in the subclass or gives you a list of candidates if there are several sub-implementations. This I consider as a very convenient extension. - Classes or Traits can implement the method #browserIcon (answering a symbol for the icon name) to define the icon they will get in the class column themselves If you have more suggestions or wishes concerning icons (or anything else), let me know. Current ideas include to introduce icons for trait classes and methods (trait methods are shown in italic right now, hence somehow conflicting with extension methods), or to have an icon for methods without any additional implementor. I would be interested to know whether you consider these ideas as valuable. To load the latest version of OB, you can use this Installer script: Installer wiresong project: 'ob'; install: 'OmniBrowser-dr.419'; install: 'OB-Standard-dr.355'; install: 'OB-Morphic-dr.57'; install: 'OB-Enhancements-dr.217'. Cheers, David

Sept. 29, 2008

Re: [Pharo-project] How do we manage todos?

by Marcus Denker

On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: > I would prefer a bugtraker with a tag todo that are not bug fixes. Ok. Then we can split up the one entry that has all the TODOs. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] About Network-YM.44.mcz

by Damien Cassou

On Sun, Sep 28, 2008 at 9:44 PM, Yann Monclair <yann.monclair(a)smalltalk.fr> wrote: > I found a few senders in Universe, but I couldn't publish the changes, the > project is ReadOnly and I haven't time to chase up the admins about it yet. Philippe and I fixed them. Thanks -- 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)

Sept. 29, 2008

RE: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside2.9 alphauniverse

by Ramon Leon

> > If it uses overrides, the MC1.5 should be able to uninstall it. > > However > > MC1.5 probably depends upon it. So you are probably stuck there. > > > > keep in mind that uninstall can not work in general... > overrides are evil. My feelings exactly. I don't want an MC that tries to be smart, I want packages who's authors recognize that overrides are pure evil and don't use overrides. If the built in method doesn't work for you, then create an extension that does with a prefix that suites your package. It might not be pretty, but it's better that changing core code and breaking other peoples packages. Ramon Leon http://onsmalltalk.com

Sept. 29, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

Marcus Denker wrote: > > On 28.09.2008, at 22:16, Keith Hodges wrote: > >> >>> considering that mantis now has >1000 open entries... >>> >>> Marcus >>> >> ?? >> >> The difference being, that we dont create a mantis entry so that it can >> languish unused. We use mantis as a vessel for holding snippets of code >> and collecting feedback. >> >> Installer collects a list of fixes applied, and Sake/Tasks has a task >> for documenting those fixes in the image. >> > > So fixes are not integrated into the image anymore and the report then > closed? When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed". Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something. Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer. This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team. > What I don't understand with the use of Installer with mantis entries: > From my > experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem. > Thas means: two fixes are overriding the same method, to harvest both, > the second > one applied can not be added but needs to be redone to take the > changes of the first > into account. > > I really can't imagine how you can automatically apply changesets from > the bugtracker Nothing is automatic. > > to build "your own release". This just can't work with all the > dependencies between > fixes. However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated. With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable" Keith

Sept. 28, 2008