- Pharo-dev - lists.pharo.org

[Pharo-project] Alien on powerpc

by John M McIntosh

I've check in a number of changes into the main SVN tree, and into the Alien MC to start to providing support for PowerPC. I do have a somewhat functional api on the cpu type now, we are still working some details about how to deal with Float/Double versus integer, and I've yet to tackle the callback logic assembler. Tomorrow if I make more progress I'll check in the assembler/glue code for the PowerPC call pattern. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Dec. 7, 2008

Re: [Pharo-project] Magma + FreeType font

by Hilaire Fernandes

Some correction, the VM also crashes with former (original) image. I guess I did not see the crash on the original image because the Morph was still in memory when I was fetching it from the database. So it is very likely there is something wrong from me in the way I extended the LogicalFont persistence with proxy. I will look at that code but I don't understand much the persistence mechanism of the object, I will need some light from Chris. Hilaire 2008/12/6 Hilaire Fernandes <hilaire(a)ofset.org>: > Hello Andrew, > > Thanks for you tips and to take time to answer to me. > > I may need to describe the context of the second image I am using to > fetch the persisted Morph. > It is the same image, in a different folder, without source and change files. > But when fetching the Morph from this image, the whole VM crash (see > the previous log file). > If I fetch the morph from the former image, it is fine. > > Does it indicate to you some causes of the problem? > > Hilaire > > > 2008/12/6 Andrew Tween <amtween(a)hotmail.com>: >> Hi Hilaire, >> >>> Date: Sat, 6 Dec 2008 12:42:16 +0100 >>> From: hilaire(a)ofset.org >>> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr >>> Subject: Magma + FreeType font >>> >>> I am now using Pharo with FreeType fonts + Magmar41.1. >>> >>> The font I am using use the LogicalFont class (this is how I declare in >>> my code the TT font I am using). >>> >>> I have extended LogicalFont to get it persisted: >>> >>> First with a new way to instantiate it: >>> >>> LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: >>> code >>> >>> ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; >>> yourself >>> >>> Then three methods for persistence, I copied the existing TType class >>> persistence methods: >>> >>> maAsStorageObject >>> "I am about to be written on an object file. Write a >>> reference to a known FontSet in the other system instead." >>> "a path to me" >>> ^ DiskProxy >>> global: #LogicalFont >>> selector: #familyName:pointSize:emphasis: >>> args: { >>> (self familyName). >>> (self pointSize). >>> (self emphasis) >>> } >>> >> >> Have a look at LogicalFont>>#objectForDataStream: >> It is doing something similar to your method, and is creating a DiskProxy >> for DataStreams... >> DiskProxy global: #LogicalFont selector: >> #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: >> args: {self familyName. self fallbackFamilyNames. self pointSize. self >> stretchValue. self weightValue. self slantValue}. >> >> Your code looks ok to me and should work fine; but you might try creating a >> DiskProxy in the manner above, and see if that cures your problem. >> >> If that doesn't fix it, then do you have an image (+ database) that you can >> share so I can investigate further? >> >> Thanks, >> Andy >> >> >>> maUsesStandardStorage >>> >>> ^ false >>> >>> maWantsPreSerialization >>> ^ true >>> >>> >>> Basically these methods are used when I am persisting in the Magma >>> Database a morph with some text. >>> >>> Now when I am fetching such Morph from the Magma data base in another >>> image (with the same code extension) I got a Segmentation fault (the >>> trace is included there). >>> >>> The crash is clearly happening in FreeType code, in the primitive >>> called from FT2Face>setPixelWidth:height: >>> >>> Probably I got something wrong in my persistence code, I will be more >>> than happy with any kind of tips. >>> >>> Thanks, >>> >>> Hilaire >> >> >> ________________________________ >> Win John Lewis vouchers with BigSnapSearch.com Search now > > > > -- > http://blog.ofset.org/hilaire > -- http://blog.ofset.org/hilaire

Dec. 6, 2008

Re: [Pharo-project] Magma + FreeType font

by Hilaire Fernandes

