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

Re: [Pharo-project] Pharo on retina display

by Tudor Girba

Hi Igor, The only reason we were thinking of the bitmap font support was that there was no ready-made vm to get people to use the new canvas. But, if you are getting the vms ready ... this is fantastic. I would say that as soon as they are ready Moose will likely move to Athens. Cheers, Doru On Fri, Oct 12, 2012 at 2:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 October 2012 13:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > > Athens would indeed be great. And I am happy that this investment has > high > > priority in the team. But, I think for the usages that I see, we would > need > > font support. Is there any progress on this front? > > > > Font support is there. I currently working on Morphic rendering (see > screenshot) and getting VMs for all 3 platforms Athens-ready. > > As i said previously, don't expect Athens to support raster fonts. It > doesn't makes any sense. > With athens, you can always render number of glyphs into bitmaps and > draw them as bitmaps later, if you want it, > but i wouldn't call it 'font support', it is bitmap support. :) > > For Cairo backend i did integration with freetype (which already in > pharo as you know), which means that you can > render any scalable fonts. > > And if you may know, freetype package supports embedded fonts (i.e. > font data loaded from memory), > which means you don't even need to have a separate font file along the > image, you can keep font in image itself. > As for amount of memory, needed to hold truetype font in image: > we did a small experiment with Camillo few days ago , we took single > font (Deja Vu sans mono), > and edited it to have only ascii character set (0..127). The resulting > font file size is just 30Kb! > > Now compare it with following: > > (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory > ]) sum > 1504444 > > 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. > > For same size, you could have 1500/30 = 50 various vector fonts (if > only ascii character range of course). > > > > Cheers, > > Doru > > > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2012

Re: [Pharo-project] Fwd: Some progress on Athens

by Igor Stasenko

On 12 October 2012 14:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > It looks nice! Everything on the screen is rendered by Athens? Or only > the color bars? > everything. Sorry, there was no comments on it, because i sent screens to Stef without any explanation, and he decided to forward them to Pharo list. So, some details: there are two screenshots, one rendered by Athens (cairo.png), another is rendered by balloon (what we have right now). As you may noticed, the font quality is lower in cairo.png. this is because i cannot force cairo to use subpixel AA for some reason, so it renders using grayscale AA. It also misses text in text panel (simply because text rendering is not integrated yet with morphic), as for the rest, you see that screenshots is quite similar. Obviously, not all morphs has code for rendering on athens canvas, but i gradually adding drawing methods for more and more. > --Hannes > -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by Benjamin

