On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
> You mentioned X11 to me before, when we talked about this idea over email.

Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier.

For instance, in my crappygui.d, I used XDrawString to draw text. This was the result: http://arsdnet.net/gui.png

That's a true type font (Bitstream Vera Sans, a fairly good looking font), but X doesn't support antialiasing.

There's a library called Xft that draws fonts prettier. But how does it work? Instead of sending DrawText(x, y, "hello world!") to the display server, it uses a drawing library to render the text as an image in the application, then sends that image to the display server.

And BTW if the display doesn't support the alpha blending extension (the XRender extension), it first takes a partial screenshot, does the blending in library, and sends that image back!

Note that the X protocol does not compress the image data. So if you send a 100x30 pixel image of text, you're shooting some 10 KB - or double that without XRender - down the network wire instead of the .... idk exactly for sure, but I think it is about 32 bytes to just send the draw instruction.


Now, you can compress an X stream over ssh, so it isn't always this bad in practice, but still, since the X display server doesn't support the expected modern feature, it blows up in bandwidth to compensate and that can kill the user experience.

Note btw though, you *can* save the image on the display server to reuse it later, so every time you print a string it doesn't necessarily send that data across, but I'm not sure if the higher level libraries actually do this... the downsides of abstractions is you can miss important details like this.

This is why my simpledisplay.d now has a class Sprite in addition to class Image, and why Qt has QImages and QPixmaps, but how often do you think of drawing text as being something that needs a Pixmap to be efficient? Again the library might handle it, I'm not sure, but the relatively pathetic performance of a lot of apps on a remote X connection makes me think they probably don't.



Anyway, the other thing too is all events go to the client application from the display server, and then the application's changes go back to the display server. Since X itself doesn't offer any kind of widgets, a text control for instance would work like this:

application -> display: draw the box
display -> application: key press event
application -> display: draw the character, advance the cursor,,, and if oyu have to scroll btw it might draw a whole lot of stuff (though if you know you're on a potentially networked app, you'd do something like XCopyArea and tell the display to move a whole block of data up without resending it all, but again the leaky abstraction can kill you)


But yeah, the event needs a round trip to react. On a LAN, you're probably ok, but what about on the open internet where there's some latency? Well, sometimes it is actually quite fine there too, I spend a *lot* of time using both X and ssh remotely, but sometimes it gets to be really, really annoying.


So I'd want to do higher level events too, and the application can request them. For instance, if all you want is a basic text input, output something like <textarea></textarea> and let the display do the details.

(Another really nice benefit here, if we do it right, is it could use native controls on systems like Windows, or even pipe it to an external app on unix, and get a nice customized, adaptable system. Though while it sounds simpler in ways, this is easier said than done.)

With these higher level events and widgets, unless you need to override some event, it can just be handled without the round trip and improve response time on slow connections.

Though, if you do need real time event processing, you're back to the round trip, but meh, some speedup is better than none.




But, indeed, we don't want to go *too* far either, especially since then we'd end up with a web browser situation where people write their applications in the scripting language...


> What basic widgets do you have in mind, to keep on the client-side?  Also, just widgets in the client or some basic layout too?

Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different.

For my crappygui.d, I'm aiming to do:

menus, labels, radio box, checkbox, buttons, grid layouts, text input, slider, number chooser, list boxes, and basic 2d drawing. Pretty much the basic stuff you get on html forms. Maybe more later, but I want to actually be able to get this working over the next weekend or two, so I'm keeping it simple. (And right now I'm not actually doing network transparency, I'll come back to that, my basic idea there is to simply forward all the function calls with rpc.)

> As for detaching and reattaching, that is easier to do, the more state is kept on the server. :)

Yeah, my old DWS idea was to do three applications, but that was a pain, a lot of duplication to add a new function. So now I want the middle man program to be really simple, basically a switchboard, and then the detach/attach messages will be handled by the application, just shooting its current state to the new display.

> it's more complicated to code all that reattaching functionality and isn't necessary for most apps, most app devs don't bother.

If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me -  I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.

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

