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

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

by Simon Kirk

On 24 Sep 2008, at 20:21, StÃ©phane Ducasse wrote: >> Hi folks. This thread is a bit stale now, but Gary and I were >> playing with getting our latest web app installed on this Pharo >> image - plus of course our in-house tools that Gary's built. > > Excellent! > >> I run a Mac (unlike everybody else in the office) and my clipboard >> is no longer working. > > Argh! > >> In other words, text I copy to the clipboard in OSX can't be pasted >> into the Pharo image. The reverse *does* work (ie text copied in >> the image can be pasted into an app in OSX). > > Which VM are you using? > Because I tried with the latest pharo image 74 and this is working. > I'm on mac os 10.5 latest update running 3.8.18Beta1U Well, I'm using the one-click image from this thread (from here: https://gforge.inria.fr/frs/download.php/7268/Pharo0.1-PolymorphTT.zip) , so I presume it's running a VM that gets packaged with it? Certainly when running an image "bare" I'm running it with the VM I have installed on the Mac, which is 3.8.18Beta3U, and copy and paste works fine there. However, I think when I'm running the one-click image, I'm running a VM packaged within? For comparison, here is the printit output from "SmalltalkImage current vmVersion" on an image run "standalone": 'Squeak3.8.1 of ''28 Aug 2006'' [latest update: #6747] Squeak VM 3.8.18b3' And here's the printit output from the Pharo one-click linked above: 'Squeak3.8.1 of ''28 Aug 2006'' [latest update: #6747] Pharo'. I don't know if that helps. Ah, now things get extra weird! Copy and paste has *literally just* started working. I have seen this before. Perhaps it's because I tried a copy and paste on the "bare" image, then on Pharo? I can't say for sure what the conditions are yet, but perhaps somebody else has seen it. Either way, Gary definitely saw the same behaviour earlier today over my shoulder so he can confirm I'm not going mad :) >> I'm not sure if I'm repeating an earlier bug report here, or >> something already known, sorry if I am. >> >> Other than that, the image is looking really good :) > > > :) > > I want more :) I want that when I open a class browser it looks > really cool :) Amen to that! :) S ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 24, 2008

Re: [Pharo-project] possible TODOs...

by StÃ©phane Ducasse

Hi marcus did you remove squeakmap already? Stef On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote: > > -> SqueakMap stores 1.5MB of crap in the image. make changeset that > removes SqueakMap from the image. > (check SqueakMap default purge)

Sept. 24, 2008

Re: [Pharo-project] Other Morphic question: allKnownNames

by StÃ©phane Ducasse

We are in sync then I think that morphic will be quite small once we will get done with it. :) I will release ComponentLikeModel removal BTW scriptEditorMoprh is not in etoy package but it smells like it. I think that I will try to remove it too. What do you think? Stef On Sep 24, 2008, at 9:17 PM, Marcus Denker wrote: > > On 24.09.2008, at 21:03, StÃ©phane Ducasse wrote: > >> Hi >> >> I'm reading >> innocuousName >> allKnownNames >> allSubmorphNamesDo: >> >> and friends >> > > >> It seems to me that Morph submorph elements could be given names >> from the user interface and >> this would define automatically instance variables or something >> like that with the given name. > > > And this has even been used to find morphs to send messages to. > Because, besides "findA:" and "submorphThat:", > there is even: submorphNamed: > > in CodeHolder, there is this wonderful piece of code: > > buttonWithSelector: aSelector > "If receiver has a control button with the given action selector > answer it, else answer nil. morphic only at this point" > > | aWindow aPane | > ((aWindow := self containingWindow) isSystemWindow) > ifFalse: [^nil]. > (aPane := aWindow submorphNamed: 'buttonPane') ifNil: [^nil]. > ^aPane submorphThat: > [:m | > (m isKindOf: PluggableButtonMorph) and: [m actionSelector == > aSelector]] > ifNone: [^nil] > > > ;-) > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2008

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

by StÃ©phane Ducasse

> Hi folks. This thread is a bit stale now, but Gary and I were > playing with getting our latest web app installed on this Pharo > image - plus of course our in-house tools that Gary's built. Excellent! > I run a Mac (unlike everybody else in the office) and my clipboard > is no longer working. Argh! > In other words, text I copy to the clipboard in OSX can't be pasted > into the Pharo image. The reverse *does* work (ie text copied in the > image can be pasted into an app in OSX). Which VM are you using? Because I tried with the latest pharo image 74 and this is working. I'm on mac os 10.5 latest update running 3.8.18Beta1U > I'm not sure if I'm repeating an earlier bug report here, or > something already known, sorry if I am. > > Other than that, the image is looking really good :) :) I want more :) I want that when I open a class browser it looks really cool :)

Sept. 24, 2008

Re: [Pharo-project] Other Morphic question: allKnownNames

by Marcus Denker

On 24.09.2008, at 21:03, StÃ©phane Ducasse wrote: > Hi > > I'm reading > innocuousName > allKnownNames > allSubmorphNamesDo: > > and friends > > It seems to me that Morph submorph elements could be given names > from the user interface and > this would define automatically instance variables or something like > that with the given name. And this has even been used to find morphs to send messages to. Because, besides "findA:" and "submorphThat:", there is even: submorphNamed: in CodeHolder, there is this wonderful piece of code: buttonWithSelector: aSelector "If receiver has a control button with the given action selector answer it, else answer nil. morphic only at this point" | aWindow aPane | ((aWindow := self containingWindow) isSystemWindow) ifFalse: [^nil]. (aPane := aWindow submorphNamed: 'buttonPane') ifNil: [^nil]. ^aPane submorphThat: [:m | (m isKindOf: PluggableButtonMorph) and: [m actionSelector == aSelector]] ifNone: [^nil] ;-) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

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

by Simon Kirk

Hi folks. This thread is a bit stale now, but Gary and I were playing with getting our latest web app installed on this Pharo image - plus of course our in-house tools that Gary's built. I run a Mac (unlike everybody else in the office) and my clipboard is no longer working. In other words, text I copy to the clipboard in OSX can't be pasted into the Pharo image. The reverse *does* work (ie text copied in the image can be pasted into an app in OSX). I'm not sure if I'm repeating an earlier bug report here, or something already known, sorry if I am. Other than that, the image is looking really good :) Cheers, Simon On 24 Sep 2008, at 07:59, StÃ©phane Ducasse wrote: > May be we should add this info in a class comment. > This is why I should continue to work on this idea of a manisfesto > per package. > > Stef > > On Sep 24, 2008, at 12:01 AM, Andrew Tween wrote: > >> >> "Norbert Hartl" <norbert(a)hartl.name> wrote in message news:1222159745.9772.5.camel@localhost >> ... >>> 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. >> >> FreeTypeFontProvider current embedFilesInDirectory: aDirectory >> will do this >> >>> >>> Norbert >> >> >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 24, 2008

Re: [Pharo-project] About Flap

by Marcus Denker

On 24.09.2008, at 20:14, Bill Schwab wrote: > Lukas, > > That's fine if my hands are on the keyboard, but if I have one on the > mouse (common when browsing), then (in Dolphin at least), I end up > either right clicking on a class in an open browser, or hitting a > toolbar button. For the more obscure tools, the shell menus (Tools) > do > the trick. Shortcuts are great, but we should also provide mouse- > based > options. > remember: there will be a menu, with a "tools" entry. And there will always be the world-menu (click on the backround). the flap is not faster in the number of clicks than a pulldown menu... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

