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

Re: [Pharo-project] PhobosDemo problem on MACBook

by Pavel Krivanek

Hi Dario, it is a known problem and we currently have no fix. You may open the image by CogVM (PhobosDemo.app/Contents/Resources/chrome/app.image), resize, save and then open the demo application again. -- Pavel On Fri, Oct 12, 2012 at 11:42 AM, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Hi, > > i download the : PhobosDemo.app.tar.bz2 on a MAC . > > When i open the application the system open: the a Pharo app.image and the > Phobos Demo window. > > Now when resizing the Pharo window the content is lost and inrecuperabile. > > > Some idea? > > Thanks, > > Dario

Oct. 13, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 401 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 13, 2012

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

by Pavel Krivanek

On Sat, Oct 13, 2012 at 1:43 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Pavel, since i am potential user of Spec, i would like to know more details. > I know it takes more time to explain what exactly you don't like and > propose better alternative, > instead of just generic "i don't like it". Well, some points: - bindings management. Currently if you want to use different binding/platform, you have to specify it for every single widget. It doesn't use platform of the parent. Notice that I had to create own binding even in case I wanted to use smaller font for lists or iconic buttons. - bindings extensions. Imagine the situation when you want to use some special widget in Morphic, let's say some new button type. Currently you create own binding class. But in case that you will want to use something different from Morphic (eg. HTML) you are in trouble because you already used custom binding mechanism for extension of set of the widgets, not for UI framework independence. Spec should provide a way how to offer both - UI independence and widgets extensibility (with fallback mechanism in case that the special widget has no implementation in the currently used UI - in our case a normal button would be used). - layout management. The layout management is taken directly from Morphic. Imagine you should create a HTML binding. Direct ratios and size values!!! are used everywhere. Why to specify how thick a bar with buttons should be? Widgets should know their own optimal size. Look at our current retina display issues. Flex mechanism from XUL is quite nice here (https://developer.mozilla.org/en-US/docs/XUL_Tutorial/Using_Spacers) - Morphic... look at Nautilus (eg. buildMiddlePlugins message) how Spec based tool must look now. > OmniBrowser is older than Spec, so it is not a big surprise that it > has more backends implemented. > > Now, if we don't want Ben's effort to be wasted, we should do a little > bit more than just stating "this is not what i want". It is in our > best interests to make it what we want. > > I attempted to extend/improve toolbuilder once.. as well as implement > own UI layer on top of it.. > I found it quite limited (very small set of widgets, very coarse > control over them), no way extending widget sets, composition etc. > > I think Spec was initially planned to address those issues. While i > did not took part in this project directly, > i know that Stef (and others) were discussing deeply design of Spec > with Ben were quite serious about it and were putting certain goals to > achieve. > So, if what we got is not something that we want, perhaps we should > help fixing it before it's too late :) > We both know that "successfull" project is not the one which just > finished , launched and just works, but the one which has many users > and they enjoy using it and help improving it. As I already told, for Spec would be very benefical to create at least HTML backend in parallel to the Morphic one. Cheers, -- Pavel > > -- > Best regards, > Igor Stasenko. >

Oct. 13, 2012

Re: [Pharo-project] Pharo on retina display

by Sven Van Caekenberghe

On 13 Oct 2012, at 08:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> 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. > > Yes Igor is working on the three platforms. Igor is fixing the windows one currently and he is near the end. > We are going to release vm with NativeBoost, Freetype, SSL support on all platforms. Yes, yes, yes !! It's a long road, but we are moving forward on so many fronts, it will be non-linear indeed. > Stef > >> 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. 13, 2012

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

by StÃ©phane Ducasse

