Smalltalk › Frameworks & Tools › Moose

[ann] gt diagrammer

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

34 messages Options

Tudor Girba-2

[ann] gt diagrammer

Hi,

We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.

It looks like this:

https://twitter.com/feenkcom/status/976341449267531776

We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.

One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152

The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.

We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.

Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.

There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.

To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.

And then inspect:
GtDiagrammerElement new

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Thierry Goubier

Re: [ann] gt diagrammer

Hi Doru,

interesting. You're recreating HotDraw then?

Do you intent to go to the point where you could define with a domain
specific editor inside HotDraw the behavior of interactors for HotDraw
itself?

Regards,

Thierry

Le 07/04/2018 à 18:39, Tudor Girba a écrit :

> Hi,
>
> We are happy to announce an initial version of GT Diagrammer, an engine
> for constructing diagrams interactively. This is the newest addition to
> the next generation GT built on Bloc.
>
> It looks like this:
> https://twitter.com/feenkcom/status/976341449267531776
>
>
>
> We chose to work on Diagrammer for multiple reasons. First, developers
> often need to create hand built diagrams to communicate intentions, and
> an integrated experience should not require us to leave our environment
> to create them. At the same time, Diagrammer is an application that
> requires a widgets and interactions, and thus it is a nice exercise for
> Bloc and Brick.
>
> One requirement we had from the beginning was to make it work with any
> Bloc element. This means that the editing part had to be reasonably
> generic. To this end, we now have elements that can define visual
> editors. This is somewhat a combination between Magritte descriptions,
> and inspector extensions. An interesting side effect is that now we can
> edit visual properties when inspecting any element. In other words, we
> got the basic infrastructure of a UI painter. It looks like this:
> https://twitter.com/feenkcom/status/982656456968241152
>
> The user interface essentially relies on two widgets: scrollable list
> and toggle button. While the visual look of the toggle button is
> inspired from material design, the most interesting part is that now
> we have an implementation for controlling looks per element instance. A
> key issue here is that looks can react to events coming from the element
> and inject visual attributes and possible even change behavior (for
> example, changing an icon while pressing a button). We will post more
> about looks soon.
>
> We now also have a nice solution for overlays. For example, we have an
> overlay showing selection and an overlay for resizing elements.
>
> Perhaps less obvious, Diagrammer also offers a basic infrastructure for
> the area of visual languages. As Diagrammer works with any Bloc
> elements, we can simply create dedicated visual elements. As an example,
> Diagrammer comes with an implementation of a UML class figure.
> Furthermore, as the functionality does not impose a specific model,
> custom language semantics can be mapped on visual actions.
>
> There are several things to do still for it to become a mature solution.
> An important next step is to serialize a diagram scene in a reproducible
> manner. Currently, the diagram (or any element) can be exported as pdf
> (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png,
> gif or jpeg by directly using the low level canvas. However, for
> the diagram to be truly useful we need to store the result in either
> code or another reloadable form such as STON. Other future directions
> are related to figure controlling (for example, custom anchors or line
> bending points) and to enhanced editors.
>
> To play with it, the easiest way is to download the new GT in a Pharo
> 6.1 image:
> Metacello new
>    baseline: 'GToolkit';
>    repository: 'github://feenkcom/gtoolkit/src';
>    load.
>
> And then inspect:
> GtDiagrammerElement new
>
> Cheers,
> The feenk team
>
>
> --
> www.tudorgirba.com <http://www.tudorgirba.com>
> www.feenk.com
>
> "Presenting is storytelling."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: [ann] gt diagrammer

Hi Thierry,

We are not recreating HotDraw.

One important characteristic of Diagrammer, like with all other visualizations built on Bloc, is that it does not have a separate model that renders with Bloc. It is actually an editor of arbitrary Bloc elements. The diagramming of a graph scene with figures and lines is but a specific use case that happens to have practical meaning.

But, perhaps even more important is that it shows that Bloc&Brick start to provide an initial basis for applications (as opposed to drawings).

Cheers,
Doru

> On Apr 7, 2018, at 6:56 PM, Thierry Goubier <[hidden email]> wrote:
>
> Hi Doru,
>
> interesting. You're recreating HotDraw then?
>
> Do you intent to go to the point where you could define with a domain specific editor inside HotDraw the behavior of interactors for HotDraw itself?
>
> Regards,
>
> Thierry
>
> Le 07/04/2018 à 18:39, Tudor Girba a écrit :
>> Hi,
>> We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.
>> It looks like this:
>> https://twitter.com/feenkcom/status/976341449267531776
>> We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
>> One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
>> https://twitter.com/feenkcom/status/982656456968241152
>> The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
>> We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
>> Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
>> There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
>> To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
>> Metacello new
>> baseline: 'GToolkit';
>> repository: 'github://feenkcom/gtoolkit/src';
>> load.
>> And then inspect:
>> GtDiagrammerElement new
>> Cheers,
>> The feenk team
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>> www.feenk.com
>> "Presenting is storytelling."
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

“Programming is executable philosophy."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Stéphane Ducasse

Re: [ann] gt diagrammer

On 7 Apr 2018, at 19:16, Tudor Girba <[hidden email]> wrote:

Hi Thierry,

We are not recreating HotDraw.

One important characteristic of Diagrammer, like with all other visualizations built on Bloc, is that it does not have a separate model that renders with Bloc. It is actually an editor of arbitrary Bloc elements. The diagramming of a graph scene with figures and lines is but a specific use case that happens to have practical meaning.

But, perhaps even more important is that it shows that Bloc&Brick start to provide an initial basis for applications (as opposed to drawings).

And I see that we will be able to extend diagrammer in a lot of direction

- smart guides

- UI builder

- domain specific

…

To me it shows that we will change our life because Morphic was hampering us to dream

Cheers,
Doru

On Apr 7, 2018, at 6:56 PM, Thierry Goubier <[hidden email]> wrote:

Hi Doru,

interesting. You're recreating HotDraw then?

Do you intent to go to the point where you could define with a domain specific editor inside HotDraw the behavior of interactors for HotDraw itself?

Regards,

Thierry

Le 07/04/2018 à 18:39, Tudor Girba a écrit :
Hi,
We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.
It looks like this:
https://twitter.com/feenkcom/status/976341449267531776
We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152
The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
  baseline: 'GToolkit';
  repository: 'github://feenkcom/gtoolkit/src';
  load.
And then inspect:
GtDiagrammerElement new
Cheers,
The feenk team
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

“Programming is executable philosophy."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--------------------------------------------

Stéphane Ducasse

http://stephane.ducasse.free.fr

http://www.synectique.eu / http://www.pharo.org

03 59 35 87 52

Assistant: Julie Jonas

FAX 03 59 57 78 50

TEL 03 59 35 86 16

S. Ducasse - Inria

40, avenue Halley,

Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650

France

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Thierry Goubier

Re: [ann] gt diagrammer

In reply to this post by Tudor Girba-2

Hi Doru,

Le 07/04/2018 à 19:16, Tudor Girba a écrit :
> Hi Thierry,
>
> We are not recreating HotDraw.

That's sad.

I miss the time when I was doing domain specific editors in HotDraw.

Thierry
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Stéphane Ducasse

Re: [ann] gt diagrammer

On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email]> wrote:

