April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] updated documentation on magritte?

by phil＠highoctane.be

On Tue, Apr 22, 2014 at 9:14 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 22 Apr 2014, at 20:20, stepharo <stepharo(a)free.fr> wrote: > > > Not that I know. > > I started a chapter on the pharo for the entreprise (with the idea to > base it on the seaside book) but I need help. > > If you start writing a draft I will do a pass. > > I was fearing thatâ¦ but ok :) > I have collected quite a number of items regarding magritte. And I used 3.x for one project of mine, which exposed a number of elements. I'll try to make a package with all of it. Phil > > > > > Stef > > > > On 22/4/14 09:28, Esteban Lorenzano wrote: > >> Hi, > >> > >> is there an updated documentation on magritte? where can I find it? > >> > >> cheers, > >> Esteban > >> > >> > > > > > > >

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by Nicolas Cellier

2014-04-22 21:30 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 22/4/14 14:19, Tudor Girba wrote: > > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. > > > In fact this is buggy even without that. The system reports strike and > freetype fonts when we are in ft mode :( > > > Are you questionning about updateFontsAtImageStartup? The reason for not wanting to update fonts at image startup was to avoid loosing time at startup. http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009358.html If this was a valuable setting at that time, what makes it not valuable now? Or are you questionning about presence of FreeType fonts in FontChooser? I have FT on but updateFTAtStartup off, and for seeing the FT fonts I have to open the dialog, press update button, close the dialog, reopen, and only then I can see the FreeType fonts. Is that the bug you're after? > I fail to see why we need the option in the first place. All I am > saying is that we should remove the option from the settings browser and > simply have the freetype fonts enable all the time. This means that you > will still be able to load the bitmap fonts without problems just like > before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > >> 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> I am not arguing for dropping of bitmap fonts at all. I am only arguing >>> for removing the option of not having freetype. People on slow devices will >>> still be able to use the bitmap fonts. >>> >>> Is that wrong? >>> >> >> Well, look at it this way: who should be able to have the final word on >> what side of the speed/prettiness dichotomy Pharo should be: the user or >> the system? >> >> Cheers, >> Sergi >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by Tudor Girba

Why is this buggy? Right now, the meaning of the checkbox is to allow the user to have FT in addition to bitmap fonts. That is why I say we should just drop the checkbox altogether and we have solved a source of problems. We can rethink the infrastructure for Pharo 4. Doru On Tue, Apr 22, 2014 at 9:30 PM, stepharo <stepharo(a)free.fr> wrote: > > On 22/4/14 14:19, Tudor Girba wrote: > > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. > > > In fact this is buggy even without that. The system reports strike and > freetype fonts when we are in ft mode :( > > > I fail to see why we need the option in the first place. All I am saying > is that we should remove the option from the settings browser and simply > have the freetype fonts enable all the time. This means that you will still > be able to load the bitmap fonts without problems just like before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > >> 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> I am not arguing for dropping of bitmap fonts at all. I am only arguing >>> for removing the option of not having freetype. People on slow devices will >>> still be able to use the bitmap fonts. >>> >>> Is that wrong? >>> >> >> Well, look at it this way: who should be able to have the final word on >> what side of the speed/prettiness dichotomy Pharo should be: the user or >> the system? >> >> Cheers, >> Sergi >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by stepharo

On 22/4/14 14:19, Tudor Girba wrote: > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. In fact this is buggy even without that. The system reports strike and freetype fonts when we are in ft mode :( > I fail to see why we need the option in the first place. All I am > saying is that we should remove the option from the settings browser > and simply have the freetype fonts enable all the time. This means > that you will still be able to load the bitmap fonts without problems > just like before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com > <mailto:sergi.reyner@gmail.com>> wrote: > > 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > I am not arguing for dropping of bitmap fonts at all. I am > only arguing for removing the option of not having freetype. > People on slow devices will still be able to use the bitmap fonts. > > Is that wrong? > > > Well, look at it this way: who should be able to have the final > word on what side of the speed/prettiness dichotomy Pharo should > be: the user or the system? > > Cheers, > Sergi > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by stepharo

Hi nicolas I agree with you :). My goal is not to drop strike fonts because I think that the code is working and it can be useful for some people. I just want to make sure that StandardFonts (TextStyle and others...) does not mess up FreeType and StrikeFonts. We got a lot of problems with this for our clients. Stef On 22/4/14 09:09, Nicolas Cellier wrote: > > 2014-04-22 6:30 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > One question is why do still have the disable free type fonts option? > This was useful when free type was still in development, but I > think now it is no longer useful. > Or are there still use cases for it? > > Doru > > > > At the risk of repeating myself (that's maybe 10 times I say it here, > but it's like shouting in the desert...) , > freetype is pretty inefficient because it displays characters one by > one (call a primitive foreach and every character). > So if you are on a not so fast device, strike fonts are still a good > option because the primitive displays groups of characters in a batch. > So please, please, please, for once before breaking things that works > and replacing them by a thing that works only partially, > do it the other way around: > - first make it fully work (that means add a new freetype primitive > displaying batch of chars) > - then drop any historical bits you want > > Of course, you are free to completely drop support for slow machines, > but it must be consciously. > > > On Mon, Apr 21, 2014 at 7:32 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > when freetype is on do you think that it makes sense to have > strikeFont > proposed as default fonts? Like it is done right now, I get > bitmapVera even if I > want to see FreeType fonts. > > Stef > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

April 22, 2014

Re: [Pharo-dev] updated documentation on magritte?

by Esteban Lorenzano

On 22 Apr 2014, at 20:20, stepharo <stepharo(a)free.fr> wrote: > Not that I know. > I started a chapter on the pharo for the entreprise (with the idea to base it on the seaside book) but I need help. > If you start writing a draft I will do a pass. I was fearing thatâ¦ but ok :) > > Stef > > On 22/4/14 09:28, Esteban Lorenzano wrote: >> Hi, >> >> is there an updated documentation on magritte? where can I find it? >> >> cheers, >> Esteban >> >> > >

April 22, 2014

Re: [Pharo-dev] Lost in spec

by Nicolai Hess

2014-04-22 13:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > i want to use different adaptor for TextModel, when opening my UI > so that when widget is built for it, it will be my own widget, > not PluggableTextMorph.. > > but i found it hard to do.. here what i tried: > > > I try to replace bindings, so at the stage when spec interpreted, it uses > my bindings: > > openWithSpec > > | old result | > old := SpecInterpreter bindings. > > SpecInterpreter bindings: TxAdapterBindings new. > > [ result := super openWithSpec ] > ensure: [ SpecInterpreter bindings: old ]. > ^ result > > > in TxAdapterBindings i initialize it same as morphic bindging, except from > text model binding: > #TextAdapter => #TxTextAdapter > > but it is never invoked nor used :( > > i understand the overall model, but it seems like not completely, > (else the above trick would work).. what do i miss? > > -- > Best regards, > Igor Stasenko. > You code works, it is just that the TextModel is not the first one that calls the spec interpreter. The first one is the WindowModel. And after a spec is "interpreted" spec interpreter calls self hardResetBindings and that one reinitialize the binding to MorphicAdapterBindings. nicolai

April 22, 2014

Re: [Pharo-dev] Confused by NewListExample

by Stephan Eggermont

- title toggling doesnât work - doesnât have a usable size - window title not set - dragging doesnât work - disallows selection in one place, allows it somewhere else - menu the same on list title - uses halts directly instead of calling a method on self displaying the action (open a dialog, show a growl)

April 22, 2014

Re: [Pharo-dev] Lost in spec

by Igor Stasenko

TxText-Athens-IgorStasenko.27 (TxText on smalltalkhub) just committed see TxApplicationWithToolbar TxApplicationWithToolbar new openWithSpec etc On 22 April 2014 20:21, stepharo <stepharo(a)free.fr> wrote: > Igor where is your code so that I can give a try? > > > > On 22/4/14 13:56, Igor Stasenko wrote: > >> i want to use different adaptor for TextModel, when opening my UI >> so that when widget is built for it, it will be my own widget, >> not PluggableTextMorph.. >> >> but i found it hard to do.. here what i tried: >> >> >> I try to replace bindings, so at the stage when spec interpreted, it uses >> my bindings: >> >> openWithSpec >> >> | old result | >> old := SpecInterpreter bindings. >> >> SpecInterpreter bindings: TxAdapterBindings new. >> >> [ result := super openWithSpec ] >> ensure: [ SpecInterpreter bindings: old ]. >> ^ result >> >> >> in TxAdapterBindings i initialize it same as morphic bindging, except >> from text model binding: >> #TextAdapter => #TxTextAdapter >> >> but it is never invoked nor used :( >> >> i understand the overall model, but it seems like not completely, >> (else the above trick would work).. what do i miss? >> >> -- >> Best regards, >> Igor Stasenko. >> > > > -- Best regards, Igor Stasenko.

April 22, 2014

Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

by roberto.minelli＠usi.ch

If done right, TimeStamp would have not caused any confusion. Now that I discovered that a TimeStamp is a DateAndTime with rounded seconds (read: non-sense) I agree with you. On Apr 22, 2014, at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > TimeStamp is deprecated, because it creates too much confusion, you better use DateAndTime. > > On 22 Apr 2014, at 17:11, roberto.minelli(a)usi.ch wrote: > >> "TimeStamp now" rounds the timestamp, so #asNanoSeconds returns the seconds * 10e9. >> >> Doing âDateAndTime nowâ solves my issue, but this is a total non-sense. >> >> Cheers, >> R >> >> On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> Well, it has #asNanoSeconds, how finer can you go? >>> >>> Uko >>> >>> On 22 Apr 2014, at 17:13, roberto.minelli(a)usi.ch wrote: >>> >>>> Hi, >>>> >>>> I am wondering if there is the possibility to get milliseconds in a TimeStamp. >>>> >>>> I need to record fine-grained events and second-granularity is not enough. >>>> >>>> Cheers, >>>> Roberto >>> >>> >> >> > >

April 22, 2014