Hello Andrew, Thanks for you tips and to take time to answer to me. I may need to describe the context of the second image I am using to fetch the persisted Morph. It is the same image, in a different folder, without source and change files. But when fetching the Morph from this image, the whole VM crash (see the previous log file). If I fetch the morph from the former image, it is fine. Does it indicate to you some causes of the problem? Hilaire 2008/12/6 Andrew Tween <amtween(a)hotmail.com>: > Hi Hilaire, > >> Date: Sat, 6 Dec 2008 12:42:16 +0100 >> From: hilaire(a)ofset.org >> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr >> Subject: Magma + FreeType font >> >> I am now using Pharo with FreeType fonts + Magmar41.1. >> >> The font I am using use the LogicalFont class (this is how I declare in >> my code the TT font I am using). >> >> I have extended LogicalFont to get it persisted: >> >> First with a new way to instantiate it: >> >> LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: >> code >> >> ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; >> yourself >> >> Then three methods for persistence, I copied the existing TType class >> persistence methods: >> >> maAsStorageObject >> "I am about to be written on an object file. Write a >> reference to a known FontSet in the other system instead." >> "a path to me" >> ^ DiskProxy >> global: #LogicalFont >> selector: #familyName:pointSize:emphasis: >> args: { >> (self familyName). >> (self pointSize). >> (self emphasis) >> } >> > > Have a look at LogicalFont>>#objectForDataStream: > It is doing something similar to your method, and is creating a DiskProxy > for DataStreams... > DiskProxy global: #LogicalFont selector: > #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: > args: {self familyName. self fallbackFamilyNames. self pointSize. self > stretchValue. self weightValue. self slantValue}. > > Your code looks ok to me and should work fine; but you might try creating a > DiskProxy in the manner above, and see if that cures your problem. > > If that doesn't fix it, then do you have an image (+ database) that you can > share so I can investigate further? > > Thanks, > Andy > > >> maUsesStandardStorage >> >> ^ false >> >> maWantsPreSerialization >> ^ true >> >> >> Basically these methods are used when I am persisting in the Magma >> Database a morph with some text. >> >> Now when I am fetching such Morph from the Magma data base in another >> image (with the same code extension) I got a Segmentation fault (the >> trace is included there). >> >> The crash is clearly happening in FreeType code, in the primitive >> called from FT2Face>setPixelWidth:height: >> >> Probably I got something wrong in my persistence code, I will be more >> than happy with any kind of tips. >> >> Thanks, >> >> Hilaire > > > ________________________________ > Win John Lewis vouchers with BigSnapSearch.com Search now -- http://blog.ofset.org/hilaire

Dec. 6, 2008

Re: [Pharo-project] Magma + FreeType font

by Andrew Tween

Hi Hilaire,> Date: Sat, 6 Dec 2008 12:42:16 +0100> From: hilaire(a)ofset.org> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr> Subject: Magma + FreeType font> > I am now using Pharo with FreeType fonts + Magmar41.1.> > The font I am using use the LogicalFont class (this is how I declare in > my code the TT font I am using).> > I have extended LogicalFont to get it persisted:> > First with a new way to instantiate it:> > LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: > code> > ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; yourself> > Then three methods for persistence, I copied the existing TType class > persistence methods:> > maAsStorageObject> "I am about to be written on an object file. Write a> reference to a known FontSet in the other system instead."> "a path to me"> ^ DiskProxy> global: #LogicalFont> selector: #familyName:pointSize:emphasis:> args: {> (self familyName).> (self pointSize).> (self emphasis)> }> Have a look at LogicalFont>>#objectForDataStream: It is doing something similar to your method, and is creating a DiskProxy for DataStreams... DiskProxy global: #LogicalFont selector: #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: args: {self familyName. self fallbackFamilyNames. self pointSize. self stretchValue. self weightValue. self slantValue}. Your code looks ok to me and should work fine; but you might try creating a DiskProxy in the manner above, and see if that cures your problem. If that doesn't fix it, then do you have an image (+ database) that you can share so I can investigate further? Thanks, Andy > maUsesStandardStorage> > ^ false> > maWantsPreSerialization> ^ true> > > Basically these methods are used when I am persisting in the Magma > Database a morph with some text.> > Now when I am fetching such Morph from the Magma data base in another > image (with the same code extension) I got a Segmentation fault (the > trace is included there).> > The crash is clearly happening in FreeType code, in the primitive > called from FT2Face>setPixelWidth:height:> > Probably I got something wrong in my persistence code, I will be more > than happy with any kind of tips.> > Thanks,> > Hilaire _________________________________________________________________ Imagine a life without walls.Â See the possibilities. http://clk.atdmt.com/UKM/go/122465943/direct/01/

Dec. 6, 2008

Re: [Pharo-project] Removing a trait from a class

by StÃ©phane Ducasse