[Pharo-project] Other Morphic question: allKnownNames

by StÃ©phane Ducasse

Hi I'm reading innocuousName allKnownNames allSubmorphNamesDo: and friends It seems to me that Morph submorph elements could be given names from the user interface and this would define automatically instance variables or something like that with the given name. My gut feeling is shouting inside me to tell me that we should remove that. I would really like to know your point of view. I checked in Squeak2.8 allKnownNames "Answer a list of all the names of all named objects borne in my instance variable values" ^ self instanceVariableValues select: [:e | (e ~~ nil) and: [e knownName ~~ nil]] thenCollect: [:e | e knownName] Stef

Sept. 24, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

Hi david something I would love to have..... is a means to know whether a method is defined in multiple class or only the one I'm browsing. Because I'm always doing alt M and closing the window... when reading foreign code that I'm cleaning. Stef

Sept. 24, 2008

Re: [Pharo-project] About Flap

by Bill Schwab

Lukas, That's fine if my hands are on the keyboard, but if I have one on the mouse (common when browsing), then (in Dolphin at least), I end up either right clicking on a class in an open browser, or hitting a toolbar button. For the more obscure tools, the shell menus (Tools) do the trick. Shortcuts are great, but we should also provide mouse-based options. 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 >>> renggli(a)gmail.com 09/24/08 1:51 PM >>> > I like the way they are in dev images. You move the mouse to the right > side of the image and the flap opens. From there, you can drag&drop > your favorite tool. Do you have any faster way to open a browser or a > transcript? Ctrl+B and Ctrl+T -- 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

Sept. 24, 2008

Re: [Pharo-project] About Flap

by Lukas Renggli

> I like the way they are in dev images. You move the mouse to the right > side of the image and the flap opens. From there, you can drag&drop > your favorite tool. Do you have any faster way to open a browser or a > transcript? Ctrl+B and Ctrl+T -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 24, 2008

Re: [Pharo-project] Burning the disk packs: Who puts equality into Object?

by Marcus Denker

Hi, If you look at Object: Object numberOfMethods 449 Object linesOfCode 2356 I have somehow the feeling that there is some other stuff that we should remove before thinking about removing equality... Marcus On 24.09.2008, at 18:14, Bill Schwab wrote: > I have always seen defaulting equality to identity to be a useful > confusion, and I fear it would simply be copied down (often in > frustration) into many classes vs. done once. It also removes a > compatibility with other Smalltalks, which I think we should be > working > to maintain and enhance where it is not destructive to do so. Just > my 2 > asCents. > > 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 > >>>> diegogomezdeck(a)consultar.com 09/24/08 9:30 AM >>> > Hi guys, > > I recently discovered Pharo project and I'd like to fire a proposal > for > cleaning Object class. > > The "simple" idea is to remove equality concept (implemented with #= > and > #hash messages) from Object. > > Equality means that different instances can represent the same value > (like Numbers, Strings, Dates, etc). Identity means that any object > is > a different object from any other from the world. > > All objects have identity (#== and #basicHash messages), but not all > object share the equality concept. To make the things worst, the > default implementation of equality is based on the identity, > producing a > big confusion to newbies (and experts too!). > > One implementation option is to implement the Equality concept in a > super-class of Magnitude (Comparable?), and reused all over the class > hierarchy with traits. > > Of course such factorization will impact also on the Collections that > (most of them) also confuses equality with identity. Probably some > collections will need an Strategy-pattern to use identity or equality > based behavior. > > What do you think? > > Cheers, > > -- Diego > > > > _______________________________________________ > 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

Re: [Pharo-project] Burning the disk packs: Who puts equality into Object?

by Bill Schwab

I have always seen defaulting equality to identity to be a useful confusion, and I fear it would simply be copied down (often in frustration) into many classes vs. done once. It also removes a compatibility with other Smalltalks, which I think we should be working to maintain and enhance where it is not destructive to do so. Just my 2 asCents. 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 >>> diegogomezdeck(a)consultar.com 09/24/08 9:30 AM >>> Hi guys, I recently discovered Pharo project and I'd like to fire a proposal for cleaning Object class. The "simple" idea is to remove equality concept (implemented with #= and #hash messages) from Object. Equality means that different instances can represent the same value (like Numbers, Strings, Dates, etc). Identity means that any object is a different object from any other from the world. All objects have identity (#== and #basicHash messages), but not all object share the equality concept. To make the things worst, the default implementation of equality is based on the identity, producing a big confusion to newbies (and experts too!). One implementation option is to implement the Equality concept in a super-class of Magnitude (Comparable?), and reused all over the class hierarchy with traits. Of course such factorization will impact also on the Collections that (most of them) also confuses equality with identity. Probably some collections will need an Strategy-pattern to use identity or equality based behavior. What do you think? Cheers, -- Diego _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 24, 2008

Re: [Pharo-project] About traits support in OB

by StÃ©phane Ducasse

Hi david > To browse traits used in a given class, we have this fourth switch > next to instance / ? / class, called 'traits'. Clicking on it then > lists in the next column all traits used in this class and the class > itself. This additional column duplicates the switches > instance / ? / class. > > For classes using traits you can see methods coming from traits in > italic, methods defined but not implemented in a trait in normal > font when browsing the class and in blue when browsing the trait. > You also see the hierarchy of the used traits in this 'trait column'. > > But it's also possible to open this 'trait column' for classes that > do not use any traits, this is very confusing. Also it's not nice to > suddenly get five columns instead of four. Yes! > My suggestions to better integrate traits is to show them below the > classes using them directly in the class column, hierarchially > sorted and marked either with an icon or with a colored label (eg. > in blue). Like this we can get rid of this additional column and the > additional 'trait' switch. Would be cool. > The only problem I see with this change is that it might confuse > people as traits are displayed along with all classes of a package/ > class cat in the class column, although they might not be part of > neither the package/class cat nor the class hierarchy. > > What do you think, should I change it like this or not? Give a try. I think that this is worth. I would like to rewrite a part of the collection hierarchy and use Nile so more traits. Stef > > > 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. 24, 2008

Re: [Pharo-project] About Flap

by Bill Schwab

Now THAT'S a reason for us to remove them!!!!!!! :) 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 >>> damien.cassou(a)gmail.com 09/24/08 9:07 AM >>> On Wed, Sep 24, 2008 at 3:05 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Sep 24, 2008 at 1:55 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I would like to know what do we decided for Flaps? > > I like the way they are in dev images. You move the mouse to the right > side of the image and the flap opens. From there, you can drag&drop > your favorite tool. Do you have any faster way to open a browser or a > transcript? Note that latest versions of Microsoft Visual Studio now contains flaps too. -- 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. 24, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

Hi Torsten, > this crashes the browser for traits. I think #browserIcon returning nil > is also required in Trait/TraitDescription class. At least this works for me > then. oh, yes, sure, thanks! OB-Enhancements-dr.212 fixes this. David

Sept. 24, 2008

[Pharo-project] On Icons

by Torsten Bergmann

