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

RPM Fusion Bugzilla noreply at rpmfusion.org
Sun Jan 4 20:34:30 CET 2009


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





--- Comment #16 from Stewart Adam <s.adam at diffingo.com>  2009-01-04 20:34:30 ---
(In reply to comment #14)
> Which is not much useful, as the user can only use drivers that support the
> installed hardware. IOW: even if he has a GPU that supported by the 173 drivers
> and later then he can only use the 173 drivers if one of the cards he has is
> not supported by the 177 and later. 
Yup - I'll get rid of that top section and just update the "recommended driver"
radio button instead. If the two cards require an older series driver to
function correctly, then that's what the recommended button will do. 

> The tool has all the information; if there are unsupported configurations (e.g.
> one card that is only supported <=173 and one that is only supported in >=177)
> then the tool should warn and not configure the drivers, as that would render
> one of the cards unuseable.
I haven't coved that case yet, but will do for rc3. As of now it would just say
"no available drivers for your system".

> Most users won't be interested in this. They just want to use the recommended
> driver. Directly offering beta and alternate drivers just confuse users. They
> should be offered, but they should be a bit hidden.
The drivers will only appear in the list once the user has installed them, as
the xorg-x11-drv-foo package will have to place the config file into
rpmfusion-config-display's directory before it can detect and configure the
driver... So the variants will only be selectable as long as they've installed
the driver first.

> And in your latest mockup they are way to obvious. I'd even say that users will
> accidentally select the 173 drivers in your design, as it looks like you need
> to select one in that drop-down-box. 
Sorry, bug in glade - the sensitivity of the drop-down menu is set to False, so
that would be grayed it out and it would not respond to user interaction until
the user clicked the "manual" radiobutton.

> IOW: if you (for example) have five drivers to offer then use one scheme to
> present them. E.g. five radiobuttons or one drop-down box with five entries.
> Mixing the two variants will just confuse users. That why I added the checkbox
> "show beta and alternate drivers"; after checing that the radiobutton lists
> would need to be recreated and show the others as well.
Normally, I'd agree here but I think that using the dropdown for the drivers is
a better option as we don't want to confuse users with a bunch of radio buttons
(all labeled nvidia-this and nvidia-that)... With three these radio buttons,
the user has a clear choice between the default driver, the recommended one and
if they know what they're doing, then they can move to the manual list.

> Maybe a second, small app that creates a pop-up right after logging in?
A small rpmfusion applet would be useful... maybe we could integrate this with
all kmods? Anyways, that's something we can figure out after this is done.

(In reply to comment #15)
> Do we maybe have any experts in UI design on rpmfusion-developers-list that
> could help out here to suggest/create a clean design?
Any comments are welcome!


-- 
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