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

Re: Xconfigurator --kickstart

On Thu, 2002-06-27 at 10:18, Erik Troan wrote:
> On Thu, 27 Jun 2002, Matt Fahrner wrote:
> > So, why then was Xconfigurator built into kickstart? It seems to make 
> > a lot more sense to use XFree86's, though maybe a pain because 
> > packages have to be pre-loaded. Is it because of the GUI install front 
> > end?
> Yep. We need to be able to configure X before we can run Xconfigurator.
> > I think it would be worth some effort to go back to "Xconfigurator 
> > --kickstart" (not that I'm offering). As it is we have found no way to 
> > make kickstart properly detect our Samsung 750p's.
> The monitor detection code is almost identical; you should (ideally) find
> where it's going wrong in your case or at least file a bug in bugzilla. The
> Xconfigurator code is reall horrible. It started life as xf86config (which
> was really ugly to begin with) and then had a number of quick hacks put
> on top of it. The code is really unmaintainable and needs to be thrown
> out at some point.

This will happen at some point in the relatively near future.  Alex has
a really nice GUI tool for configuring X.  It can create a file from
scratch (like Xconfigurator) or it can modify an existing file (unlike
Xconfigurator).  I don't think he'll have a text mode version for the
next release, but it should happen at some point.  

I believe that it allows you to pass it some arguments on the command
line, so it should be usable with kickstart someday.  The ultimate goal
is to have anything that ever needs to configure the XF86Config file
(such as anaconda, redhat-config-mouse, redhat-config-keyboard, and
redhat-config-xfree86) all share the same backend code.  We're moving in
that direction, but it takes time.  But Xconfigurator should go away in
the next few releases, and that will be a good thing.


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