Hi Doru,

Le 07/04/2018 à 19:16, Tudor Girba a écrit :
Hi Thierry,
We are not recreating HotDraw.

That's sad.

No it is not. :)

You can rebuild a new hotdraw if you want.

This is what diagrammer is showing.

It shows that we can move on the UI level again. I’m waiting for this since at least eigth years.

Stef

I miss the time when I was doing domain specific editors in HotDraw.

Thierry
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--------------------------------------------

Stéphane Ducasse

http://stephane.ducasse.free.fr

http://www.synectique.eu / http://www.pharo.org

03 59 35 87 52

Assistant: Julie Jonas

FAX 03 59 57 78 50

TEL 03 59 35 86 16

S. Ducasse - Inria

40, avenue Halley,

Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650

France

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Thierry Goubier

Re: [ann] gt diagrammer

Hi Stef,

Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :

>
>> On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi Doru,
>>
>> Le 07/04/2018 à 19:16, Tudor Girba a écrit :
>>> Hi Thierry,
>>> We are not recreating HotDraw.
>>
>> That's sad.
>
> No it is not. :)
> You can rebuild a new hotdraw if you want.
> This is what diagrammer is showing.
>
> It shows that we can move on the UI level again. I’m waiting for this
> since at least eigth years.

Good for you :) I'm not so optimistic.

