- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Product Brand Pharo

by Gary Chambers

I remember doing a "Wizard" framework in VisualAge... shudders... Still, nice to have standardised support for such things rather than ad-hoc BookMorphs (for example). Regards, Gary. ----- Original Message ----- From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 23, 2008 12:03 PM Subject: Re: [Pharo-project] Product Brand Pharo > Markus, > > Based on the discussion, I started noting how long it takes my images to > load; a splash screen might be in order; I also fear that by the time VM > loads and the GUI is able to draw itself, it is no longer needed :( > Still, I'd add it to the milestones, but probably late in the process. > > About help, I am not very sympathetic on the "no documentation" front. > Someone seeking to join us will quickly find tutorials, and can post > questions. Dolphin's MVP framework almost invariably had the newbie > expressing pain and confusion, followed by "why was this so hard last > week???" Conversely, the MS Office IDL for Automation has LOTS of > "help" - almost all of it useless. The message (pun intended) needs to > be "this is not trivial to learn, but very worth your time." Ensuring > that good tutorials are linked from our Wiki would be a nice gesture. > > Wizards in the IDE - that's a very good idea, and Dolphin helps it along > through the IDE extension framework, which is little more than events > triggered at the right time, off of each tool's class and giving the > needed instances for the code to make the desired changes. Dolphin's > view resources, and our lack of them, would require some adaptation. > However we do it, it would be a nice addition. The idea is to do > _something_ that allows each of us to provide hooks into the IDE w/o > having to alter the code. That way, building a new image and updating > an existing one will not destroy the extensions. > > 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 > > > _______________________________________________ > 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] Halt once; workspace(?) menu

by Bill Schwab

Stef, The class can be more flexible than what is in Pharo, and FWIW, is not built into the system. Since it does not need to be built-in, that's a plus in my thinking. Not much of a difference, I must admit. 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. 23, 2008

Re: [Pharo-project] Product Brand Pharo

by Bill Schwab

Markus, Based on the discussion, I started noting how long it takes my images to load; a splash screen might be in order; I also fear that by the time VM loads and the GUI is able to draw itself, it is no longer needed :( Still, I'd add it to the milestones, but probably late in the process. About help, I am not very sympathetic on the "no documentation" front. Someone seeking to join us will quickly find tutorials, and can post questions. Dolphin's MVP framework almost invariably had the newbie expressing pain and confusion, followed by "why was this so hard last week???" Conversely, the MS Office IDL for Automation has LOTS of "help" - almost all of it useless. The message (pun intended) needs to be "this is not trivial to learn, but very worth your time." Ensuring that good tutorials are linked from our Wiki would be a nice gesture. Wizards in the IDE - that's a very good idea, and Dolphin helps it along through the IDE extension framework, which is little more than events triggered at the right time, off of each tool's class and giving the needed instances for the code to make the desired changes. Dolphin's view resources, and our lack of them, would require some adaptation. However we do it, it would be a nice addition. The idea is to do _something_ that allows each of us to provide hooks into the IDE w/o having to alter the code. That way, building a new image and updating an existing one will not destroy the extensions. 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. 23, 2008

Re: [Pharo-project] First pharo-dev with limited package set

by Adrian Lienhard

Hi Damien, Thanks, looks good! Question: Does this include Universes? It's not listed below but I see the menu item (which does not work because of a deprecation warning). I think we need Universes mainly because Seaside will be packaged with Universes soon, and being able to easily load Seaside is a key requirement for Pharo. Another thing we need to look at (and I planned to do this) is the open menu. With all the additional packages in the dev version its even worse than before. For example there are 3(!) items for opening a workspace: Workspace Workspace (without colourisation) Shout Workspace There ought to be just one, and in the right place. Cheers, Adrian On Sep 23, 2008, at 09:52 , StÃ©phane Ducasse wrote: > This sounds good. > Now we should be able to see the overrides of ecompletion. > > Stef > > On Sep 23, 2008, at 8:20 AM, Damien Cassou wrote: > >> Hi, >> >> I've just released the first pharo-dev which contains a limited >> package set. See http://code.google.com/p/pharo/wiki/Packages for the >> list of packages we want in Pharo. >> >> You can download the image at >> https://gforge.inria.fr/frs/download.php/7404/pharo0.1-10074dev08.09.2.zip >> . >> >> Here is the list of packages included in this release: >> >> AST version 160 >> eCompletion version 0.90 >> OB-Enhancements version 0.203 >> OmniBrowser version 0.416 >> OmniBrowser-Morphic version 0.52 >> OmniBrowser-Refactory version 1.0 >> OmniBrowser-Regex version 0.9.1 >> OmniBrowser-Standard version 0.346 >> Pharo packages version 0.3 >> Refactoring Core version 5 >> RoelTyper version 0.60 >> Shout version 3.15-tween.72 >> ShoutWorkspace version 1-tween.2 >> VBRegex version 1.9 >> >> -- >> 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 > > > _______________________________________________ > 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 David RÃ¶thlisberger

> 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

Sept. 23, 2008

Re: [Pharo-project] UTF support

by StÃ©phane Ducasse

I have the impression that this is an important todo for the future pharo milestones. Stef >> >>> >>> Hi all, >>> >>> In the Linux VM, when I try to input, via paste or the right alt >>> combination, non-ascii characters, like 'Ã¶' or 'Ã©' for example, >>> Squeak >>> merely shows 'o?' or 'e?' I researched into this and accordingly >>> chose a >>> font that supports UTF-8 and set the locale and VM command line >>> options >>> appropriately: >>> >>> export LC_CTYPE="en_IE.UTF-8" >>> locale-gen en_IE.UTF-8 >>> (...which claims that locale is upto date...) >>> sudo dpkg-reconfigure -plow locales >>> (...which outputs en_IE.UTF-8... done among other things....) >>> squeak -encoding UTF-8 -textenc UTF-8 -pathenc UTF-8 >>> Squeak3.10.2-7179-basic.image >>> >>> Now when I try to input the aforementioned characters I encounter >>> a debug >>> message: "Error subscript is out of bound." >>> >>> However, I have set Squeak's language to Spanish and then German, >>> and the >>> characters display perfectly well in the menus. Although, the same >>> cannot be >>> said for the any files with non-ascii characters in the file >>> dialogue. So, >>> it seems it's an input problem. >>> >>> Anyone with any ideas? Thanks. >> >> This has only been addressed recently, and may not have found its >> way into a release yet. >> >> You need the very latest Squeak VM (3.10-1 at least). It supports >> Unicode keyboard events (which are passed to the image as UTF32). >> >> To make use of these events your image needs to be using >> UTF32InputInterpreter. Evaluate >> >> ActiveHand keyboardInterpreter >> >> to see the currently used one. It can be changed by patching >> Latin1Environment class>>inputInterpreterClass. >> >> I don't know if this is in any official release yet, or scheduled >> for one. >> >> Some relevant change sets from the Etoys image seem to be >> >> http://tinlizzie.org/updates/etoys/updates/1713UnicodeInput1-yo.cs >> http://tinlizzie.org/updates/etoys/updates/1714UnicodeInput2-yo.cs >> http://tinlizzie.org/updates/etoys/updates/1925unixLatin1Input-yo.cs >> http://tinlizzie.org/updates/etoys/updates/1935unicodeFallback-bf.cs >> >> - Bert - >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> > > > _______________________________________________ > 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 David RÃ¶thlisberger

>> 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

Sept. 23, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

> > 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

Sept. 23, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

> > - 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

Sept. 23, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

On 9/23/08, StÃ©phane Ducasse <stephane.ducasse(a)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

Sept. 23, 2008