Ideas for a brand new widget toolkit

[Paul Z. Barsan]

Hello everyone,

These days I've been searching for a cross-platform IDE for D and 
I found out that there aren't any viable standalone options. 
After a few clicks, I've ran over this topic: 
http://forum.dlang.org/thread/astrlgbptrlvcdicqxux@forum.dlang.org 
and it wasn't a surprise to see there are other people searching 
for the very same thing.One of the reasons for the absence of 
such IDEs is that there are no widget toolkits written in D 
except DWT, but some people are complaining about DWT for being a 
clone of SWT and that clients will want DWT to be in sync with 
SWT since SWT is a "marketing paradigm". As such, I want to 
embark on a long journey of writing a new widget toolkit from 
scratch.

Here are the ideas that people came up with so far(sorry if I 
omitted something):

evilrat:
* we need a truly D UI(not wrapper) first
* there are almost no declarative cross platform(i mean major OS) 
toolkit for writing simple yet highly customizable UI's, with 
HTML markup-like,
customizable UI's without messing with 
imperative(C/C++/D/whatever) code

eles:
* a D-ported version of a rather anonymous toolkit won't be 
shaded by the original
* evolution is slower, so not a fast-moving target
* the team behind that toolkit will be more than glad to help, as 
their toolkit will gain in popularity, and could even be 
converted to D-development (instead of C or C++ or whatever)
* re-write FOX tk in D, not to bind to it
* drivers as the lower bound in my original post. The rest should 
be drawn...

Trvhgoy:
* define the layout with a markup language like XAML or XUL for 
example and the styling with a CSS-like definition.

Mike Parker:
* Harmonia might be a good place to start: 
http://harmonia.terrainformatica.com/doku.php

Chris:
* a UI tool like Glade or Interface Builder is indispensible

Jacob Carlborg:
* You would still need to some graphics primitives. Do you want 
to implement them yourself as well? I mean, you have to draw the 
line somewhere. There's always a layer beneath you that you rely 
on, if you're not doing embedded or similar.
* you want a non-native toolkit.
* primitives would be implemented on top of OpenGL or DirectX. 
OpenGL is implemented in the graphics drivers, don't know how it 
works with DirectX.

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.

In the previously mentioned forum thread, I've seen that there 
are other developers willing to contribute to a new widget 
toolkit project.I haven't hosted the project yet because I'm 
undecided what hosting service should I use. AFAIK, sourceforge 
is for projects and it gives you the option of hosting a website, 
using other bugtrackers such as Trac and github is focused more 
on the code. So where do you think a project of this magnitude 
should be hosted ?

Think of this topic as writing letters to Santa, so: what say you 
?