Cherrypicking system-config-xfree86 from redhat

[Erast Benson]

On Sat, 2005-12-24 at 10:48 +0100, Simon Edwards wrote:
> On Friday 23 December 2005 18:45, Erast Benson wrote:
> > On Thu, 2005-12-22 at 23:28 +0100, Simon Edwards wrote:
> > > FWIIW. I'm working on an X configuration utility which will hopefully be
> > > in  
> > > good shape for Kubuntu's Dapper release. 
> > > The project is called Guidance:
> > > http://www.simonzone.com/software/guidance/ 
> > Nice!
> > why not just to use system-tools-backends which is part of
> > freedesktop.org ? And build Python/KDE GUI on top of that?
> 
> I've looked at these backends in the past and quickly realised that they don't 
> solve any problems I have. At least not in an economical way...
> 
> > And besides, it provides initial backend for Xorg configuration...
> 
> ...reading and writing xorg.conf is the easy part. This is all that 
> system-tools-backends seems to offer.

oh, I do not claim system-tools-backeds has complete X configuration
backend yet. It could be extended easily.

> I started out with the read/write code that Red Hat is using (really just 
> Python bindings on the XFree86 C parser). I then had some issues with it and 
> quickly wrote my own version in Python over the course of a few evenings. 
> This code is current under 700 lines.
> 
> Now, ignoring the GUI code, the place where most of the work has gone to is 
> creating a sane layer for dealing with Xorg configuration, hardware 
> detection, gfx card and monitor databases, and things like on the fly gamma 
> changes and resolution chances (using the Rotate and Resize X extension). 
> Basically all of the messy stuff. (about 2500 lines now and growing). Almost 
> all of this code is Xorg specific. The API that this exposes tries hard *not* 
> to be Xorg specific.

I think it is OK for backend and frontend to be Xorg specific since this
is the only task this tool is trying to resolve.

> If system-tools-backends offered a working X configuration API like the one 
> above, then it would be a lot more interesting. But right now I don't see the 
> point in dealing with IPC systems and backends which only seem to add 
> complexity without moving me closer to my goal.
> 
> (Personally I don't see the point in having seperate out-of-process backends, 
> what is wrong with just creating a library for handling things that an 
> application can call directly?)

system-tools-backends offers XML-based messaging interface which is
quite portable, easy to parse at frontend side and easy to extend.
This messages could be passed trough different transports, like ssh for
instance, which makes it easy remote sort of configuration and forces to
keep backends not to be KDE, GNOME, Xfce, ... specific which is inline
with freedesktop.org design.

> I don't want to sound all negative, that's just the way it all looks from 
> here.

Sure. And I just giving you my opinion. I'm not a system-tools-backends
core developer, I'm just porting it to Nexenta so it will be as easy to
configure as Ubuntu. So, as a user of GNU/Solaris and GNU/Linux systems
I would really appreciate if my systems designed to have single
configuration layer like system-tools-backends and various GUI apps just
make use of this backends layer all over.

> > I could help you with STB backends and Guidance KDE/GUI integration in
> > some ways since I'm currently working on Nexenta OS GNU/Solaris
> > (http://www.gnusolaris.org) of system-tools-backends port.
> 
> If Nexenta uses Xorg as their X server, then porting 'displayconfig' probably 
> wouldn't be all that hard.

sure, as well as pretty much every(non-Linux kernel specific) package
from Ubuntu/Breezy works on Nexenta just fine.