Re: [xougen] Regarding server side widgets

[Tyler Hall]

Alan Cox wrote:

> On Gwe, 2003-08-29 at 18:11, address@hidden wrote:
>  
>
> > Server side widgets will be optional. They also should be put into an 
> > separate module, which is loaded on call.
> >    
>
> Server side widgets is totally foreign to X. If you want to go do that
> I suggest you go write yourself a seperate remote widget server.
>  
Perhaps the _functionality_ of widgets is foreign to X but not the 
drawing of them. X wasn't originally designed to accept "Here's a 
description of a 3D shape, please draw it" messages from the client, yet 
the GLX extension allows X to support clients who speak those messages. 
Similary a new X extension to could be designed handle "Here's a 
description of a widget, please remember it" and "please draw that 
widget at this location". Even a _little_bit_ of widget functionality 
could be implemented on the server side, maybe enough to allow the 
client to request "don't bother telling me about any pointer changes 
except: a button-down/up in this rectangle, a focus-change in this 
rectangle, etc.".

Does it add to the Xserver? of course. Is it worth it to the client? I 
think so.  Is it changing the idea of what X is? I don't think so; most 
extensions are just implementations of common macros, and I think there 
is enough demand for some serious brainstorming on this idea. I would 
hate to think that something (Xserver) so central to *NIX windowing 
can't allow clients to do their job faster because it's something that X 
isn't used to.

>  
>
> > I dont need drivers for thousands of video cards I do not own.
> >    
>
> But anyone developing does need the full tree. Thats a binary packing
> problem for vendors not a reason to split the source tree
>
>  
And what if I'm a user (not a developer) who wants to download the 
latest driver for my 3dfx card in my i386-based machine, should I have to:
- download the full source tree
- patch the files scattered throughout the full tree to implement the 
driver update
- compile the _full_ tree (because I just downloaded it and haven't 
compiled it before), including even the SPARC video drivers
OR would be more convenient to:
- download the XCommon, XServerLib, XVideoDriver-3dfx packages (or if I 
already had the tree downloaded I can just download the 
XVideoDriver-3dfx package to replace the older one)
- ./configure examines what I have and don't have, adjusts Makefiles 
accordingly
- compile the stuff I want, only the stuff I want.

Keeping the tree as it stands right now offers no such modularity. We 
need to reorganize the source to allow such modularity, not just to make 
life easier for binary packers, but for those developers who wish to 
contribute to just one module.

Tyler