I think that the trait should be used in multiple classes :) > I already tried, but I still cannot reproduce the problem. I take a > fresh 185 image and create a class with two traits and remove a trait > and everything works as expected. > > This is really strange. I wonder where the method with the comment > "This method does not exist." comes from. May be the browser > > > One problem I found occurs when you remove a trait on the class side. > The reason is that Metaclass recently was modified. But this is > something else (and the tests document the problem). > > I think the simplest way to track that down is if you can give me an > image in this state so that I can dig into it. Or even better, if > possible, to explain me how I can reproduce the problem. Take a collection tests and remove a trait stef > > > Adrian > > On Dec 5, 2008, at 16:56 , StÃ©phane Ducasse wrote: > >> adrian when you will work on traits, you should really add two traits >> to a class and remove one to see >> the problem. >> Now I have the traits method inside the class with probably something >> generated. >> >> testCopyEmpty >> "This method does not exist." >> self halt. >> >> On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: >> >>> I was using the package browser >>> >>> Stef >>> >>> On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: >>> >>>> ok, we need to take a closer look at this, >>>> Do you remember which browser you used? If Omnibrowser, do you also >>>> know which one? >>>> Adrian >>>> >>>> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >>>> >>>>> Adrian >>>>> I got some problems during the last smalltalk party at paris. >>>>> my pair programmer quitted the image without saving and when I >>>>> reloaded the changes it was a mess. >>>>> I could not remove methods from a class. The methods were not in >>>>> the method dictionary but their names showed >>>>> up in the browser.... The class organizer had them in. I would >>>>> love to check the classorganizer concept :) >>>>> I could not remove the traits from the class. >>>>> >>>>> Stef >>>>> >>>>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>>>> >>>>>> Hi Hilaire, >>>>>> >>>>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>>>> shipped with the Core image. >>>>>> Could you try to reproduce the problem in a newer version of >>>>>> Pharo? (10050 is *very* old). >>>>>> >>>>>> I'd like to take a look then. It's strange because we have been >>>>>> using traits for two years now without seeing this problem. So it >>>>>> may indeed be a problem related to the UI that somehow brings >>>>>> traits into an inconsistent state. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>>>> >>>>>>> I can't remove a trait from a class using UI tools. (pharo >>>>>>> 10050) >>>>>>> How can I remove it programmatically ? >>>>>>> >>>>>>> Next with this same class, message from this trait are not >>>>>>> reachable, >>>>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>>>> is not >>>>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>>>> trait >>>>>>> as IFIEtayage. >>>>>>> It looks like there is mismatch in the classes with traits. (see >>>>>>> screenshot) >>>>>>> >>>>>>> Now I realize my last istoa release suffer from this problem :) >>>>>>> >>>>>>> Hilaire >>>>>>> >>>>>>> -- >>>>>>> http://blog.ofset.org/hilaire >>>>>>> <bug-trait.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 >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 >

Dec. 5, 2008

Re: [Pharo-project] Removing a trait from a class

by Adrian Lienhard

I already tried, but I still cannot reproduce the problem. I take a fresh 185 image and create a class with two traits and remove a trait and everything works as expected. This is really strange. I wonder where the method with the comment "This method does not exist." comes from. One problem I found occurs when you remove a trait on the class side. The reason is that Metaclass recently was modified. But this is something else (and the tests document the problem). I think the simplest way to track that down is if you can give me an image in this state so that I can dig into it. Or even better, if possible, to explain me how I can reproduce the problem. Adrian On Dec 5, 2008, at 16:56 , StÃ©phane Ducasse wrote: > adrian when you will work on traits, you should really add two traits > to a class and remove one to see > the problem. > Now I have the traits method inside the class with probably something > generated. > > testCopyEmpty > "This method does not exist." > self halt. > > On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: > >> I was using the package browser >> >> Stef >> >> On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: >> >>> ok, we need to take a closer look at this, >>> Do you remember which browser you used? If Omnibrowser, do you also >>> know which one? >>> Adrian >>> >>> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >>> >>>> Adrian >>>> I got some problems during the last smalltalk party at paris. >>>> my pair programmer quitted the image without saving and when I >>>> reloaded the changes it was a mess. >>>> I could not remove methods from a class. The methods were not in >>>> the method dictionary but their names showed >>>> up in the browser.... The class organizer had them in. I would >>>> love to check the classorganizer concept :) >>>> I could not remove the traits from the class. >>>> >>>> Stef >>>> >>>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>>> >>>>> Hi Hilaire, >>>>> >>>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>>> shipped with the Core image. >>>>> Could you try to reproduce the problem in a newer version of >>>>> Pharo? (10050 is *very* old). >>>>> >>>>> I'd like to take a look then. It's strange because we have been >>>>> using traits for two years now without seeing this problem. So it >>>>> may indeed be a problem related to the UI that somehow brings >>>>> traits into an inconsistent state. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>>> >>>>>> I can't remove a trait from a class using UI tools. (pharo 10050) >>>>>> How can I remove it programmatically ? >>>>>> >>>>>> Next with this same class, message from this trait are not >>>>>> reachable, >>>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>>> is not >>>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>>> trait >>>>>> as IFIEtayage. >>>>>> It looks like there is mismatch in the classes with traits. (see >>>>>> screenshot) >>>>>> >>>>>> Now I realize my last istoa release suffer from this problem :) >>>>>> >>>>>> Hilaire >>>>>> >>>>>> -- >>>>>> http://blog.ofset.org/hilaire >>>>>> <bug-trait.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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 5, 2008