I already opened this can of worms: http://forum.dlang.org/thread/vtaufckbpdkpuxyztyoi@forum.dlang.org?page=1

There's some good feedback there. Not sure if you saw this one.

> Here are the ideas that people came up with so far(sorry if I omitted something):
>
> snip...
>
> Think of this topic as writing letters to Santa, so: what say you ?

I'm a web developer, and CSS+HTML works quite well. The DOM sucks, but the idea of separating markup, style and code has worked out pretty well. QML uses this model pretty well, and I think we can do something pretty nice with D's awesome template support and CTFE.

My general preferences:

- simple, orthogonal, efficient
- theme-able at runtime
- simple event model

Opinions:

- no XML
- few abstractions (i.e. avoid Java-esque OO obsession)

Features I'd really like:

- direct frame buffer support (like qingy on Linux, but not sucky)
- no GC (in an ideal world)
  - I'm not a big fan of Phobos relying on the GC
  - removes a barrier to writing bare-metal applications (only have to implement a new backend, not the whole ecosystem)
  - less expensive to link into a non-D project
- CTFE
- entire API accessable from C
  - so I can reuse it in another language (i.e. Rust, Go, Python, etc.)

Overall design:

- simple buffer layering strategy, with bottom up and top-down message passing

    http://swtch.com/~rsc/thread/cws.pdf

- scene graph (like clutter): http://en.wikipedia.org/wiki/Clutter_%28toolkit%29

I'd be interested in helping out, but I can't promise I'll be dependable enough to be a major maintainer, since I don't have any real projects that use D. Writing a UI toolkit is on my already long list of TODOs.

On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
>> You mentioned X11 to me before, when we talked about this idea over email.
>
> Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier.
> snip...

I'm in the opposite camp. The server is never going to be able to support everything, and people are just going to fall back to rendering themselves anyway.

For example, say you need to screw a screw into a piece of wood. Let's also say you have the following: hammer, screwdriver (doesn't fit the screw), means to fab a new screwdriver. Let's also say that the screw needs to be in by tomorrow. Will you:

a) spend all night trying to get the screwdriver to work?
b) design a new screwdriver (also takes all night)
c) pound the screw in with the hammer (< 5 minutes) and promise yourself you'll make that screwdriver (which will never get done)

I think most people will go with c. This is exactly what happened with X. People didn't care enough to put font-rendering into X, so they wrote a rendering library and used it everywhere. This way they don't have to force their users to upgrade their X server, and they still get pretty fonts (at the risk of slow X forwarding, which hardly anyone uses anyway).

> Anyway, the other thing too is all events go to the client application from the display server, and then the application's changes go back to the display server. Since X itself doesn't offer any kind of widgets, a text control for instance would work like this:
>
> application -> display: draw the box
> display -> application: key press event
> application -> display: draw the character, advance the cursor,,, and if oyu have to scroll btw it might draw a whole lot of stuff (though if you know you're on a potentially networked app, you'd do something like XCopyArea and tell the display to move a whole block of data up without resending it all, but again the leaky abstraction can kill you)
>
>
> But yeah, the event needs a round trip to react. On a LAN, you're probably ok, but what about on the open internet where there's some latency? Well, sometimes it is actually quite fine there too, I spend a *lot* of time using both X and ssh remotely, but sometimes it gets to be really, really annoying.

Just tried to X forward Chrome on a local lan. It worked, but it was dog slow. I can't imagine trying this over a dodgy network. The problem is likely that Chrome (like most apps) makes extensive use of x frame buffer. This is the way many apps are going, and that trend is not likely to change.

> So I'd want to do higher level events too, and the application can request them. For instance, if all you want is a basic text input, output something like <textarea></textarea> and let the display do the details.
>
> (Another really nice benefit here, if we do it right, is it could use native controls on systems like Windows, or even pipe it to an external app on unix, and get a nice customized, adaptable system. Though while it sounds simpler in ways, this is easier said than done.)
>
> With these higher level events and widgets, unless you need to override some event, it can just be handled without the round trip and improve response time on slow connections.
>
> Though, if you do need real time event processing, you're back to the round trip, but meh, some speedup is better than none.

