Ideas for a brand new widget toolkit

[Joakim]

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.