I have the feeling that it's not the GUI framework that was holding you,
but the architecture philosophy in the implementation: wrongly remapping
of a type of GUI over another system, widgets with hundreds of instance
variables all blocks so that we can't understand what they are used for,
widgets requiring thousands of lines of code to produce the dozens of
different things on a view they require, a widget system with call
depths so long you have no idea of the path it's taking to open a
window, another where you have to explore your container to do things
when you create a view.

So, will that change? Or, has that been carried over to the new one?

Thierry

>
> Stef
>
>> I miss the time when I was doing domain specific editors in HotDraw.
>>
>> Thierry
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Ben Coman

Re: [ann] gt diagrammer

In reply to this post by Tudor Girba-2

Nice to hear of progress in this area.

Cheers to feenk team

On 8 April 2018 at 00:39, Tudor Girba <[hidden email]> wrote:

Hi,

We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.

It looks like this:
https://twitter.com/feenkcom/status/976341449267531776

We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.

One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152

The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.

We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.

Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.

There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.

To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.

And then inspect:
GtDiagrammerElement new

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: [ann] gt diagrammer

In reply to this post by Stéphane Ducasse

Hi,

> On Apr 7, 2018, at 8:06 PM, Stéphane Ducasse <[hidden email]> wrote:
>
>>
>> On 7 Apr 2018, at 19:16, Tudor Girba <[hidden email]> wrote:
>>
>> Hi Thierry,
>>
>> We are not recreating HotDraw.
>>
>> One important characteristic of Diagrammer, like with all other visualizations built on Bloc, is that it does not have a separate model that renders with Bloc. It is actually an editor of arbitrary Bloc elements. The diagramming of a graph scene with figures and lines is but a specific use case that happens to have practical meaning.
>>
>> But, perhaps even more important is that it shows that Bloc&Brick start to provide an initial basis for applications (as opposed to drawings).
>
> And I see that we will be able to extend diagrammer in a lot of direction
> - smart guides
> - UI builder
> - domain specific
> …

Yes.

> To me it shows that we will change our life because Morphic was hampering us to dream

Indeed, this is what it shows :)

Doru

>
>>
>> Cheers,
>> Doru
>>
>>
>>> On Apr 7, 2018, at 6:56 PM, Thierry Goubier <[hidden email]> wrote:
>>>
>>> Hi Doru,
>>>
>>> interesting. You're recreating HotDraw then?
>>>
>>> Do you intent to go to the point where you could define with a domain specific editor inside HotDraw the behavior of interactors for HotDraw itself?
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>> Le 07/04/2018 à 18:39, Tudor Girba a écrit :
>>>> Hi,
>>>> We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.
>>>> It looks like this:
>>>> https://twitter.com/feenkcom/status/976341449267531776
>>>> We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
>>>> One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
>>>> https://twitter.com/feenkcom/status/982656456968241152
>>>> The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
>>>> We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
>>>> Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
>>>> There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
>>>> To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
>>>> Metacello new
>>>> baseline: 'GToolkit';
>>>> repository: 'github://feenkcom/gtoolkit/src';
>>>> load.
>>>> And then inspect:
>>>> GtDiagrammerElement new
>>>> Cheers,
>>>> The feenk team
>>>> --
>>>> www.tudorgirba.com <http://www.tudorgirba.com>
>>>> www.feenk.com
>>>> "Presenting is storytelling."
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> “Programming is executable philosophy."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Some battles are better lost than fought."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

hernanmd

Re: [ann] gt diagrammer

In reply to this post by Tudor Girba-2

Hi Tudor,

Very nice! Thank you for sharing, this seems to be hard work.

If you welcome some feedback:

Live tab:

- When I select "Figure" button, then choose from the figures toolbar and put a figure, the selection focus goes back to the "Select" button loosing the figures toolbar. It would be nice to save some clicks by staying in the Figure when putting a lot of figures.

- The "Figure" are actually UML figures? It would be cool to categorize the types of figures available in a toolbar.

- Clicking "Line" button does not display any lines to select (maybe ToDo?)

Events tab
- I guess is used for Undo/Redo

"User data", "Resizers", and "Transformation"
- I didn't understood what are they for.

I am intrigued by the "inject visual attributes" per-instance, maybe something like the old Parts Workbench from VisualSmalltalk?

Cheers,

Hernán

2018-04-07 13:39 GMT-03:00 Tudor Girba <[hidden email]>:

Hi,

We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.

It looks like this:
https://twitter.com/feenkcom/status/976341449267531776

We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.

One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152

The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.

We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.

Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.

There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.

To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.

And then inspect:
GtDiagrammerElement new

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: [ann] gt diagrammer

Hi,

> On Apr 8, 2018, at 10:27 AM, Hernán Morales Durand <[hidden email]> wrote:
>
> Hi Tudor,
>
> Very nice! Thank you for sharing, this seems to be hard work.

Thanks.

> If you welcome some feedback:
>
> Live tab:
> - When I select "Figure" button, then choose from the figures toolbar and put a figure, the selection focus goes back to the "Select" button loosing the figures toolbar. It would be nice to save some clicks by staying in the Figure when putting a lot of figures.

Indeed, we are thinking about keeping the Figure mode when pressing Shift.

> - The "Figure" are actually UML figures? It would be cool to categorize the types of figures available in a toolbar.

The Figures is actually any figures. The figures available are there for validation to show that both simple figures and complicated one (such as a UML class) can work fine. But, you can define your own stencils (factories of figures) and they will appear there.

> - Clicking "Line" button does not display any lines to select (maybe ToDo?)

ToDo indeed :).

> Events tab
> - I guess is used for Undo/Redo
> "User data", "Resizers", and "Transformation"
> - I didn't understood what are they for.

These are element specific views in the inspector, each interesting for different purposes. For example, the Events presentation shows a log of all events that reached the element - a very useful input when debugging UI logic.

> I am intrigued by the "inject visual attributes" per-instance, maybe something like the old Parts Workbench from VisualSmalltalk?

I do not know what the Parts Workbench is. In our case, we want to be able to specify the look of an element independent from the element itself, and we want to be able to do that per element instance, not per type, and not as a global behavior (like in the current theme).

Cheers,
Doru

> Cheers,
>
> Hernán
>
>
>
>
> 2018-04-07 13:39 GMT-03:00 Tudor Girba <[hidden email]>:
> Hi,
>
> We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.
>
> It looks like this:
> https://twitter.com/feenkcom/status/976341449267531776
> <diagrammer-overview.png>
>
>
> We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
>
> One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
> https://twitter.com/feenkcom/status/982656456968241152
>
> The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
>
> We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
>
> Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
>
> There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
>
> To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
> Metacello new
> baseline: 'GToolkit';
> repository: 'github://feenkcom/gtoolkit/src';
> load.
>
> And then inspect:
> GtDiagrammerElement new
>
> Cheers,
> The feenk team
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Presenting is storytelling."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: [ann] gt diagrammer

In reply to this post by Thierry Goubier

Hi,

> On Apr 7, 2018, at 10:22 PM, Thierry Goubier <[hidden email]> wrote:
>
> Hi Stef,
>
> Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
>>> On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> Hi Doru,
>>>
>>> Le 07/04/2018 à 19:16, Tudor Girba a écrit :
>>>> Hi Thierry,
>>>> We are not recreating HotDraw.
>>>
>>> That's sad.
>> No it is not. :)
>> You can rebuild a new hotdraw if you want.
>> This is what diagrammer is showing.
>> It shows that we can move on the UI level again. I’m waiting for this since at least eigth years.
>
> Good for you :) I'm not so optimistic.
>
> I have the feeling that it's not the GUI framework that was holding you, but the architecture philosophy in the implementation: wrongly remapping of a type of GUI over another system, widgets with hundreds of instance variables all blocks so that we can't understand what they are used for, widgets requiring thousands of lines of code to produce the dozens of different things on a view they require, a widget system with call depths so long you have no idea of the path it's taking to open a window, another where you have to explore your container to do things when you create a view.
>
> So, will that change? Or, has that been carried over to the new one?

Bloc is a fresh implementation and the goal is to provide the foundation for the future UI of Pharo. I would be very happy to get your feedback on code, should you have the time time to look at it.