It just seems simpler to render into buffers on the client then upload entire chunks to the server. This will have less round-trips at the expense of larger packets each update.

For many high-latency networks, bandwidth is not a big problem. This is why websites try to reduce the number of downloads they have by increasing sizes of each download. For example, Opera Mobile worked well because they would render the page to an image before it got to the phone. Phones were on high-latency networks, so this meant fewer round-trips.

> But, indeed, we don't want to go *too* far either, especially since then we'd end up with a web browser situation where people write their applications in the scripting language...
>
>
>> What basic widgets do you have in mind, to keep on the client-side?  Also, just widgets in the client or some basic layout too?
>
> Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different.

This is nice. I've also thought about how to make this not suck. My initial thought was to see how ViM works (gvim runs stand-alone, vim runs in console).

> For my crappygui.d, I'm aiming to do:
>
> menus, labels, radio box, checkbox, buttons, grid layouts, text input, slider, number chooser, list boxes, and basic 2d drawing. Pretty much the basic stuff you get on html forms. Maybe more later, but I want to actually be able to get this working over the next weekend or two, so I'm keeping it simple. (And right now I'm not actually doing network transparency, I'll come back to that, my basic idea there is to simply forward all the function calls with rpc.)
>
>> As for detaching and reattaching, that is easier to do, the more state is kept on the server. :)
>
> Yeah, my old DWS idea was to do three applications, but that was a pain, a lot of duplication to add a new function. So now I want the middle man program to be really simple, basically a switchboard, and then the detach/attach messages will be handled by the application, just shooting its current state to the new display.
>
>> it's more complicated to code all that reattaching functionality and isn't necessary for most apps, most app devs don't bother.
>
> If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me -  I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.

You may find this interesting: http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland

I would love attach/reattach for UIs. This seems like it would have to be supported at the protocol level.

I like the idea of Wayland, because we can both have our cake and eat it too! (just use a compositor that supports whatever you like).

On Tuesday, 13 August 2013 at 22:27:16 UTC, Joakim wrote:
> On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
>> http://wayland.freedesktop.org/
>  I don't see how that's relevant to the networked GUIs we're talking about.

The interesting part is the rational, why they do not support remote access (for now). Short version: VNC does it better on-top than X11 does it natively, so just use VNC (or RDP or any other on-top solution).

On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
>> You mentioned X11 to me before, when we talked about this idea over email.
>
> Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier.
>
> For instance, in my crappygui.d, I used XDrawString to draw text. This was the result: http://arsdnet.net/gui.png
>
> That's a true type font (Bitstream Vera Sans, a fairly good looking font), but X doesn't support antialiasing.
>
> There's a library called Xft that draws fonts prettier. But how does it work? Instead of sending DrawText(x, y, "hello world!") to the display server, it uses a drawing library to render the text as an image in the application, then sends that image to the display server.
>
> And BTW if the display doesn't support the alpha blending extension (the XRender extension), it first takes a partial screenshot, does the blending in library, and sends that image back!
>
> Note that the X protocol does not compress the image data. So if you send a 100x30 pixel image of text, you're shooting some 10 KB - or double that without XRender - down the network wire instead of the .... idk exactly for sure, but I think it is about 32 bytes to just send the draw instruction.

Font rendering is often application specific and very
 complex. This is why it is done client-side in X11 nowadays.

State of Text Rendering on Linux: http://behdad.org/text/

On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson Little wrote:
> Just tried to X forward Chrome on a local lan. It worked, but it was dog slow. I can't imagine trying this over a dodgy network. The problem is likely that Chrome (like most apps) makes extensive use of x frame buffer. This is the way many apps are going, and that trend is not likely to change.

Yep, this is pretty much the issue. Any application that needs own rendering (any 3d, web browsers, custom widgets) does not make use of efficient X primitives - it just renders everything into buffer and provides it to server as a whole picture. Of course, X wasn't designed to work remotely in such model.

And I actually doubt primitive-based protocol can be created that does it generic enough.

On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson Little wrote:
> I'm in the opposite camp. The server is never going to be able to support everything, and people are just going to fall back to rendering themselves anyway.

