When all you have is Spec, everything looks like a nail?
I've been mulling this over for a while, and since we've been having conversations about Spec's place in our future... DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something. The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph. Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good. My discomfort is with making *all* our core tools Spec-based. While it is great from an "eating our own dog food perspective", one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this. My 2c. ----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi sean
I've been mulling this over for a while, and since we've been having conversations about Spec's place in our future... :) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking. Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+1 to both of you :) Doru On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of
the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out. How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain). Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular. It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping. An example: MorphicRadioButtonAdapter defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"} A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself. Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine? Phil On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of
the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
Personally there are two thing I dont like about Spec a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use. b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes. On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve. On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of
the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway. nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
For a small prototype GUI, anything longer than one method is too long. Doru On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Doru, Some smart snippets welcome :-) Can use that for a demo! Phil On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
For a small prototype GUI, anything longer than one method is too long.
Doru
On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
nah, it depends on the size of the method too :) I much prefer 5 methods of 5 lines each than one of 25. Esteban On 01 Sep 2014, at 11:58, phil@highoctane.be wrote:
Doru,
Some smart snippets welcome :-)
Can use that for a demo!
Phil
On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <tudor@tudorgirba.com> wrote: For a small prototype GUI, anything longer than one method is too long.
Doru
On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote: When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote: +1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote: Hi sean
I've been mulling this over for a while, and since we've been having conversations about Spec's place in our future... :) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
My point is that Spec was not conceived with this target in mind. We probably could get there, but we have to make it an explicit target. In contrast, Glamour was constructed like that. This is why you can now build rather complicated UIs with snippets that do fit in one method. You are not constrained by the one method for larger things, but you can start like that. Of course, Glamour does not have the same target as Spec, so this message is not about which one is better. I am simply pointing out that we need to change the focus if we want to get to easy-to-code-small-prototypes, specifically given that this fast prototyping is what makes Pharo stand apart. Doru On Mon, Sep 1, 2014 at 11:58 AM, phil@highoctane.be <phil@highoctane.be> wrote:
Doru,
Some smart snippets welcome :-)
Can use that for a demo!
Phil
On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
For a small prototype GUI, anything longer than one method is too long.
Doru
On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be
wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective",
one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do: button := PluggableButtonMorph new. button label: 'Button'. button openInWindow . According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods. https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess... I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong. On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
| dcm | (dcm := DynamicComposableModel new) instantiateModels: #(button ButtonModel). dcm button label: 'Button'; action: [ self halt ]. dcm openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #button ]; yourself). 2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
ok looks like I don't understand the Spec documentation well enough. So I tried this code in workspace based on your code dcm := DynamicComposableModel new. dcm instantiateModels: #(button ButtonModel ). dcm button label: 'Button'; action: Transcript open. dcm openWithSpecLayout: (SpecLayout composed newColumn: [:c | c add: #button]) but I have an issue, that action method there I assumed its the action triggered when I click the button. But instead Transcript opens when I do the code and if I close the Transcript window and click the button again, it does not open Transcript. Am I doing something wrong ? I am using latest Pharo 3 on Ubuntu. By the way thank you very much about your reply it looks like Spec is much closer to what I like that I initially thought , will study the documentation carefully and try some experiments to gain a better understanding. On Mon, Sep 1, 2014 at 2:56 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
| dcm | (dcm := DynamicComposableModel new) instantiateModels: #(button ButtonModel). dcm button label: 'Button'; action: [ self halt ]. dcm openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #button ]; yourself).
2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
Lets take a very simple example of creating a UI that contains one very
simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be
wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective",
one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
yes ignore me I am an idiot I missed the fact I need to pass a block as argument to action method now it works as expected, again thank you :) On Mon, Sep 1, 2014 at 3:23 PM, kilon alios <kilon.alios@gmail.com> wrote:
ok looks like I don't understand the Spec documentation well enough. So I tried this code in workspace based on your code
dcm := DynamicComposableModel new. dcm instantiateModels: #(button ButtonModel ). dcm button label: 'Button'; action: Transcript open. dcm openWithSpecLayout: (SpecLayout composed newColumn: [:c | c add: #button])
but I have an issue, that action method there I assumed its the action triggered when I click the button. But instead Transcript opens when I do the code and if I close the Transcript window and click the button again, it does not open Transcript. Am I doing something wrong ? I am using latest Pharo 3 on Ubuntu.
By the way thank you very much about your reply it looks like Spec is much closer to what I like that I initially thought , will study the documentation carefully and try some experiments to gain a better understanding.
On Mon, Sep 1, 2014 at 2:56 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
| dcm | (dcm := DynamicComposableModel new) instantiateModels: #(button ButtonModel). dcm button label: 'Button'; action: [ self halt ]. dcm openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #button ]; yourself).
2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
Lets take a very simple example of creating a UI that contains one very
simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be < phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been
having conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective",
one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
Err..., not really longer nor lots of methods. ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec. Bear in mind that Spec is based on models, not actual "Morphs". The ComposableModel idea is key here. HTH Phil On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios@gmail.com> wrote:
Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one
of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
On 01 Sep 2014, at 15:15, phil@highoctane.be wrote:
Err..., not really longer nor lots of methods.
+1 It can't get much shorter than this...
ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec.
Bear in mind that Spec is based on models, not actual "Morphs". The ComposableModel idea is key here.
HTH
Phil
On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios@gmail.com> wrote: Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be> wrote: When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote: +1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote: Hi sean
I've been mulling this over for a while, and since we've been having conversations about Spec's place in our future... :) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective", one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
Oh this is great, I am so glad I was wrong :) Looks like the design of Spec is much better than I first thought. How do I change the color of the button I tried using the color: message from ButtonModel superclass AbstractWidgetModel but button remains grey. On Mon, Sep 1, 2014 at 4:15 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Err..., not really longer nor lots of methods.
ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec.
Bear in mind that Spec is based on models, not actual "Morphs". The ComposableModel idea is key here.
HTH
Phil
On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios@gmail.com> wrote:
Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do:
button := PluggableButtonMorph new. button label: 'Button'. button openInWindow .
According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods.
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess...
I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong.
On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Personally there are two thing I dont like about Spec
a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use.
Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway.
nicolai
b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes.
On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve.
On Mon, Sep 1, 2014 at 10:32 AM, phil@highoctane.be <phil@highoctane.be
wrote:
When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out.
How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain).
Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular.
It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping.
An example: MorphicRadioButtonAdapter
defaultSpec <spec> ^ {#CheckboxMorph. #on:selected:changeSelected:. #model. #state. #state:. #label:. { #model. #label }. #labelClickable:. { #model. #labelClickable}. #beRadioButton. #hResizing:. #shrinkWrap. #vResizing:. #shrinkWrap. #setBalloonText:. #(model help). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). #dragEnabled:. #(model dragEnabled). #dropEnabled:. #(model dropEnabled). "#borderWidth:. #(model borderWidth). #borderColor:. #(model borderColor)"}
A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself.
Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine?
Phil
On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
+1 to both of you :)
Doru
On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo@free.fr> wrote:
Hi sean
I've been mulling this over for a while, and since we've been having
conversations about Spec's place in our future...
:) Good. This is important that everybody express itself.
DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something.
The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph.
Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good.
My discomfort is with making *all* our core tools Spec-based.
I agree this is why I started to write some little tool to be able to browse the system when Spec is shaking.
Now when you see the code of the old browser this is not nice either. So we will see and learn. But I can tell you that nothing is curved in stone. We will introduce GT but again you will get the same because GT is a frameworks.
While it is great from an "eating our own dog food perspective",
one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this.
We should iterate on it. May be another framework will be better in the future
My 2c.
----- Cheers, Sean -- View this message in context: http://forum.world.st/When- all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
philippeback wrote
ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec.
Just what I hoped for this thread - that we would all learn some cool things! And, Steph answered my concern right away with "So we will see and learn. But I can tell you that nothing is carved in stone". Perfect. ----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (9)
-
Esteban Lorenzano -
Hernán Morales Durand -
kilon alios -
Nicolai Hess -
phil＠highoctane.be -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Tudor Girba