xouvert-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] Regarding server side widgets


From: Tyler Hall
Subject: Re: [xougen] Regarding server side widgets
Date: Fri, 29 Aug 2003 21:53:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]