[Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)
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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
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
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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
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
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
What about proper formatting? :-) --Hannes On 10/12/12, Benjamin <benjamin.vanryseghem.pharo@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
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@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
On Thu, Oct 11, 2012 at 11:11 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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
Well, at least from the perspective of UI independence it looks much better. -- Pavel
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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
On 11 October 2012 23:04, Pavel Krivanek <pavel.krivanek@gmail.com> 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. }
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.
yess.. do some ass kicking please :) As for omnibrowser.. well I didn't looked at spec code, but what i saw in omnibrowser code didn't impressed me much, like having own subclass for every toolbuilder class. Anyways, UI stuff is tend to be complex no matter how nicely you wrap it.. because it is UI.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
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. 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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
On Fri, Oct 12, 2012 at 10:45 AM, Stéphane Ducasse <stephane.ducasse@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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
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@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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
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@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@gmail.com> wrote:
On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo@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@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.
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.
On Sat, Oct 13, 2012 at 1:43 AM, Igor Stasenko <siguctua@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.
participants (6)
-
Benjamin -
H. Hirzel -
Henrik Sperre Johansen -
Igor Stasenko -
Pavel Krivanek -
Stéphane Ducasse