David, this crashes the browser for traits. I think #browserIcon returning nil is also required in Trait/TraitDescription class. At least this works for me then. Bye Torsten -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal fÃ¼r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Sept. 24, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

>> 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 ok. You can now (as of OB-Enhancements-dr.211) implement a method #browserIcon on the class-side of any class you want and let this method return a symbol of the desired icon. This setting has the highest priority. example: OBNode class >> browserIcon ^#needsWork Cheers, David

Sept. 24, 2008

[Pharo-project] Burning the disk packs: Who puts equality into Object?

by Diego Gomez Deck

Hi guys, I recently discovered Pharo project and I'd like to fire a proposal for cleaning Object class. The "simple" idea is to remove equality concept (implemented with #= and #hash messages) from Object. Equality means that different instances can represent the same value (like Numbers, Strings, Dates, etc). Identity means that any object is a different object from any other from the world. All objects have identity (#== and #basicHash messages), but not all object share the equality concept. To make the things worst, the default implementation of equality is based on the identity, producing a big confusion to newbies (and experts too!). One implementation option is to implement the Equality concept in a super-class of Magnitude (Comparable?), and reused all over the class hierarchy with traits. Of course such factorization will impact also on the Collections that (most of them) also confuses equality with identity. Probably some collections will need an Strategy-pattern to use identity or equality based behavior. What do you think? Cheers, -- Diego

Sept. 24, 2008

[Pharo-project] About Flap

by Torsten Bergmann

Damien wrote >Do you have any faster way to open a browser or a transcript? Hit Cmd+b for browser and Cmd+t for transcript. ;) Bye Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Sept. 24, 2008

Re: [Pharo-project] Please use your name and not initial

by Damien Cassou

On Wed, Sep 24, 2008 at 2:23 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Where is the text and who should get a signed copy? http://code.google.com/p/pharo/wiki/LicenseAgreement. Send that to StÃ©phane. -- 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. 24, 2008

Re: [Pharo-project] About Flap

by Damien Cassou

On Wed, Sep 24, 2008 at 3:05 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Sep 24, 2008 at 1:55 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I would like to know what do we decided for Flaps? > > I like the way they are in dev images. You move the mouse to the right > side of the image and the flap opens. From there, you can drag&drop > your favorite tool. Do you have any faster way to open a browser or a > transcript? Note that latest versions of Microsoft Visual Studio now contains flaps too. -- 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. 24, 2008

Re: [Pharo-project] About Flap

by Damien Cassou

On Wed, Sep 24, 2008 at 1:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would like to know what do we decided for Flaps? I like the way they are in dev images. You move the mouse to the right side of the image and the flap opens. From there, you can drag&drop your favorite tool. Do you have any faster way to open a browser or a transcript? -- 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. 24, 2008

[Pharo-project] About traits support in OB

by David RÃ¶thlisberger

Hi, I'm not terribly happy with the current traits integration in OB. To browse traits used in a given class, we have this fourth switch next to instance / ? / class, called 'traits'. Clicking on it then lists in the next column all traits used in this class and the class itself. This additional column duplicates the switches instance / ? / class. For classes using traits you can see methods coming from traits in italic, methods defined but not implemented in a trait in normal font when browsing the class and in blue when browsing the trait. You also see the hierarchy of the used traits in this 'trait column'. But it's also possible to open this 'trait column' for classes that do not use any traits, this is very confusing. Also it's not nice to suddenly get five columns instead of four. My suggestions to better integrate traits is to show them below the classes using them directly in the class column, hierarchially sorted and marked either with an icon or with a colored label (eg. in blue). Like this we can get rid of this additional column and the additional 'trait' switch. The only problem I see with this change is that it might confuse people as traits are displayed along with all classes of a package/class cat in the class column, although they might not be part of neither the package/class cat nor the class hierarchy. What do you think, should I change it like this or not? Cheers, David

Sept. 24, 2008

[Pharo-project] Please use your name and not initial

by Torsten Bergmann

Hi Stef, that's me. It was just a basic test for committing to pharo income (just categorized an uncategorized method). You can drop the version and categorize the method yourself with a different name meanwhile (so actually it's not a license issue). Sorry for the confusion. Signed an agreement for Squeak already but it look like another one is required for Pharo. Where is the text and who should get a signed copy? Bye Torsten -- GMX Kostenlose Spiele: Einfach online spielen und SpaÃ haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

Sept. 24, 2008

Re: [Pharo-project] About Flap

by Marcus Denker

On 24.09.2008, at 13:55, StÃ©phane Ducasse wrote: > Hi guys > > we are applying our tools on pharo :) > and I would like to know what do we decided for Flaps? > I thought that we will remove this class. Yes, remove. Instead we should have a normal pull-down menu. (Like NewSpeak). And that actually should later be replaced by sophie style use of the operating system. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

[Pharo-project] Please use your name and not initial

by StÃ©phane Ducasse

Hi guys there is a Kernel-tbn in pharoInbox and this is important for us to know who is the person since we want him to sign the agreement (even if pubishing in the repository means that you license the code under MIT). Stef

Sept. 24, 2008

Re: [Pharo-project] About Flap

by Lukas Renggli

> we are applying our tools on pharo :) > and I would like to know what do we decided for Flaps? > I thought that we will remove this class. Yes, please remove the flaps. I always hide them anyway. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 24, 2008

[Pharo-project] About Flap

by StÃ©phane Ducasse

Hi guys we are applying our tools on pharo :) and I would like to know what do we decided for Flaps? I thought that we will remove this class. Stef

Sept. 24, 2008

Re: [Pharo-project] Re: Re: Re: First pharo-dev with limited package set+ aShout workspace where highlighting can be toggled

by Damien Cassou

On Wed, Sep 24, 2008 at 1:26 PM, Andrew Tween <amtween(a)hotmail.com> wrote: >> I think I found a bug : > I think I've fixed it - > http://www.squeaksource.com/shout/ShoutWorkspace.1-tween.4.mcz Indeed, thank you very much. -- 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. 24, 2008

[Pharo-project] Re: Re: Re: First pharo-dev with limited package set+ aShout workspace where highlighting can be toggled

by Andrew Tween

"Damien Cassou" <damien.cassou(a)gmail.com> wrote in message news:6ac749c10809240351o32c3b4f3qff0a9ba9988d851a@mail.gmail.com... > On Wed, Sep 24, 2008 at 9:02 AM, Andrew Tween <amtween(a)hotmail.com> wrote: >> It's here - >> http://www.squeaksource.com/shout/ShoutWorkspace.1-tween.3.mcz > > > I think I found a bug : > > 1- Open a shout workspace > 2- Activate syntax highlighting > 3- Type any non smalltalk text ('etekjkldg' for example) > 4- It appears in red which is correct > 5- Deactivate syntax highlighting > 6- It is still red which is incorrect Thanks, I think I've fixed it - http://www.squeaksource.com/shout/ShoutWorkspace.1-tween.4.mcz Cheers, Andy > > -- > 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 >

Sept. 24, 2008

Re: [Pharo-project] Re: Re: First pharo-dev with limited package set + aShout workspace where highlighting can be toggled

by Damien Cassou

