On Apr 7, 2018, at 6:56 PM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; 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(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On Apr 7, 2018, at 8:06 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr&gt; wrote: > > On 7 Apr 2018, at 19:16, Tudor Girba <tudor(a)tudorgirba.com&gt; 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(a)gmail.com&gt; 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(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > “Programming is executable philosophy." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On 7 Apr 2018, at 21:25, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: Hi Doru, Le 07/04/2018 à 19:16, Tudor Girba a écrit : > Hi Thierry, > We are not recreating HotDraw. That's sad.

I miss the time when I was doing domain specific editors in HotDraw. Thierry _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

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

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

On Apr 9, 2018, at 6:47 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: >> >> Hi Stef, >> >> Le 07/04/2018 à 21:28, Stéphane Ducasse a écrit : >>>> On 7 Apr 2018, at 21:25, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>> >>>> Hi Doru, >>>> >>>> Le 07/04/2018 à 19:16, Tudor Girba a écrit : >>>>> Hi Thierry, >>>>> We are not recreating HotDraw. >>>> >>>> That's sad. >>> No it is not. :) >>> You can rebuild a new hotdraw if you want. >>> This is what diagrammer is showing. >>> It shows that we can move on the UI level again. I’m waiting for this since at least eigth years. >> >> Good for you :) I'm not so optimistic. >> >> I have the feeling that it's not the GUI framework that was holding you, but the architecture philosophy in the implementation: wrongly remapping of a type of GUI over another system, widgets with hundreds of instance variables all blocks so that we can't understand what they are used for, widgets requiring thousands of lines of code to produce the dozens of different things on a view they require, a widget system with call depths so long you have no idea of the path it's taking to open a window, another where you have to explore your container to do things when you create a view. >> >> So, will that change? Or, has that been carried over to the new one? > Bloc is a fresh implementation and the goal is to provide the foundation for the future UI of Pharo. I would be very happy to get your feedback on code, should you have the time time to look at it. 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(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> -------------------------------------------- >>> Stéphane Ducasse >>> http://stephane.ducasse.free.fr >>> http://www.synectique.eu / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Julie Jonas >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- > www.tudorgirba.com > www.feenk.com > "Being happy is a matter of choice." > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: > 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).

2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com&gt;: > > > On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier < > thierry.goubier(a)gmail.com&gt; wrote: > >> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: >> > Hi, >> > >> > I think it might be more interesting to start the review from the >> usage of it, not from the internals. >> >> Well, from the usage of it, I've seen nothing that doesn't fit into >> the yagt. I've seen that field evolve and try clever things, really >> different things, and Bloc does not look like one of thoses. >> >> > Indeed, Bloc is primarily an engineering effort. But, there are a >> couple of things that make it rather different from other solutions. For >> example: >> > - Only one rendering tree in all cases. This works also for graph >> visualizations that work with any element without imposing knowledge about >> edges in the base system. We think this is quite important, and especially >> when combined with a performant rendering, it can open new doors for UI >> design. >> >> Look, from the point of view of the man of the art, it doesn't seems >> like a breakthrough. >> > > > ​Do we need a breakthrought for UI ? > No ! > We need something that works that's it, stable software with good > documentation and tests. > After that people can build the next-UI if they want, but this is build > on solid foundations. > Agreed. And this is where it is critical. I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? Do you imagine how it will be, 10 years down the line? Do you think it will be the stable foundation you're looking for? > > >> Compared to other smalltalk-based solutions, yes, it may be seen as an >> improvement. >> >> I think you underestimate how advanced that field has been / is, and >> how far behind the state of the art are industrial solutions. >> >> There is only one development in the Smalltalk space in GUI that is >> worthy of interest for me: the anti-aliasing of Juan Vuletich. It >> would have so much impact overall (remove all dependencies on external >> libs, remove the need to do font anti-aliasing, scrap thousands of >> lines of slow and ugly Smalltalk code, simplify the FreeType >> infrastructure, remove MBs of external librairies, ensure long-term >> porting ease / code evolution). >> > > M > ​aybe this was a breakthrought, but how many users ? > Very few users. Juan has not yet implemented it. Regards, Thierry > ​ > > ​Regards,​ > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com&gt;: Hi, For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :) Remind me, please: what is the budget of Google for the ongoing maintenance of Android? The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k. For a non-rendering core? 2k.

Thierry Cheers, Alex On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com&gt;: On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: > Hi, > > I think it might be more interesting to start the review from the usage of it, not from the internals. Well, from the usage of it, I've seen nothing that doesn't fit into the yagt. I've seen that field evolve and try clever things, really different things, and Bloc does not look like one of thoses. > Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example: > - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design. Look, from the point of view of the man of the art, it doesn't seems like a breakthrough. ​Do we need a breakthrought for UI ? No ! We need something that works that's it, stable software with good documentation and tests. After that people can build the next-UI if they want, but this is build on solid foundations. Agreed. And this is where it is critical. I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? Do you imagine how it will be, 10 years down the line? Do you think it will be the stable foundation you're looking for? Compared to other smalltalk-based solutions, yes, it may be seen as an improvement. I think you underestimate how advanced that field has been / is, and how far behind the state of the art are industrial solutions. There is only one development in the Smalltalk space in GUI that is worthy of interest for me: the anti-aliasing of Juan Vuletich. It would have so much impact overall (remove all dependencies on external libs, remove the need to do font anti-aliasing, scrap thousands of lines of slow and ugly Smalltalk code, simplify the FreeType infrastructure, remove MBs of external librairies, ensure long-term porting ease / code evolution). M ​aybe this was a breakthrought, but how many users ? Very few users. Juan has not yet implemented it. Regards, Thierry ​ ​Regards,​ -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute." http://www.doesnotunderstand.org/ _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On Apr 9, 2018, at 1:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu&gt;: > > >> On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >> >> >> >> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com&gt;: >> Hi, >> >> For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :) >> >> Remind me, please: what is the budget of Google for the ongoing maintenance of Android? >> >> The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k. >> >> For a non-rendering core? 2k. > > I think that having a time/space efficient high quality well documented code base is definitively a goal, they are probably not there yet. > > Being the smallest out there is probably not a goal, nor is that a particularly interesting one, IMHO. Small means a real effort has been to: - not reimplement already available mechanisms, - build the most effective abstractions, - do not factor in unneeded customizations points, I value highly someone that try to reach thoses. Thierry >> Thierry >> >> >> Cheers, >> Alex >> >> On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >> >> >> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com&gt;: >> >> >> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: >>> Hi, >>> >>> I think it might be more interesting to start the review from the usage of it, not from the internals. >> >> Well, from the usage of it, I've seen nothing that doesn't fit into >> the yagt. I've seen that field evolve and try clever things, really >> different things, and Bloc does not look like one of thoses. >> >>> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example: >>> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design. >> >> Look, from the point of view of the man of the art, it doesn't seems >> like a breakthrough. >> >> >> Do we need a breakthrought for UI ? >> No ! >> We need something that works that's it, stable software with good documentation and tests. >> After that people can build the next-UI if they want, but this is build on solid foundations. >> >> Agreed. And this is where it is critical. >> >> I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. >> >> And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? >> >> Do you imagine how it will be, 10 years down the line? >> >> Do you think it will be the stable foundation you're looking for? >> >> >> >> Compared to other smalltalk-based solutions, yes, it may be seen as an >> improvement. >> >> I think you underestimate how advanced that field has been / is, and >> how far behind the state of the art are industrial solutions. >> >> There is only one development in the Smalltalk space in GUI that is >> worthy of interest for me: the anti-aliasing of Juan Vuletich. It >> would have so much impact overall (remove all dependencies on external >> libs, remove the need to do font anti-aliasing, scrap thousands of >> lines of slow and ugly Smalltalk code, simplify the FreeType >> infrastructure, remove MBs of external librairies, ensure long-term >> porting ease / code evolution). >> >> M >> aybe this was a breakthrought, but how many users ? >> >> Very few users. Juan has not yet implemented it. >> >> Regards, >> >> Thierry >> >> >> >> Regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for machines to execute." >> http://www.doesnotunderstand.org/ >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On Apr 9, 2018, at 3:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: The only way one can review it is to reverse engineer the whole code base then. How much did you say? 2 peoples, how many months? A few questions then, after a cursory glance: - In what way an infinite BlElement is infinite? - Why does an infinite BlElement has what seems to be a sort of "currently processing a request" instance variable? Regards, Thierry 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: > Hi, > > We are doing that. We rewrote the system multiple times precisely because of these reasons. We could certainly do better, but I think that any meaningful conversation must happen around code, and we’d be happy to learn where we did not exploit all abstractions we could. Actually, I would be happy to even have a conversation about issues, even if the solution is not given. It can start by simply being pointed to code that does not sound right. > > Cheers, > Doru > > >> On Apr 9, 2018, at 1:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >> >> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu&gt;: >>> >>> >>>> On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >>>> >>>> >>>> >>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com&gt;: >>>> Hi, >>>> >>>> For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :) >>>> >>>> Remind me, please: what is the budget of Google for the ongoing maintenance of Android? >>>> >>>> The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k. >>>> >>>> For a non-rendering core? 2k. >>> >>> I think that having a time/space efficient high quality well documented code base is definitively a goal, they are probably not there yet. >>> >>> Being the smallest out there is probably not a goal, nor is that a particularly interesting one, IMHO. >> >> Small means a real effort has been to: >> >> - not reimplement already available mechanisms, >> >> - build the most effective abstractions, >> >> - do not factor in unneeded customizations points, >> >> I value highly someone that try to reach thoses. >> >> Thierry >> >>>> Thierry >>>> >>>> >>>> Cheers, >>>> Alex >>>> >>>> On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >>>> >>>> >>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com&gt;: >>>> >>>> >>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: >>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: >>>>> Hi, >>>>> >>>>> I think it might be more interesting to start the review from the usage of it, not from the internals. >>>> >>>> Well, from the usage of it, I've seen nothing that doesn't fit into >>>> the yagt. I've seen that field evolve and try clever things, really >>>> different things, and Bloc does not look like one of thoses. >>>> >>>>> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example: >>>>> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design. >>>> >>>> Look, from the point of view of the man of the art, it doesn't seems >>>> like a breakthrough. >>>> >>>> >>>> Do we need a breakthrought for UI ? >>>> No ! >>>> We need something that works that's it, stable software with good documentation and tests. >>>> After that people can build the next-UI if they want, but this is build on solid foundations. >>>> >>>> Agreed. And this is where it is critical. >>>> >>>> I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. >>>> >>>> And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? >>>> >>>> Do you imagine how it will be, 10 years down the line? >>>> >>>> Do you think it will be the stable foundation you're looking for? >>>> >>>> >>>> >>>> Compared to other smalltalk-based solutions, yes, it may be seen as an >>>> improvement. >>>> >>>> I think you underestimate how advanced that field has been / is, and >>>> how far behind the state of the art are industrial solutions. >>>> >>>> There is only one development in the Smalltalk space in GUI that is >>>> worthy of interest for me: the anti-aliasing of Juan Vuletich. It >>>> would have so much impact overall (remove all dependencies on external >>>> libs, remove the need to do font anti-aliasing, scrap thousands of >>>> lines of slow and ugly Smalltalk code, simplify the FreeType >>>> infrastructure, remove MBs of external librairies, ensure long-term >>>> porting ease / code evolution). >>>> >>>> M >>>> aybe this was a breakthrought, but how many users ? >>>> >>>> Very few users. Juan has not yet implemented it. >>>> >>>> Regards, >>>> >>>> Thierry >>>> >>>> >>>> >>>> Regards, >>>> -- >>>> Serge Stinckwich >>>> UMI UMMISCO 209 (SU/IRD/UY1) >>>> "Programs must be written for people to read, and only incidentally for machines to execute." >>>> http://www.doesnotunderstand.org/ >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On Apr 9, 2018, at 11:36 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com&gt;: Hi, For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :) Remind me, please: what is the budget of Google for the ongoing maintenance of Android? The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k. For a non-rendering core? 2k. Thierry Cheers, Alex On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com&gt;: On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com&gt; wrote: 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com&gt;: > Hi, > > I think it might be more interesting to start the review from the usage of it, not from the internals. Well, from the usage of it, I've seen nothing that doesn't fit into the yagt. I've seen that field evolve and try clever things, really different things, and Bloc does not look like one of thoses. > Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example: > - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design. Look, from the point of view of the man of the art, it doesn't seems like a breakthrough. ​Do we need a breakthrought for UI ? No ! We need something that works that's it, stable software with good documentation and tests. After that people can build the next-UI if they want, but this is build on solid foundations. Agreed. And this is where it is critical. I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? Do you imagine how it will be, 10 years down the line? Do you think it will be the stable foundation you're looking for? Compared to other smalltalk-based solutions, yes, it may be seen as an improvement. I think you underestimate how advanced that field has been / is, and how far behind the state of the art are industrial solutions. There is only one development in the Smalltalk space in GUI that is worthy of interest for me: the anti-aliasing of Juan Vuletich. It would have so much impact overall (remove all dependencies on external libs, remove the need to do font anti-aliasing, scrap thousands of lines of slow and ugly Smalltalk code, simplify the FreeType infrastructure, remove MBs of external librairies, ensure long-term porting ease / code evolution). M ​aybe this was a breakthrought, but how many users ? Very few users. Juan has not yet implemented it. Regards, Thierry ​ ​Regards,​ -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute." http://www.doesnotunderstand.org/ _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

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

On Apr 9, 2018, at 8:42 AM, Stéphane Ducasse <stephane.ducasse(a)inria.fr&gt; 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

First we should get a first 1.0 release :)

Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

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