> One of the goal of Spec is to be portable. > > But sadly, I am not an engineer working full time of Spec. > Right now I have priorities which slow down Spec improvements. Yes and these priorities are important for you and for us as well. We want you to have great grades! Now we will see and will ask esteban to allocate time on Spec. We should discuss about it after my birthday cake eating time. :) > But the infrastructure for having Spec portable is not so far > > > Ben > > > > On Oct 12, 2012, at 11:28 PM, Pavel Krivanek wrote: > >> On Fri, Oct 12, 2012 at 10:45 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Pavel >>> >>> do you know VW spec, it is an array of symbol and spec is the same. >>> We should change the api at some point. >>> >>> The point is that you do not code it by hand but that tools generate them. >>> Now we are not to the point where a tools can generate them. >>> >>> But for us the OB is not the way to go because it is not flexible at all. >> >> OmniBrowser is not perfect. On the other hand I know about five >> different UI frameworks that can display it (Morphic, Seaside, >> SeasideXUL, Mars and Phobos). When I firstly heard about Spec, I >> expected that the easy "portability" will be one of the main trait. To >> create new platform for OmniBrowser is quite easy and as the result >> you have almost complete Smalltalk IDE. Current Nautilus would not be >> able to work on any UI different from Morphic even in case that Spec >> would have full support there. >> >> With OmniBrowser or Glamour you create very high-level description of >> the tools. It limits flexibility. But Spec is too low-level, it really >> looks more like a layer that should make Morphic more friendly than >> universal UI description of the tools. >> SpecLayout seems to be more promising and I'm glad that Ben is working >> on it. In some aspects it resembles Seaside/Phobos UI descriptions and >> it would be really great if it would find some inspiration in that >> world. >> I am not impartial but I think that component based XUL subset with >> Seaside-style description would promise good mix of readability, >> flexibility, abstraction and portability. >> >> One way or another, if we want usable result, such layer should be >> designed and created for several different UIs at once - including the >> mobile ones. >> >> Cheers, >> -- Pavel >> >> >> >>> Stef >>> >>> >>>> 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. } >>>> >>>> Of course these methods are implemented only in Morphic classes. Whole >>>> layout management is directly taken from Morphic. And the Spec >>>> definitions are unclear and hard to read. They are composed almost >>>> solely from symbols so it is hard to work with and analyze them with >>>> our development tools. We have such beautiful metalanguage where to >>>> create DSL is so easy... >>>> >>>> In comparison with OmniBrowser the Spec is big step back. Sorry, I do >>>> not want to be ugly but I started this impression when I was working >>>> on Periscope and since that time it is deeper and deeper. >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Oct 11, 2012 at 10:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>>> This method is actually the only one from ComposableModel with direct Morphic binding :) >>>>>> >>>>>> >>>>>> I am still trying to move that away, but I needed the rebuild to work >>>>>> >>>>> i think you can introduce own protocol (and put it as extension to >>>>> morphic, if you want to) >>>>> so, instead of saying >>>>> >>>>> widget removeAllMorphs >>>>> >>>>> you will use own extension method ,like: >>>>> >>>>> widget specRemoveAllChilds >>>>> >>>>> etc (spec here is namespacing prefix for a method, to indicate that it >>>>> belongs to spec package >>>>> and to indicate that it is a contract implied between spec and widget) >>>>> >>>>>> Ben >>>>>> >>>>>> On Oct 11, 2012, at 8:49 PM, Pavel Krivanek wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> I really would like to write Spec binding for Phobos (Esteban will >>>>>>> want to do it for Mars etc.). But, how to say that, Spec was not >>>>>>> written with UI Independence in mind :-) Very basic example of that >>>>>>> fact: >>>>>>> >>>>>>> ComposableModel>>buildWithSpec: aSpec >>>>>>> "Build the widget using the spec name provided as argument" >>>>>>> | widget | >>>>>>> >>>>>>> (self spec notNil and: [ self needRebuild not ]) >>>>>>> ifTrue: [ | old | >>>>>>> self needRebuild: true. >>>>>>> old := self widget. >>>>>>> old removeAllMorphs. >>>>>>> self ensureExtentFor: old. >>>>>>> widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. >>>>>>> widget submorphs do:[ :e | old addMorphBack: e ]. >>>>>>> self spec instance: old. >>>>>>> ^ old ] >>>>>>> ifFalse: [ widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. ]. >>>>>>> >>>>>>> self ensureExtentFor: widget. >>>>>>> >>>>>>> ^ widget >>>>>>> >>>>>>> Can you please do at least basic steps in the architecture of Spec to >>>>>>> make it more independent on Morphic? >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>>> >>>>>>> On Wed, Oct 10, 2012 at 12:10 AM, Benjamin >>>>>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>>>>> It was part of my battle plan to rule the world ;) >>>>>>>> >>>>>>>> We wanted with Nico to part it to Amber to get the Javascript part for free, then generate some XUL :) >>>>>>>> >>>>>>>> Anyway, really cool job, and impressive as well :) >>>>>>>> >>>>>>>> Ben >>>>>>>> >>>>>>>> On Oct 9, 2012, at 11:07 PM, StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>>> It looks really nice. >>>>>>>>> I imagine that Spec could generate XUL too. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> On Oct 9, 2012, at 9:48 PM, Pavel Krivanek wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I would like to introduce you Phobos - the XULRunner based Smalltalk >>>>>>>>>> framework for development of native GUI with standard look&feel for >>>>>>>>>> Linux, Mac OS X and Windows. >>>>>>>>>> >>>>>>>>>> It is based on Zinc, WebSockets and Seaside continuations. For more >>>>>>>>>> information including more screenshots see the project page: >>>>>>>>>> >>>>>>>>>> http://code.google.com/p/phobos-framework/ >>>>>>>>>> >>>>>>>>>> You should pay attentions to FAQ too: >>>>>>>>>> http://code.google.com/p/phobos-framework/wiki/FAQ >>>>>>>>>> >>>>>>>>>> Phobos has Seaside-like components and rendering style, can combine >>>>>>>>>> XUL with HTML or SVG, supports printing etc. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> -- Pavel >>>>>>>>>> <01.png> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>> >>> >> > >

