Re: [xougen] Regarding server side widgets

[Craig Ringer]

> > The problem with DRI is that it _ONLY_ works on the local machine, it 
> > isn't just and restriction, it just can't work if the client isn't on 
> > the same machine.
>
> Yes. But other similar interfaces/protocols could be possible, which 
> can do it (of course much slower). It should be the job of the client
> library to negotiate with the server, which protocol is the best.

Why? It's an X server, and it seems sensible to stick to the basic task 
of being a /good/ X server, not a multi-protocol display server. Other 
display protocols, if any, could easily be handled by an X client doing 
translation on the same machine as the X server (think VNC).

Multi-protocol client support strikes me as excessively complex, and I 
personally don't see any need. X11 can be a little too low level at 
times, but this is improved by the RENDER extension, and Xr / Cairo 
should provide some interesting possibilities as well. The key point is 
that it can ALL be done with X11 extensions, retaining backward 
compatability. Why break it when it works well?

In fact, if you want to write an XWIDGET extension, it might be quite 
possble within the existing X11 protocol. I really don't know enough 
about the innards of the protocol to say. Perhaps if you could say 
"here's an example implementation - these tests show a significant 
improvement, and clients can automatically back to using libxwidget to 
send basic X11 requests if the server doesn't support XWIDGET" then you 
might find folks more interested.

I've expressed interest previously in built-in VNC support for the X 
server... but for the X server to provide a VNC server (note overloaded 
meaning of server) that can be used to view the X server's frame buffer 
remotely. An entirely different thing, and if it's best done outside the 
X server, then cool - but currently it'd be a handy thing to have 
available universally.

I can't claim to know overly much about Xlib, but from what I've been 
hearing it's a bit of a pain to code against. So perhaps there's an 
argument for an "xlib2" or something - but that need not break or even 
touch existing xlib code, since it'd just be a separate client-side 
interface, and wouldn't need to have anything to do with any /specific/ 
X server. In other words, it's not an issue for a project that's 
currently focusing on the X server only.

There are a lot of cool possibilities with X11, but it strikes me that 
the real issues right now are not with the protocol or such, but with 
driver availability and the difficulty of getting updated drivers for 
XFree86 as things stand. Xouvert can improve that by providing 
separately packaged drivers, and IMHO that'd be an important step. I 
feel rather stupid every time I have to tell someone that their graphics 
chipset isn't supported under distro blah, so they'll have to update 
their distro or reinstall the entirity of XFree86 (w/o suitable 
packages, just drop it in and hope it works as expected). Sure, it's 
possible and for many not that hard - but it's unfortunate that it's 
needed at all when XFree86 4 had so much work done on it to make sure 
drivers would be portable between versions.

Craig Ringer