Trust me, even with the nicest formatting, it's not something that you want to read, or to write... Here the formatting is bad because this code is generated by the SpecLayout object. Ben On Oct 12, 2012, at 2:40 PM, H. Hirzel wrote: > What about proper formatting? :-) > > --Hannes > > On 10/12/12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Feel free to use this representaion instead: >> >> {#ComposableSpec. #add:. {{#ComposableSpec. #add:. {#(#model #browseModel). >> #layout:. {#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: ((1/5)@1). >> (0@0) corner: (0@0)}}. #add:. {#(#model #sendersModel). #layout:. >> {#FrameLayoutSpec. #fractions:offsets:. ((1/5)@0) corner: ((2/5)@1). (4@0) >> corner: (0@0)}}. #add:. {#(#model #implementorsModel). #layout:. >> {#FrameLayoutSpec. #fractions:offsets:. ((2/5)@0) corner: ((3/5)@1). (4@0) >> corner: (0@0)}}. #add:. {#(#model #versionsModel). #layout:. >> {#FrameLayoutSpec. #fractions:offsets:. ((3/5)@0) corner: ((4/5)@1). (4@0) >> corner: (0@0)}}. #add:. {#(#model #dropListModel). #layout:. >> {#FrameLayoutSpec. #fractions:offsets:. ((4/5)@0) corner: (1@1). (4@0) >> corner: (0@0)}}. #checkSplitters}. #layout:. {#FrameLayoutSpec. >> #fractions:offsets:. (0@0) corner: (1@0). (0@0) corner: (0@25)}}} >> >> >> Goodluck >> Ben >> >> On Oct 12, 2012, at 1:49 PM, Henrik Sperre Johansen wrote: >> >>> On 11.10.2012 23:11, Benjamin wrote: >>>> On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote: >>>> >>>>> Unfortunately it is not only about a layer between Morphic and Spec. >>>>> Whole Spec design is greatly conforming to Morphic. Check out Spec >>>>> definitions, they look almost like transcription of Morphic calls >>>>> >>>>> MethodToolbar class >> defaultSpec >>>>> <spec> >>>>> ^ { #Panel. >>>>> #changeTableLayout. >>>>> #listDirection:. #rightToLeft. >>>>> #addMorph:. {#model. #browseModel.}. >>>>> #addMorph:. {#model. #sendersModel.}. >>>>> #addMorph:. {#model. #implementorsModel.}. >>>>> #addMorph:. {#model. #versionModel. }. >>>>> #addMorph:. {#model. #dropListModel.}. >>>>> #hResizing:. #spaceFill. >>>>> #vResizing:. #shrinkWrap. } >>>> This is because this method is out dated, it shold be now >>>> >>>> ^ SpecLayout composed >>>> newRow:[: r | >>>> r >>>> add: #browseModel; >>>> add: #sendersModel; >>>> add: #implementorsModel; >>>> add: #versionsModel; >>>> add: #dropListModel ] >>>> height: 25 >>>> >>> And this seems even worse, tbh. >>> No longer does it seem to be a literal array which some interpreter >>> translates into an abstract model (One bad thing about the first version, >>> as Pavel pointed out, it wasn't very abstract), nor is it a pure DSL for >>> creating abstract models, but some weird amalgam of the two. >>> >>> Now, I DO like creating my interface by hand in a DSL (which can then be >>> instantiated in myriad ways), and such a thing seem to me to be needed >>> anyways for the datamodel of a literal array representation interpreter, >>> so why not start with that, and add the parser of a literal array syntax >>> for specifying the same DSL later on? >>> >>> Not saying you need to reinvent ToolBuilder, but the underlying idea >>> certainly wasn't as bad an idea as some seem to think :) >>> >>> Cheers, >>> Henry >>> >> >> >> >

Oct. 12, 2012

Re: [Pharo-project] Some progress on Athens

by Sven Van Caekenberghe

What does this screenshot actually represent ? A whole image rendered through Athens ? That would be incredibleâ¦ On 11 Oct 2012, at 21:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks guys! > > Stef > > Begin forwarded message: > >> From: Igor Stasenko <siguctua(a)gmail.com> >> Subject: Some progress on Athens >> Date: October 11, 2012 7:03:18 PM GMT+02:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Some fixes i did today, with some help of Camillo. >> >> >> -- >> Best regards, >> Igor Stasenko. >> <morphic.png><cairo.png> > -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Igor Stasenko

ahem.. do not confuse: the given screenshot is an image rendered 100% by athens. it is not a screenshot, just for showing that there is some classes in Athens for "font support" :) -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Fwd: Some progress on Athens

by H. Hirzel

It looks nice! Everything on the screen is rendered by Athens? Or only the color bars? --Hannes On 10/11/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks guys! > > Stef > > Begin forwarded message: > >> From: Igor Stasenko <siguctua(a)gmail.com> >> Subject: Some progress on Athens >> Date: October 11, 2012 7:03:18 PM GMT+02:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Some fixes i did today, with some help of Camillo. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Igor Stasenko

