Ideas for a brand new widget toolkit

[Joakim]

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