Re: [Pharo-project] Removing a trait from a class

by StÃ©phane Ducasse

adrian when you will work on traits, you should really add two traits to a class and remove one to see the problem. Now I have the traits method inside the class with probably something generated. testCopyEmpty "This method does not exist." self halt. On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: > I was using the package browser > > Stef > > On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: > >> ok, we need to take a closer look at this, >> Do you remember which browser you used? If Omnibrowser, do you also >> know which one? >> Adrian >> >> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >> >>> Adrian >>> I got some problems during the last smalltalk party at paris. >>> my pair programmer quitted the image without saving and when I >>> reloaded the changes it was a mess. >>> I could not remove methods from a class. The methods were not in >>> the method dictionary but their names showed >>> up in the browser.... The class organizer had them in. I would >>> love to check the classorganizer concept :) >>> I could not remove the traits from the class. >>> >>> Stef >>> >>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>> >>>> Hi Hilaire, >>>> >>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>> shipped with the Core image. >>>> Could you try to reproduce the problem in a newer version of >>>> Pharo? (10050 is *very* old). >>>> >>>> I'd like to take a look then. It's strange because we have been >>>> using traits for two years now without seeing this problem. So it >>>> may indeed be a problem related to the UI that somehow brings >>>> traits into an inconsistent state. >>>> >>>> Adrian >>>> >>>> >>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>> >>>>> I can't remove a trait from a class using UI tools. (pharo 10050) >>>>> How can I remove it programmatically ? >>>>> >>>>> Next with this same class, message from this trait are not >>>>> reachable, >>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>> is not >>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>> trait >>>>> as IFIEtayage. >>>>> It looks like there is mismatch in the classes with traits. (see >>>>> screenshot) >>>>> >>>>> Now I realize my last istoa release suffer from this problem :) >>>>> >>>>> Hilaire >>>>> >>>>> -- >>>>> http://blog.ofset.org/hilaire >>>>> <bug-trait.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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >

Dec. 5, 2008

[Pharo-project] about merge tool

by StÃ©phane Ducasse

Hi I got some problems with the new merge tool - I do not succeed to say which changes I want to keep and reject all the actions are grey - when I click on the small green arrow in bteween the two panes I get an error - the modal interaction make difficult to copy and paste changes in case we want to do that. Stef

Dec. 5, 2008

Re: [Pharo-project] Inspector Gadget

by StÃ©phane Ducasse

It is not this is that the servers were migrated today and yesterday On Dec 5, 2008, at 3:28 PM, David Pennell wrote: > [this bounced yesterday] > > OK - where is the agreement? The link on http://code.google.com/p/pharo/wiki/LicenseAgreement > is broken. > > On Thu, Dec 4, 2008 at 4:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > +1 > send the code and sign the agreement :) > > Stef > On Dec 4, 2008, at 1:32 AM, David Pennell wrote: > > > We currently have both "inspect" and "explore". It would be nice to > > have one tool. I'd vote for "explore" as a base with some > > enhancements to pick up the useful features from "inspect". > > > > -david > > _______________________________________________ > > 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

Dec. 5, 2008

[Pharo-project] about UI

by StÃ©phane Ducasse

Hi I would like to ask you if you do not get the same proble, as me. When I do not know an application I try to clik on the pane to see if there is a menu and it is like blind testing... It would be great if the mouse would change when the pane can display a menu. Stef

Dec. 5, 2008