[Xorg] Server side widgets

[Sean Middleditch]

On Mon, 2004-07-12 at 01:46 +0300, Ely Levy wrote:
> On Sun, 11 Jul 2004, Sean Middleditch wrote:
> >
> > 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.

Why bother inventing a whole new scripting/widget system for no proven
gain?  Why don't we solve real problems instead of making them up just
to look for solutions...?

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

Because the language has nothing to do with it.  It's a basic problem of
"who has the data?"  If the server is responsible for arranging and
displaying the data, but the client has the data, then the server needs
access to that data.  Which means the client code now has to store the
data in some special format that's dependent on the display system being
used (which also then makes making cross-platform clients a pain in the
arse), or the data has to be copied to the server.  Either solution is
stupid.

And the server shouldn't have a language.  Why do we need to make
everything so complex?  What we have _works_, and works absolutely fine.
We have no shortage of speed, no shortage of flexibility, no shortage of
features... there is _no_ reason to make things more complex and
introduce all sorts of new APIs and such for developers to learn for no
good actual reason.  "If it ain't broke, don't fix it."  ;-)

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

Display PostScript is, iirc, not a widget system.  It's a 2D rendering
system.  I.e., what we already have with X/GLX/RENDER.  The client
doesn't do the actual rendering, it just sends some high-level commands
to the server (like draw trapezoid with properties foo and bar) and the
server does all the rendering.

That's why widgets on the server don't really offer even much
theoretical speed gain; today's clients already have very little
traffic.  Putting widgets in the server would mostly just change what
traffic that is.  (Instead of low-level input events and high-level
drawing commands, it'd be requests for information and high-level input
events.)

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

Prove it.  ;-)

> in my pervious mail I email a link to someone thesis about the subject,
> and fresco guys seems very supportive of it.

Fresco guys haven't made anything usable other than some basic tech
demos.  The in-development extensions for kdrive/Xorg can let Xorg do
everything Fresco can without needing overly complex server-side trash.

Honestly, in the end, any such design probably isn't going to be X,
it'll be something new (like Fresco), so this is probably entirely the
wrong list to be discussing it...

> I wouldn't be so fast rolling it out.
> 
> Ely
> 
>