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."
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),%C2%A0svg%C2%A0(http..., 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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 :
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
“Programming is executable philosophy."
On 7 Apr 2018, at 19:16, Tudor Girba tudor@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
On Apr 7, 2018, at 6:56 PM, Thierry Goubier thierry.goubier@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 :
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
“Programming is executable philosophy."
Moose-dev mailing list 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
Hi,
On Apr 7, 2018, at 8:06 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
On 7 Apr 2018, at 19:16, Tudor Girba tudor@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
…
Yes.
To me it shows that we will change our life because Morphic was hampering us to dream
Indeed, this is what it shows :)
Doru
Cheers, Doru
On Apr 7, 2018, at 6:56 PM, Thierry Goubier thierry.goubier@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 :
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
“Programming is executable philosophy."
Moose-dev mailing list 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Some battles are better lost than fought."
On 7 Apr 2018, at 21:25, Thierry Goubier 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.
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list 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
Hi Stef,
Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit :
On 7 Apr 2018, at 21:25, Thierry Goubier <thierry.goubier@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?
Thierry
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Apr 7, 2018, at 10:22 PM, Thierry Goubier thierry.goubier@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@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
Thierry
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
Hi,
On Apr 7, 2018, at 10:22 PM, Thierry Goubier thierry.goubier@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@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.
I am, probably (very) slowly, because:
- Bloc is huge: 45k lines(*). Congratulations to all the effort that went into it.
- From the examples and a cursory look at the code, it is yagt (yet another gui toolkit), which does not make it interesting to review(**). There is maybe really interesting stuff in there, but it may be very hard to find the interesting detail in that huge chunk of code.
Have you evaluated Bloc with the Moose tools?
Regards,
Thierry
(*) Which means, in C terms, probably the equivalent of half a million lines of code, given Smalltalk ability to produce dense code. (**) I'm not good nor an interesting person to ask for a review of an engineering effort.
Cheers, Doru
Thierry
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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.
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@gmail.com wrote:
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
Hi,
On Apr 7, 2018, at 10:22 PM, Thierry Goubier thierry.goubier@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@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.
I am, probably (very) slowly, because:
Bloc is huge: 45k lines(*). Congratulations to all the effort that went into it.
From the examples and a cursory look at the code, it is yagt (yet another gui toolkit), which does not make it interesting to review(**). There is maybe really interesting stuff in there, but it may be very hard to find the interesting detail in that huge chunk of code.
Have you evaluated Bloc with the Moose tools?
Regards,
Thierry
(*) Which means, in C terms, probably the equivalent of half a million lines of code, given Smalltalk ability to produce dense code. (**) I'm not good nor an interesting person to ask for a review of an engineering effort.
Cheers, Doru
Thierry
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@gmail.com wrote:
Hi Doru,
Le 08/04/2018 à 20:23, Tudor Girba a écrit :
Hi,
On Apr 7, 2018, at 10:22 PM, Thierry Goubier thierry.goubier@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@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.
I am, probably (very) slowly, because:
Bloc is huge: 45k lines(*). Congratulations to all the effort that went into it.
From the examples and a cursory look at the code, it is yagt (yet another gui toolkit), which does not make it interesting to review(**). There is maybe really interesting stuff in there, but it may be very hard to find the interesting detail in that huge chunk of code.
Have you evaluated Bloc with the Moose tools?
Regards,
Thierry
(*) Which means, in C terms, probably the equivalent of half a million lines of code, given Smalltalk ability to produce dense code. (**) I'm not good nor an interesting person to ask for a review of an engineering effort.
Cheers, Doru
Thierry
Stef
I miss the time when I was doing domain specific editors in HotDraw.
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@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@gmail.com wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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,
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com:
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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On 9 Apr 2018, at 11:36, Thierry Goubier thierry.goubier@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe sven@stfx.eu:
On 9 Apr 2018, at 11:36, Thierry Goubier thierry.goubier@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@gmail.com wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe sven@stfx.eu:
On 9 Apr 2018, at 11:36, Thierry Goubier thierry.goubier@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@tudorgirba.com:
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@gmail.com wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe sven@stfx.eu:
On 9 Apr 2018, at 11:36, Thierry Goubier thierry.goubier@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@tudorgirba.com:
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@gmail.com wrote:
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe sven@stfx.eu:
On 9 Apr 2018, at 11:36, Thierry Goubier thierry.goubier@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
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
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@gmail.com wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel alex.syrel@gmail.com: 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@gmail.com wrote:
2018-04-09 11:02 GMT+02:00 Serge Stinckwich serge.stinckwich@gmail.com:
On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier thierry.goubier@gmail.com wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba tudor@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
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
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@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@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."
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
Hi,
On Apr 9, 2018, at 8:42 AM, Stéphane Ducasse stephane.ducasse@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@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."
Nice to hear of progress in this area. Cheers to feenk team
On 8 April 2018 at 00:39, Tudor Girba tudor@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@tudorgirba.com:
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Apr 8, 2018, at 10:27 AM, Hernán Morales Durand hernan.morales@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@tudorgirba.com: 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-
Aliaksei Syrel -
Ben Coman -
Hernán Morales Durand -
Sean P. DeNigris -
Serge Stinckwich -
Stéphane Ducasse -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba