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