Cheers,
Doru

> Thierry
>
>> Stef
>>> I miss the time when I was doing domain specific editors in HotDraw.
>>>
>>> Thierry
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> --------------------------------------------
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> http://www.synectique.eu / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Thierry Goubier

Re: [ann] gt diagrammer

Hi Doru,

Le 08/04/2018 à 20:23, Tudor Girba a écrit :

> Hi,
>
>
>> On Apr 7, 2018, at 10:22 PM, Thierry Goubier <[hidden email]> wrote:
>>
>> Hi Stef,
>>
>> Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
>>>> On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> Hi Doru,
>>>>
>>>> Le 07/04/2018 à 19:16, Tudor Girba a écrit :
>>>>> Hi Thierry,
>>>>> We are not recreating HotDraw.
>>>>
>>>> That's sad.
>>> No it is not. :)
>>> You can rebuild a new hotdraw if you want.
>>> This is what diagrammer is showing.
>>> It shows that we can move on the UI level again. I’m waiting for this since at least eigth years.
>>
>> Good for you :) I'm not so optimistic.
>>
>> I have the feeling that it's not the GUI framework that was holding you, but the architecture philosophy in the implementation: wrongly remapping of a type of GUI over another system, widgets with hundreds of instance variables all blocks so that we can't understand what they are used for, widgets requiring thousands of lines of code to produce the dozens of different things on a view they require, a widget system with call depths so long you have no idea of the path it's taking to open a window, another where you have to explore your container to do things when you create a view.
>>
>> So, will that change? Or, has that been carried over to the new one?
>
> Bloc is a fresh implementation and the goal is to provide the foundation for the future UI of Pharo. I would be very happy to get your feedback on code, should you have the time time to look at it.

I am, probably (very) slowly, because:

- Bloc is huge: 45k lines(*). Congratulations to all the effort that
went into it.

- From the examples and a cursory look at the code, it is yagt (yet
another gui toolkit), which does not make it interesting to review(**).
There is maybe really interesting stuff in there, but it may be very
hard to find the interesting detail in that huge chunk of code.

Have you evaluated Bloc with the Moose tools?

Regards,

Thierry

(*) Which means, in C terms, probably the equivalent of half a million
lines of code, given Smalltalk ability to produce dense code.
(**) I'm not good nor an interesting person to ask for a review of an
engineering effort.

> Cheers,
> Doru
>
>
>
>> Thierry
>>
>>> Stef
>>>> I miss the time when I was doing domain specific editors in HotDraw.
>>>>
>>>> Thierry
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email] <mailto:[hidden email]>
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>> --------------------------------------------
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr
>>> http://www.synectique.eu / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Stéphane Ducasse

Re: [ann] gt diagrammer

In reply to this post by Tudor Girba-2

Hi doru

A while ago I was talking with Alain about the size of Bloc and Alain told me that it was normal that Bloc was large
because it is doing more than Morphic and I should not compare.
Ok ok ok but what is miniBloc?
Because one of this day it will happen. I mean the instance var number of certain classes is simply huge.
And it would be good have also a more modular view.

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

miniBloc [was gt diagrammer]

Hi,

That is a good question.

The core of Bloc is found in the Bloc package. That one has 14k lines of code.

It can be loaded as:
Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc/src';
load: #'minimal:bloc’

This part is also built separately in Travis:
https://travis-ci.org/pharo-graphics/Bloc

The minimal Bloc does not have any rendering, and should even be independent from Sparta.

We should also take into account that Bloc is not just a GUI framework, but also a visualization one, and that its model is fine grained.

The instance variable count in BlElement is large, indeed. This is a problem we are constantly struggling with. We are still in the process of removing a couple, but it will still be large. So, that’s still an issue.

Cheers,
Doru

> On Apr 9, 2018, at 7:58 AM, Stéphane Ducasse <[hidden email]> wrote:
>
> Hi doru
>
> A while ago I was talking with Alain about the size of Bloc and Alain told me that it was normal that Bloc was large
> because it is doing more than Morphic and I should not compare.
> Ok ok ok but what is miniBloc?
> Because one of this day it will happen. I mean the instance var number of certain classes is simply huge.
> And it would be good have also a more modular view.
>
> Stef
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant,
it probably isn't."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Stéphane Ducasse