On Wed, Sep 24, 2008 at 9:02 AM, Andrew Tween <amtween(a)hotmail.com> wrote: > It's here - http://www.squeaksource.com/shout/ShoutWorkspace.1-tween.3.mcz I think I found a bug : 1- Open a shout workspace 2- Activate syntax highlighting 3- Type any non smalltalk text ('etekjkldg' for example) 4- It appears in red which is correct 5- Deactivate syntax highlighting 6- It is still red which is incorrect -- 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. 24, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

> What about using the left *and* also the right side of the method list > to show icons... > > If we could use the right side for "optionnal" icons, that would be > still readable and we could have more icons. yes, but it gets very confusing when you have icons on the left and on the right. And when you only have icons on the right, then they are not getting the same attention as when they are on the left. It also depends whether you place the icons always directly after the method label, or in one vertical column whose position is decided by the longest method label in the list. The latter looks nicer, but has the problem that you don't see the icons when you have just one single very long method name in your list that takes more space than the column is width (which happens many times when browsing all methods of a class in my image). You then have to make your browser window bigger which is cumbersome. So I don't know whether this is a good solution. Icons should be easy to grasp visually and normally, as we read from left to right, this is achieved when they are on the left side. David

Sept. 24, 2008

Re: [Pharo-project] On Icons

by CÃ©drick BÃ©ler

What about using the left *and* also the right side of the method list to show icons... If we could use the right side for "optionnal" icons, that would be still readable and we could have more icons. Just a thought. CÃ©drick

Sept. 24, 2008

Re: [Pharo-project] [OT] Sophie in Java

by Nikolay Suslov

Some moments 'clear'!? From thier site? "Sophie... Developed by Astea in collaboration with Impara GmbH..." . On Tue, Sep 23, 2008 at 10:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hmm, maybe before blaming people, you should make some moments clear? > > For reading from their site http://asteasolutions.com/ > --- > Sophie has received key support from The Andrew W. Mellon Foundation > (http://www.mellon.org/) The Institute for the Future of the Book > designs and develops the tools and philosophy that will guide the form > and function of books as they evolve from the print-based format to a > digital format. Developed by Astea in collaboration with Impara GmbH > (http://www.impara.de/) of Magdeburg, Germany, and a team of the > world's leading Squeak experts, Sophie is the Institute's premiere > effort. > --- > > They have a references to origin, and maybe a point of > misunderstanding that they not clearly stating their goals? > I see nothing bad, if they like to adopt original idea using Java - it > is their own problem, after all. > > And before starting a war/conflict, try to resolve it peacefully - ask > them to rename the project, and ask to keep referencing to origin. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2008

Re: [Pharo-project] Re: about http://bugs.squeak.org/view.php?id=6336

by Marcus Denker

On 24.09.2008, at 09:02, StÃ©phane Ducasse wrote: > Thanks. > Another problem with real atomic loading. > > Stef > >> Hi Stef, >> >> there is nothing special with the two change sets except their >> fileIn order, since instances of Character are used while both of >> them are loaded and compiled ... >> >> The 3.10 release team attempted to make .mcz out of them but failed >> miserably, so I suggest you just file them in. >> >> Let me know how it worked for you; perhaps also see if before/after >> the .image indeed gets smaller by ca. 300 KB. >> >> Ah, and before I forget: because of Association #hash #= (since 3.8 >> or so, Marcus knows the problem), compilation of Unicode methods >> take looong, since one of its class variables has a populated >> SparseLarge* thing which is #hash'ed and #='ed when compiling >> access to each class variable :( But this is a genaral problem, >> which just manifests, when compiling Unicode, with pain. I added Association = while working on AOStA... I searched for a long time for some bug until I found that = was inherited from LookUpKey only taking the key into account. I checked with VW, and there it checks both key and value for =. What I then did is to add a hash, too. That was no good idea, as it makes now the #hash very slow. In VW, theu just use the #hash of LookUpKey. So: we should do the same. Keep =, but remove #hash. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

Re: [Pharo-project] [OT] Sophie in Java

by CÃ©drick BÃ©ler

maybe Pharo would have change that ? I don't know if we can blame people from beeing scared by squeak ;) I really think this is important Sophie continue to evolve to show Java is not the way to go. After seaside, this could be the second main ST project developped with it... My 2 cents. CÃ©drick 2008/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this is not the way politics works. > Apparently the founder was ready to found anything but squeak. > Strange no. > > Stef > > On Sep 23, 2008, at 10:13 PM, Igor Stasenko wrote: > >> Hmm, maybe before blaming people, you should make some moments clear? >> >> For reading from their site http://asteasolutions.com/ >> --- >> Sophie has received key support from The Andrew W. Mellon Foundation >> (http://www.mellon.org/) The Institute for the Future of the Book >> designs and develops the tools and philosophy that will guide the form >> and function of books as they evolve from the print-based format to a >> digital format. Developed by Astea in collaboration with Impara GmbH >> (http://www.impara.de/) of Magdeburg, Germany, and a team of the >> world's leading Squeak experts, Sophie is the Institute's premiere >> effort. >> --- >> >> They have a references to origin, and maybe a point of >> misunderstanding that they not clearly stating their goals? >> I see nothing bad, if they like to adopt original idea using Java - it >> is their own problem, after all. >> >> And before starting a war/conflict, try to resolve it peacefully - ask >> them to rename the project, and ask to keep referencing to origin. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- CÃ©drick

Sept. 24, 2008

[Pharo-project] Re: Re: First pharo-dev with limited package set + aShout workspace where highlighting can be toggled

by Andrew Tween

"Damien Cassou" <damien.cassou(a)gmail.com> wrote in message news:6ac749c10809232226h45195cecg94ba10fb82421a44@mail.gmail.com... > On Tue, Sep 23, 2008 at 9:47 PM, Andrew Tween <amtween(a)hotmail.com> wrote: >> Attached is a fileout of the Shout Workspace class, modified so that the >> Syntax Highlighting can be toggled from the title bar menu. >> see attached pic >> It remembers the last toggle value in a class inst var and uses that as >> the >> default for any new workspaces opened. >> This could easily be changed to be a real Preference setting. >> >> You can try it out in the pharo-dev image, just install it and open a new >> Workspace. >> >> What do people think? > > This is the best solution I think. Please post it to SqueakSource and > I will update the Universe. Thanks Damien, It's here - http://www.squeaksource.com/shout/ShoutWorkspace.1-tween.3.mcz Andy > > Thank you > > -- > 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 >

Sept. 24, 2008

[Pharo-project] Re: about http://bugs.squeak.org/view.php?id=6336

by StÃ©phane Ducasse

Thanks. Another problem with real atomic loading. Stef > Hi Stef, > > there is nothing special with the two change sets except their > fileIn order, since instances of Character are used while both of > them are loaded and compiled ... > > The 3.10 release team attempted to make .mcz out of them but failed > miserably, so I suggest you just file them in. > > Let me know how it worked for you; perhaps also see if before/after > the .image indeed gets smaller by ca. 300 KB. > > Ah, and before I forget: because of Association #hash #= (since 3.8 > or so, Marcus knows the problem), compilation of Unicode methods > take looong, since one of its class variables has a populated > SparseLarge* thing which is #hash'ed and #='ed when compiling access > to each class variable :( But this is a genaral problem, which just > manifests, when compiling Unicode, with pain. > > Cheers, > Klaus > > On Tue, 23 Sep 2008 21:52:35 +0200, StÃ©phane Ducasse wrote: > >> Hi klaus >> >> I would like to include the following in pharo >> about http://bugs.squeak.org/view.php?id=6336 >> >> can you tell me if I should pay attention to something in particular. >> >> Stef >> > >

