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

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

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

Sept. 23, 2008

[Pharo-project] Fonts related from OLPC / rome also

by StÃ©phane Ducasse

I started to go over http://tinlizzie.org/updates/etoys/updates to see if some of the fixes of yoshiki for unicode and others were there. Here is a list of names that may be should be further investigated - 1622fontFix-sw.cs - 1626FontNameGlitch-y.. - 1711UTF8Clipboard.cs - 1712utf8toSqueakFix-. - 1713UnicodeInput1-yo.cs - 1714UnicodeInput2-yo.cs - 1715utf8toSqueakFix2..> - 1725SystemFont-yo.cs - 1726SystemFont2-yo.cs - 1731UpdBtnFontFix-KR.cs - 1813macPasteUTF8-bf.cs - 1815latin1Chars-yo.cs - 1821UnicodeFntLoadin..> - 1826TTCFontSetRework..> - 1826TTCFontSetRework..> - 1827sketchColor-sw.cs - 1832TTCFontSetFix-yo.cs -1834FontRegFix-yo.cs - 1862TTCFontObjStream..> - 1869latin1PathEncodi..> - 1884TTObjForStream-y.. - 1907crlfFix-bf.cs - 1918UTF8InputFix-ar.cs - 1925unixLatin1Input-..> - 1935unicodeFallback-. - 2143macEnc-bf.cs about the rome canvas 1932romepango-base.cs 1933romepango.cs 1934romepango2-yo.cs 24

Sept. 23, 2008

Re: [Pharo-project] Product Brand Pharo

by Igor Stasenko

My thoughts about splash. It could be useful only in case, when there is not a VM who driving it, but image instead. Yes, image, at the point when it just loaded, can instruct VM to show window with splash image (held in image, not in file,btw), and show some progress bar during its initialization, and then destroy this window and create a normal main window (if its required). Of course this will be possible only when all windowing could be controlled by language side through HostWindowPlugin, which i proposed earlier, not by VM like currently :) -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2008

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

by Damien Cassou

On Tue, Sep 23, 2008 at 11:42 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > 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. Universes and Installer are present. They are not listed because I installed them by hand and not by using Universe. I will fix it for the next version. > 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 I think we need to keep two entries. Something like 'Smalltalk workspace' and 'Text workspace'. What do you think? -- 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. 23, 2008

Re: [Pharo-project] On Icons

by Igor Stasenko

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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2008

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

by Bill Schwab

Ok, but only if you allow a choice of which one to use. I am a HUGE fan of Shout, but I generally do not want a workspace trying to colorize my notes to myself. If I end up with enough code that the syntax is not clear, it probably belongs in a class and in a package or change set - at least I try to do that. 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 >>> adi(a)netstyle.ch 09/23/08 5:42 AM >>> 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 _______________________________________________ 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] Product Brand Pharo

by Bill Schwab

Gary, There are two topics here: (1) allowing ourselves and others to easily retrofit tools into the various menus; (2) building a fast and elegant GUI framework. BookMorphs are a (not terribly good) implementation attempts at the latter. For the newbie (or even us trying to get something done), it can be very helpful to have tools offered in the right places. Cleaner is better of course, but the "user" in the case is more interested in whether the tool works than in how the tool works. Set out to write your own helpful wizard, and elegance is appreciated. 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 >>> gazzaguru2(a)btinternet.com 09/23/08 7:16 AM >>> 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 _______________________________________________ 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] 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