[Xorg] Server side widgets

[Sean Middleditch]

On Sun, 2004-07-11 at 20:51 +0300, Ely Levy wrote:
> 
> On Sun, 11 Jul 2004, Sean Middleditch wrote:

> > Fourth, a vast array of applications use custom widgets.  How would
> > those work?  You'd either need to still allow client-side drawing (and
> > then all the client-side support to mimic the themes and styles of the
> > server-side widgets) or let clients upload code/scripts to the (again)
> > root-running server.
> 
> Backward compatibilty is always a problem,
> You won't get anywhere without breaking it from time to time,
> Both solutions you offered seemed to work though, still allowing
> client-side drawing would work for a while. and as I said before
> the fact xserver runs as root needs to be fixed anyhow.
> (I think it's not like that on some other systems?)

You're msising the point.  It has nothing to do with backwards
compatibility.  It has to do with applications needing custom widgets.
You will never come up with a list of widgets that covers everything
every application needs.  In order to support any new or custom widgets
apps may need down the road, you need client-side drawing, and all the
complex machinery and API for client-side theming and such.  What point
then is there in the server?

> 
> > Fifth, how do you advance the state of the art?  We started off with
> > things like Xt, Motif, etc.  GTK+/Qt are much better than those in so
> > many ways.  They probably couldn't have developed so quickly and with so
> > much innovation if they were limited to using a pre-defined protocol for
> > server-side widgets, and had to run in the display server.
> 
> True,
> But maybe we got to the point where things are more stable?
> I know fd.o is making a lot of effords making GTK/Qt (gnome/kde)
> agree on certain standards, that can be yet another one.
> other option like you said is to make it in extandable way
> following the long X tradition:)
> (uploading bytecode to the server?)

The standards have very little to do with how the widgets look or act.
That is entirely something that should never be standardized, because
there is a big reason they act differently in those respects.

ALso, what about any new ideas down the road?  Something like Looking
Glass, maybe.  Putting things in the server shoots future innovation in
the foot.

> 
> > Sixth, who has _proven_ they're actually faster in the server?
> > Especially for more complex widgets?  Imagine something like the tree
> > view in GTK+ - the server would need access to all that information so
> > that if the user scrolls around, it knows what to display.  No way that
> > could be faster in the server.
> 
> I think both ywindows and fresco debated about that,
> I guess what pushed it is less the speed which would probebly won't
> make that much diffrent, but the fact it's uniform and easier to use.

How?  Either way, apps just call an API. The application in no way
should care whether the widgets in that API are implemented in the
client-side library or server.  Unless they start doing custom widgets
(quite common), in which case the client-side API is much easier.

And the speed _would_ be a huge factor.  The server woudl either need
all the information that client has about the client-specific data, or
there would need to be a metric ton of signals/messages going back-and-
forth to keep things updated (i.e., messages requiring round-trips and
thus latency, which just having the client redraw the widget view
wouldn't need to anywhere near the same degree).  Either way, you are
going to run no faster, possibly a lot slower, than what we have now...
so why bother?  If the only advantages anybody has ever tried to list
for putting widgets server-side isn't true, then putting them server-
side is a pretty goofy thing to do.

> 
> http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/MarkThomas.pdf
> 
> Ely
> 
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
>