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