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

Re: [Pharo-project] Re: Removing default fonts

by Antony Blakey

On 21/10/2008, at 2:52 AM, StÃ©phane Ducasse wrote: > First let's remove all the etoys/BookMorph > Second clean Morphic > Third clean a lot of the rest > Fourth then we should be in position to have a smaller kernel > and may be someone will start to clean and refactor the fonts. But these don't really define the purpose of Pharo e.g. Who is the intended audience? In this thread it's already been determined that Pharo 'Must not require FreeType', and someone said 'Must run on bare metal' and 'Must not require external libraries'. Those are the kind of constraints that would immediately define what can be added and what removed. Another important class of constraints would be what packages must not be broken e.g. must Whisker still work?, and thus what packages can/ should be removed. And there must be some context behind wanting to remove eToys/ BookMorph. Is it obsolete/unused? Is it used only by a class of user that you explicitly don't wish to target? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Success is not the key to happiness. Happiness is the key to success. -- Albert Schweitzer

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Adrian Lienhard

Hi Markus, Have a look at StrikeFont>>writeAsStrike2named: and #readFromStrike2:. I assume with these methods you can write out the existing strike fonts and read them in again. I would not care about the existing TT fonts as they are in low quality (i.e., blurry, probably because of missing sub-pixel AA). I think that, at least for now, we should leave the two strike fonts I propose in the system and not remove the whole font implementation to not depend on the platform specific free type font implementation. This also leaves the possibility to remove the free type functionality for server images to reduce the memory footprint. Adrian On Oct 17, 2008, at 20:59 , Markus Fritsche wrote: > StÃ©phane Ducasse schrieb: > >>> So basically, I'd like to vote for "remove and make loadable steph >>> by >>> steph" > >> step by step because steph is too buzy :) >> Markus we hear well your wishes now the best way to make it real >> is to send us some code :) > > Just fair. I'll see what I can up with to load fonts by request with > the > tools supplied within a vanilla pharo image and a given URL (don't > nail > me on that, I'm known not to keep promises). > > I guess if I will contribute code I will have to give a signature and > mail it, right!? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Dan Corneanu

On Mon, Oct 20, 2008 at 10:09 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Oct 20, 2008 at 8:57 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: >> Here is a change set with the proper fix for the issue. > > What was the problem with the other one? > If you search for a package whose category is already selected, the UI will not be properly updated. Other subclasses of OBNode implement a domain related ancestrySelector, like isDescendantOfClass: or isDescendantOfClassCat:. So, I have also implemented methods isDescendantOfUniverse:, isDescendantOfCategory:and isDescendantOfPackage:. P.S. Even the last changeset has a flaw, the method OBColumnPanel>>hopTo: aNode should use column refreshAndSignal: true instead column refreshAnd or else the right most panel in the browser will not be properly updated.

Oct. 20, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Damien Cassou

On Mon, Oct 20, 2008 at 8:57 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > Here is a change set with the proper fix for the issue. What was the problem with the other one? > Do you think it is possible that someone reviews it before you include > it in the image? The feature did not work before so it can't be worse :-). > This time I think I got it right. I've also added 2 unit tests. > Nevertheless, I would be more confident if someone reviews it :) > > P.S. > Do you think it would be better to make a Monticello SLICE and publish > it to PharoInbox SqueakSource repository? No, it has nothing to do with Pharo. -- 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)

Oct. 20, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Dan Corneanu

Here is a change set with the proper fix for the issue. Do you think it is possible that someone reviews it before you include it in the image? This time I think I got it right. I've also added 2 unit tests. Nevertheless, I would be more confident if someone reviews it :) P.S. Do you think it would be better to make a Monticello SLICE and publish it to PharoInbox SqueakSource repository?

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by StÃ©phane Ducasse

>> that's why my argument about refactoring the font/text/style >> machinery wasn't completely orthogonal :-) > > Point taken. > > Does anyone else think that a better exposition of the goals/ > constraints/applicability etc of Pharo would significantly improve > the chance of meeting those goals? First let's remove all the etoys/BookMorph Second clean Morphic Third clean a lot of the rest Fourth then we should be in position to have a smaller kernel and may be someone will start to clean and refactor the fonts. There is no magic but we will make sure that if somebody does it we will integrate it. Stef

Oct. 20, 2008

[Pharo-project] Strange bug with the compiler?

by nico

Hi, Something strange happened to me today. I made some changes in a method, accepted it, but couldn't see them when I called the method. In the class browser I saw that source and decompiled code didn't match, so I recompiled the class, and now it works! Sorry, but I can't reproduce it... I use the latest Pharo-Dev image. Any idea about what happened? Nico

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Antony Blakey

On 20/10/2008, at 8:37 PM, Michael Rueger wrote: > that's why my argument about refactoring the font/text/style > machinery wasn't completely orthogonal :-) Point taken. Does anyone else think that a better exposition of the goals/ constraints/applicability etc of Pharo would significantly improve the chance of meeting those goals? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The truth does not change according to our ability to stomach it. -- Flannery O'Connor

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Michael Rueger

Antony Blakey wrote: > > On 20/10/2008, at 7:45 PM, <bryce(a)kampjes.demon.co.uk> > <bryce(a)kampjes.demon.co.uk> wrote: > >> I'd vote for the latter too, imagine you want to do a quick VM >> experiment and you're not used to building VMs for that platform. > > But is that a good enough reason to retain all of the other font > machinery? What cost in complexity is it worth paying so that someone that's why my argument about refactoring the font/text/style machinery wasn't completely orthogonal :-) Michael

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by StÃ©phane Ducasse

I agree. Stef On Oct 20, 2008, at 9:04 AM, Michael Rueger wrote: > Antony Blakey wrote: >> On 20/10/2008, at 10:48 AM, John M McIntosh wrote: >>> Well for one thing it requires then implementing the freetype >>> plugin on the iPhone, so it's a barrier to entry for VM developers >>> who are dealing with platforms that may or may not >>> have freetype on them to enable the running of a pharo image. >> In that is the case, then I think a stated requirement for Pharo >> should be a list of platforms, or an explicit statement that it >> must be usable without FreeType. > > I would vote for the latter. > > I would vote strongly against leaving out Squeak's "native" text > rendering. With Squeak native I mean a method to render text without > any external libraries, e.g. for systems like SqueakNOS, bare metal > systems etc. > > What needs to be done is a proper refactoring of the text, font and > text style system so the different rendering mechanisms are easily > interchangeable and transparent to the programmer. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2008