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 ?

On 08/13/2013 03:23 PM, Paul Z. Barsan wrote:

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

I'd bet on QtD.

On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
> 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 ?

http://pages.github.com/ perhaps?

On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath wrote:
> I'd bet on QtD.

   QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things.

   Besides that, there are widget toolkits written in all major programming languages: GTK+ in C, Qt in C++, Swing in Java and so on. Another gui toolkit will bring more users to D itself.

On Tuesday, 13 August 2013 at 13:51:40 UTC, John Colvin wrote:
> http://pages.github.com/ perhaps?

I didn't know of this github feature. I only used sourceforge and bitbucket before. Another option was dsource but it seems to me like a sinking boat and its user are moving their projects to github. Thanks for the tip !

On 08/13/2013 04:10 PM, Paul Z. Barsan wrote:
>
>     QtD provides language bindings just like GtkD or wxD. Qt as a
> framework is a mammoth. It provides support for networking, threads and
> even has wrappers for basic types such as QString. Phobos already
> provides support for this sort of things.

So additionally to a GUI Toolkit we get a framework full of useful things, that many C++ programmer already know. I'll take that as an argument pro QtD.

>     Besides that, there are widget toolkits written in all major
> programming languages: GTK+ in C, Qt in C++, Swing in Java and so on.

Nope. GTK+, Qt and Swing all have a over hundred man years advantage
over yet-another-gui-toolkit. Programmer who want to build a
non trivially gui, will just take a language that has a comparable solution to these three. That will not be D.

> Another gui toolkit will bring more users to D itself.
Good bindings to an existant GUI toolkit will bring users to D. No one really cares, which language it's originally written in. See Python/Ruby.

On Tuesday, 13 August 2013 at 14:22:09 UTC, Tobias Pankrath wrote:
> So additionally to a GUI Toolkit we get a framework full of useful things

Useful for C++. Sometimes. Actually, that was a reason to prefer GTK over Qt for me even in C++ times. No way I'll ever use this monster in D.

Coincidentally, I started slapping one together over the weekend.

As you can see, it is hideous:
http://arsdnet.net/gui.png

And if I saw someone else coding a gui the way I am, I'd call them silly for rejecting all things that are good and decent.

So, what am I doing and why am I doing it that way?

Let's start with the why:

Qt and GTK are just too big, and other lightweight wrappers still tend to have runtime requirements that i hate. I want to be able to distribute a stand-alone exe that people can use that is < 1 MB, so there's a reasonable download time from my slow computer.

The qtd and gtkd wrappers make them even bigger and more fragile. The D forms library is ok, still a bit big and buggy when I tried, but the real blocker there is zero linux support.

So I'm doing just win32 and xlib, built on my simpledisplay.d that already provides basics. Since xlib doesn't provide any widgets, I'm diying there. (But might change my mind later and dynamically link gtk, idk, the linux version will probably only be used by myself so it isn't that important.)

My goal: provide very basic, but useful, capabilities in one D module.



What exactly am I doing? Just drawing rectangles and reading events (simpledisplay.d supports these, and I'm improving it as needed for this) and calling it a gui!


I don't my approach of from scratch, custom widgets is a good idea in most cases.

On Tuesday, 13 August 2013 at 14:10:24 UTC, Paul Z. Barsan wrote:
> On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath wrote:
>> I'd bet on QtD.
>
>    QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things.
>
clip

Qt is modular. I would assume a qtD would only need to support
QtCore and QtGui (those are pretty big though), but you still
shouldn't need to support all of the Qt Framework (XML,
Networking, QtConcurrent, etc.).

Craig

Am 13.08.2013 15:23, schrieb Paul Z. Barsan:
> Think of this topic as writing letters to Santa, so: what say you

sorry your list is much to big - feels like the next Doom 5 128 Bit with hypergigagraphics...

your talking about serveral years of development - and yes - there are many developers that want a new great gui blabla thing - but don't want to invest time to produce it - want != personal invest

just look at the design and code of Qt and you will see that is much much more needed then just nice ideas (and even if D will help to keep out strange looking codestuff, macros etc - you will still neede much of the surounding code

btw: you should not start to design a new gui system without deep knowledge of the currently used ones (like GtK, Qt, ... XUL, XAML,...)

Start else another GUI toolkit it's bad idea, we already have about 5-6 GUI toolkit's that's done only on half. Much better to take any of existent, for example http://code.google.com/p/dgui/ and continue of it's developing