Couldn't you make the same argument against any gui library? But there's a lot of stuff in common that might be sped up. Menus are very slow on Qt over remote X11 (at least with the default theme). Ironically though, the tabbed widgets are pretty fast, aside from a somewhat slow startup.

But menus are pretty much the same for any application, so that'd be a good thing to put in the display library.

Of course, you do want just "blit this image" as a generic fallback, and we can do better than X too, by just making it use png+jpg or something. Boom, transparency (yes, X has this in the render extension) and some big compression boosts.

Add display side scaling, perhaps make the pixmap be implemented as an opengl texture so you can scale, rotate, quickly paint, etc., and that's pretty useful for a lot of things. But I don't think it replaces the usefulness of higher level concepts like menus, buttons, etc. Sure, the app might have to customize them, but do they have to customize *all* of them?





> You may find this interesting: http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland

hmm, indeed.

> I would love attach/reattach for UIs. This seems like it would have to be supported at the protocol level.

Yeah, and probably a middle man of some sort too so each application doesn't have to be listening on a port. But with the client state, if it can just send that back to the new connection, it shouldn't be too hard.

On Wednesday, 14 August 2013 at 14:26:12 UTC, Adam D. Ruppe wrote:
>
> Of course, you do want just "blit this image" as a generic fallback, and we can do better than X too, by just making it use png+jpg or something. Boom, transparency (yes, X has this in the render extension) and some big compression boosts.
>
I recall NX does something like this, plus a number of other neat tricks.
http://www.nomachine.com/documents/NX-XProtocolCompression.php

-Wyatt

On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
>> You mentioned X11 to me before, when we talked about this idea over email.
>
> Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier.
As you point out later, I don't think it's the compactness of the commands that is the problem as much as that X11 bites off too much.  If you're going to be both efficient and allow remote GUI forwarding, that's an incredibly difficult and orthogonal set of features to deliver on, which is why Wayland only focuses on efficiency.  I'd punt on much of the stuff X11 tries to do with my lean GUI runtime, which I'll call Crack from here on out.

> For instance, in my crappygui.d, I used XDrawString to draw text. This was the result: http://arsdnet.net/gui.png
--snip--
> Note btw though, you *can* save the image on the display server to reuse it later, so every time you print a string it doesn't necessarily send that data across, but I'm not sure if the higher level libraries actually do this... the downsides of abstractions is you can miss important details like this.
Interesting, it does highlight what a mess X11 is.  I see no reason to build on such an old protocol.

> This is why my simpledisplay.d now has a class Sprite in addition to class Image, and why Qt has QImages and QPixmaps, but how often do you think of drawing text as being something that needs a Pixmap to be efficient? Again the library might handle it, I'm not sure, but the relatively pathetic performance of a lot of apps on a remote X connection makes me think they probably don't.
This is why I'd implement text layout and rendering in the Crack client, with the server simply passing along strings for the client to render, breaking the simple OpenGL wrapper promised before. ;) Here's some other exceptions I'd put in, which I mentioned to you before:

Text input - As you say below, you wouldn't want to hit the server for every keypress, so text input boxes would be handled by the client.  It would be easy to implement since you're already doing text layout and rendering in the client.

Scrolling - Just as with text input, if you're using one rectangle onscreen as a scrollbar, you usually wouldn't want to hit the server just to get the new scroll position of the other rectangle it controls.  There would be some scrolling-related event-handling in the Crack client, so that you could designate one rectangle as the scrollbar control for another rectangle and the client would handle scrolling, simply notifying the server of the new scroll position after the user is done scrolling.

Upload/Download progress -  Another ability you'll need is to update a rectangle based on the progress of files being downloaded or uploaded, so you can create a progress bar without having to constantly hit the server to get the status of file transfers.

File chooser - And of course, access to the native file chooser widget.

Caching - Finally, you'll want some resource and event-handling caching so that you can load updates quicker, just like AJAX once hacked into the web stack.  Say you're implementing a photo gallery, you'll have the Crack client download the next photo in the gallery and be able to tell the client that if a certain rectangle is clicked, it should swap in the next photo without checking with the server first.  This is similar to your "predictive paths" idea from DWS and would greatly decrease network traffic and GUI lag.

The caching of event handling would be narrowly circumscribed, boolean logic with mouse/keyboard events as input and GUI updates as output, so that it's simpler and much more secure than a full language interpreter like javascript.

Obviously, all these exceptions break the simple OpenGL wrapper that I'd wanted Crack to be, but the goal is to minimize such exceptions, so that you don't become the bloated beast that the web client has become today. :)

> Anyway, the other thing too is all events go to the client application from the display server, and then the application's changes go back to the display server. Since X itself doesn't offer any kind of widgets, a text control for instance would work like this:
--snip--
> So I'd want to do higher level events too, and the application can request them. For instance, if all you want is a basic text input, output something like <textarea></textarea> and let the display do the details.
I agree, text input boxes should be handled by the Crack client.

> (Another really nice benefit here, if we do it right, is it could use native controls on systems like Windows, or even pipe it to an external app on unix, and get a nice customized, adaptable system. Though while it sounds simpler in ways, this is easier said than done.)
I was thinking along similar lines for other widgets, like a video player.  I don't think video should be in the initial release, too complex, but just as HTML5 eventually added video functionality, you're going to want it in Crack someday.

The way I formulated it is that users would choose from various video player widgets and that widget would come up in any app that played video, ie the video player is out of the control of the app developer.  This avoids the problem you see with video on the web today, where you are presented with dozens of different video player implementations, whether implemented in Flash, Silverlight, or HTML5, all broken in their own special ways. ;)

The app simply sends a video file to the Crack client and then the video player widget of the user's choice kicks in.  This video player widget would be written in D and the user would be given a choice of which player widget best suits them when they download the Crack runtime.  Alternatively, you could use plugins, but the key is to tightly control where these player widgets could come from, so that you aren't running untrusted code in the runtime.

Perhaps the same choice could be offered with text input boxes and other functionality in the client.

> With these higher level events and widgets, unless you need to override some event, it can just be handled without the round trip and improve response time on slow connections.
Yeah, you do need local logic or widgets for some special cases, no doubt about it.

> But, indeed, we don't want to go *too* far either, especially since then we'd end up with a web browser situation where people write their applications in the scripting language...
Agreed, you need to keep tight limitations, or things get out of hand into the mess that the web stack is today.  This is why I wouldn't put javascript or any other scripting language in Crack.

>> What basic widgets do you have in mind, to keep on the client-side?  Also, just widgets in the client or some basic layout too?
>
> Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different.
I want to keep as much layout as possible out of the Crack client, and I don't think this warrants it.

> For my crappygui.d, I'm aiming to do:
>
> menus, labels, radio box, checkbox, buttons, grid layouts, text input, slider, number chooser, list boxes, and basic 2d drawing. Pretty much the basic stuff you get on html forms. Maybe more later, but I want to actually be able to get this working over the next weekend or two, so I'm keeping it simple. (And right now I'm not actually doing network transparency, I'll come back to that, my basic idea there is to simply forward all the function calls with rpc.)
Most, but not all, of those can be done with just rectangles directed from the server in Crack, with the aforementioned exceptions of sliders and text input.  As for basic 2D drawing, I see no worthwhile use case.  We've had the canvas tag in the browser for years now, anyone really using it?

>> it's more complicated to code all that reattaching functionality and isn't necessary for most apps, most app devs don't bother.
>
> If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me -  I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.
While remote desktop is decent, it's trying to do too much: mirroring an entire desktop is overkill.  Better to use a lean client that handles most situations.

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

I'm currently toying with my own gui toolkit. Not at all ready to show yet.
Its originally based on OOGL https://github.com/Overv/OOGL
Basically the way I'm planning on it every control is drawn by an opengl shader that can be switched out at the system, user and app level.
Enabling themeing by pretty much anybody.
It however won't use native controls.

I do have a port of OOGL to D but its really just for OOP of opengl.
https://github.com/rikkimax/D_OOGL

The controls will end up being a seperate library but the core library will basically a much nicer version of it.