From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 Description of problem: redhat-config-xfree86 is missing functionality that xf86cfg has. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: run rh-cfg-xf86 Actual Results: cannot configure multiple depths, modelines, multiple keyboards, multiple mice, or use the multiple layout options of XF86-4.x. Expected Results: All are possible with the defaultconfig tool from XFree86.org, xf86cfg. Since Mike has *removed* xf86cfg completely from the Red Hat packages, to force the use of the new tool, it should support the functionality of the tool it replaces. The only useless part of xf86cfg that I have seen is the "Expert Mode". Xf86cfg should be rewritten to use GTK+ or gnome libs like rh-cfg-xf86, without loosing *_ANY_*functionality. Additional info: Examples: xf86cfg allows me to select the order of resolutions in the Screen configuration, which changes the cycling order of the hot keys. I prefer to have <KP+> give higher resolutions and <KP-> give lower ones. Multiple screens. One for everyday work, high reosolution, 16bit screen, mostly for 2D work. An a lower resolution, high color screen for 3D games like tuxracer. Modeline configuration. Similar to xvidtune, but part of the config pExamples: xf86cfg allows me to select the order of resolutions in the Screen configuration, which changes the cycling order of the hot keys. I prefer to have <KP+> give higher resolutions and <KP-> give lower ones. Multiple screens. One for everyday work, high reosolution, 16bit screen, mostly for 2D work. An a lower resolution, high color screen for 3D games like tuxracer. Modeline configuration. Similar to xvidtune, but part of the config program. Changed/custom modelines saved in the config file. I can change the verticle refresh, hight, width, and postiton. Selections for VESA standard modes are in a menu. Configure multiple options for multiple mice. I havwe a 3 button PS/2 trackball and a 2 button USB mouse. I normaly use the track ball, but occasional use the mouse. xf86cfg allow each to be configured with seperate options. So the USB mouse has emulate 3 button options, and the trackball doesn't.rogram. Changed/custom modelines saved in the config file. I can change the verticle refresh, hight, width, and postiton. Selections for VESA standard modes are in a menu. Configure multiple options for multiple mice. I havwe a 3 button PS/2 trackball and a 2 button USB mouse. I normaly use the track ball, but occasional use the mouse. xf86cfg allow each to be configured with seperate options. So the USB mouse has emulate 3 button options, and the trackball doesn't. Current workaround is to rebuild the SRPM and xf86cfg on in the build. Then install the new package. But, how long before Mike removes the code and selection switch, and I have to use the XF86,org tarball to build it?
Each individual feature you're requesting should be individually reported in one bugzilla report per feature request. Each feature can then be individually evaluated, and if it gets implemented, the request can be closed as RAWHIDE or whatever. Having 50 requests in one bugzilla report is not feature-trackable, and either leaves the report staying open indefinitely, or getting closed as RAWHIDE prematurely. My recommendation is to file individual features in their own RFE's, and leave this report as a dependancy tracker.
Also note with rant-style bugzilla entries that I'm more inclined to make a conveinience "toggle and rebuild" feature in XFree86.spec just disappear if the people I include it cause me grief. xf86cfg is dead in Red Hat Linux. The likelyhood of it ever returning is slim. Get over it. Maintaining 50 config programs is a useless waste of time. We need ONE config tool. One that works well. Not 50. Help us make things better by using our software, reporting bugs and feature requests. Preferably without ranting. It's easier to work with polite people than negative people ranting.
Also make sure you don't duplicate the RFEs. There are alreay several.
I don't see them as "individual" RFEs though. A good configuration tool has been replaced by one with missing functions. Implement the missing features then replace it. If it was one or two sure, 2 reports. But currently it's like replacing tcsh/bash with the DOS command.com and asking for each missing part to be a seperate RFE. I'll try to file a few. But If I can do it in xf86cfg I should be able to do it in rh-cfg-xf86.
There are features that redhat-config-xfree86 has that xf86cfg doesn't, such as being useful by non-experts in Xservers. Also, we still ship both emacs and vi, so no configuration functionality has been completely removed. If you want to do something unusual (not that all of the above requests are, some are reasonable) I really don't see the advantage of xf86cfg over emacs.
Sorry Mike. I didn't mean to rant, I already did that on the beta list :) I just don't understand the direction Red Hat is going. Wouldn't it be better for Red Hat to use outside config tools where possible. Making changes/enhancements to the ones that exist instead of re-inventing the wheel over and over? I don't know the internal politics of XFree86, so it might not be possible. But I would think adding command line options for kickstart to xf86cfg would have been easier than starting from scratch. Same with adding GTK+/Qt support. I think I've seen code that supports Xt and GTK+, at least at compile time. I'm no X expert, that's Mike. Is it possible to do the xvidtune stuff in python (like rh-cfg-xf uses?) or does it require lower level access that python provides?
Mike. I don't want 50. I want one good one as well. There are lots of X options undocumented. A config tool that tells me about them would be great (like all the options for Mouse devices). And I'm just starting to look at multiple layouts and screens. That have been part of X for a while now. They are difficult to configure and even harder to use. What's the latest rh-xfg-xf86? Any new feature since 0.6.4-1? I look it over an add some RFE's for it.
The "outside" config tools _suck_. And their existance of sucking holds back tools from being created that do not suck. It's totally not open to debate. Why? Because I personally think that the creation of a single GTK based tool for X configuration that doesn't suck, is a good idea. That tool once improved via feedback and internally generated ideas will completely replace all useful required functionality of any of the bullshit crappy tools that exist prior to now. By people using the new tool, they will provide feedback on how to make it better. By supplying 50 tools, little feedback, and hence little progress will be achieved. I consider this the end of that discussion right there. It is not worthy of further discussion, and debate arguement is pointless. Nobody is going to convince me otherwise that our goal is bad of writing and maintaining the best possible X config tool we can, and making all other tools that exist now in XFree86 irrelevant. This goal is strong, and challenging. I put forth that we're up to that challenge, and we will agressively seek to meet it, and then some. If you want to debate it, or argue about it, do so with your friends, outside of bugzilla. This isn't a debate forum. Provide feature requests in bugzilla and bug reports ONLY. Once us developers have stated our opinions and goals, and plans, debating this crap with 500 people wastes our time. I'd rather put someone in my .procmailrc than waste precious time arguing crap with them that there isn't any single arguement they could come up with in 1000 years that is going to change my mind. Call me stubborn, call me an idiot, call me a jackass, call me what you will. As long as me, Alex and anyone else who cares about our goal of simple easy to use X configuration meet our goal, and flames/names/whatever make the trip worthwhile.
>I don't see them as "individual" RFEs though. They _ARE_ individual RFE's. Again, not open for debate. A feature request is ONE FEATURE, not 450. When a feature is completed, it gets closed. Simple. If you don't like that, I can just as easily CLOSED->TOUGH this one right now, and wait for reasonable people to file RFE's who are easy to have 2 way constructive communication with, and whom don't want to argue/debate every comment for 3 days. We have limited time, and limited resources. I want to get work done, and as much as possible. I'm sure Alex shares this time-thought and wants to get work done too. Arguing is pointless. Provide ideas, provide thoughts. Make one request per bug report, and be polite. Not much to ask for. Can't do that, then please, don't request anything at all. Wait for someone else who has the time and patience to do so without some personal vendetta/grudge/flamelist. I don't have the patience for this sort of stuff. >A good configuration tool has been replaced by one with >missing functions. No, a ugly non user friendly tool has been removed (xf86cfg) which barely anyone who uses Red Hat Linux ever used in the first place. Another config tool, (Xconfigurator) has been removed. It did "work" for most people in most situations, but which is an ugly hack of horrible unmaintainable spaghetti code that built up one kludge on top of another by several people over many years, whom probably didn't want to be working on the ugly crap code in the first place. Looking at the various problems common to all X configuration tools provided one list to work from. Looking at the individual problems of each individual tool provided another list. Looking at features that were missing from all of them another list. User friendliness, and a decent user interface another list. Over several releases, a lot of data was put together on what was needed for X configuration. A lot of research by several people has been done to determine what to do about all of these problems. The goal of doing something about it was a no-brainer "write a NEW config tool from scratch", and to reuse existing code that was reuseable in any sane fashion without leaving a mess of crap unmaintainable code. That is not a small task, considering all that was and is needed to be done. A lot of important decisions needed to be made, and they were made. The decision was to write a new tool with the long term goal of it being kick ass, and the short term goals of it being user friendly, and implementing the minimum functionality to get most common graphical setups up and running. The long term goal is well.... long term. The short term goal has been met fairly well right now IMHO. Is it currently perfect? No. Does it have bugs? Yes. Does it work for everyone in the world? No. Is it missing features? Yes. Do we care? Yes. What are we doing about it? A lot. We're taking a hard line stance to solve the damn ugly X configuration problem for once and for all for everyone who uses Red Hat Linux. This is a process which will not happen in one software release of redhat-config-xfree86. It will take several releases, just like any other piece of software that gets developed. Shipping multiple crap config tools, clearly would make a lot of people who experience problems with the new tool simply say "it sucks, I'll just use the old tool foocfg instead, it works", and then in fact, the new tool _would_ suck. I am aware of all of the ups and the downs of this decision. All of them. There are advantages of shipping 50 tools, and there are disadvantages of shipping 50 tools. There are advantages of shipping 1 tool, and disadvantages of shipping one tool. Knowing the advantages and disadvantages of each possible choice, and considering the goals at hand, it is without question that the choice to ship one tool that we plan on putting a LOT of effort into in the future and dropping all of the other has-been tools was the right decision for us to make for the long term, and the right decision for the short term so long as the new tool could configure working video for most users within reason. It is not an uber-hacker tool, and it isn't horribly advanced to be able to configure every single XFree86 option known to man. Every thought that could be thought about this, WAS thought. By me at least. The decision to drop Xconfigurator was simple. Every Red Hat user who has ever used Red Hat Linux since the beginning of Xconfigurator would instinctively look for that program, and not know about or use the new tool except maybe by accident. Xconfigurator is unmaintainable, and crap code. Impossible to fix a lot of the crap bugs in it without a lot of work. It is horribly bloated and the time spent maintaining it at all anymore is time taken away from the new config tool. So, Xconfigurator is gone. The other tools are used by few people because most people used Xconfigurator anyway. It is impossible to please every person in the world, and if you try, you will fail. I learned that a long time ago. And shipping 50 config tools that do the same thing, is trying to please everyone in the world, and leaving Linux stuck in 1980. Time for change. Time to improve the situation. Does that piss off some people? Perhaps it does. Hopefully they'll see the light, see the good intentions of change, and see the long term goals of a Linux operating system that grandma can use. Perhaps they'll realize that these goals require some personal preference sacrifices, and that some things take time to change, to get implemented, to be extremely high quality. So yes, I realize the ups and downs, the advantages and disadvantages, and whatnot of these decisions. Only if one MAKES a decision, and stands firmly by that decision in the persuit of their goals, will they reach them. I hope Red Hat Linux users see these types of things as decisions made to strengthen Linux and open source usage, and to make the Red Hat Linux experience one that can rival popular mainstream operating systems from Redmond. I hope people will set aside their personal rant-of-the-day about missing-feature-foo and bug-bar, and will see the light, and report problems properly, and make feature requests properly. That way we can do our jobs, and not have to write pocket novels in bug reports and have to continuously counter every Red Hat is evil for reason foo and bar conspiracy theory that comes up every 5 minutes. The more people keep these change is bad attitudes, the longer Linux stays stuck in 1980, and the longer it takes for any useful things to happen. </RANT> >Implement the missing features then replace it. No. I've already stated this is unacceptable. People wont use it, they'll use what they're used to, because they're used to it. Then it doesn't get well tested, and the rest of the people who use it wont use it because it is buggy crap. Well, had I not removed Xconfigurator and xf86cfg, I believe 100% that redhat-config-xfree86 will in the end have shipped with a LOT more bugs than it has now, and possibly a lot less features than we'll have added before final release. This was aparent to me due to all the rawhide Xconfigurator bug reports being received. So, a decision was made. It's done. It isn't changing. The decision was the right one, and Alex has done a remarkable job of making the new tool kick some serious first generation config tool butt. >If it was one or two sure, 2 reports. But currently it's like >replacing tcsh/bash with the DOS command.com and asking for >each missing part to be a seperate RFE. Tough luck then. Either request them individually if you care, or don't bother at all. Recompile XFree86 and get the tools you want, or use some other distro. I don't care. I want Red Hat Linux to rock, and I want our software to be useable to all users. I also want us to be able to write as much software as we can between releases, and to be able to fix as many bugs as we can in our software and in other software we ship between releases. By shipping 450 programs that do the same thing, those goals are not met. You can either work with us in our goals to provide you with high quality software, and report bugs PROPERLY to us, and request features PROPERLY to us, or you can work against us, and reduce the amount of resources we have available to develop software to (hopefully) meet your needs. Unfortunately, out of 10 decisions made in a day, I have to debate and/or justify them to 300 users and I'm quite frankly getting sick of the drawn out procedure. I want to get more work done, and do so in less time, with less idle chatter/debate/waste of time. I'd rather just ignore people who can't provide positive constructive feedback in a manner which saves me time (such as the requested one feature/bug per report) than to bother with them at all. If someone cant file a report properly, and work with me, I'd rather they not do so at all. If their problem report or feature request was indeed useful, and popular, sooner or later, someone else will file the report properly. And there is always WAY more than enough work to go around without writing pocket novels like this every time someone decides to have an endless pointless debate over some issue. Please lets let this pointless charade to rest. All sides of the discussioin are spoken and everyone knows where everyone stands. Lets now contribute to the solution how best each of us can, either by writing code, or filing proper bug reports and feature requests, and not hassling developers. </rant2>
>They _ARE_ individual RFE's. Again, not open for debate. The most important to me were added as new, or extended an existing bug thay would be fiexd with the feature. >The goal of doing something about it was a no-brainer "write a >NEW config tool from scratch", and to reuse existing code that >was reuseable in any sane fashion without leaving a mess of crap >unmaintainable code. Great. I Agree that from scratch is a viable way to go. As I said. I don't follow X code. If you say it is better to startover, instad of fix extend other work, fine. >Please lets let this pointless charade to rest. All sides of the >discussioin are spoken and everyone knows where everyone stands. Again, I concurr. See private mail, sent prior to last comments. See also #72803, 72067, and 74132