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/astrlgbptrlvcdicq...@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
?
