- Pharo-dev - lists.pharo.org

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

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

by Schwab,Wilhelm K

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

March 17, 2009

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

by John M McIntosh

On 16-Mar-09, at 2:21 PM, Adrian Lienhard 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??) This is part of the multiple window Ffenestri support people wailed for 5 years back, it's part of the EventSensor logic to at least support WindowEventMetricChange := 1. " size or position of window changed - value1-4 are left/top/right/bottom values " WindowEventClose := 2. " window close icon pressed " WindowEventIconise := 3. " window iconised or hidden etc " WindowEventActivated :=4. " window made active - some platforms only - do not rely upon this " WindowEventPaint := 5. " window area (in value1-4) needs updating. Some platforms do not need to send this, do not rely on it in image I believe MOST VMs now support the WindowEventClose via this logic so that people can choose to terminate an image by clicking on the close window button. I'd consider part of the base kernel since it's VM event related. > > - Compression (I think, does not need to be in the kernel) > - Sound (dito) Polymorph-Widgets-Themes uses RestSound, otherwise you could remove all of sound I think, I've done that for an iphone image. You need to alter the Object>beep logic to invoke (somehow) the primtiive beep sound, versus bring up an entire Sound subsystem to beep. > > - 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 16, 2009

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

by Adrian Lienhard

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

March 16, 2009