On Wednesday, 14 August 2013 at 17:35:24 UTC, Joakim wrote:
> 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.

Maybe this is because I'm used to Linux, but I generally just want to forward an application, not the entire desktop. On Linux, this is trivial:

    $ ssh -X user@host
    $ gui-program <args>

However, Windows doesn't have this workflow, so mirroring the entire desktop became necessary.

Simpler is usually better, as long as simpler doesn't prevent you from creating something robust on top.

In a widget toolkit, I think the same applies: make just enough controls that most people are satisfied, then make the toolkit easy to extend with custom controls.

On Thursday, 15 August 2013 at 01:03:24 UTC, Tyler Jameson Little wrote:
> However, Windows doesn't have this workflow, so mirroring the entire desktop became necessary.

It does now, Server 2008 I think was the first one, or maybe Windows 7, they call it Seamless RDP.

> In a widget toolkit, I think the same applies: make just enough controls that most people are satisfied, then make the toolkit easy to extend with custom controls.

Yeah, and that's a much more modest goal too.

BTW I spent a couple more hours on my crappygui.d today. No network transparency here, just drawing non-native widgets. So yeah it sucks, but it is small, simple, and standalone. Take a look at this screenie!

http://arsdnet.net/gui2.png

My keyboard is literally falling apart and backspace doesn't work in the text edit yet (big downside of non-native widgets, the behavior is hard to get right)... so not much of an edit lol... but yeah it is moving along. I think by the end of this weekend, it will be good enough for me and I'll put the code on my misc github.

The event model is lifted from javascript:

     button.addEventListener("click", { window.close(); });

and mouseenter, keydown, etc. are implemented too. It does the capture, bubble, preventDefault, stopPropagation, just like the w3c dom. I kinda like that model.

On Thursday, 15 August 2013 at 01:03:24 UTC, Tyler Jameson Little wrote:
> On Wednesday, 14 August 2013 at 17:35:24 UTC, Joakim wrote:
>> 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.
>
> Maybe this is because I'm used to Linux, but I generally just want to forward an application, not the entire desktop. On Linux, this is trivial:
>
>     $ ssh -X user@host
>     $ gui-program <args>
>
> However, Windows doesn't have this workflow, so mirroring the entire desktop became necessary.
Sure, but X forwarding is still laggy, as you pointed out.

> Simpler is usually better, as long as simpler doesn't prevent you from creating something robust on top.
Well, that's where the problems come in. :) Making something robust usually implies complexity.

Best to split up the job, client-server runtimes, like webapps or the lean Crack client I'm talking about, handle most non-realtime online GUIs, while other toolkits handle the offline or real-time cases.  No one toolkit can do it all, the market has already splintered this way.

> In a widget toolkit, I think the same applies: make just enough controls that most people are satisfied, then make the toolkit easy to extend with custom controls.
I'm suggesting taking that philosophy to an extreme: almost no local controls, just a simple rendering runtime that slaps up rectangles and renders text, along with a few niceties like caching to lessen lag.  All the controls are composed and placed into a layout on the server, which then tells the client how to build those controls out of very simple primitives: put a rectangle here and render this png into it, which happens to look like a button to the user.  This won't work for side-scrolling games or other real-time stuff that's usually done in Flash now, but it will handle the long tail of apps.

On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
>
> Sure, but X forwarding is still laggy, as you pointed out.
>
I think that's only because it's a naive, uncompressed implementation.  Proper protocol compression pretty much removes that for most use cases.

-Wyatt

On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
> On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
> >
> >Sure, but X forwarding is still laggy, as you pointed out.
> >
> I think that's only because it's a naive, uncompressed implementation.  Proper protocol compression pretty much removes that for most use cases.
[...]

I've run X11 forwarding over a compressed SSH tunnel before. It's actually usable. Not fast, but usable. (And this was over the internet, not in a LAN, which would be significantly faster.) I used to run X11 forwarding over an uncompressed channel, and it was unusably slow.

X11 was really designed for server + many workstations LAN setups, and it still works pretty well in those scenarios. It was never designed to be used over WANs, so it performs poorly when your link goes through the internet. It also wasn't designed for desktop apps, though modern X servers bypass most of the performance overhead by extensions that allow direct memory mapping between the server and client, so you could, e.g., directly access VRAM once it's negotiated with the server.


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

On 14.08.2013 19:35, Joakim wrote:
> On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
[snip a lot of discussion of Adam and Joakim]

>> 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.

Another solution would be to have a client/server architecture in your application. Usually the GUI talks via std.concurrency messages to your business logic and itself receives input events this way. However if you're doing remote it's transparently replaced with messages over the network.

Starting a remote session for the first time could involve wget and rdmd though.

The other option discussed here: 'Yeah, X11 is kinda cool, sadly the protocol didn't forsee the future 20 years, but the approach is right!'
will be considered failure in 20 years.

On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
> All the controls are composed and placed into a layout on the server

How do you handle styling? If the application defines its own theme, your thing will be good, but if you want to blend in with the rest of the desktop, that's a lot of work.

One option though would be to ask the display for its current them when you connect, and then render using it in the library. Actually that's not a bad idea at all.

But I think it is just easier to use native widgets on the display when you can, then they are styled automatically.


Of course, this applies to any GUI library: native vs DIY is one of the great divides here....

On Thursday, 15 August 2013 at 17:10:13 UTC, Tobias Pankrath wrote:
> Another solution would be to have a client/server architecture in your application.

This is actually how I did D gui apps before, with the "server" being a C++ dll that uses the qt library. (I tried qtd but it crashed too much.)

> The other option discussed here: 'Yeah, X11 is kinda cool, sadly the protocol didn't forsee the future 20 years, but the approach is right!'
> will be considered failure in 20 years.

meh, in 20 years they can always write a new one.

On Thursday, 15 August 2013 at 16:44:21 UTC, H. S. Teoh wrote:
> On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
>> On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
>> >
>> >Sure, but X forwarding is still laggy, as you pointed out.
>> >
>> I think that's only because it's a naive, uncompressed
>> implementation.  Proper protocol compression pretty much removes
>> that for most use cases.
> [...]
>
> I've run X11 forwarding over a compressed SSH tunnel before. It's
> actually usable. Not fast, but usable. (And this was over the internet,
> not in a LAN, which would be significantly faster.) I used to run X11
> forwarding over an uncompressed channel, and it was unusably slow.
I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.

> X11 was really designed for server + many workstations LAN setups, and
> it still works pretty well in those scenarios. It was never designed to
> be used over WANs, so it performs poorly when your link goes through the
> internet. It also wasn't designed for desktop apps, though modern X
> servers bypass most of the performance overhead by extensions that allow
> direct memory mapping between the server and client, so you could, e.g.,
> directly access VRAM once it's negotiated with the server.
What is the latency or bandwidth threshold that X11 needs?  I've found it slow even with low latency and plenty of bandwidth, ie over a local LAN.  "It also wasn't designed for desktop apps:" what was it designed for then, xterm and xclock and that's it?

On Thursday, 15 August 2013 at 17:10:13 UTC, Tobias Pankrath wrote:
> Another solution would be to have a client/server architecture in your application. Usually the GUI talks via std.concurrency messages to your business logic and itself receives input events this way. However if you're doing remote it's transparently replaced with messages over the network.
Yeah, Craig and I talked about this possibility earlier in this thread.

> The other option discussed here: 'Yeah, X11 is kinda cool, sadly the protocol didn't forsee the future 20 years, but the approach is right!'
> will be considered failure in 20 years.
Like Adam said, that's good enough.  X11 had it's time; if a Crack client can have it's time, that's all that matters.  Trying to look ahead 20 years is a mug's game.

On Thursday, 15 August 2013 at 17:18:53 UTC, Adam D. Ruppe wrote:
> On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
>> All the controls are composed and placed into a layout on the server
>
> How do you handle styling? If the application defines its own theme, your thing will be good, but if you want to blend in with the rest of the desktop, that's a lot of work.
>
> One option though would be to ask the display for its current them when you connect, and then render using it in the library. Actually that's not a bad idea at all.
I don't think "blending in with the rest of the desktop" is a worthwhile goal.  Web controls largely don't do this and that hasn't hurt the web.  But yeah, you can try to recreate the user's theme on the server, once the client tells you what OS it's running on, if you really wanted to.

There are a lot of possibilities: you could run Qt or Gtk+ on the server and then write a backend for each of those toolkits so they can call the simple Crack server APIs and render to the Crack client.

The essential idea here is to push as much as possible to the server, which the developer actually controls.  So he doesn't have to deal with a dozen browsers, all with their subtle implementation differences of the web protocols.  He doesn't have to deal with a dozen different native widget libraries, rewriting his UI in each.  You get a lot of the benefits of the web, without some of the costs, hopefully. ;)

> Of course, this applies to any GUI library: native vs DIY is one of the great divides here....
I come down on the DIY side, at least for this runtime, with the possible exception of client-side widgets like a video player.  But you have the flexibility to ape the native theme, if you can reproduce it faithfully on the server.

> There are a lot of possibilities: you could run Qt or Gtk+ on the server and then write a backend for each of those toolkits so they can call the simple Crack server APIs and render to the Crack client.

Gtk Broadway.

http://www.youtube.com/watch?v=fr8eo4RlPw4