Future features (was Re: Discussing issues)

On Wed, Apr 16, 2003 at 07:52:54PM +0100, Alan Hourihane wrote: 
> When forum was started I posted a list of what the core team had talked
> about as things we may do for XFree86 5.0. By no means is this a fixed
> list or guaranteed. It was to open up discussion on what people are 
> interested in doing for the next major release.
> 
> If you read that Havoc I think it'll give you an idea on where we
> think we're heading, but please throw in some ideas on what else you
> think needs to happen. Maybe someone with that itch would step forward
> and write it, or has already been thinking the same thing.
> 
> Roll on discussion of where we're all heading in future features and
> we'll all get a better picture of what's happening around us. I'm sure
> we'll all come to like each other a lot more if we can be productive
> in this type of communication.

Cool, the link for convenience:
  http://www.xfree86.org/pipermail/forum/2003-March/000004.html 

Some things I can think of offhand to add:

 - for accessibility and some UI stuff a thumbnail/magnification 
   extension. Keith has proposed doing this as part of the same 
   code changes needed for alpha channels on windows.

   This is something I was trying to quickly address with the DAMAGE
   extension I posted a while back. The reply I got on that extension 
   was from Keith and he said my extension shouldn't be included 
   because his bigger-picture changes would provide the same
   functionality more generally.

 - related to hot plug there's a general issue that the
   desktop/application layer needs to track all the devices connected
   to a system, whether they are enabled/disabled, etc. and provide 
   appropriate UI

   I've been advocating a "hardware abstraction layer" for a while 
   that would essentially be a shared library that manages 
   a list of Device objects and tells an application when a device
   comes and goes. A "Device" in this context on Linux is basically 
   a major/minor pair as I understand it, i.e. a virtual device 
   that already has a driver loaded.

   However, the hardware abstraction layer should be cross-platform.

   I would say that loading the driver is the domain of the operating
   system, and apps/desktop only care about devices the OS has already
   "found."

   For implementing the backend of this library, and perhaps 
   for coordinating device usage among various X servers, 
   I think D-BUS could be very useful. See 
   http://www.freedesktop.org/software/dbus/

   This has also been discussed a bit in relation to Linux hotplug.
   However it's important to understand (if I have this right) that
   Linux hotplug is something that happens before a driver for a
   device is loaded, and most things we probably care about happen
   after a driver is loaded.

   I have some more extensive thoughts on this written down but 
   they're written down in pretty rough form.

   Anyway, I don't know if XFree86 wants to try to look at this more
   globally or if just a mouse/keyboard specific fairly limited
   codebase is the right way to go. However, if there's a UI that
   lists the devices on your system and the user can specify there
   that "this USB device is a keyboard," I would think as soon as the
   user identifies the device as a keyboard that X should pick it up -
   ideally without even restarting the server.  So it would be nice if
   we had *one* place on the system that said "USB device XYZ is a
   keyboard" - and if in this place, the XYZ<->keyboard mapping could
   be established by either an OS vendor, an OEM, or a local user
   site.

   Some related threads:
 http://sourceforge.net/mailarchive/forum.php?thread_id=1948705&forum_id=3157
 https://listman.redhat.com/pipermail/message-bus-list/2003-April/000222.html

 - right now we have a bunch of keymaps that come with the GNOME
   keyboard switcher applet.

   I think the idea of a "Swedish keyboard keymap" should probably 
   come with X instead, so that these little applets are just 
   a GUI widget that sends some request to the server or invoke 
   some library. Then there's only one place you have to fix the
   keymap.

   I don't know a lot about this, I just see the keymaps coming with
   an applet and think "gee that is really wrong" ;-) maybe 
   XFree86 already contains a better way to do it and the applet 
   is just hosed.

 - I would like to see a remote desktop feature work "out of the box,"
   Alan I mailed you about this a while back, here is a mail that
   includes the notes I made on that:
   http://mail.gnome.org/archives/desktop-devel-list/2002-December/msg00221.html

   I realize xf4vnc exists, but something folded into XFree86 upstream
   would be a plus. libvncserver or functional equivalent would also
   be nice to have, if not as part of X, at least readily available.
   Ideally if the server side is a VNC server it would use the same
   libvncserver as any client side VNC server, so that features can be
   added in one spot.

   Ideas on how this should be done such that it would be acceptable
   for upstream integration would be very useful. I have working on
   this somewhere on my back burner; far enough back that it won't
   happen all that soon, but near enough that it could happen
   someday. ;-) In the meantime various random people have expressed
   interest in doing it and I'd like to have a plan of action
   available that they can just follow if they get excited one
   weekend.

   Some people have suggested that this be done with X protocol 
   extensions rather than using VNC, but to me that's probably 
   more effort than the problem justifies.

 - Double buffering that spans multiple windows, specifically the
   window manager frame and the application inside it. Some mechanism
   for WM and app to coordinate when to pop the buffer and draw to the
   screen.

   Within a single X window, a server-side damage region and backing
   store extension might be interesting if it were more efficient - we
   currently do this on the client side for GTK+, but could use a
   server side feature when available if it offered advantages.

   The multi-window case is the one that can't be done client side
   right now, though.

 - Another thing that might partially address the same issue 
   as double buffering would be a way to sync to the monitor 
   refresh, has been discussed in the past I know

 - Earlier on this list we had a thread about how it was hard to do
   smooth animation. I can't find the link now, but some general
   thinking in that area would be useful.

 - Some of the freedesktop.org specs such as EWMH could use broader
   review and feedback.

 - I think it would help people test and work with the XFree86
   codebase if you could basically just run a build-and-install script
   which would leave you with a way to start an X session using
   XFree86 from CVS, without messing up the files owned by your
   packaging system. i.e. type one command, walk away, shut down
   current X, start the new one, now you're using your custom X build.
   Maybe it's this easy now, but it isn't clear to me how you do it.
   When I wrote that DAMAGE extension I debugged the whole thing with
   Xnest instead of the XFree86 server.

Havoc