March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Removing more classes from Pharo

by Gary Chambers

Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, March 17, 2009 1:13 AM Subject: Re: [Pharo-project] Removing more classes from Pharo > Ffenestri is a possible route to host windows. I am *not* a "native > widgets or bust guy" (emulation has its points, performance under scaling > being high on the list), but there are reasons to want to use host windows > too. I would hesitate to remove this too quickly, unless Pinesoft tells > us there is a better way to meet the objective. > > Compression probably does not need to be in the kernel, but IMHO it does > belong in Pharo 1.0. Ditto sounds. Sound is something that people will > expect in a well-rounded system. Zip compression is required by Monticello, of course ;-) > > I'm all for cleaning out cruft, but things that are part of the releases > are probably more likely to get seen, used, and therefore have bugs > detected. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian > Lienhard > Sent: Monday, March 16, 2009 4:21 PM > To: Pharo Development > Subject: [Pharo-project] Removing more classes from Pharo > > In quest of modularizing Pharo and reducing its memory footprint, I > was wondering whether the following packages should be removed: > > - TrueType and related classes in Multilingual-Display (are obsolete > since we have FreeType, no?) > - Services (does not seem to be used, except by a subclass in Polymorph) > - Graphics-External-Ffenestri (why is this in the image??) > - Compression (I think, does not need to be in the kernel) > - Sound (dito) > - Traits-LocalSends and Traits-Requires (are not used) > - MorphicExtras (I assume at least some of those could extracted) > - ...? > > I would put these in a repository so they can be loaded if needed. The > extraction of some of these packages likely needs some work, but would > be a first step towards a more modular kernel. > > What do others think? > > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > 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

March 17, 2009

Re: [Pharo-project] World Graphics and Halos

by StÃ©phane Ducasse

do you have a nice little cs :) Stef On Mar 17, 2009, at 11:09 AM, Gary Chambers wrote: > If we are going to use the optimised general case in Morph (a valid > thing to do given the default drawOn: implementation) then I guess > we need to check all implementors of drawOn: to do a proper > areasRemainingToFill: if they are not standard and have non-opaque > regions. > > Changing HaloMorph>>defaultColor to answer Color transparent fixes > this one... In fact, for HaloMorph, #borderWidth should be overriden > with the showBoundsInHalo/World logic and #defaultBorderColor to > return Preferences menuSelectionColor. #drawOn: can then be removed. > > Regards, Gary > ----- Original Message ----- > From: Rob Rothwell > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, March 16, 2009 7:39 PM > Subject: Re: [Pharo-project] World Graphics and Halos > > Yes... > > Preferences resetHaloSpecifications "works," but notice that when > selecting a "plain old" Morph (like Morph new), it is overwritten by > the background color... > > Rob > > On Mon, Mar 16, 2009 at 3:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Ok I got it and I opened an issue. > > Stef > > On Mar 16, 2009, at 11:52 AM, Gary Chambers wrote: > > > Not one of mine... > > The halo item in question is the addPaintBgdHandle which is still > > present in > > the images but removed. > > Preferences resetHaloSpecifications needs to be invoked. > > > > Regards, Gary > > > > ----- Original Message ----- > > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > To: <Pharo-project(a)lists.gforge.inria.fr> > > Sent: Monday, March 16, 2009 10:12 AM > > Subject: Re: [Pharo-project] World Graphics and Halos > > > > > >> Once you arrive to a fix point > >> let me know what I should integrate. > >> Stef > >> > >> On Mar 15, 2009, at 12:24 PM, Gary Chambers wrote: > >> > >>> I noticed the halo problem in the dev image too. Resetting the > halo > >>> specs is needed since one has been removed... > >>> > >>> Regards, Gary > >>> ----- Original Message ----- > >>> From: Rob Rothwell > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Sent: Saturday, March 14, 2009 11:35 PM > >>> Subject: Re: [Pharo-project] World Graphics and Halos > >>> > >>> Yep...that seemed to fix it! > >>> > >>> Now if I could just figure out how to remove a Morph from the > World > >>> without Halos! > >>> > >>> If I do System->About it is so big now that it won't all fit on my > >>> screen, so I can't reach the ok button to close it and I am stuck > >>> with it! > >>> > >>> Rob > >>> > >>> On Sat, Mar 14, 2009 at 7:11 PM, Henrik Sperre Johansen > >>> <henrik.s.johansen(a)veloxit.no > >>>> wrote: > >>> Attached a .cs to the issue with a fix, also including the > solution > >>> Gary suggested for the taskbar-issue that was reported. > >>> (I don't know how to remove methods in .cs files, and haven't yet > >>> gotten around to learn how to make slices, so > >>> BorderedMorph>>areasRemainingToFill: would have to be removed by > >>> hand..) > >>> > >>> Cheers, > >>> Henry > >>> > >>> On 14.03.2009 22:04, Rob Rothwell wrote: > >>>> > >>>> Done. > >>>> > >>>> Issues 655 > >>>> > >>>> On Mar 14, 2009, at 8:14 PM, Rob Rothwell wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> Open up a 10250 dev image and click anywhere within the bounds > of > >>>>> the "Pharo" graphic. > >>>>> > >>>>> The world menu pops up and leaves part of itself behind when you > >>>>> click somewhere else on the screen. > >>> > >>> > >>> _______________________________________________ > >>> 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________… > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2009

