- Pharo-dev - lists.pharo.org

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

by Marcus Denker

On 20.10.2008, at 23:44, Antony Blakey wrote: > > > 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? > eToys is, implementation wise, not written very cleanly. The implementors of etoys always knew 100% that "this hack is the last, then we rewrite everything". If you do that for 10 years, hmm, it shows in code quality. EToys, the one on the OLPC, is based on 3.8 plus *many* changes. Etoys will never be based on 3.9 or 3.10. Thus the etoys in 3.10 (or pharo) would be a fork indpependend of the main eToy branch. Nobody would be interested in maintaining that. But seriously, look at the code. It's a nice example for many things. For example: the prototype will be the product. Or: Never plan to redo everything. You will not. It kind of validates the idea that *evolution* is the most important property of software, and if we want to make progress, supporting evolution is *the* thing to do. The next revolution in software will be a system that supports evolution. Etoys + the support are maybe (conservative estimate) 100.000 of 280.000 lines of code in Pharo. Just imagine how much less maintance, less bugs and in general cleaner architecture we will have. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 21, 2008

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

by StÃ©phane Ducasse

On Oct 20, 2008, at 11:44 PM, Antony Blakey wrote: > > 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. who said that? We will not be backwards compatible with software that is not used and not maintain. > 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? have a look at the code and you will get the answer. No giant spagetthi code in pharo. I do not want to argue endlessly on that. Squeak is the forum for that kind of discussions. > > > 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. 21, 2008

Re: [Pharo-project] Refresh (alt+r) was useful

by Marcus Denker

On 21.10.2008, at 06:25, Damien Cassou wrote: > Hi, > > there is no "refresh" entry in the world menu anymore. It was > sometimes useful when the UI has some problems. Could you please readd > it somewhere? The shortcut key ALT+r is still working. > > It's in "Debug" Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 21, 2008

[Pharo-project] Refresh (alt+r) was useful

by Damien Cassou

Hi, there is no "refresh" entry in the world menu anymore. It was sometimes useful when the UI has some problems. Could you please readd it somewhere? The shortcut key ALT+r is still working. -- 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. 21, 2008

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