Oct. 13, 2012

Re: [Pharo-project] Pharo on retina display

by StÃ©phane Ducasse

> 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. Yes Igor is working on the three platforms. Igor is fixing the windows one currently and he is near the end. We are going to release vm with NativeBoost, Freetype, SSL support on all platforms. Stef > 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. 13, 2012

Re: [Pharo-project] Pharo on retina display

by StÃ©phane Ducasse

> > Yes, best thing for retina displays is to use Athens. It is maybe not > yet ready for prime time, but of course it is more than nothing, and i > crawling slowly to finish line :) > > I can only say that it was right strategic choice to put effort in > developing it. > Because if we wouldn't make such choice few years ago, and allocate > our resources to other tasks (and there's plenty), > there would be nothing to propose at all to support new generation of > hardware which comes these days. :) I like when you call me visionary man :). if we look at Fuel and other nice recent development like build systems, bootstrapping, network improvement and others it shows that we are really going in the right direction :) Stef

Oct. 13, 2012

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

by Igor Stasenko

Pavel, since i am potential user of Spec, i would like to know more details. I know it takes more time to explain what exactly you don't like and propose better alternative, instead of just generic "i don't like it". OmniBrowser is older than Spec, so it is not a big surprise that it has more backends implemented. Now, if we don't want Ben's effort to be wasted, we should do a little bit more than just stating "this is not what i want". It is in our best interests to make it what we want. I attempted to extend/improve toolbuilder once.. as well as implement own UI layer on top of it.. I found it quite limited (very small set of widgets, very coarse control over them), no way extending widget sets, composition etc. I think Spec was initially planned to address those issues. While i did not took part in this project directly, i know that Stef (and others) were discussing deeply design of Spec with Ben were quite serious about it and were putting certain goals to achieve. So, if what we got is not something that we want, perhaps we should help fixing it before it's too late :) We both know that "successfull" project is not the one which just finished , launched and just works, but the one which has many users and they enjoy using it and help improving it. -- Best regards, Igor Stasenko.

Oct. 12, 2012

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

by Benjamin

