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