Bug 74121 - rh-cfg-xf86 missing functionality
Summary: rh-cfg-xf86 missing functionality
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: redhat-config-xfree86
Version: null
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-16 15:01 UTC by Thomas Dodd
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-09-17 00:20:54 UTC
Embargoed:


Attachments (Terms of Use)

Description Thomas Dodd 2002-09-16 15:01:18 UTC
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?

Comment 1 Mike A. Harris 2002-09-16 15:39:16 UTC
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.


Comment 2 Mike A. Harris 2002-09-16 15:51:48 UTC
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.




Comment 3 Alexander Larsson 2002-09-16 15:53:28 UTC
Also make sure you don't duplicate the RFEs. There are alreay several.


Comment 4 Thomas Dodd 2002-09-16 15:59:01 UTC
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.

Comment 5 Alexander Larsson 2002-09-16 16:08:17 UTC
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.


Comment 6 Thomas Dodd 2002-09-16 17:57:45 UTC
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?


Comment 7 Thomas Dodd 2002-09-16 18:13:05 UTC
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.


Comment 8 Mike A. Harris 2002-09-16 22:59:03 UTC
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.



Comment 9 Mike A. Harris 2002-09-16 23:42:34 UTC
>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>




Comment 10 Thomas Dodd 2002-09-17 00:20:48 UTC
>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



Note You need to log in before you can comment on or make changes to this bug.