One of the goal of Spec is to be portable. But sadly, I am not an engineer working full time of Spec. Right now I have priorities which slow down Spec improvements. But the infrastructure for having Spec portable is not so far Ben On Oct 12, 2012, at 11:28 PM, Pavel Krivanek wrote: > On Fri, Oct 12, 2012 at 10:45 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Pavel >> >> do you know VW spec, it is an array of symbol and spec is the same. >> We should change the api at some point. >> >> The point is that you do not code it by hand but that tools generate them. >> Now we are not to the point where a tools can generate them. >> >> But for us the OB is not the way to go because it is not flexible at all. > > OmniBrowser is not perfect. On the other hand I know about five > different UI frameworks that can display it (Morphic, Seaside, > SeasideXUL, Mars and Phobos). When I firstly heard about Spec, I > expected that the easy "portability" will be one of the main trait. To > create new platform for OmniBrowser is quite easy and as the result > you have almost complete Smalltalk IDE. Current Nautilus would not be > able to work on any UI different from Morphic even in case that Spec > would have full support there. > > With OmniBrowser or Glamour you create very high-level description of > the tools. It limits flexibility. But Spec is too low-level, it really > looks more like a layer that should make Morphic more friendly than > universal UI description of the tools. > SpecLayout seems to be more promising and I'm glad that Ben is working > on it. In some aspects it resembles Seaside/Phobos UI descriptions and > it would be really great if it would find some inspiration in that > world. > I am not impartial but I think that component based XUL subset with > Seaside-style description would promise good mix of readability, > flexibility, abstraction and portability. > > One way or another, if we want usable result, such layer should be > designed and created for several different UIs at once - including the > mobile ones. > > Cheers, > -- Pavel > > > >> Stef >> >> >>> 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. } >>> >>> Of course these methods are implemented only in Morphic classes. Whole >>> layout management is directly taken from Morphic. And the Spec >>> definitions are unclear and hard to read. They are composed almost >>> solely from symbols so it is hard to work with and analyze them with >>> our development tools. We have such beautiful metalanguage where to >>> create DSL is so easy... >>> >>> In comparison with OmniBrowser the Spec is big step back. Sorry, I do >>> not want to be ugly but I started this impression when I was working >>> on Periscope and since that time it is deeper and deeper. >>> >>> Cheers, >>> -- Pavel >>> >>> >>> >>> >>> >>> On Thu, Oct 11, 2012 at 10:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>> This method is actually the only one from ComposableModel with direct Morphic binding :) >>>>> >>>>> >>>>> I am still trying to move that away, but I needed the rebuild to work >>>>> >>>> i think you can introduce own protocol (and put it as extension to >>>> morphic, if you want to) >>>> so, instead of saying >>>> >>>> widget removeAllMorphs >>>> >>>> you will use own extension method ,like: >>>> >>>> widget specRemoveAllChilds >>>> >>>> etc (spec here is namespacing prefix for a method, to indicate that it >>>> belongs to spec package >>>> and to indicate that it is a contract implied between spec and widget) >>>> >>>>> Ben >>>>> >>>>> On Oct 11, 2012, at 8:49 PM, Pavel Krivanek wrote: >>>>> >>>>>> Hi Ben, >>>>>> >>>>>> I really would like to write Spec binding for Phobos (Esteban will >>>>>> want to do it for Mars etc.). But, how to say that, Spec was not >>>>>> written with UI Independence in mind :-) Very basic example of that >>>>>> fact: >>>>>> >>>>>> ComposableModel>>buildWithSpec: aSpec >>>>>> "Build the widget using the spec name provided as argument" >>>>>> | widget | >>>>>> >>>>>> (self spec notNil and: [ self needRebuild not ]) >>>>>> ifTrue: [ | old | >>>>>> self needRebuild: true. >>>>>> old := self widget. >>>>>> old removeAllMorphs. >>>>>> self ensureExtentFor: old. >>>>>> widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. >>>>>> widget submorphs do:[ :e | old addMorphBack: e ]. >>>>>> self spec instance: old. >>>>>> ^ old ] >>>>>> ifFalse: [ widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. ]. >>>>>> >>>>>> self ensureExtentFor: widget. >>>>>> >>>>>> ^ widget >>>>>> >>>>>> Can you please do at least basic steps in the architecture of Spec to >>>>>> make it more independent on Morphic? >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>>> >>>>>> On Wed, Oct 10, 2012 at 12:10 AM, Benjamin >>>>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>>>> It was part of my battle plan to rule the world ;) >>>>>>> >>>>>>> We wanted with Nico to part it to Amber to get the Javascript part for free, then generate some XUL :) >>>>>>> >>>>>>> Anyway, really cool job, and impressive as well :) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On Oct 9, 2012, at 11:07 PM, StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> It looks really nice. >>>>>>>> I imagine that Spec could generate XUL too. >>>>>>>> >>>>>>>> Stef >>>>>>>> On Oct 9, 2012, at 9:48 PM, Pavel Krivanek wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I would like to introduce you Phobos - the XULRunner based Smalltalk >>>>>>>>> framework for development of native GUI with standard look&feel for >>>>>>>>> Linux, Mac OS X and Windows. >>>>>>>>> >>>>>>>>> It is based on Zinc, WebSockets and Seaside continuations. For more >>>>>>>>> information including more screenshots see the project page: >>>>>>>>> >>>>>>>>> http://code.google.com/p/phobos-framework/ >>>>>>>>> >>>>>>>>> You should pay attentions to FAQ too: >>>>>>>>> http://code.google.com/p/phobos-framework/wiki/FAQ >>>>>>>>> >>>>>>>>> Phobos has Seaside-like components and rendering style, can combine >>>>>>>>> XUL with HTML or SVG, supports printing etc. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> -- Pavel >>>>>>>>> <01.png> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >

Oct. 12, 2012

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

by Pavel Krivanek