Sept. 24, 2008

Re: [Pharo-project] Re: First pharo-dev with limited package set + a Shout workspace where highlighting can be toggled

by StÃ©phane Ducasse

Yes On Sep 23, 2008, at 10:29 PM, Adrian Lienhard wrote: > I like it. I think this is a good compromise. > Adrian > > On Sep 23, 2008, at 21:47 , Andrew Tween wrote: > >> Attached is a fileout of the Shout Workspace class, modified so >> that the Syntax Highlighting can be toggled from the title bar menu. >> see attached pic >> It remembers the last toggle value in a class inst var and uses >> that as the default for any new workspaces opened. >> This could easily be changed to be a real Preference setting. >> >> You can try it out in the pharo-dev image, just install it and open >> a new Workspace. >> >> What do people think? >> >> Cheers, >> Andy >> >> >> "Adrian Lienhard" <adi(a)netstyle.ch> wrote in message news:1E60C000-96B4-44FE-95F8-F19B951E0D41@netstyle.ch >> ... >> For sake of simplicity I would prefer to have just one menu item. I >> would put just the workspace without highlighting. Like Bill, I don't >> need my notes or code snippets in the workspace colorized. >> >> Which version of the workspace do people use most often? >> >> Adrian >> >> >> On Sep 23, 2008, at 13:58 , Damien Cassou wrote: >> >>> 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) >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> < >> SHWorkspace >> .st >> > >> < >> shworkspacetoggle.PNG>_______________________________________________ >> 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. 24, 2008

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

by StÃ©phane Ducasse

May be we should add this info in a class comment. This is why I should continue to work on this idea of a manisfesto per package. Stef On Sep 24, 2008, at 12:01 AM, Andrew Tween wrote: > > "Norbert Hartl" <norbert(a)hartl.name> wrote in message news:1222159745.9772.5.camel@localhost > ... >> 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. > > FreeTypeFontProvider current embedFilesInDirectory: aDirectory > will do this > >> >> Norbert > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2008

Re: [Pharo-project] [OT] Sophie in Java

by StÃ©phane Ducasse

this is not the way politics works. Apparently the founder was ready to found anything but squeak. Strange no. Stef On Sep 23, 2008, at 10:13 PM, Igor Stasenko wrote: > Hmm, maybe before blaming people, you should make some moments clear? > > For reading from their site http://asteasolutions.com/ > --- > Sophie has received key support from The Andrew W. Mellon Foundation > (http://www.mellon.org/) The Institute for the Future of the Book > designs and develops the tools and philosophy that will guide the form > and function of books as they evolve from the print-based format to a > digital format. Developed by Astea in collaboration with Impara GmbH > (http://www.impara.de/) of Magdeburg, Germany, and a team of the > world's leading Squeak experts, Sophie is the Institute's premiere > effort. > --- > > They have a references to origin, and maybe a point of > misunderstanding that they not clearly stating their goals? > I see nothing bad, if they like to adopt original idea using Java - it > is their own problem, after all. > > And before starting a war/conflict, try to resolve it peacefully - ask > them to rename the project, and ask to keep referencing to origin. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2008

Re: [Pharo-project] Re: First pharo-dev with limited package set + a Shout workspace where highlighting can be toggled

by Damien Cassou

On Tue, Sep 23, 2008 at 9:47 PM, Andrew Tween <amtween(a)hotmail.com> wrote: > Attached is a fileout of the Shout Workspace class, modified so that the > Syntax Highlighting can be toggled from the title bar menu. > see attached pic > It remembers the last toggle value in a class inst var and uses that as the > default for any new workspaces opened. > This could easily be changed to be a real Preference setting. > > You can try it out in the pharo-dev image, just install it and open a new > Workspace. > > What do people think? This is the best solution I think. Please post it to SqueakSource and I will update the Universe. Thank you -- 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. 24, 2008

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

by Damien Cassou

On Tue, Sep 23, 2008 at 5:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Maybe it would be better then to keep two options, but name them differently: > - simple text editor > - workspace I think that is the best solution. For the text editor, Stef also proposed TextPad. What do you prefer? -- 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. 24, 2008

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

by Andrew Tween

"Norbert Hartl" <norbert(a)hartl.name> wrote in message news:1222159745.9772.5.camel@localhost... > 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. FreeTypeFontProvider current embedFilesInDirectory: aDirectory will do this > > Norbert

Sept. 23, 2008

Re: [Pharo-project] Re: First pharo-dev with limited package set + a Shout workspace where highlighting can be toggled

by Norbert Hartl

Very good solution. Now we just have to discuss which is the default setting: on or off? :))) Norbert On Tue, 2008-09-23 at 20:47 +0100, Andrew Tween wrote: > Attached is a fileout of the Shout Workspace class, modified so that the > Syntax Highlighting can be toggled from the title bar menu. > see attached pic > It remembers the last toggle value in a class inst var and uses that as the > default for any new workspaces opened. > This could easily be changed to be a real Preference setting. > > You can try it out in the pharo-dev image, just install it and open a new > Workspace. > > What do people think? > > Cheers, > Andy > > > "Adrian Lienhard" <adi(a)netstyle.ch> wrote in > message news:1E60C000-96B4-44FE-95F8-F19B951E0D41@netstyle.ch... > For sake of simplicity I would prefer to have just one menu item. I > would put just the workspace without highlighting. Like Bill, I don't > need my notes or code snippets in the workspace colorized. > > Which version of the workspace do people use most often? > > Adrian > > > On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > > > 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) > > _______________________________________________ > > 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] Re: First pharo-dev with limited package set + a Shout workspace where highlighting can be toggled

by Adrian Lienhard

I like it. I think this is a good compromise. Adrian On Sep 23, 2008, at 21:47 , Andrew Tween wrote: > Attached is a fileout of the Shout Workspace class, modified so that > the Syntax Highlighting can be toggled from the title bar menu. > see attached pic > It remembers the last toggle value in a class inst var and uses that > as the default for any new workspaces opened. > This could easily be changed to be a real Preference setting. > > You can try it out in the pharo-dev image, just install it and open > a new Workspace. > > What do people think? > > Cheers, > Andy > > > "Adrian Lienhard" <adi(a)netstyle.ch> wrote in message news:1E60C000-96B4-44FE-95F8-F19B951E0D41@netstyle.ch > ... > For sake of simplicity I would prefer to have just one menu item. I > would put just the workspace without highlighting. Like Bill, I don't > need my notes or code snippets in the workspace colorized. > > Which version of the workspace do people use most often? > > Adrian > > > On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > >> 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) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > < > SHWorkspace > .st > > > <shworkspacetoggle.PNG>_______________________________________________ > 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] [OT] Sophie in Java

by Igor Stasenko