Re: miniBloc [was gt diagrammer]

>
> Hi,
>
> That is a good question.
>
> The core of Bloc is found in the Bloc package. That one has 14k lines of code.
>
> It can be loaded as:
> Metacello new
> baseline: 'Bloc';
> repository: 'github://pharo-graphics/Bloc/src';
> load: #'minimal:bloc’
>
> This part is also built separately in Travis:
> https://travis-ci.org/pharo-graphics/Bloc
>
> The minimal Bloc does not have any rendering, and should even be independent from Sparta.
>
> We should also take into account that Bloc is not just a GUI framework, but also a visualization one, and that its model is fine grained.
>
> The instance variable count in BlElement is large, indeed. This is a problem we are constantly struggling with. We are still in the process of removing a couple, but it will still be large. So, that’s still an issue.

I imagine that you are concerned.
Do you think that traits with instance variables could help?
I do not expect an immediate answer. I was just thinking about extensibility and modularity
First we should get a first 1.0 release :)

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: miniBloc [was gt diagrammer]

Hi,

> On Apr 9, 2018, at 8:42 AM, Stéphane Ducasse <[hidden email]> wrote:
>
>>
>> Hi,
>>
>> That is a good question.
>>
>> The core of Bloc is found in the Bloc package. That one has 14k lines of code.
>>
>> It can be loaded as:
>> Metacello new
>> baseline: 'Bloc';
>> repository: 'github://pharo-graphics/Bloc/src';
>> load: #'minimal:bloc’
>>
>> This part is also built separately in Travis:
>> https://travis-ci.org/pharo-graphics/Bloc
>>
>> The minimal Bloc does not have any rendering, and should even be independent from Sparta.
>>
>> We should also take into account that Bloc is not just a GUI framework, but also a visualization one, and that its model is fine grained.
>>
>> The instance variable count in BlElement is large, indeed. This is a problem we are constantly struggling with. We are still in the process of removing a couple, but it will still be large. So, that’s still an issue.
>
> I imagine that you are concerned.
> Do you think that traits with instance variables could help?

> I do not expect an immediate answer. I was just thinking about extensibility and modularity

Yes, it likely can help.

> First we should get a first 1.0 release :)

Yes :).

Doru

> Stef
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant,
it probably isn't."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Tudor Girba-2

Re: [ann] gt diagrammer

In reply to this post by Thierry Goubier

Hi,

I think it might be more interesting to start the review from the usage of it, not from the internals.

Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example:
- Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design.
- It is inspectable. For example, inspecting an element offers views such as for tracking events, measurements or transformations. This can sound small, but when built at the very core, it decreases costs significantly later on (already did for us).

Cheers,
Doru

