no ooooooooooooo
Don't limit yourself show us your errors
your errors are coool
Glamour API should be better :)
Stef
On Nov 4, 2010, at 12:50 PM, Benjamin wrote:
Ouups :s
I'll try to open my both eyes before sending a mail now :)
Thank you
Ben _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Actually the Glamour API could be considered to be an internal DSL to describe browsers. I assume that a forth and five iteration are necessary to make it more user friendly. That is the reason why I did not pursue Glamour this May. I thought instead of going for Glamour I can just go through the effort of learning the ToolBuilder builder DSL -- which in the end is not more difficult either.
A note aside: Maybe I push the idea of DSL too much here. The question is: where do we talk about an API and where does the DSL idea start?
However --- though there are alot examples -- even more example will help and I recently enjoyed trying out some of them in the Moose-Glamour-Image.
--Hannes
On 11/4/10, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
no ooooooooooooo
Don't limit yourself show us your errors
your errors are coool
Glamour API should be better :)
Stef
On Nov 4, 2010, at 12:50 PM, Benjamin wrote:
Ouups :s
I'll try to open my both eyes before sending a mail now :)
Thank you
Ben _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
The Glamour API is intended to be an internal DSL. This is particularly useful for people that do not know Smalltalk :)
What parts of the API is not user friendly for you?
Regarding the ToolBuilder vs Glamour issue, ToolBuilder is a User Interface framework, while Glamour is a browser engine. To give you an idea, with the ToolBuilder, you place buttons in a window. With Glamour, you define the data flow and the way data is presented at a higher level.
Regarding examples, what kind of things are you interested in?
Cheers, Doru
On 4 Nov 2010, at 14:43, Hannes Hirzel wrote:
Actually the Glamour API could be considered to be an internal DSL to describe browsers. I assume that a forth and five iteration are necessary to make it more user friendly. That is the reason why I did not pursue Glamour this May. I thought instead of going for Glamour I can just go through the effort of learning the ToolBuilder builder DSL -- which in the end is not more difficult either.
A note aside: Maybe I push the idea of DSL too much here. The question is: where do we talk about an API and where does the DSL idea start?
However --- though there are alot examples -- even more example will help and I recently enjoyed trying out some of them in the Moose-Glamour-Image.
--Hannes
On 11/4/10, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
no ooooooooooooo
Don't limit yourself show us your errors
your errors are coool
Glamour API should be better :)
Stef
On Nov 4, 2010, at 12:50 PM, Benjamin wrote:
Ouups :s
I'll try to open my both eyes before sending a mail now :)
Thank you
Ben _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
Hello Tudor
On 11/4/10, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
The Glamour API is intended to be an internal DSL. This is particularly useful for people that do not know Smalltalk :)
What parts of the API is not user friendly for you?
At this moment I cannot say more that I would prefer simpler statements. A more procedural builder oriented style. Not everything in one big statement with nested blocks.
You have the graphical layout and the connections and I would just like to describe that in a sequence of statements. Not in a hierarchy of nested blocks. Less implicit semantics.
Regarding the ToolBuilder vs Glamour issue, ToolBuilder is a User Interface framework, while Glamour is a browser engine.
Sure. But as mentioned above for less complex cases it is the same. The initial effort you have to put into learning the Glamour DSL is still considerable.
To give you an idea, with the
ToolBuilder, you place buttons in a window.
Yes and no. You take an existing example as a template and change method names. There are many examples.
E.g. a Two pane browser, a three pane browser, with and without text window and so on...
With Glamour, you define the
data flow and the way data is presented at a higher level.
For a browser the data flow is often pretty standard.
Regarding examples, what kind of things are you interested in?
More simple examples which do something useful. Just to get the flavor of the DSL.
A more complex one: An example where I can navigate a network. I see all the neighbors of a node (as a list and as graph). A node has a content window. Navigation buttons forth and back.
Some real world examples outside the Smalltalk class hierarchy, for example a WordNet browser http://en.wikipedia.org/wiki/WordNet
Cheers, Doru
Thank you for answering and keeping up this interesting work.
--Hannes
On 4 Nov 2010, at 14:43, Hannes Hirzel wrote:
Actually the Glamour API could be considered to be an internal DSL to describe browsers. I assume that a forth and five iteration are necessary to make it more user friendly. That is the reason why I did not pursue Glamour this May. I thought instead of going for Glamour I can just go through the effort of learning the ToolBuilder builder DSL -- which in the end is not more difficult either.
A note aside: Maybe I push the idea of DSL too much here. The question is: where do we talk about an API and where does the DSL idea start?
However --- though there are alot examples -- even more example will help and I recently enjoyed trying out some of them in the Moose-Glamour-Image.
--Hannes
On 11/4/10, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
no ooooooooooooo
Don't limit yourself show us your errors
your errors are coool
Glamour API should be better :)
Stef
On Nov 4, 2010, at 12:50 PM, Benjamin wrote:
Ouups :s
I'll try to open my both eyes before sending a mail now :)
Thank you
Ben _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 4 Nov 2010, at 17:50, Hannes Hirzel wrote:
Hello Tudor
On 11/4/10, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
The Glamour API is intended to be an internal DSL. This is particularly useful for people that do not know Smalltalk :)
What parts of the API is not user friendly for you?
At this moment I cannot say more that I would prefer simpler statements. A more procedural builder oriented style. Not everything in one big statement with nested blocks.
You have the graphical layout and the connections and I would just like to describe that in a sequence of statements. Not in a hierarchy of nested blocks. Less implicit semantics.
:). I do not understand what you mean by less implicit semantics. The construction of the Glamour model is pretty straightforward. The blocks are nothing but a strategy to avoid subclassing when in prototyping mode.
Regarding the ToolBuilder vs Glamour issue, ToolBuilder is a User Interface framework, while Glamour is a browser engine.
Sure. But as mentioned above for less complex cases it is the same. The initial effort you have to put into learning the Glamour DSL is still considerable.
For trivial cases, you should not need much. I had several programmers that do not know Smalltalk that managed to build some simple browsers after half a day of training (including learning Smalltalk syntax, tools and so on).
To give you an idea, with the
ToolBuilder, you place buttons in a window.
Yes and no. You take an existing example as a template and change method names. There are many examples.
:)
E.g. a Two pane browser, a three pane browser, with and without text window and so on...
With Glamour, you define the
data flow and the way data is presented at a higher level.
For a browser the data flow is often pretty standard.
I do not subscribe to this statement :). There are abstract patterns, but other than that, we typically need to treat each data structure and each use case in a different way.
The problem with browsers is that even when they initially start small, they tend to grow over time. And when updating and data propagation is not approached systematically, they soon become difficult to manage. What Glamour does is to decouple the data flow from the presentation strategy. One of the things that came out of this work was the approach to think of a browser primarily as a data flow, and only secondarily as a way to present the data. Perhaps from what exists now, it is still not that obvious what the approach brings, but I am confident that it will make a significant different in the not-so-long-run.
Regarding examples, what kind of things are you interested in?
More simple examples which do something useful. Just to get the flavor of the DSL.
A more complex one: An example where I can navigate a network. I see all the neighbors of a node (as a list and as graph). A node has a content window. Navigation buttons forth and back. Some real world examples outside the Smalltalk class hierarchy, for example a WordNet browser http://en.wikipedia.org/wiki/WordNet
There are several examples of browsing more complex pieces of information in Moose. For example, by doing: - MooseMetaBrowser open - MoosePanel open
Thank you for answering and keeping up this interesting work.
Thanks for asking. Actually, if you have more punctual questions about Glamour, we would welcome more questions.
Cheers, Doru
--Hannes
On 4 Nov 2010, at 14:43, Hannes Hirzel wrote:
Actually the Glamour API could be considered to be an internal DSL to describe browsers. I assume that a forth and five iteration are necessary to make it more user friendly. That is the reason why I did not pursue Glamour this May. I thought instead of going for Glamour I can just go through the effort of learning the ToolBuilder builder DSL -- which in the end is not more difficult either.
A note aside: Maybe I push the idea of DSL too much here. The question is: where do we talk about an API and where does the DSL idea start?
However --- though there are alot examples -- even more example will help and I recently enjoyed trying out some of them in the Moose-Glamour-Image.
--Hannes
On 11/4/10, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
no ooooooooooooo
Don't limit yourself show us your errors
your errors are coool
Glamour API should be better :)
Stef
On Nov 4, 2010, at 12:50 PM, Benjamin wrote:
Ouups :s
I'll try to open my both eyes before sending a mail now :)
Thank you
Ben _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
-
Hannes Hirzel -
Stéphane Ducasse -
Tudor Girba