Hmm, maybe before blaming people, you should make some moments clear? For reading from their site http://asteasolutions.com/ --- Sophie has received key support from The Andrew W. Mellon Foundation (http://www.mellon.org/) The Institute for the Future of the Book designs and develops the tools and philosophy that will guide the form and function of books as they evolve from the print-based format to a digital format. Developed by Astea in collaboration with Impara GmbH (http://www.impara.de/) of Magdeburg, Germany, and a team of the world's leading Squeak experts, Sophie is the Institute's premiere effort. --- They have a references to origin, and maybe a point of misunderstanding that they not clearly stating their goals? I see nothing bad, if they like to adopt original idea using Java - it is their own problem, after all. And before starting a war/conflict, try to resolve it peacefully - ask them to rename the project, and ask to keep referencing to origin. -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2008

Re: [Pharo-project] [OT] Sophie in Java

by Michael Rueger

Janko MivÅ¡ek wrote: > Terrible indeed! And please, put the names of that guys in public, so > that we will know in the future, who to avoid for all costs. Because > this company is made out of people... well, yes. But I must really defend the little guys here, all very smart kids from the University there. They were basically caught on the wrong side of politics and IMHO to naive to know. Michael

Sept. 23, 2008

Re: [Pharo-project] [OT] Sophie in Java

by Janko MivÅ¡ek

Terrible indeed! And please, put the names of that guys in public, so that we will know in the future, who to avoid for all costs. Because this company is made out of people... Janko StÃ©phane Ducasse wrote: > Terrible! > I'm really sad. > And I went to give them lectures for free..... > No comment. > > > Stef > > >> Hi all, >> >> the Mellon foundation just approved the grant to Astea in Bulgaria to >> redevelop Sophie in Java! Astea (http://asteasolutions.com) are the >> nice guys that we trained and who then turned around, stating on their >> web site that they developed Sophie, took our Sophie documents and >> artwork for their proposal and managed to persuade Mellon to actually >> give them money... >> >> We moved the current Sophie project to http://opensophie.org, hoping >> to keep Sophie alive and making Sophie better than what they can come >> up with. >> >> And why I'm sending this to the Pharo list? >> Pharo already has so much promise as a base system, hopefully >> providing in the core already what we had to re-invent in Sophie >> because it didn't work in the main Squeak version. The Freetype stuff >> already turned out really well! Hopefully more to come. >> >> And once I finish these new etoys installers I can do some Pharo work >> too, hopefully ;-) >> >> >> Michael >> >> _______________________________________________ >> 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 > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Sept. 23, 2008

[Pharo-project] about http://bugs.squeak.org/view.php?id=6336

by StÃ©phane Ducasse

Hi klaus I would like to include the following in pharo about http://bugs.squeak.org/view.php?id=6336 can you tell me if I should pay attention to something in particular. Stef

Sept. 23, 2008

[Pharo-project] Re: First pharo-dev with limited package set + a Shout workspace where highlighting can be toggled

by Andrew Tween

Attached is a fileout of the Shout Workspace class, modified so that the Syntax Highlighting can be toggled from the title bar menu. see attached pic It remembers the last toggle value in a class inst var and uses that as the default for any new workspaces opened. This could easily be changed to be a real Preference setting. You can try it out in the pharo-dev image, just install it and open a new Workspace. What do people think? Cheers, Andy "Adrian Lienhard" <adi(a)netstyle.ch> wrote in message news:1E60C000-96B4-44FE-95F8-F19B951E0D41@netstyle.ch... For sake of simplicity I would prefer to have just one menu item. I would put just the workspace without highlighting. Like Bill, I don't need my notes or code snippets in the workspace colorized. Which version of the workspace do people use most often? Adrian On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > 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) > _______________________________________________ > 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] [OT] Sophie in Java

by StÃ©phane Ducasse

Terrible! I'm really sad. And I went to give them lectures for free..... No comment. Stef > Hi all, > > the Mellon foundation just approved the grant to Astea in Bulgaria > to redevelop Sophie in Java! Astea (http://asteasolutions.com) are > the nice guys that we trained and who then turned around, stating on > their web site that they developed Sophie, took our Sophie documents > and artwork for their proposal and managed to persuade Mellon to > actually give them money... > > We moved the current Sophie project to http://opensophie.org, hoping > to keep Sophie alive and making Sophie better than what they can > come up with. > > And why I'm sending this to the Pharo list? > Pharo already has so much promise as a base system, hopefully > providing in the core already what we had to re-invent in Sophie > because it didn't work in the main Squeak version. The Freetype > stuff already turned out really well! Hopefully more to come. > > And once I finish these new etoys installers I can do some Pharo > work too, hopefully ;-) > > > Michael > > _______________________________________________ > 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] First pharo-dev with limited package set

by StÃ©phane Ducasse

The problem is that preferences are a plague. So why not but .... > Stef, > > How about a preference for both? I generally find the color > annoying in workspaces, and _greatly_ appreciate shout in browsers > and the debugger. > > There is a preference to disable automatic definition of workspace > variables??? Great idea!!! I'm not a fan of them. > > 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 > > >>>> stephane.ducasse(a)inria.fr 9/23/2008 11:08:17 AM >>> > Damien > > I would go for the workspace with color. > and we should set the pref to have to type | | to declare varaibles. > > > stef > > On Sep 23, 2008, at 4:30 PM, Damien Cassou wrote: > >> On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> uh? does not work for me no idea what is a Smalltalk workspace. >> >> a workspace to write Smalltalk code as opposed to a workspace to >> write text. >> >> At the beginning, the ShoutWorkspace replaced the Workspace but some >> people complained. That's why there are two workspaces now. I've >> never >> used the non-colored workspace: when I want to write text, I enclose >> it in quotes. >> >> -- >> 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] First pharo-dev with limited package set

by StÃ©phane Ducasse

For notes we should call it TextPad and not workspace. Stef On Sep 23, 2008, at 8:03 PM, Bill Schwab wrote: > Damien, > > I thought about that, but it all get colored the way I LIKE having > my method comments colored - I do NOT<g> like that for my notes. > Shout is very helpful, and the rendering speed and stability are > nothing short of amazing. However, I want a choice in what I use > for a workspace, and it is almost always going to be plain text. > Having the two menu options is fine/preferred, but a preference > would work too. > > 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 > > >>>> damien.cassou(a)gmail.com 9/23/2008 9:30:05 AM >>> > On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> uh? does not work for me no idea what is a Smalltalk workspace. > > a workspace to write Smalltalk code as opposed to a workspace to > write text. > > At the beginning, the ShoutWorkspace replaced the Workspace but some > people complained. That's why there are two workspaces now. I've never > used the non-colored workspace: when I want to write text, I enclose > it in quotes. > > -- > 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 >

Sept. 23, 2008

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

by Bill Schwab

Stef, How about a preference for both? I generally find the color annoying in workspaces, and _greatly_ appreciate shout in browsers and the debugger. There is a preference to disable automatic definition of workspace variables??? Great idea!!! I'm not a fan of them. 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 >>> stephane.ducasse(a)inria.fr 9/23/2008 11:08:17 AM >>> Damien I would go for the workspace with color. and we should set the pref to have to type | | to declare varaibles. stef On Sep 23, 2008, at 4:30 PM, Damien Cassou wrote: > On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> uh? does not work for me no idea what is a Smalltalk workspace. > > a workspace to write Smalltalk code as opposed to a workspace to > write text. > > At the beginning, the ShoutWorkspace replaced the Workspace but some > people complained. That's why there are two workspaces now. I've never > used the non-colored workspace: when I want to write text, I enclose > it in quotes. > > -- > 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] First pharo-dev with limited package set