> On Apr 9, 2018, at 6:47 AM, Thierry Goubier <[hidden email]> wrote:
>
> Hi Doru,
>
> Le 08/04/2018 à 20:23, Tudor Girba a écrit :
>> Hi,
>>> On Apr 7, 2018, at 10:22 PM, Thierry Goubier <[hidden email]> wrote:
>>>
>>> Hi Stef,
>>>
>>> Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
>>>>> On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Hi Doru,
>>>>>
>>>>> Le 07/04/2018 à 19:16, Tudor Girba a écrit :
>>>>>> Hi Thierry,
>>>>>> We are not recreating HotDraw.
>>>>>
>>>>> That's sad.
>>>> No it is not. :)
>>>> You can rebuild a new hotdraw if you want.
>>>> This is what diagrammer is showing.
>>>> It shows that we can move on the UI level again. I’m waiting for this since at least eigth years.
>>>
>>> Good for you :) I'm not so optimistic.
>>>
>>> I have the feeling that it's not the GUI framework that was holding you, but the architecture philosophy in the implementation: wrongly remapping of a type of GUI over another system, widgets with hundreds of instance variables all blocks so that we can't understand what they are used for, widgets requiring thousands of lines of code to produce the dozens of different things on a view they require, a widget system with call depths so long you have no idea of the path it's taking to open a window, another where you have to explore your container to do things when you create a view.
>>>
>>> So, will that change? Or, has that been carried over to the new one?
>> Bloc is a fresh implementation and the goal is to provide the foundation for the future UI of Pharo. I would be very happy to get your feedback on code, should you have the time time to look at it.
>
> I am, probably (very) slowly, because:
>
> - Bloc is huge: 45k lines(*). Congratulations to all the effort that went into it.
>
> - From the examples and a cursory look at the code, it is yagt (yet another gui toolkit), which does not make it interesting to review(**). There is maybe really interesting stuff in there, but it may be very hard to find the interesting detail in that huge chunk of code.
>
> Have you evaluated Bloc with the Moose tools?
>
> Regards,
>
> Thierry
>
> (*) Which means, in C terms, probably the equivalent of half a million lines of code, given Smalltalk ability to produce dense code.
> (**) I'm not good nor an interesting person to ask for a review of an engineering effort.
>
>> Cheers,
>> Doru
>>> Thierry
>>>
>>>> Stef
>>>>> I miss the time when I was doing domain specific editors in HotDraw.
>>>>>
>>>>> Thierry
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email] <mailto:[hidden email]>
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>> --------------------------------------------
>>>> Stéphane Ducasse
>>>> http://stephane.ducasse.free.fr
>>>> http://www.synectique.eu / http://www.pharo.org
>>>> 03 59 35 87 52
>>>> Assistant: Julie Jonas
>>>> FAX 03 59 57 78 50
>>>> TEL 03 59 35 86 16
>>>> S. Ducasse - Inria
>>>> 40, avenue Halley,
>>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>>> Villeneuve d'Ascq 59650
>>>> France
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> "Being happy is a matter of choice."
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Thierry Goubier

Re: [ann] gt diagrammer

2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi,
>
> I think it might be more interesting to start the review from the usage of it, not from the internals.

Well, from the usage of it, I've seen nothing that doesn't fit into
the yagt. I've seen that field evolve and try clever things, really
different things, and Bloc does not look like one of thoses.

> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example:
> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design.

Look, from the point of view of the man of the art, it doesn't seems
like a breakthrough.

Compared to other smalltalk-based solutions, yes, it may be seen as an
improvement.

I think you underestimate how advanced that field has been / is, and
how far behind the state of the art are industrial solutions.

There is only one development in the Smalltalk space in GUI that is
worthy of interest for me: the anti-aliasing of Juan Vuletich. It
would have so much impact overall (remove all dependencies on external
libs, remove the need to do font anti-aliasing, scrap thousands of
lines of slow and ugly Smalltalk code, simplify the FreeType
infrastructure, remove MBs of external librairies, ensure long-term
porting ease / code evolution).

> - It is inspectable. For example, inspecting an element offers views such as for tracking events, measurements or transformations. This can sound small, but when built at the very core, it decreases costs significantly later on (already did for us).

That may well be the key of the innovative aspect of it: not the
design, not the software architecture, but the development stories
around it.

In the example Bloc application, what is interesting is the use of the
GT inspector. All the code, the objects, the framework, feels
underwhelming, at least not worthy of any hype, apart from: yes, it
works. So what?

But I think I told you about that before. I want to see your ideas
about how to transform the development experience... I don't see Bloc
as a very interesting development in that; it would have been a lot
more significant to manage to do that over Morphic, for example.
Because, you see, you designed Bloc so that it could be ameneable to
your development experiences, and as such you're making it a lot
easier on yourself; you're not proving the applicability of your ideas
to GUI implementations, but the implementation of a GUI toolkit
according to your idea requirements.

And I do believe you would have done a very fine point of both
improving Morphic, and proving your Ideas, and investing a lot less
than with Bloc.

(What Alain Plantec showed me of his early beginnings with
reimplementing Morphic, the tooling he used: that was really clever.)

Regards,

Thierry

