7 Apr
2018
7 Apr
'18
6:39 p.m.
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."
7 Apr
7 Apr
6:56 p.m.
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
7:16 p.m.
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
<thierry.goubier(a)gmail.com> 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 :
--
www.tudorgirba.com
www.feenk.com
“Programming is executable philosophy."
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
8:06 p.m.
On 7 Apr 2018, at 19:16, Tudor Girba
<tudor(a)tudorgirba.com> 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
--------------------------------------------
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
On Apr 7, 2018, at 6:56 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> 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 :
--
www.tudorgirba.com
www.feenk.com
“Programming is executable philosophy."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8 Apr
8 Apr
7:09 a.m.
Hi,
--
www.tudorgirba.com
www.feenk.com
"Some battles are better lost than fought."
On Apr 7, 2018, at 8:06 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
Yes.
On 7 Apr 2018, at 19:16, Tudor Girba <tudor(a)tudorgirba.com> 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
Indeed, this is what it shows :)
Doru
Cheers,
Doru
--------------------------------------------
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Apr 7, 2018, at 6:56 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> 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 :
--
www.tudorgirba.com
www.feenk.com
“Programming is executable philosophy."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:28 p.m.
On 7 Apr 2018, at 21:25, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Doru,
Le 07/04/2018 à 19:16, Tudor Girba a écrit :
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
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
Moose-dev(a)list.inf.unibe.ch
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
10:22 p.m.
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
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
On 7 Apr 2018, at 21:25, Thierry Goubier
<thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
Hi Doru,
Le 07/04/2018 à 19:16, Tudor Girba a écrit :
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. Hi Thierry,
We are not recreating HotDraw.
That's sad.
Stef
I miss the time when I was doing domain specific
editors in HotDraw.
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8 Apr
8 Apr
8:23 p.m.
Hi,
On Apr 7, 2018, at 10:22 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
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
On 7 Apr
2018, at 21:25, Thierry Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
Hi Doru,
Le 07/04/2018 à 19:16, Tudor Girba a écrit :
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. Hi Thierry,
We are not recreating HotDraw.
That's sad. Thierry
--
www.tudorgirba.com
www.feenk.com
"Being happy is a matter of choice."
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev I miss the time when I was doing domain specific
editors in HotDraw.
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9 Apr
9 Apr
6:47 a.m.
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
Hi,
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.
On Apr 7, 2018, at 10:22 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
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. On 7 Apr
2018, at 21:25, Thierry Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> 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. Cheers,
Doru
Thierry
--
www.tudorgirba.com
www.feenk.com
"Being happy is a matter of choice."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev I miss the time when I was doing domain specific
editors in HotDraw.
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:14 a.m.
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
<thierry.goubier(a)gmail.com> wrote:
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"Value is always contextual."
Hi,
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.
On Apr 7, 2018, at 10:22 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
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. > On 7 Apr 2018, at 21:25, Thierry Goubier
<thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> 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? Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Thierry
--
www.tudorgirba.com
www.feenk.com
"Being happy is a matter of choice."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Stef
> I miss the time when I was doing domain specific editors in HotDraw.
>
> Thierry
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
> 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
10:54 a.m.
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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
<thierry.goubier(a)gmail.com> wrote:
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hi,
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.
On Apr 7, 2018, at 10:22 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
>> On 7 Apr 2018, at 21:25, Thierry Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Thierry
> Stef
>> I miss the time when I was doing domain specific editors in HotDraw.
>>
>> Thierry
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
>> 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
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
11:02 a.m.
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
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.
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).
M
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/
11:12 a.m.
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
Very few users. Juan has not yet implemented it.
Regards,
Thierry
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think),
followed it to the beginning of Squeak (1998). When I came back to Pharo in
2011, I was horrified by what it has became: a monster of thousands over
thousands of buggy lines.
And now I see a replacement, that, before going into production, is already
at 45k lines? And with a planned, huge dependency on the GUI lib of another
project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
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.
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).
M
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
11:23 a.m.
Hi,
For the record, View class, a root class of all visual elements in Android
27 is 26'488 lines of code. It didn't hover prevent it from being used on
more than 2 billion devices :)
The core of Bloc is just 14k lines of code. It would be nice to know how
many lines of code should be considered too much, 5k, 7.43k or 10k.
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
Very few users. Juan has not yet implemented it.
Regards,
Thierry
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <
thierry.goubier(a)gmail.com> wrote:
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think),
followed it to the beginning of Squeak (1998). When I came back to Pharo in
2011, I was horrified by what it has became: a monster of thousands over
thousands of buggy lines.
And now I see a replacement, that, before going into production, is
already at 45k lines? And with a planned, huge dependency on the GUI lib of
another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
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.
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).
M
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
11:36 a.m.
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android
27 is 26'488 lines of code. It didn't hover prevent it from being used on
more than 2 billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance
of Android?
The core of Bloc is just 14k lines of code. It would
be nice to know how
many lines of code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
Very few users. Juan has not yet implemented it.
Regards,
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <
thierry.goubier(a)gmail.com> wrote:
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think),
followed it to the beginning of Squeak (1998). When I came back to Pharo in
2011, I was horrified by what it has became: a monster of thousands over
thousands of buggy lines.
And now I see a replacement, that, before going into production, is
already at 45k lines? And with a planned, huge dependency on the GUI lib of
another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
> 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).
M
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
noon
On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
The core of Bloc is just 14k lines of code. It would be nice to know how many lines of
code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
I think that having a time/space efficient high quality well documented code base is
definitively a goal, they are probably not there yet.
Being the smallest out there is probably not a goal, nor is that a particularly
interesting one, IMHO.
Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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.
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the
beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it
has became: a monster of thousands over thousands of buggy lines.
And now I see a replacement, that, before going into production, is already at 45k lines?
And with a planned, huge dependency on the GUI lib of another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
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).
M
aybe this was a breakthrought, but how many users ?
Very few users. Juan has not yet implemented it.
Regards,
Thierry
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
1:04 p.m.
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
Small means a real effort has been to:
- not reimplement already available mechanisms,
- build the most effective abstractions,
- do not factor in unneeded customizations points,
I value highly someone that try to reach thoses.
Thierry
On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
The core of Bloc is just 14k lines of code. It would be nice to know how many lines of
code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
I think that having a time/space efficient high quality well documented code base is
definitively a goal, they are probably not there yet.
Being the smallest out there is probably not a goal, nor is that a particularly
interesting one, IMHO. Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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.
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the
beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it
has became: a monster of thousands over thousands of buggy lines.
And now I see a replacement, that, before going into production, is already at 45k lines?
And with a planned, huge dependency on the GUI lib of another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
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).
M
aybe this was a breakthrought, but how many users ?
Very few users. Juan has not yet implemented it.
Regards,
Thierry
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2:08 p.m.
Hi,
We are doing that. We rewrote the system multiple times precisely because of these
reasons. We could certainly do better, but I think that any meaningful conversation must
happen around code, and we’d be happy to learn where we did not exploit all abstractions
we could. Actually, I would be happy to even have a conversation about issues, even if the
solution is not given. It can start by simply being pointed to code that does not sound
right.
Cheers,
Doru
On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
Small means a real effort has been to:
- not reimplement already available mechanisms,
- build the most effective abstractions,
- do not factor in unneeded customizations points,
I value highly someone that try to reach thoses.
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"We cannot reach the flow of things unless we let go."
On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
The core of Bloc is just 14k lines of code. It would be nice to know how many lines of
code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
I think that having a time/space efficient high quality well documented code base is
definitively a goal, they are probably not there yet.
Being the smallest out there is probably not a goal, nor is that a particularly
interesting one, IMHO. Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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.
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the
beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it
has became: a monster of thousands over thousands of buggy lines.
And now I see a replacement, that, before going into production, is already at 45k lines?
And with a planned, huge dependency on the GUI lib of another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
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).
M
aybe this was a breakthrought, but how many users ?
Very few users. Juan has not yet implemented it.
Regards,
Thierry
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3:54 p.m.
The only way one can review it is to reverse engineer the whole code
base then. How much did you say? 2 peoples, how many months?
A few questions then, after a cursory glance:
- In what way an infinite BlElement is infinite?
- Why does an infinite BlElement has what seems to be a sort of
"currently processing a request" instance variable?
Regards,
Thierry
2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
Hi,
We are doing that. We rewrote the system multiple times precisely because of these
reasons. We could certainly do better, but I think that any meaningful conversation must
happen around code, and we’d be happy to learn where we did not exploit all abstractions
we could. Actually, I would be happy to even have a conversation about issues, even if the
solution is not given. It can start by simply being pointed to code that does not sound
right.
Cheers,
Doru
On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
Small means a real effort has been to:
- not reimplement already available mechanisms,
- build the most effective abstractions,
- do not factor in unneeded customizations points,
I value highly someone that try to reach thoses.
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
The core of Bloc is just 14k lines of code. It would be nice to know how many lines of
code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
I think that having a time/space efficient high quality well documented code base is
definitively a goal, they are probably not there yet.
Being the smallest out there is probably not a goal, nor is that a particularly
interesting one, IMHO. Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
> 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.
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the
beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it
has became: a monster of thousands over thousands of buggy lines.
And now I see a replacement, that, before going into production, is already at 45k lines?
And with a planned, huge dependency on the GUI lib of another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
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).
M
aybe this was a breakthrought, but how many users ?
Very few users. Juan has not yet implemented it.
Regards,
Thierry
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
18 Apr
18 Apr
6:45 a.m.
Hi,
Sorry for the late reply. I missed this email.
BlInfiniteElement’s comment says:
"I'm an element which is supposed to contain huge amount of children and layout
only those of them that are visible inside my viewport.
I work with DataSources to fetch data from and can present data within different Infinite
Layouts.”
It is used in both lists and in the text editor.
I am not sure which variable you refer to by "currently processing a request”. Can
you clarify?
Cheers,
Doru
On Apr 9, 2018, at 3:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
The only way one can review it is to reverse engineer the whole code
base then. How much did you say? 2 peoples, how many months?
A few questions then, after a cursory glance:
- In what way an infinite BlElement is infinite?
- Why does an infinite BlElement has what seems to be a sort of
"currently processing a request" instance variable?
Regards,
Thierry
2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
--
www.tudorgirba.com
www.feenk.com
"Things happen when they happen,
not when you talk about them happening."
Hi,
We are doing that. We rewrote the system multiple times precisely because of these
reasons. We could certainly do better, but I think that any meaningful conversation must
happen around code, and we’d be happy to learn where we did not exploit all abstractions
we could. Actually, I would be happy to even have a conversation about issues, even if the
solution is not given. It can start by simply being pointed to code that does not sound
right.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
--
www.tudorgirba.com
www.feenk.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
> On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>
>
>
> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
> Hi,
>
> For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
>
> Remind me, please: what is the budget of Google for the ongoing maintenance of
Android?
>
> The core of Bloc is just 14k lines of code. It would be nice to know how many lines
of code should be considered too much, 5k, 7.43k or 10k.
>
> For a non-rendering core? 2k.
I think that having a time/space efficient high quality well documented code base is
definitively a goal, they are probably not there yet.
Being the smallest out there is probably not a goal, nor is that a particularly
interesting one, IMHO.
Small means a real effort has been to:
- not reimplement already available mechanisms,
- build the most effective abstractions,
- do not factor in unneeded customizations points,
I value highly someone that try to reach thoses.
Thierry
> Thierry
>
>
> Cheers,
> Alex
>
> On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>
>
> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
>
>
> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
>> 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.
>
> Agreed. And this is where it is critical.
>
> I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to
the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what
it has became: a monster of thousands over thousands of buggy lines.
>
> And now I see a replacement, that, before going into production, is already at 45k
lines? And with a planned, huge dependency on the GUI lib of another project?
>
> Do you imagine how it will be, 10 years down the line?
>
> Do you think it will be the stable foundation you're looking for?
>
>
>
> 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).
>
> M
> aybe this was a breakthrought, but how many users ?
>
> Very few users. Juan has not yet implemented it.
>
> Regards,
>
> Thierry
>
>
>
> 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
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
9 Apr
9 Apr
5:43 p.m.
Tudor Girba-2 wrote
We could certainly do better… I would be happy to even
have a conversation
about issues…
Thank you guys for this thread! It is very helpful to understand how/why we
got to the current situation from Morphic to Bloc :)
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Moose-f1310756.html
2:02 p.m.
Hi,
Thanks for your thoughts.
Yes, the main feature of Bloc is that it works and that it can enable us to create
interfaces for Pharo that are from this millennium.
We do look well outside of the Smalltalk world, but it can happen that we might have
overlooked something. I’d be happy to get pointed to those places. For example, I would be
very interested in systems that have editors that can both work with 100Mb and that can
now mix text with graphics in any way we want, while typing, and that enable applications
like Connector.
Bloc is not an increment over Morphic, and we would have not reached it by incrementing
over Morphic. We know because we tried.
About the size issue: Indeed, we are sensitive to this as well. However, this code was
actually developed by about 2 people at any point in time. And it was rewritten multiple
times. So, the argument that it falls under its own weight is not quite correct given that
it did not stop us from producing significant things with it. The size is offset by the
fact that the system is debuggable.
It should also be noted that the basic framework provides a lot already. We know this
because the editor is 3k lines of code and Mondrian is 1K (two applications with radically
different needs).
The dependency on Moz2D is not mandatory. It is offered as an option for those that want
to produce industrial solutions.
The current core has parts that do not necessarily have to be there (for example, support
for overlays or scrolling). So, the minimal core can be made below 10k without much work.
Cheers,
Doru
On Apr 9, 2018, at 11:36 AM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>om>:
Hi,
For the record, View class, a root class of all visual elements in Android 27 is
26'488 lines of code. It didn't hover prevent it from being used on more than 2
billion devices :)
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
The core of Bloc is just 14k lines of code. It would be nice to know how many lines of
code should be considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
--
www.tudorgirba.com
www.feenk.com
"Quality cannot be an afterthought."
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.
Agreed. And this is where it is critical.
I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the
beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it
has became: a monster of thousands over thousands of buggy lines.
And now I see a replacement, that, before going into production, is already at 45k lines?
And with a planned, huge dependency on the GUI lib of another project?
Do you imagine how it will be, 10 years down the line?
Do you think it will be the stable foundation you're looking for?
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).
M
aybe this was a breakthrought, but how many users ?
Very few users. Juan has not yet implemented it.
Regards,
Thierry
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
7:58 a.m.
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
8:36 a.m.
New subject: 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
<stephane.ducasse(a)inria.fr> 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
Moose-dev(a)list.inf.unibe.ch
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."
8:42 a.m.
New subject: 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
8:48 a.m.
New subject: miniBloc [was gt diagrammer]
Hi,
On Apr 9, 2018, at 8:42 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> 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
Moose-dev(a)list.inf.unibe.ch
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."
8 Apr
8 Apr
6:32 a.m.
Nice to hear of progress in this area.
Cheers to feenk team
On 8 April 2018 at 00:39, Tudor Girba <tudor(a)tudorgirba.com> 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
10:27 a.m.
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 <tudor(a)tudorgirba.com>om>:
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8:21 p.m.
Hi,
On Apr 8, 2018, at 10:27 AM, Hernán Morales Durand
<hernan.morales(a)gmail.com> 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 <tudor(a)tudorgirba.com>om>:
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Sometimes the best solution is not the best solution."
2197
days inactive
2208
days old
29 comments
9 participants
participants (9)
-
Aliaksei Syrel -
Ben Coman -
Hernán Morales Durand -
Sean P. DeNigris -
Serge Stinckwich -
Stéphane Ducasse -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba