On Tuesday, 13 August 2013 at 19:21:31 UTC, Michael wrote:
> Maybe a port of Fltk library? Small and good enough.

There is a C++ GUI framework (BSD license) with good design and
native controls http://vcf-online.org/. Is it good enough for
making a partial port?

On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
> Think of this topic as writing letters to Santa, so: what say you ?
I'll take this opportunity to put forward a GUI idea I plan on implementing in D at some point.

The concept is to build a client-server GUI runtime that is as simple as possible on the client side.  That means the client's graphics are a small wrapper around OpenGL, simply slapping rectangles composed of pngs and text on screen and handling mouse and keyboard events.  The client sends event data back to the server in a highly optimized binary protocol, which then does all layout and GUI calculations.  Finally, the server sends simple commands back to the server saying what text/pngs/rectangles it wants moved or updated.  The client simply handles absolutely positioned rectangles with a z-index, all relative layout and higher-level state is calculated on the server.

The idea is to keep the GUI client as lean as possible, moving as much calculation as possible to the server, ie when you resize your window, the server has to recalculate layout, not the client.  It would be incredibly easy to port this client to new platforms, such a lean client would be ideal for mobile platforms, efficient and low power.  I think of it as the web, ie HTML/CSS/javascript, done right.  There would be no javascript or other general purpose language on the client, far too complicated and insecure.

Obviously this runtime wouldn't suffice for everything: you're not going to write real-time physics-based games in such a GUI runtime, which you could do in javascript in a web browser.  The network lag would kill you, since all layout and GUI calculations are done on the server.  But such a lean GUI runtime would handle most light and medium-strength GUI applications, most apps south of Photoshop. ;)

This is a unique, innovative approach I'd like to see taken, planning to do it myself if nobody gets around to it first.  But I thought I'd throw it out there as a possible approach for a D GUI to take, see what others think.

On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
> The concept is to build a client-server GUI runtime that is as simple as possible on the client side.

Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.

I've been wanting to do a network transparent gui myself, and is one thing I might do with my crappy implementation once it is a little more complete. I'd make the display a little thicker though, with basic widgets being there so it can just communicate in higher level events. I also want the ability to detach and reattach elsewhere, ala gnu screen.

On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe wrote:
> On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
>> The concept is to build a client-server GUI runtime that is as simple as possible on the client side.
>
> Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
You mentioned X11 to me before, when we talked about this idea over email.  I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind.  I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency.

Yes, such networked GUIs assume low latency, just as most of the web assumes a working internet connection. ;) This is not a solution for offline GUIs, and so wouldn't work as a general-purpose GUI toolkit.  I wonder if offline is a niche worth serving these days however.

> I've been wanting to do a network transparent gui myself, and is one thing I might do with my crappy implementation once it is a little more complete. I'd make the display a little thicker though, with basic widgets being there so it can just communicate in higher level events. I also want the ability to detach and reattach elsewhere, ala gnu screen.
Yeah, I saw your DWS writeup, seems like we have some similar ideas: :)

http://arsdnet.net/dws/

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?

With my idea, the client is only given sizes and absolute positions of rectangles, with pngs or text to render inside the rectangle: it has no conception of what it is rendering and can't do any layout on its own.  For example, an offline web browser can layout a page anew when the window is resized, but all layout for my client is done on the server.

As for detaching and reattaching, that is easier to do, the more state is kept on the server. :) You could do it in most webapps today, after you login at the new location, but since it's more complicated to code all that reattaching functionality and isn't necessary for most apps, most app devs don't bother.

On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
clip
>
> Yes, such networked GUIs assume low latency, just as most of the web assumes a working internet connection. ;) This is not a solution for offline GUIs, and so wouldn't work as a general-purpose GUI toolkit.  I wonder if offline is a niche worth serving these days however.
>
clip

A couple of comments on the point above.

1. Could it not work for offine GUIs, assuming the server and
client
were on the same machine, in which case one would hope the
latency is
low.  For example X11 works locally without a network connection.

2. Based on your "I wonder if offline is a niche ...." I get the
impression you live in a part of the world that has more reliable
internet access than where I am from :o)

On Tuesday, 13 August 2013 at 21:05:21 UTC, Craig Dillabaugh wrote:
> 1. Could it not work for offine GUIs, assuming the server and
> client
> were on the same machine, in which case one would hope the
> latency is
> low.  For example X11 works locally without a network connection.
Yes, you could put the server on the user's desktop, then drive the GUI runtime locally.  But this could raise a host of issues with portability and capability, which you see with webapps that try this offline model today.  You'd need to make sure that the Apache server and your oddball-cool Erlang webapp can run on the user's Windows desktop, that they won't fry his Celeron with all the stuff you can do easily on your Xeon server.

But yeah, if you kept the server-side lean and portable, you could go offline this way, and I imagined that something like this would be the solution for offline use eventually.

> 2. Based on your "I wonder if offline is a niche ...." I get the
> impression you live in a part of the world that has more reliable
> internet access than where I am from :o)
Actually no, which is why I have multiple redundant internet connections at my place, only one of which is connected right now. ;) But offline apps are increasingly fading away: most people spend most of their time these days using apps that are constantly connected to the internet, whether email or webapps.

I'm offering an idea for a specialized solution that optimizes that common connected use case, rather than a general solution that is more work for the programmer, forcing him to write more low-level networking and GUI synchronization code on his own.  That's the tack the web takes, I'm following in that vein with a different approach.  I'm not trying to say offline apps aren't an important use case; I'm just saying there can be other GUI toolkits to handle mostly-offline apps for now.

On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
> On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
>>> The concept is to build a client-server GUI runtime that is as simple as possible on the client side.
>>
>> Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
> You mentioned X11 to me before, when we talked about this idea over email.  I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind.  I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency.
>

Have you seen this?

http://wayland.freedesktop.org/

On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
> Have you seen this?
>
> http://wayland.freedesktop.org/
I've heard of it, but I didn't look at it much before.  It's always described as a leaner version of X11, just as I'm suggesting a much leaner runtime than the web, but I never saw specifics on how Wayland translated that at the protocol level.  I now see that remote access, like VNC or X11 provide, is unimplemented for Wayland: it's only for local use at the moment.  I don't see how that's relevant to the networked GUIs we're talking about.

On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
> On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
>> On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe wrote:
>>> On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
>>>> The concept is to build a client-server GUI runtime that is as simple as possible on the client side.
>>>
>>> Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
>> You mentioned X11 to me before, when we talked about this idea over email.  I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind.  I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency.
>>
>
> Have you seen this?
>
> http://wayland.freedesktop.org/

I only mention it as it might provide a good platform to build upon in D, or at least provide a solid place to start expermenting with ideas.

It's small and written in C. It also has a compositor component called Weston, again in C.

On 08/13/2013 09:23 AM, Paul Z. Barsan wrote:
>
> Think of this topic as writing letters to Santa, so: what say you ?

Let me propose a nice a name, RADD (simply pronounced as 'rad') stands for "Rapid Application Development with D".