[Xorg] Server side widgets

[Ely Levy]

On Sun, 11 Jul 2004, Sean Middleditch wrote:

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

Well, then having extandble widget set is the answer,
most applications uses widgets from a tool kit like motif gnome kde and
the like anyhow, and those who doesn't can either use client side widgets
or upload their widget to the server.
The exact way should probebly be thought of to find an efficient solution
but it doesn't sound impossible.
Ofcourse if someone is going to implemant it you need to find a good
flexible way to make programer life easier.
something like XUL or c# or that weird ps language someone mentioned
before:)

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

Why not? most widgets look the same, and good scripting method can solve
the flexibility problem without hurting the uniformaty of the desktop.

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

Again, I'm not saying throwing away client side, I'm sure there would be
programs who would want to use it, I'm not saying closing the door to
other sorts of extentions or making people use it.
But I think that the it can be mainstream.
That's the beauty of opensource, applications support standards
but if they want they can add their own unstandard methods.

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

I don't see why it would be easier if you have good language for server
side..

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

ok, there are other servers using a similar method,
we can go and check how they did it and see if it's indeed slower.
Someone mentioned DPS saying Xsun uses it.
Can someone who knows it elebrate on how they solved those problems?

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

Ofcourse, but I'm preety sure that it is.
in my pervious mail I email a link to someone thesis about the subject,
and fresco guys seems very supportive of it.
I wouldn't be so fast rolling it out.

Ely