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

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

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

On Sep 23, 2008, at 10:26 AM, David RÃ¶thlisberger wrote: > Hi Lukas, > >> - 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? 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 >> - 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. >> - The same for extension methods. I see that, because it is in a >> different protocol and because its name is in italic (the same as >> with >> the extension classes). I don't need yet another icon. > > The name of an extension method is normally not in italic, only if > you are browsing it directly in the package, and then only if it's > an extension of this package. > Furthermore, you don't see to which protocol a method belongs when > browsing all methods of a class (I do that often...). Hence this > icon quickly provides important information that you otherwise have > to access with several clicks. I agree. The icon is ugly but it is important (see other mail) > 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. > >> This would greatly improve the interface. The browser starts to be >> really messy. > > 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. > > >> 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. Yes this is important that the class get its word

Sept. 23, 2008

Re: [Pharo-project] Re: Re: Re: [ANN] Demo with both Truetype +Polymorph

by Norbert Hartl

On Tue, 2008-09-23 at 10:01 +0200, Marcus Denker wrote: > On 23.09.2008, at 09:09, Andrew Tween wrote: > > > Note that with a one-click app distribution, it isn't necessary to > > embed the fonts in the image. > > FreeType Plus looks for a folder named Fonts relative to the .image > > file, and loads any fonts it finds from there. > > > > Putting the font file(s) into the Fonts folder has these advantages... > > > > 1.The image isn't bloated. (embedding a 20Mb font file would grow > > the image by 20Mb) > > So, the default font could be a large Unicode one, for example > > > > 2.Easier to create a one-click app for distribution. > > > > 3.Easier to install the font files into the OS so that other > > applications can also use them. > > > > 4. Free fonts that don't allow embedding can be used (e.g. > > Bitstream). This widens the choice of available free fonts. > > > > The advantage to embedding the font file in the image is that it > > moves around with the .image file. > > Which for a one-click app isn't really an advantage at all :) > > Cool! > > We should actually think about moving more data into files... for > example, there are huge literal arrays > in UCSTable's class side initialize methods that are only there for > initializing the class a long time ago. > These would not even be needed to be read on startup. > > Of course, this is violently against the "everything in the image" > philosophy of Squeak... but I guess > that any device one would want to run it on would have a filesystem of > some sort. > Or there could be a call that reads it in and keeps it in the image. Easy for people they want to have it in their image. Norbert

Sept. 23, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

> > > I am horrified with all these colored icons on methods. That's worse > > > > > than in the old browser with the button that had 8 different colors > > depending on the state of the method. > > > > Uh? > Lukas I think that david is spending a lot of time on improving the browser > so I would suggest you to be less aggressive and more bringing suggestions. I am sorry, I did not intend to be aggressive. I tried to give a list of suggestions to improve and simplify the interface. I am only talking about my personal experience using the browser enhancements and how I am confused with all the method icons. The icons are not intuitive and their priority is unclear. I need to keep the wiki open to understand them. > > - 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). If I want to know if a > > method calls super (and when) I need to look at the method anyway. > > No I'm sorry but I disagree. > Knowing that there is a supercall is as important as knowing that the > method > is specialized. I think it is misleading. There are methods that only call super under certain conditions or even call different super methods. This might lead to wrong assumptions. > Look at LimitedWriteStream you get instantanly the fact that the three > methods are doing a super send! > and this is really important to know. Again, I think it is most important to see at one glance if there are super and sub implementations. This is the only thing I can't find out with a single click and without loosing the context. In the current implementation this information is sometimes hidden. > > - 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. > > No this is your point of view on that. But knowing that a method is > abstract > is useful too Maybe, but it should not hide more important information. > > - The same for extension methods. I see that, because it is in a > > different protocol and because its name is in italic (the same as with > > the extension classes). I don't need yet another icon. > > It depends on which browser you are. Reinforcing the information is often > good. What I am criticizing here is that information is duplicated (icon and category) and not consistently displayed (classes with extension methods are italic, methods have a special icon). > > The only valuable thing for me as a developer is to know if there is a > > super/sub implementation of a method. And maybe if there are halts > > inside. > > Sorry but knowing that there are self flag and halt is extremely valuable. I agree. > But we do not want that click. > I do not know to click on all the method of my class to see if they all do > a supercall. Then we should move to files where we see all the source at one glance ;-) An icon can only tell yes or no. In most cases (such as with super calls) the situation is more complicated. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 23, 2008