On Fri, Oct 12, 2012 at 10:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Pavel > > do you know VW spec, it is an array of symbol and spec is the same. > We should change the api at some point. > > The point is that you do not code it by hand but that tools generate them. > Now we are not to the point where a tools can generate them. > > But for us the OB is not the way to go because it is not flexible at all. OmniBrowser is not perfect. On the other hand I know about five different UI frameworks that can display it (Morphic, Seaside, SeasideXUL, Mars and Phobos). When I firstly heard about Spec, I expected that the easy "portability" will be one of the main trait. To create new platform for OmniBrowser is quite easy and as the result you have almost complete Smalltalk IDE. Current Nautilus would not be able to work on any UI different from Morphic even in case that Spec would have full support there. With OmniBrowser or Glamour you create very high-level description of the tools. It limits flexibility. But Spec is too low-level, it really looks more like a layer that should make Morphic more friendly than universal UI description of the tools. SpecLayout seems to be more promising and I'm glad that Ben is working on it. In some aspects it resembles Seaside/Phobos UI descriptions and it would be really great if it would find some inspiration in that world. I am not impartial but I think that component based XUL subset with Seaside-style description would promise good mix of readability, flexibility, abstraction and portability. One way or another, if we want usable result, such layer should be designed and created for several different UIs at once - including the mobile ones. Cheers, -- Pavel > Stef > > >> 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. } >> >> Of course these methods are implemented only in Morphic classes. Whole >> layout management is directly taken from Morphic. And the Spec >> definitions are unclear and hard to read. They are composed almost >> solely from symbols so it is hard to work with and analyze them with >> our development tools. We have such beautiful metalanguage where to >> create DSL is so easy... >> >> In comparison with OmniBrowser the Spec is big step back. Sorry, I do >> not want to be ugly but I started this impression when I was working >> on Periscope and since that time it is deeper and deeper. >> >> Cheers, >> -- Pavel >> >> >> >> >> >> On Thu, Oct 11, 2012 at 10:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> This method is actually the only one from ComposableModel with direct Morphic binding :) >>>> >>>> >>>> I am still trying to move that away, but I needed the rebuild to work >>>> >>> i think you can introduce own protocol (and put it as extension to >>> morphic, if you want to) >>> so, instead of saying >>> >>> widget removeAllMorphs >>> >>> you will use own extension method ,like: >>> >>> widget specRemoveAllChilds >>> >>> etc (spec here is namespacing prefix for a method, to indicate that it >>> belongs to spec package >>> and to indicate that it is a contract implied between spec and widget) >>> >>>> Ben >>>> >>>> On Oct 11, 2012, at 8:49 PM, Pavel Krivanek wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> I really would like to write Spec binding for Phobos (Esteban will >>>>> want to do it for Mars etc.). But, how to say that, Spec was not >>>>> written with UI Independence in mind :-) Very basic example of that >>>>> fact: >>>>> >>>>> ComposableModel>>buildWithSpec: aSpec >>>>> "Build the widget using the spec name provided as argument" >>>>> | widget | >>>>> >>>>> (self spec notNil and: [ self needRebuild not ]) >>>>> ifTrue: [ | old | >>>>> self needRebuild: true. >>>>> old := self widget. >>>>> old removeAllMorphs. >>>>> self ensureExtentFor: old. >>>>> widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. >>>>> widget submorphs do:[ :e | old addMorphBack: e ]. >>>>> self spec instance: old. >>>>> ^ old ] >>>>> ifFalse: [ widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. ]. >>>>> >>>>> self ensureExtentFor: widget. >>>>> >>>>> ^ widget >>>>> >>>>> Can you please do at least basic steps in the architecture of Spec to >>>>> make it more independent on Morphic? >>>>> >>>>> Cheers, >>>>> -- Pavel >>>>> >>>>> On Wed, Oct 10, 2012 at 12:10 AM, Benjamin >>>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>>> It was part of my battle plan to rule the world ;) >>>>>> >>>>>> We wanted with Nico to part it to Amber to get the Javascript part for free, then generate some XUL :) >>>>>> >>>>>> Anyway, really cool job, and impressive as well :) >>>>>> >>>>>> Ben >>>>>> >>>>>> On Oct 9, 2012, at 11:07 PM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> It looks really nice. >>>>>>> I imagine that Spec could generate XUL too. >>>>>>> >>>>>>> Stef >>>>>>> On Oct 9, 2012, at 9:48 PM, Pavel Krivanek wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I would like to introduce you Phobos - the XULRunner based Smalltalk >>>>>>>> framework for development of native GUI with standard look&feel for >>>>>>>> Linux, Mac OS X and Windows. >>>>>>>> >>>>>>>> It is based on Zinc, WebSockets and Seaside continuations. For more >>>>>>>> information including more screenshots see the project page: >>>>>>>> >>>>>>>> http://code.google.com/p/phobos-framework/ >>>>>>>> >>>>>>>> You should pay attentions to FAQ too: >>>>>>>> http://code.google.com/p/phobos-framework/wiki/FAQ >>>>>>>> >>>>>>>> Phobos has Seaside-like components and rendering style, can combine >>>>>>>> XUL with HTML or SVG, supports printing etc. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -- Pavel >>>>>>>> <01.png> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

Oct. 12, 2012