Ideas for a brand new widget toolkit

[captaindet]

On 2013-08-13 08:23, Paul Z. Barsan wrote:
> Now let me complete these notes:
>
> * I think that porting an anonymous toolkit to D will do more harm
> than good because if the original project was lacking some features
> then clients will think that the ported version lacks them as well.
> If we want to take this route then, besides Harmonia and FOX tk, we
> might borrow things from FLTK(Fast Light Toolkit) * If the projects
> starts from zero, with its own design and is "shiny new" then people
> will be more attracted. * Even if we don't port a toolkit we can
> still get inspired to see how they interact with the underlying
> system. For example, we can take a look over the SDL way of handling
> input. * for drawing primitives we can use Cairo(curently used by
> GTK) or libX11 on linux and Directx on windows.Bindings for cairo and
> libX11 are provided by Deimos. I'm not sure if we can use OpenGL
> because it requires a rendering window or it renders in fullscreen
> mode.That rendering window can be provided by other toolkits but I
> don't think we want to depend on them. The OS window manager(xorg on
> linux) needs to keep track of the things it draws on its root window
> or surface and must be aware what to clean-up after you close your
> program. So the layer beneath this widget toolkit on Linux would be
> X(libX11). * XAML is being developed by Microsoft and XUL by
> Mozzilla. I think XUL is a better choice for a markup language and
> more friendlier with an open source toolkit. It would be pretty nice
> if we can make the GuiParser and abstract class and provide an
> implementation for XUL because that will allow us to write an
> implementation for the QML(Qt) aswell or other flavors of layout and
> style files. * If we want the project to scale up nicely then we
> should do things by the book. That is doing some research to see what
> technologies are involved, what the client programmers want(this
> thread) and then write some specs. * After we have the specs then we
> can start designing the toolkit using UML diagrams such that we will
> end up with a clean API and avoid future re-factoring. For UML
> designs, I recommend this web app https://www.draw.io/ which saves
> its files in XML format and we can store them in the git repository.
> * Only after we have a good design we will begin the actual coding. *
> there is this 3D modelling tool called Blender which has a
> modern-looking UI. People have been wondering if that GUI can be used
> as a library and the answer is no because the gui is harcoded into
> Blender. If our default ui look resembles that one(not necessarily
> identical) then we will gain more clients.Maybe we can even get
> support from its huge community of artists. Take a look:
> http://www.blender.org/features-gallery/features/ * this toolkit can
> complement DWT because DWT will provide native look and this one will
> provide the same look on all platforms.

i like your ideas, especially the the clear top-down strategy. if the vision, i.e. design/API and roadmap is clear, and the documentation is good from the very beginning (something i want to stress particularly), then it could develop some dynamic.

to ppl shrugging it off with the arguments that it is too much work or has been tried before: well, these arguments cancel each other out. previous projects have been very promising and accomplished a lot, enough for a kickstart. in theory - as it did not happen. and why?
i think their biggest problem was that they were basically one man projects, not community projects. they did not outline design goals, open issues, roadmaps, - heck they did not even provide a sufficient documentation for using them. so they more or less died once the original maintainer lost interest. i often think what nice a D GUI package we would have by now if those 3 or 4 ppl running the previous attempts would have worked together. i played a bit with DFL some years ago and was quite impressed (it even had a GUI designer!) - but only to a certain point. i wanted multi platform and being only the occasional programmer, i need a good, detailed documentation. so back than i decided to not use D altogether as a GUI was a must for my application. (the core procedures being in C i still hope to move it to D at one point though)

having a D-simple and D-safe pure D GUI is worth a try and would boost D's popularity. if it takes 2 years before it is usable, so what. it would not slow down improving D in other aspects as i think a GUI development would motivate a different set of ppl to contribute, i.e. would not withdraw current phobos and compiler devs.


just my 2c,

det