Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: When X isn't working it is not logical to use X to setup X. redhat-config-xfree86 could not properly figure out my screen resolution on my Presario 700 notebook, and running redhat-config-xfree86 resulted in unreadable text or the select box being cut off. A text only interface is needed. Version-Release number of selected component (if applicable): How reproducible: Always
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.