[Bug 171] Review Request: rpmfusion-config-display - tool to manage proprietary graphic drivers

RPM Fusion Bugzilla noreply at rpmfusion.org
Mon Jan 5 21:01:03 CET 2009


http://bugzilla.rpmfusion.org/show_bug.cgi?id=171





--- Comment #23 from Stewart Adam <s.adam at diffingo.com>  2009-01-05 21:01:02 ---
(In reply to comment #21)
> No; it IMHO definitely should be part of the driver package and completely auto
> generated there. Maintaining such a package manually sounds way to complicated
> to me -- especially when it comes to people that mix packages from updates,
> updates-testing or other repos (rawhide, external)
The config files can't be autogenerated, as they'll change from release to
release (for example, the past 2 versions of fglrx require a Screen section
while the previous releases didn't) and they include the PCI IDs of the
supported hardware as well... I mean, either way something has manual, but with
this setup we'll be changing an option in the config file instead of changing
the initscripts or foo-config-display scripts all the time.

> > One problem we would have to work out ahead of time is how to determine when a
> > driver is installed... We can check for our drivers via rpm-python, but say the
> > user installs from nvidia.com.
> 
> Then he IMHO is own his own; improving our stuff and making things as easy as
> possible is IMHO way more important then supporting corner cases that have
> known downsides.
Agreed, but if we can easily have a way to do it I don't see why we shouldn't.
I'll have to do a bit more testing, but I think the config flag should work.
(In reply to comment #22)
> (In reply to comment #21)
> > > I'm jumping back and forth here, but I've scanned through the Gnome HIG and it
> > > would be acceptable to use a drop-down menu or radio buttons. I think we should
> > > use a drop-down menu since we have no way of predicting what we need to
> > > display.
> > 
> > As mentioned on IRC: I dislike a "drop-down menu" solution, as you can't see 
> > directly what options are available. You instead and to create on the drop-down
> > box, which is error-prone. 
> 
> the last sentence got corrupted. What I wanted to say:
> 
> To see all available choices you have to click on the drop-down box; that
> afaics is error-prone, as one afaics sometimes accidentally changes the setting
> when doing that. At least it happened to me a few times in the past when I
> clicked on similar drop-down boxes just to see the available options.
> 
It's just as easy to hide the menu items as checkbuttons, either way it's just
an "if" check in the loop which adds the widgets/menu items.

I mean it's not a huge deal, but I just think that if we're trying to avoid
clutter and make things simple, let's not present 6+ button to the users at all
unless they want to see them, which is when they click on the Manual radio
button so they can see their options in the the menu. The menu itself will have
a "-- Please select an item --" so that we avoid the accidental-selection
problem, and when the user clicks back on the "recommended" or "open source"
radiobuttons, the combobox's state is reset to a blank state.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the rpmfusion-developers mailing list