Re: [Pharo-project] Losing click event

by Gary Chambers

Yeah, the otherworldySteppers is part of my cleanup script too ;-) (which deals with the TransferMorphs, I think). Regards, Gary ----- Original Message ----- From: "David RÃ¶thlisberger" <squeak(a)webcitas.ch> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 16, 2009 10:18 PM Subject: Re: [Pharo-project] Losing click event > >> Have you tried the following? >> TransferMorph allInstances do: [:ea | ea delete] > > or: > Utilities cleanseOtherWorldlySteppers > > David > >> from >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-December/133369… >> HTH, >> Adrian >> >> On Mar 16, 2009, at 17:17 , Hilaire Fernandes wrote: >> >>> No, there is no hidden morph. There is a variation in the bug, as for >>> some time I need to move slighly the mouse to get the clic event >>> handled. >>> I remove all Morph from screen including taskbar, does not get better. >>> I try with different theme >>> Nothing special in the process browser, at least no process I can >>> kill. >>> I saw it is reported in Mantis >>> http://bugs.squeak.org/view.php?id=7039 >>> >>> It seems the problem started to occure from a debugging session with >>> seaside >>> >>> >>> 2009/3/16 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>> Not seen that recently, since I fixed the DockingBar (if you use one) >>>> layering and the putting of minimised window (invisible with >>>> taskbar) well >>>> offscreen. Perhaps you have an inivisble Morph around (World >>>> submorphs >>>> should verify). >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- >>>> From: "Hilaire Fernandes" <hilaire(a)ofset.org> >>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, March 16, 2009 1:17 PM >>>> Subject: [Pharo-project] Losing click event >>>> >>>> >>>>> I have something strange happening in an image. >>>>> >>>>> Randomly, mouse click event seems to be lost. I have to click two or >>>>> three times to get the event handled. It happens anywhere in the >>>>> image. >>>>> Is there a way to fix that? >>>>> >>>>> Hilaire >>>>> -- >>>>> http://blog.ofset.org/hilaire >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> http://blog.ofset.org/hilaire >>> >>> _______________________________________________ >>> 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

March 17, 2009

Re: [Pharo-project] World Graphics and Halos

by Gary Chambers

