[Xorg] Server side widgets

[Ely Levy]

On Sun, 11 Jul 2004, Sean Middleditch wrote:

> On Sun, 2004-07-11 at 19:22 +0300, Ely Levy wrote:
> > Hey,
> > latly I saw quite a few flame wars about server side widgets,
> > People from projects like y-windows and onyx claim for performance
> > improvments and nicer cleaner implementations,
> > as well as that X doesn't support it from the plain reason it is old.
> > I got the impression it was a design descision, which lead to many
> > diffrent tool kits.
> >
> > My question is, why did X chose not to use server side widgets (if it was
> > ever concidered)?
> >
> > and what other advantages/disadvatages it has?
>
> First, it's policy in the server.  X is designed to have zero policy,
> and to let the users over-ride it.

Simple as possible, but I still featurefull
> Second, how do users modify those widgets, such as with themes?  The
> server still generally requires root access; do you really want users to
> be able to modify the code that runs there?
>
> Third, speaking of root, do you really want all that complex code in
> such a process?  The more code you have, the more potential bugs and
> security holes.

Loading a theme is not really running code there,
but you are right, the xserver on linux need to be fixed so it wouldn't
need root access to run.

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

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

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

http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/MarkThomas.pdf

Ely