>
> Cheers,
> Doru
>
>
>> On Apr 9, 2018, at 6:47 AM, Thierry Goubier <[hidden email]> wrote:
>>
>> Hi Doru,
>>
>> Le 08/04/2018 à 20:23, Tudor Girba a écrit :
>>> Hi,
>>>> On Apr 7, 2018, at 10:22 PM, Thierry Goubier <[hidden email]> wrote:
>>>>
>>>> Hi Stef,
>>>>
>>>> Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
>>>>>> On 7 Apr 2018, at 21:25, Thierry Goubier <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Hi Doru,
>>>>>>
>>>>>> Le 07/04/2018 à 19:16, Tudor Girba a écrit :
>>>>>>> Hi Thierry,
>>>>>>> We are not recreating HotDraw.
>>>>>>
>>>>>> That's sad.
>>>>> No it is not. :)
>>>>> You can rebuild a new hotdraw if you want.
>>>>> This is what diagrammer is showing.
>>>>> It shows that we can move on the UI level again. I’m waiting for this since at least eigth years.
>>>>
>>>> Good for you :) I'm not so optimistic.
>>>>
>>>> I have the feeling that it's not the GUI framework that was holding you, but the architecture philosophy in the implementation: wrongly remapping of a type of GUI over another system, widgets with hundreds of instance variables all blocks so that we can't understand what they are used for, widgets requiring thousands of lines of code to produce the dozens of different things on a view they require, a widget system with call depths so long you have no idea of the path it's taking to open a window, another where you have to explore your container to do things when you create a view.
>>>>
>>>> So, will that change? Or, has that been carried over to the new one?
>>> Bloc is a fresh implementation and the goal is to provide the foundation for the future UI of Pharo. I would be very happy to get your feedback on code, should you have the time time to look at it.
>>
>> I am, probably (very) slowly, because:
>>
>> - Bloc is huge: 45k lines(*). Congratulations to all the effort that went into it.
>>
>> - From the examples and a cursory look at the code, it is yagt (yet another gui toolkit), which does not make it interesting to review(**). There is maybe really interesting stuff in there, but it may be very hard to find the interesting detail in that huge chunk of code.
>>
>> Have you evaluated Bloc with the Moose tools?
>>
>> Regards,
>>
>> Thierry
>>
>> (*) Which means, in C terms, probably the equivalent of half a million lines of code, given Smalltalk ability to produce dense code.
>> (**) I'm not good nor an interesting person to ask for a review of an engineering effort.
>>
>>> Cheers,
>>> Doru
>>>> Thierry
>>>>
>>>>> Stef
>>>>>> I miss the time when I was doing domain specific editors in HotDraw.
>>>>>>
>>>>>> Thierry
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>> --------------------------------------------
>>>>> Stéphane Ducasse
>>>>> http://stephane.ducasse.free.fr
>>>>> http://www.synectique.eu / http://www.pharo.org
>>>>> 03 59 35 87 52
>>>>> Assistant: Julie Jonas
>>>>> FAX 03 59 57 78 50
>>>>> TEL 03 59 35 86 16
>>>>> S. Ducasse - Inria
>>>>> 40, avenue Halley,
>>>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>>>> Villeneuve d'Ascq 59650
>>>>> France
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> "Being happy is a matter of choice."
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Value is always contextual."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

SergeStinckwich

Re: [ann] gt diagrammer

On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote:

2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi,
>
> I think it might be more interesting to start the review from the usage of it, not from the internals.

Well, from the usage of it, I've seen nothing that doesn't fit into
the yagt. I've seen that field evolve and try clever things, really
different things, and Bloc does not look like one of thoses.

> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example:
> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design.

Look, from the point of view of the man of the art, it doesn't seems
like a breakthrough.

​Do we need a breakthrought for UI ?
No !

We need something that works that's it, stable software with good documentation and tests.

After that people can build the next-UI if they want, but this is build on solid foundations.

Compared to other smalltalk-based solutions, yes, it may be seen as an
improvement.

I think you underestimate how advanced that field has been / is, and
how far behind the state of the art are industrial solutions.

There is only one development in the Smalltalk space in GUI that is
worthy of interest for me: the anti-aliasing of Juan Vuletich. It
would have so much impact overall (remove all dependencies on external
libs, remove the need to do font anti-aliasing, scrap thousands of
lines of slow and ugly Smalltalk code, simplify the FreeType
infrastructure, remove MBs of external librairies, ensure long-term
porting ease / code evolution).

​aybe this was a breakthrought, but how many users ?
​

​Regards,​

Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)

"Programs must be written for people to read, and only incidentally for machines to execute."

http://www.doesnotunderstand.org/

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev