Ideas for a brand new widget toolkit

[Tyler Jameson Little]

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