by Bill Schwab

Damien, I thought about that, but it all get colored the way I LIKE having my method comments colored - I do NOT<g> like that for my notes. Shout is very helpful, and the rendering speed and stability are nothing short of amazing. However, I want a choice in what I use for a workspace, and it is almost always going to be plain text. Having the two menu options is fine/preferred, but a preference would work too. 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 >>> damien.cassou(a)gmail.com 9/23/2008 9:30:05 AM >>> On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > uh? does not work for me no idea what is a Smalltalk workspace. a workspace to write Smalltalk code as opposed to a workspace to write text. At the beginning, the ShoutWorkspace replaced the Workspace but some people complained. That's why there are two workspaces now. I've never used the non-colored workspace: when I want to write text, I enclose it in quotes. -- 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] [ANN] Demo with both Truetype + Polymorph

by Hilaire Fernandes

Works like a charm on a classmate with windows xp. Hilaire 2008/9/21 Marcus Denker <denker(a)iam.unibe.ch>: > > Here is a Demo with TrueType fonts and Polymorph installed (only tested on > Mac). > > https://gforge.inria.fr/frs/download.php/7268/Pharo0.1-PolymorphTT.zip > > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

Sept. 23, 2008

Re: [Pharo-project] Tree View in OmniBrowser

by CÃ©drick BÃ©ler

>> >> Sound very interesting. Can you attach a small screenshoot for us who won't >> be able to test it directly? >> better than a screenshot, an image: http://cdrick.seasidehosting.st/resources/PharoOBTreeView.rar really cool :) CÃ©drick ps: sorry to use seasidehosting for that ;) but my ftp is too slow...

Sept. 23, 2008

[Pharo-project] [OT] Sophie in Java

by Michael Rueger

Hi all, the Mellon foundation just approved the grant to Astea in Bulgaria to redevelop Sophie in Java! Astea (http://asteasolutions.com) are the nice guys that we trained and who then turned around, stating on their web site that they developed Sophie, took our Sophie documents and artwork for their proposal and managed to persuade Mellon to actually give them money... We moved the current Sophie project to http://opensophie.org, hoping to keep Sophie alive and making Sophie better than what they can come up with. And why I'm sending this to the Pharo list? Pharo already has so much promise as a base system, hopefully providing in the core already what we had to re-invent in Sophie because it didn't work in the main Squeak version. The Freetype stuff already turned out really well! Hopefully more to come. And once I finish these new etoys installers I can do some Pharo work too, hopefully ;-) Michael

Sept. 23, 2008

Re: [Pharo-project] Tree View in OmniBrowser

by CÃ©drick BÃ©ler

Morever Janko, if you use OBEnhencement, and the OBPackageBrowser, you'll have the monticello command directly in the browser as you want ;)... Cheers, CÃ©drick 2008/9/23 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Hi David, > > Sound very interesting. Can you attach a small screenshoot for us who won't > be able to test it directly? > > Best regards > Janko > > David RÃ¶thlisberger wrote: >> >> Hello, >> >> It was very hard work, but finally and eventually I managed to integrate >> the tree >> view of Juraj in a reasonable way into OmniBrowser, so that we can use it >> for >> instance to browse packages. The package browser of OB-Enhancements is now >> using this >> tree in the first column to render packages on the first level and class >> categories >> on the second level. >> >> As this is a rather drastic change affecting also the underlying >> meta-model >> representing navigation in OB, I'd appreciate if some people give this a >> try and >> report any problems they might find to me. I extensively tested it, but >> you never know. >> I'm still working on some little things concerning this tree integration, >> mostly internal stuff, so nothing that should stand in way of using it >> already now. Just drop me a note if you encounter any problems, something >> that can still occur right now. >> >> >> Other recent enhancements include: >> >> - OB-TraitsIntegration is now part of OB-Enhancements as some people >> wanted to have it integrated in this package >> - mouse-over for icons in columns to get an explanation label >> - some icons are clickable, eg. to directly browse methods in superclasses >> - improvements in smart groups >> >> >> You need to load the following packages: >> >> OmniBrowser-dr.417 >> OB-Morphic-dr.54 >> OB-Standard-dr.351 >> OB-Enhancements-dr.207 >> >> >> ToDos: >> >> - refactor some of the code for the tree view >> - address several minor issues (eg. performance) >> - write more tests for tree view >> - integrate OmniBrowserFixes in OB-Enhancements >> >> >> Cheers, >> David > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Sept. 23, 2008

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

by StÃ©phane Ducasse

Damien I would go for the workspace with color. and we should set the pref to have to type | | to declare varaibles. stef On Sep 23, 2008, at 4:30 PM, Damien Cassou wrote: > On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> uh? does not work for me no idea what is a Smalltalk workspace. > > a workspace to write Smalltalk code as opposed to a workspace to > write text. > > At the beginning, the ShoutWorkspace replaced the Workspace but some > people complained. That's why there are two workspaces now. I've never > used the non-colored workspace: when I want to write text, I enclose > it in quotes. > > -- > 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

Sept. 23, 2008

Re: [Pharo-project] Tree View in OmniBrowser

by Janko MivÅ¡ek

Hi David, Sound very interesting. Can you attach a small screenshoot for us who won't be able to test it directly? Best regards Janko David RÃ¶thlisberger wrote: > Hello, > > It was very hard work, but finally and eventually I managed to integrate > the tree > view of Juraj in a reasonable way into OmniBrowser, so that we can use > it for > instance to browse packages. The package browser of OB-Enhancements is > now using this > tree in the first column to render packages on the first level and class > categories > on the second level. > > As this is a rather drastic change affecting also the underlying meta-model > representing navigation in OB, I'd appreciate if some people give this a > try and > report any problems they might find to me. I extensively tested it, but > you never know. > I'm still working on some little things concerning this tree > integration, mostly internal stuff, so nothing that should stand in way > of using it already now. Just drop me a note if you encounter any > problems, something that can still occur right now. > > > Other recent enhancements include: > > - OB-TraitsIntegration is now part of OB-Enhancements as some people > wanted to have it integrated in this package > - mouse-over for icons in columns to get an explanation label > - some icons are clickable, eg. to directly browse methods in superclasses > - improvements in smart groups > > > You need to load the following packages: > > OmniBrowser-dr.417 > OB-Morphic-dr.54 > OB-Standard-dr.351 > OB-Enhancements-dr.207 > > > ToDos: > > - refactor some of the code for the tree view > - address several minor issues (eg. performance) > - write more tests for tree view > - integrate OmniBrowserFixes in OB-Enhancements > > > Cheers, > David -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Sept. 23, 2008

[Pharo-project] Tree View in OmniBrowser

by David RÃ¶thlisberger

Hello, It was very hard work, but finally and eventually I managed to integrate the tree view of Juraj in a reasonable way into OmniBrowser, so that we can use it for instance to browse packages. The package browser of OB-Enhancements is now using this tree in the first column to render packages on the first level and class categories on the second level. As this is a rather drastic change affecting also the underlying meta-model representing navigation in OB, I'd appreciate if some people give this a try and report any problems they might find to me. I extensively tested it, but you never know. I'm still working on some little things concerning this tree integration, mostly internal stuff, so nothing that should stand in way of using it already now. Just drop me a note if you encounter any problems, something that can still occur right now. Other recent enhancements include: - OB-TraitsIntegration is now part of OB-Enhancements as some people wanted to have it integrated in this package - mouse-over for icons in columns to get an explanation label - some icons are clickable, eg. to directly browse methods in superclasses - improvements in smart groups You need to load the following packages: OmniBrowser-dr.417 OB-Morphic-dr.54 OB-Standard-dr.351 OB-Enhancements-dr.207 ToDos: - refactor some of the code for the tree view - address several minor issues (eg. performance) - write more tests for tree view - integrate OmniBrowserFixes in OB-Enhancements Cheers, David

Sept. 23, 2008

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

by Igor Stasenko

2008/9/23 Damien Cassou <damien.cassou(a)gmail.com>: > On Tue, Sep 23, 2008 at 2:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> uh? does not work for me no idea what is a Smalltalk workspace. > > a workspace to write Smalltalk code as opposed to a workspace to write text. > > At the beginning, the ShoutWorkspace replaced the Workspace but some > people complained. That's why there are two workspaces now. I've never > used the non-colored workspace: when I want to write text, I enclose > it in quotes. > I never use any advanced workspace features, only for holding a useful text like todos & doits. So, i don't care if it auto-colored or not, but i'd like to not have a magic like holding temp vars. As for me, a simple text editor and Alt-d/Alt-p shortcuts is more than enough to work efficiently :) Maybe it would be better then to keep two options, but name them differently: - simple text editor - workspace > -- > 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 > > -- 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 2:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > uh? does not work for me no idea what is a Smalltalk workspace. a workspace to write Smalltalk code as opposed to a workspace to write text. At the beginning, the ShoutWorkspace replaced the Workspace but some people complained. That's why there are two workspaces now. I've never used the non-colored workspace: when I want to write text, I enclose it in quotes. -- 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

