Re: [xougen] Regarding server side widgets

[William Lahti]

On Friday 29 August 2003 10:53 pm, Tyler Hall wrote:
> 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

Yes thats a problem.

> - patch the files scattered throughout the full tree to implement the
> driver update

Yes thats a problem.

> - compile the _full_ tree (because I just downloaded it and haven't
> compiled it before), including even the SPARC video drivers

Um what? Check out the files in xc/config/cf. One of those in there 
has an option for which drivers to compile. Just remove all the ones
you dont need and leave the ones you want. You can also tell it to
only compile the server so you dont have to sit and wait for xterm, twm
etc to compile.

> 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
>
>
>
> _______________________________________________
> xouvert-general mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/xouvert-general

-- 
--------------------------------
$ printinfo
Fury // a.k.a William Lahti
Developer, Xouvert
Developer, Slicker Project
Developer, Calyptos
$ /usr/games/fortune
"I admit I've done too much playing around without understanding
 the issues involved over the last years as well, but it's time
 to stop reinventing the (sometimes octangular) wheel and learn
 everything from history which we can learn."

        - Rik van Riel
$ uptime
 13:13:46  up 18:07,  4 users,  load average: 0.30, 0.25, 0.18