Ideas for a brand new widget toolkit

[Adam D. Ruppe]

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.

For instance, in my crappygui.d, I used XDrawString to draw text. 
This was the result: http://arsdnet.net/gui.png

That's a true type font (Bitstream Vera Sans, a fairly good 
looking font), but X doesn't support antialiasing.

There's a library called Xft that draws fonts prettier. But how 
does it work? Instead of sending DrawText(x, y, "hello world!") 
to the display server, it uses a drawing library to render the 
text as an image in the application, then sends that image to the 
display server.

And BTW if the display doesn't support the alpha blending 
extension (the XRender extension), it first takes a partial 
screenshot, does the blending in library, and sends that image 
back!

Note that the X protocol does not compress the image data. So if 
you send a 100x30 pixel image of text, you're shooting some 10 KB 
- or double that without XRender - down the network wire instead 
of the .... idk exactly for sure, but I think it is about 32 
bytes to just send the draw instruction.


Now, you can compress an X stream over ssh, so it isn't always 
this bad in practice, but still, since the X display server 
doesn't support the expected modern feature, it blows up in 
bandwidth to compensate and that can kill the user experience.

Note btw though, you *can* save the image on the display server 
to reuse it later, so every time you print a string it doesn't 
necessarily send that data across, but I'm not sure if the higher 
level libraries actually do this... the downsides of abstractions 
is you can miss important details like this.

This is why my simpledisplay.d now has a class Sprite in addition 
to class Image, and why Qt has QImages and QPixmaps, but how 
often do you think of drawing text as being something that needs 
a Pixmap to be efficient? Again the library might handle it, I'm 
not sure, but the relatively pathetic performance of a lot of 
apps on a remote X connection makes me think they probably don't.



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.


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.




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.

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.