|
Bugzilla – Full Text Bug Listing |
| Summary: | software repositories: sources and debug are refreshed but disabled | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | macias - <bluedzins> |
| Component: | YaST2 | Assignee: | Ladislav Slezák <lslezak> |
| Status: | RESOLVED INVALID | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Minor | ||
| Priority: | P4 - Low | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
macias -
2009-01-15 17:18:29 UTC
Source and debug repos are disabled by default because they are needed only for special purposes (debugging, rebuilding from sources...). Autorefresh status is irrelevant, only enabled repositories are autorefreshed. Autorefresh is by default on so you can simply enable the repository (one click instead of two). In such case it is HIG violation -- they can be enabled but the checkboxes should be grayed out, since their settings are no longer relevant. Reopening. Hm, that would prevent me from disabling autorefresh for disabled sources. I have several disabled repositories and I want to disable autorefresh for them (when I later enable them autorefresh will be already off so I won't have to bother about that) - I would have to: 1) enable repo, 2) disable autorefresh, 3) disable repo back for each repo. It might sound strange but I already have done that several times. Martin, what is your opinion? Maciej: which HIG are you talking about? Sorry, not the HIG -- something more fundamental, meaning of the checkbox (part of the UI) itself. You can of course look for any definition of it, but just in case, one of many: "When a check box contains a checkmark, the function is "enabled," which means it is turned on and active. When the box is empty, the option is not active (disabled)." OK, maybe this definition is true for other cases but in YaST this issue is handled differently: check boxes are always enabled regardless whether they are checked or unchecked. Oh, so you are "simply" reinventing the checkbox. Of course for years, the most important advantage of GUI was consistent behaviour and meaning, but changing the well established meaning can be fun.
Everywhere, except yast.
on --> on
off -> off
in yast
on --> well, it depends, read manual if it is really on
off --> read manual too, you need to figure out the dependencies
> check boxes are always enabled regardless whether they are checked or
> unchecked.
I didn't say a word about this. I said, that if the "parent" widget is off, thus the state of the checkbox is irrelevant, it should be disabled to notify the user about true meaning.
Currently it only misinforms the user, but as I said, it may be fun, to surprise the user or force him/her to study manuals.
|