On 12 October 2012 13:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Athens would indeed be great. And I am happy that this investment has high > priority in the team. But, I think for the usages that I see, we would need > font support. Is there any progress on this front? > Font support is there. I currently working on Morphic rendering (see screenshot) and getting VMs for all 3 platforms Athens-ready. As i said previously, don't expect Athens to support raster fonts. It doesn't makes any sense. With athens, you can always render number of glyphs into bitmaps and draw them as bitmaps later, if you want it, but i wouldn't call it 'font support', it is bitmap support. :) For Cairo backend i did integration with freetype (which already in pharo as you know), which means that you can render any scalable fonts. And if you may know, freetype package supports embedded fonts (i.e. font data loaded from memory), which means you don't even need to have a separate font file along the image, you can keep font in image itself. As for amount of memory, needed to hold truetype font in image: we did a small experiment with Camillo few days ago , we took single font (Deja Vu sans mono), and edited it to have only ascii character set (0..127). The resulting font file size is just 30Kb! Now compare it with following: (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum 1504444 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. For same size, you could have 1500/30 = 50 various vector fonts (if only ascii character range of course). > Cheers, > Doru > -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by H. Hirzel

What about proper formatting? :-) --Hannes On 10/12/12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Feel free to use this representaion instead: > > {#ComposableSpec. #add:. {{#ComposableSpec. #add:. {#(#model #browseModel). > #layout:. {#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: ((1/5)@1). > (0@0) corner: (0@0)}}. #add:. {#(#model #sendersModel). #layout:. > {#FrameLayoutSpec. #fractions:offsets:. ((1/5)@0) corner: ((2/5)@1). (4@0) > corner: (0@0)}}. #add:. {#(#model #implementorsModel). #layout:. > {#FrameLayoutSpec. #fractions:offsets:. ((2/5)@0) corner: ((3/5)@1). (4@0) > corner: (0@0)}}. #add:. {#(#model #versionsModel). #layout:. > {#FrameLayoutSpec. #fractions:offsets:. ((3/5)@0) corner: ((4/5)@1). (4@0) > corner: (0@0)}}. #add:. {#(#model #dropListModel). #layout:. > {#FrameLayoutSpec. #fractions:offsets:. ((4/5)@0) corner: (1@1). (4@0) > corner: (0@0)}}. #checkSplitters}. #layout:. {#FrameLayoutSpec. > #fractions:offsets:. (0@0) corner: (1@0). (0@0) corner: (0@25)}}} > > > Goodluck > Ben > > On Oct 12, 2012, at 1:49 PM, Henrik Sperre Johansen wrote: > >> On 11.10.2012 23:11, Benjamin wrote: >>> On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote: >>> >>>> Unfortunately it is not only about a layer between Morphic and Spec. >>>> Whole Spec design is greatly conforming to Morphic. Check out Spec >>>> definitions, they look almost like transcription of Morphic calls >>>> >>>> MethodToolbar class >> defaultSpec >>>> <spec> >>>> ^ { #Panel. >>>> #changeTableLayout. >>>> #listDirection:. #rightToLeft. >>>> #addMorph:. {#model. #browseModel.}. >>>> #addMorph:. {#model. #sendersModel.}. >>>> #addMorph:. {#model. #implementorsModel.}. >>>> #addMorph:. {#model. #versionModel. }. >>>> #addMorph:. {#model. #dropListModel.}. >>>> #hResizing:. #spaceFill. >>>> #vResizing:. #shrinkWrap. } >>> This is because this method is out dated, it shold be now >>> >>> ^ SpecLayout composed >>> newRow:[: r | >>> r >>> add: #browseModel; >>> add: #sendersModel; >>> add: #implementorsModel; >>> add: #versionsModel; >>> add: #dropListModel ] >>> height: 25 >>> >> And this seems even worse, tbh. >> No longer does it seem to be a literal array which some interpreter >> translates into an abstract model (One bad thing about the first version, >> as Pavel pointed out, it wasn't very abstract), nor is it a pure DSL for >> creating abstract models, but some weird amalgam of the two. >> >> Now, I DO like creating my interface by hand in a DSL (which can then be >> instantiated in myriad ways), and such a thing seem to me to be needed >> anyways for the datamodel of a literal array representation interpreter, >> so why not start with that, and add the parser of a literal array syntax >> for specifying the same DSL later on? >> >> Not saying you need to reinvent ToolBuilder, but the underlying idea >> certainly wasn't as bad an idea as some seem to think :) >> >> Cheers, >> Henry >> > > >

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by Benjamin

Feel free to use this representaion instead: {#ComposableSpec. #add:. {{#ComposableSpec. #add:. {#(#model #browseModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: ((1/5)@1). (0@0) corner: (0@0)}}. #add:. {#(#model #sendersModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:. ((1/5)@0) corner: ((2/5)@1). (4@0) corner: (0@0)}}. #add:. {#(#model #implementorsModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:. ((2/5)@0) corner: ((3/5)@1). (4@0) corner: (0@0)}}. #add:. {#(#model #versionsModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:. ((3/5)@0) corner: ((4/5)@1). (4@0) corner: (0@0)}}. #add:. {#(#model #dropListModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:. ((4/5)@0) corner: (1@1). (4@0) corner: (0@0)}}. #checkSplitters}. #layout:. {#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: (1@0). (0@0) corner: (0@25)}}} Goodluck Ben On Oct 12, 2012, at 1:49 PM, Henrik Sperre Johansen wrote: > On 11.10.2012 23:11, Benjamin wrote: >> On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote: >> >>> Unfortunately it is not only about a layer between Morphic and Spec. >>> Whole Spec design is greatly conforming to Morphic. Check out Spec >>> definitions, they look almost like transcription of Morphic calls >>> >>> MethodToolbar class >> defaultSpec >>> <spec> >>> ^ { #Panel. >>> #changeTableLayout. >>> #listDirection:. #rightToLeft. >>> #addMorph:. {#model. #browseModel.}. >>> #addMorph:. {#model. #sendersModel.}. >>> #addMorph:. {#model. #implementorsModel.}. >>> #addMorph:. {#model. #versionModel. }. >>> #addMorph:. {#model. #dropListModel.}. >>> #hResizing:. #spaceFill. >>> #vResizing:. #shrinkWrap. } >> This is because this method is out dated, it shold be now >> >> ^ SpecLayout composed >> newRow:[: r | >> r >> add: #browseModel; >> add: #sendersModel; >> add: #implementorsModel; >> add: #versionsModel; >> add: #dropListModel ] >> height: 25 >> > And this seems even worse, tbh. > No longer does it seem to be a literal array which some interpreter translates into an abstract model (One bad thing about the first version, as Pavel pointed out, it wasn't very abstract), nor is it a pure DSL for creating abstract models, but some weird amalgam of the two. > > Now, I DO like creating my interface by hand in a DSL (which can then be instantiated in myriad ways), and such a thing seem to me to be needed anyways for the datamodel of a literal array representation interpreter, so why not start with that, and add the parser of a literal array syntax for specifying the same DSL later on? > > Not saying you need to reinvent ToolBuilder, but the underlying idea certainly wasn't as bad an idea as some seem to think :) > > Cheers, > Henry >

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by Henrik Sperre Johansen

On 11.10.2012 23:11, Benjamin wrote: > On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote: > >> Unfortunately it is not only about a layer between Morphic and Spec. >> Whole Spec design is greatly conforming to Morphic. Check out Spec >> definitions, they look almost like transcription of Morphic calls >> >> MethodToolbar class >> defaultSpec >> <spec> >> ^ { #Panel. >> #changeTableLayout. >> #listDirection:. #rightToLeft. >> #addMorph:. {#model. #browseModel.}. >> #addMorph:. {#model. #sendersModel.}. >> #addMorph:. {#model. #implementorsModel.}. >> #addMorph:. {#model. #versionModel. }. >> #addMorph:. {#model. #dropListModel.}. >> #hResizing:. #spaceFill. >> #vResizing:. #shrinkWrap. } > This is because this method is out dated, it shold be now > > ^ SpecLayout composed > newRow:[: r | > r > add: #browseModel; > add: #sendersModel; > add: #implementorsModel; > add: #versionsModel; > add: #dropListModel ] > height: 25 > And this seems even worse, tbh. No longer does it seem to be a literal array which some interpreter translates into an abstract model (One bad thing about the first version, as Pavel pointed out, it wasn't very abstract), nor is it a pure DSL for creating abstract models, but some weird amalgam of the two. Now, I DO like creating my interface by hand in a DSL (which can then be instantiated in myriad ways), and such a thing seem to me to be needed anyways for the datamodel of a literal array representation interpreter, so why not start with that, and add the parser of a literal array syntax for specifying the same DSL later on? Not saying you need to reinvent ToolBuilder, but the underlying idea certainly wasn't as bad an idea as some seem to think :) Cheers, Henry

Oct. 12, 2012