I totally disagree.  A text mode interface is definitely not needed.
Microsoft Windows does not have a text mode interface for configuring
video hardware, and it gets by just fine.

What _is_ needed however, is good bug reports for when the configuration
tool fails, so that defaults can be improved, and autodetection and
autoconfiguration can be much smoother.  Creating a text based UI would
be saying nothing more than "yeah, it is impossible to autodetect and
configure video hardware, lets give up and do it the 1980's way".

Also, a second reason for not creating a text mode user interface, is
that it then means that two user interfaces need to be developed side
by side and supported, which means that 50% of the features and bug
fixes, etc. can get implemented because developer time is split in
half.

If you read the help screen for redhat-config-xfree86, it is able
to work from the commandline with various arguments for supplying
resolution, etc.

If you have a specific bug to report in the tool, please do so, but
it is extremely unlikely that we will ever make a text based UI for
this tool such as Xconfigurator had.  The engineering effort is much
better spent fixing bugs, and implementing new features, and making
more and more things autodetect.

I agree that autodetection working better would be great, especially with mice,
keyboards, monitors, and video cards. But I doubt you can get it to be 100%
reliable with every hardware configuration. That belief is one of Window's
shortcomings.

>I totally disagree.  A text mode interface is definitely not needed.
>Microsoft Windows does not have a text mode interface for configuring
>video hardware, and it gets by just fine.

Windows XP: Recovery console, and Safe Mode command prompt. Both of which allow
hardware-level configuration. Windows XP installer is also text-based. You can
also used Windows XP's text-based "repair" option on the CD. Windows also does
fail occasionally in this respect, and when it does, most users don't have any
clue what to do. Using recovery console and safe mode command prompt to fix
hardware is a pain in the butt. Fixing a problem in automation or autodection
can often take days of combing message boards of similiarly frustrated users.
Example:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=FC8F8994E85EB179.5720C82292387352.42EA130ACEAAF6EB%40lp.airnews.net&rnum=9&prev=/groups%3Fq%3Dwindows%2Bxp%2Bconfiguration%2Bproblems%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DFC8F8994E85EB179.5720C82292387352.42EA130ACEAAF6EB%2540lp.airnews.net%26rnum%3D9

>What _is_ needed however, is good bug reports for when the configuration
>tool fails, so that defaults can be improved, and autodetection and
>autoconfiguration can be much smoother.  Creating a text based UI would
>be saying nothing more than "yeah, it is impossible to autodetect and
>configure video hardware, lets give up and do it the 1980's way".

And when new hardware comes out and that fails, what then? text-mode would be a
fail-safe for if all else fails. X didn't load after reboot from install and I
had to modify the XF86Config file manually. Had to do that back with RH7.2,
also. Fail-safes for configuration isn't a bad thing. Why rely on people having
X loaded? Text-mode will work just fine with text-based widgets (text-based
trees, etc).

>Also, a second reason for not creating a text mode user interface, is
>that it then means that two user interfaces need to be developed side
>by side and supported, which means that 50% of the features and bug
>fixes, etc. can get implemented because developer time is split in
>half.

If you have the widget implementation independant of the actual values being
filled into the widget, you wouldn't need to write two different versions of all
your options, etc. Something akin to an XML/HTML file containing the
configuration and a Lynx-like interface would do just fine for the text-mode.
For the graphical mode, it would appear in a window. That's something similiar
to what we do on Mozilla development. In fact, I imagine that all our widget set
could be done in text if a text-based XUL parser were written. It wouldn't look
the same, but would be functional.

Example: 

<xul blah blah>
<button/>
 <value="Click here">
</button>
</xul>

In graphical mode, you would see graphical widgets, in text mode, you would see
something like this comprising a tab-stop:
[Click here]

>If you read the help screen for redhat-config-xfree86, it is able
>to work from the commandline with various arguments for supplying
>resolution, etc.

True, but no way near the capability of text-mode configuration. It also almost
requires you to be a developer for RedHat to know how to use it.

Furthermore:
>"yeah, it is impossible to autodetect and
>configure video hardware, lets give up and do it the 1980's way".

Its just filling in the void until autodetect is perfect and can be 100%
reliable. Since I just witnessed an example of it not being 100% reliable, I
believe that this point hasn't been reached yet. Besides, text-based
configuration isn't bad at all.

I wish Windows had text-based configuration for all the GUI configuration
utilities (just-in-case)

In fact, you can probably find some perfectly adequate open-source text-based
widget sets to use.

I'm not demanding you change your policy on this and similiar issues, but am
asking that you at least think about it.

Actually, on Mozilla we used to just say "Wait until it works" and not put in a
fall-back method until then. We don't really do that anymore. If we can provide
a temporary fix to get around the issue they have, we do that until the better
solution is implemented. We also make very sure we don't let it end at the
temporary fix (like Microsoft).

Also it's not as if you would have to start from scratch.  Presumably the code
for XF86Configurator is still around somewhere.

Don't hold your breath to see a text mode front end for redhat-config-xfree86.
IMHO, the effort spent doing that, is duplication of effort, and would be much
better spent on fixing bugs in the tool so that it works better on more hardware.

As it is right now, there ARE workarounds for when the tool doesn't work
off the bat.  Using it from the commandline is one such mechanism.

redhat-config-xfree86 --help

That lists the available commandline options.

>Also it's not as if you would have to start from scratch.  Presumably the code
>for XF86Configurator is still around somewhere.

100% wrong.  Xconfigurator is a horrible pile of crap, which is total
spaghetti code, and contains zero useful code which could be used for a
text mode config front end for redhat-config-xfree86.  Xconfigurator is
written in C, redhat-config-xfree86 is written in python.  Xconfigurator
parses the config file the same way as the ancient xf86config did, because
Xconfigurator was nothing more than xf86config with a horrible newt UI glued
on top of it which got spaghetized over the years as it was hot-potatoed from
one developer to the next.  The tool got to a state where it was, (and
continues to be) completely and totally an unmaintainable mess.  The decision
to write a new tool from scratch was made, and there's no way we'll ever go
back on that decision.  We will however continue to improve the new tool
redhat-config-xfree86 with bug fixes and new features each release, which
are made based on customer feedback.

redhat-config-xfree86 is written in python, and uses a python/C wrapper around
libxf86config.a which ships as part of XFree86, and is the same parser library
that xf86cfg uses.  There is absolutely no code in Xconfigurator which would
be useful for a text mode frontend for redhat-config-xfree86, which means
that a UI would have to be written completely from scratch, and then 2 front
end UIs maintained.

That effort is much better spent, at least in my opinion, on implementing new
fixing bugs in redhat-config-xfree86, and adding new features such as multihead
configuration support, and numerous other important and often requested features.

A text mode UI is just fluff, which can be accomplished using the command line
almost 100% of the time.

One more thing...  If someone is desparately and direly interested enough
in a text mode front end...  We accept patches for review.  Anyone out there
is completely free to write a text mode front end and attach it as a unified
diff to our GPL'd sources for review and potential approval.  Seriously unlikely
that we'll embark on one however.