If we are going to use the optimised general case in Morph (a valid thing to do given the default drawOn: implementation) then I guess we need to check all implementors of drawOn: to do a proper areasRemainingToFill: if they are not standard and have non-opaque regions. Changing HaloMorph>>defaultColor to answer Color transparent fixes this one... In fact, for HaloMorph, #borderWidth should be overriden with the showBoundsInHalo/World logic and #defaultBorderColor to return Preferences menuSelectionColor. #drawOn: can then be removed. Regards, Gary ----- Original Message ----- From: Rob Rothwell To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, March 16, 2009 7:39 PM Subject: Re: [Pharo-project] World Graphics and Halos Yes... Preferences resetHaloSpecifications "works," but notice that when selecting a "plain old" Morph (like Morph new), it is overwritten by the background color... Rob On Mon, Mar 16, 2009 at 3:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: Ok I got it and I opened an issue. Stef On Mar 16, 2009, at 11:52 AM, Gary Chambers wrote: > Not one of mine... > The halo item in question is the addPaintBgdHandle which is still > present in > the images but removed. > Preferences resetHaloSpecifications needs to be invoked. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 16, 2009 10:12 AM > Subject: Re: [Pharo-project] World Graphics and Halos > > >> Once you arrive to a fix point >> let me know what I should integrate. >> Stef >> >> On Mar 15, 2009, at 12:24 PM, Gary Chambers wrote: >> >>> I noticed the halo problem in the dev image too. Resetting the halo >>> specs is needed since one has been removed... >>> >>> Regards, Gary >>> ----- Original Message ----- >>> From: Rob Rothwell >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Saturday, March 14, 2009 11:35 PM >>> Subject: Re: [Pharo-project] World Graphics and Halos >>> >>> Yep...that seemed to fix it! >>> >>> Now if I could just figure out how to remove a Morph from the World >>> without Halos! >>> >>> If I do System->About it is so big now that it won't all fit on my >>> screen, so I can't reach the ok button to close it and I am stuck >>> with it! >>> >>> Rob >>> >>> On Sat, Mar 14, 2009 at 7:11 PM, Henrik Sperre Johansen >>> <henrik.s.johansen(a)veloxit.no >>>> wrote: >>> Attached a .cs to the issue with a fix, also including the solution >>> Gary suggested for the taskbar-issue that was reported. >>> (I don't know how to remove methods in .cs files, and haven't yet >>> gotten around to learn how to make slices, so >>> BorderedMorph>>areasRemainingToFill: would have to be removed by >>> hand..) >>> >>> Cheers, >>> Henry >>> >>> On 14.03.2009 22:04, Rob Rothwell wrote: >>>> >>>> Done. >>>> >>>> Issues 655 >>>> >>>> On Mar 14, 2009, at 8:14 PM, Rob Rothwell wrote: >>>> >>>>> Hi all, >>>>> >>>>> Open up a 10250 dev image and click anywhere within the bounds of >>>>> the "Pharo" graphic. >>>>> >>>>> The world menu pops up and leaves part of itself behind when you >>>>> click somewhere else on the screen. >>> >>> >>> _______________________________________________ >>> 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

March 17, 2009

Re: [Pharo-project] Losing click event

by Hilaire Fernandes

yes it help, thanks Hilaire 2009/3/16 Adrian Lienhard <adi(a)netstyle.ch>: > Have you tried the following? > TransferMorph allInstances do: [:ea | ea delete] > from http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-December/133369… > HTH, > Adrian > > On Mar 16, 2009, at 17:17 , Hilaire Fernandes wrote: > >> No, there is no hidden morph. There is a variation in the bug, as for >> some time I need to move slighly the mouse to get the clic event >> handled. >> I remove all Morph from screen including taskbar, does not get better. >> I try with different theme >> Nothing special in the process browser, at least no process I can >> kill. >> I saw it is reported in Mantis >> http://bugs.squeak.org/view.php?id=7039 >> >> It seems the problem started to occure from a debugging session with >> seaside >> >> >> 2009/3/16 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> Not seen that recently, since I fixed the DockingBar (if you use one) >>> layering and the putting of minimised window (invisible with >>> taskbar) well >>> offscreen. Perhaps you have an inivisble Morph around (World >>> submorphs >>> should verify). >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Hilaire Fernandes" <hilaire(a)ofset.org> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, March 16, 2009 1:17 PM >>> Subject: [Pharo-project] Losing click event >>> >>> >>>> I have something strange happening in an image. >>>> >>>> Randomly, mouse click event seems to be lost. I have to click two or >>>> three times to get the event handled. It happens anywhere in the >>>> image. >>>> Is there a way to fix that? >>>> >>>> Hilaire >>>> -- >>>> http://blog.ofset.org/hilaire >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> http://blog.ofset.org/hilaire >> >> _______________________________________________ >> 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 > -- http://blog.ofset.org/hilaire

March 17, 2009

Re: [Pharo-project] [ANN] 10252

by Damien Cassou

On Tue, Mar 17, 2009 at 4:35 AM, Sebastian Sastre <ssastre(a)seaswork.com> wrote: > noob question: downloadable from? > or is just updating a 243? All downloadable versions are in: https://gforge.inria.fr/frs/?group_id=1299 If you can't find in you have to update. -- Damien Cassou http://damiencassou.seasidehosting.st

March 17, 2009

Re: [Pharo-project] Removing more classes from Pharo

by StÃ©phane Ducasse