[Pharo-project] SharedQueue Fixes from OLPC distro

by StÃ©phane Ducasse

http://tinlizzie.org/updates/etoys/updates 2009fixSharedQueue-b.. 2010fixSharedQueueAg..>

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

excellent! On Sep 23, 2008, at 2:44 PM, David RÃ¶thlisberger wrote: > >>> 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. >> Do you have the tree structure now? > > yes, I committed a working version just yesterday, but want to test > it a bit more today. I will probably announce it later today. > > > David > > _______________________________________________ > 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 StÃ©phane Ducasse

> >>>>>> - 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? >> or nothing when it is not? > > no, the case when it's not overridden is quite interesting as this > might be a hint for a problem (not needed abstract method or missing > override, etc.) I meant that a cyan triangle alone should reveal that. >> Try to come up with a nice model. >> Then after we should see how we can sell it also as a paper. > > ok, alright. > > > David > > _______________________________________________ > 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

>> 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. > Do you have the tree structure now? yes, I committed a working version just yesterday, but want to test it a bit more today. I will probably announce it later today. David

Sept. 23, 2008

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

by StÃ©phane Ducasse

for me the color is really nice because it gives iformation when I type a wrong selector. This is something that you get for free boxes in red means it does not exist box in grey means there is a boxSomething selector Stef On Sep 23, 2008, at 2:23 PM, Adrian Lienhard wrote: > For sake of simplicity I would prefer to have just one menu item. I > would put just the workspace without highlighting. Like Bill, I > don't need my notes or code snippets in the workspace colorized. > > Which version of the workspace do people use most often? > > Adrian > > > On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > >> 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) >> _______________________________________________ >> 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

>> 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? ;)) > > I can :) > I will try. Great! >>>>> - 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? > or nothing when it is not? no, the case when it's not overridden is quite interesting as this might be a hint for a problem (not needed abstract method or missing override, etc.) > Try to come up with a nice model. > Then after we should see how we can sell it also as a paper. ok, alright. David

Sept. 23, 2008

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

by Norbert Hartl

On Tue, 2008-09-23 at 14:23 +0200, Adrian Lienhard wrote: > For sake of simplicity I would prefer to have just one menu item. I > would put just the workspace without highlighting. Like Bill, I don't > need my notes or code snippets in the workspace colorized. > > Which version of the workspace do people use most often? > I use Shout not very often but every time I meet the colored workspace it annoys me :) The coloring in the code pane I like. It gives you back a little of this eclipse feeling. Wise chosen colours! :) my 2... Norbert > Adrian > > > On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > > > 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) > > _______________________________________________ > > 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] First pharo-dev with limited package set

by Tudor Girba

Hi, I think the one with color highlighting is the useful one for two reasons: - I would like to discourage people to put text/code that has no structure at all in the workspace. I would say that most of the highlighting problems in the workspace come from not putting a dot at the end of the line. This is a rather small cost to pay for having the colors working. - You can always disable the highlighting for a piece of text by putting it in a comment. Cheers, Doru On Sep 23, 2008, at 2:23 PM, Adrian Lienhard wrote: > For sake of simplicity I would prefer to have just one menu item. I > would put just the workspace without highlighting. Like Bill, I > don't need my notes or code snippets in the workspace colorized. > > Which version of the workspace do people use most often? > > Adrian > > On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > >> 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) >> _______________________________________________ >> 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] Fonts related from OLPC / rome also

by StÃ©phane Ducasse

to add more data related to fonts. http://www.nabble.com/Re%3A--squeak-dev---ANN--3.10-final-is-out-p16182045.… http://bugs.squeak.org/view.php?id=6523 http://bugs.squeak.org/view.php?id=6336 http://bugs.squeak.org/view.php?id=6520 (sounds like a hack) On Sep 23, 2008, at 2:05 PM, StÃ©phane Ducasse wrote: > 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 > > _______________________________________________ > 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] First pharo-dev with limited package set

by Adrian Lienhard

For sake of simplicity I would prefer to have just one menu item. I would put just the workspace without highlighting. Like Bill, I don't need my notes or code snippets in the workspace colorized. Which version of the workspace do people use most often? Adrian On Sep 23, 2008, at 13:58 , Damien Cassou wrote: > 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) > _______________________________________________ > 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] First pharo-dev with limited package set

by StÃ©phane Ducasse

On Sep 23, 2008, at 1:58 PM, Damien Cassou wrote: > 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? uh? does not work for me no idea what is a Smalltalk workspace. Let us kill one Shout workspace is always -> Workspace I would put the coloring workspace by default and if people do not like it they fix it. > > > -- > 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

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

On Sep 23, 2008, at 11:27 AM, David RÃ¶thlisberger wrote: > >> 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. Do you have the tree structure now? > > 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. Probably. Or we should have a set of icon that can be compose. Stef

Sept. 23, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

> >>> 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? ;)) I can :) I will try. now I think that you should try also with inkscape. The icons do not have to look good for now. We should get them right. After somebody with talent can relook them. > > >>>> - 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? or nothing when it is not? Try to come up with a nice model. Then after we should see how we can sell it also as a paper. > > > > David > > _______________________________________________ > 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 StÃ©phane Ducasse

yes priority is not good because it changes depending on the mixture. I think that we should experiment and build a conceptual model. Stef On Sep 23, 2008, at 11:10 AM, Lukas Renggli wrote: >>> 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 > > _______________________________________________ > 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 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

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