I would make a distinction between rot code in the image and working and ok code. for the working and ok code I would make sure that we can unload and reload it. and keep it for now. I think that the first goal of pharo is not to be smallish but to be good and modular. So during that process we should avoid to break code that is working. In particular it does not mean that because we don't use it, it is not useful. Stef On Mar 16, 2009, at 11:44 PM, Adrian Lienhard wrote: > Hi Pavel, > > Nice to see others interested and working on this too :) > > If I apply my cleanup script on your image (see > ScriptLoader>>cleanUpForRelease) I get an image size of 8.6MB, cool! > (A standard Pharo core image is reduced to 9.1MB if you also remove > the MC ancestory). > > I think we should > - step by step extract packages and classes from Pharo core that are > not used anymore > - create a shrink script that allows one to further reduce a Pharo > core image (like removing FreeType) > > Latter would allow us to create minimal Pharo images e.g., for > deployment. > > Could you publish the changes you made so far so we can incorporate > them? > > Cheers, > Adrian > > On Mar 16, 2009, at 22:38 , Pavel Krivanek wrote: > >> Hi Adrian, >> >> I've tried to do some steps in this direction so here's a little >> cleaned exerimental image without sound, with less unimplemented >> calls >> etc.: http://comtalk.eu/public/pub/pharo/Pharo0.1Core-10248.9.zip >> >> FreeType package can be removeable, in fact it is easier to remove >> that TrueType. >> >> -- Pavel >> >> On Mon, Mar 16, 2009 at 10:21 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> In quest of modularizing Pharo and reducing its memory footprint, I >>> was wondering whether the following packages should be removed: >>> >>> - TrueType and related classes in Multilingual-Display (are obsolete >>> since we have FreeType, no?) >>> - Services (does not seem to be used, except by a subclass in >>> Polymorph) >>> - Graphics-External-Ffenestri (why is this in the image??) >>> - Compression (I think, does not need to be in the kernel) >>> - Sound (dito) >>> - Traits-LocalSends and Traits-Requires (are not used) >>> - MorphicExtras (I assume at least some of those could extracted) >>> - ...? >>> >>> I would put these in a repository so they can be loaded if needed. >>> The >>> extraction of some of these packages likely needs some work, but >>> would >>> be a first step towards a more modular kernel. >>> >>> What do others think? >>> >>> Adrian >>> >>> ___________________ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> _______________________________________________ >>> 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 >

March 17, 2009

Re: [Pharo-project] Removing more classes from Pharo

by StÃ©phane Ducasse

The problem is that we should work that way - make a package unloadable/loadable - since we are still fixing a lot the packages should be loaded when we do change (else they will rot). - but first I would go for the closure image > - TrueType and related classes in Multilingual-Display (are obsolete > since we have FreeType, no?) > - Services (does not seem to be used, except by a subclass in > Polymorph) > - Graphics-External-Ffenestri (why is this in the image??) > - Compression (I think, does not need to be in the kernel) > - Sound (dito) > - Traits-LocalSends and Traits-Requires (are not used) if unused then we should remove them > > - MorphicExtras (I assume at least some of those could extracted) > - ...? > > I would put these in a repository so they can be loaded if needed. The > extraction of some of these packages likely needs some work, but would > be a first step towards a more modular kernel. > > What do others think? > > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 17, 2009

Re: [Pharo-project] [ANN] 10252

by Sebastian Sastre

noob question: downloadable from? or is just updating a 243? sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Stephane Ducasse > Enviado el: Friday, March 13, 2009 18:27 > Para: Pharo Development > Asunto: [Pharo-project] [ANN] 10252 > > Added BoundedGradientFillStyle. > Standard Squeak uses original menu pin form. > Tweaked appearance of drop lists for Watery 2 as an interim measure. > Fixed positioning of drop list pop-up-list to deal with > transforms (no > rotation though ;-) ) (thanks Alain) > > Removed "revert" option in patch browser for MC 1.0 compatability. > Handle missing remote definition when selecting next conflict. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2009

Re: [Pharo-project] Removing more classes from Pharo

by Michael Rueger

Schwab,Wilhelm K wrote: > Ffenestri is a possible route to host windows. I am *not* a "native > widgets or bust guy" (emulation has its points, performance under > scaling being high on the list), but there are reasons to want to use > host windows too. I would hesitate to remove this too quickly, And using host windows doesn't mean you need to use native widgets, so it isn't an all or nothing question. Using just what is already there I managed to work with multiple host windows and Rome in some experimental hacking, so we should definitely work towards keeping/supporting this core FFenestri functionality. Michael

March 17, 2009