Forwarded from test list. ----- Forwarded Message ----- From: "John Dulaney" j_dulaney@live.com To: "Fedora QA" test@lists.fedoraproject.org Sent: Sunday, June 5, 2011 8:28:45 PM Subject: RE: Proposal: Too similar application names
That all said, question remains on what to actually do on this. In a long term I'd suggest trying advocate that there is a appropriate solution based in the upstream, might it be pop-ups (sounds reasonable to do for all the desktop environments) or something based on how KDE does it. Although having upstream to do something is, like I said - long term. Thus let's decide on what to do about this now.
I'd say that a number of cases this relates to is limited to a fairly small number. I am counting:
- Software Update/Software Updates
- System Monitor
- Terminal
- system-config-(e.g. date) vs. gnome control panel applets
(and likely a few more).
As a compromise between getting rid of the problem (user annoyance...) completely and the amount of work that would have to be done, I suggest that we simply target these applications and modify the desktop files so that they become distinguishable. That means in the menus and on the first sight, whatever *.desktop field is responsible for that in particular environments. Should we manage to push having a popup in Upstream, that would be great later on.
I agree, this is a good starting point. I don't really see the point of the popups, but if other folks think they're necessary, I won't argue.
Now, should we agree on this quickfix now, how to do that? Am I right that this would mean asking the maintainers of these cca 10 packages to change the *.desktop files in the packaging process? Do the *.desktop files come from upstream or are they made or at least modified already by Fedora? I suppose it would be better if they already get modified, as then the single extra edit would be less painful for maintainers. Still - sounds relatively painless.
In theory, the technical side should be a thirty second fix. The issue would be deciding new names. Some things shouldn't be too difficult, such as renaming Software Updates to Software Sources.
We can also consider making a simple (e.g. targeting just default live installs) release criterion that would "force" such, though I'd think having it done on "voluntary" basis is more appropriate.
I wonder if this should be a QA test? It would help with improving the end product for us to check things like this, but it is also fairly subjective as to what constitutes as 'too similar.' I'm for it, but the aforementioned subjective nature makes coming up with a clear release criteria difficult.
John.
On Mon, 2011-06-06 at 06:14 -0400, Vitezslav Humpa wrote:
As a compromise between getting rid of the problem (user
annoyance...)
completely and the amount of work that would have to be done, I
suggest
that we simply target these applications and modify the desktop
files
so that they become distinguishable. That means in the menus and on
the
first sight, whatever *.desktop field is responsible for that in
particular
environments. Should we manage to push having a popup in Upstream,
that
would be great later on.
I agree, this is a good starting point. I don't really see the point of the popups, but if other folks think they're necessary, I won't argue.
Just as a note on this one, I found that a bug is already filed for the most infamous case, Software Update / Software Updates:
https://bugzilla.redhat.com/show_bug.cgi?id=702772
and has been passed on to upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=649823
I hope Richard will be able to get to that soon.
That leaves terminal / Terminal, and all the system-config-* vs. control-center components (things like Date & Time are identical between the two). That seems a larger problem than just the menu entries, though. There's kind of a demarcation question here; GNOME seems to have decided various settings should be controlled by the desktop, and Fedora probably needs to decide where it stands on that, whether all our other desktop environments agree, and how to deal with overlapping tools for such settings from all standpoints, not just menu entries. Where we agree that something should be handed off from s-c-* to desktop control, we should check on the current status of what the s-c-* app is capable of and whether the GNOME app can do all the same stuff, and whether the other desktops make it possible to deal with the same settings, I guess.
(I wonder if it might be good for there to be a cross-desktop list within Fedora, for things that concern all desktop environments? This cross-posting gets unwieldy.)
On Mon, 2011-06-20 at 17:27 -0700, Adam Williamson wrote:
Just as a note on this one, I found that a bug is already filed for the most infamous case, Software Update / Software Updates:
https://bugzilla.redhat.com/show_bug.cgi?id=702772
and has been passed on to upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=649823
I hope Richard will be able to get to that soon.
That leaves terminal / Terminal,
Filed a bug for this one:
https://bugzilla.redhat.com/show_bug.cgi?id=714835
https://bugzilla.gnome.org/show_bug.cgi?id=649823
I hope Richard will be able to get to that soon.
It's great that stones are moving on this one! It's been the most obvious one. Did you bring this to Richard already or should I reach him? Not sure now :)
That leaves terminal / Terminal, and all the system-config-* vs. control-center components (things like Date & Time are identical between the two). That seems a larger problem than just the menu entries, though. There's kind of a demarcation question here; GNOME seems to have decided various settings should be controlled by the desktop, and Fedora probably needs to decide where it stands on that, whether all our other desktop environments agree, and how to deal with overlapping tools for such settings from all standpoints, not just menu entries. Where we agree that something should be handed off from s-c-* to desktop control, we should check on the current status of what the s-c-* app is capable of and whether the GNOME app can do all the same stuff, and whether the other desktops make it possible to deal with the same settings, I guess.
I went through config utilities across different environments. In some cases definitely the s-c-* are being relied to for configuration completely, notably in cases of LXDE and Xfce too. Sometimes they overlap with the desktop environment specific utilities, but do the configuring in different scopes - e.g. s-c-keyboard will set the global system layout while xfce4 keyboard settings does it session-wise. Well, I'd say there is no point discussing the future of s-c-* utilities in respect to these environments, they are needed.
Gnome(and KDE), perhaps with some exceptions, seem to cover s-c-* options rather well. I think we should consider simply removing the conflicting s-c-* from the menus altogether, thus getting rid of the duplicity. Should the user need to access these particular s-c-* utilities, they will still be present in the system.
These are the ones, that are duplicate to the gnome-control-panel tools: system-config-date (Date & Time vs. Date and Time) system-config-printer (Printing vs. Printers) system-config-users (Users and Groups vs. User Accounts)
Thoughts?
(I wonder if it might be good for there to be a cross-desktop list within Fedora, for things that concern all desktop environments? This cross-posting gets unwieldy.)
+1, with danger of not too many people subscribing for it which could bring back the need to "cc" again
-- Vita Humpa Fedora QA
On Thu, 2011-06-23 at 11:50 -0400, Vitezslav Humpa wrote:
Gnome(and KDE), perhaps with some exceptions, seem to cover s-c-* options rather well. I think we should consider simply removing the conflicting s-c-* from the menus altogether, thus getting rid of the duplicity. Should the user need to access these particular s-c-* utilities, they will still be present in the system.
These are the ones, that are duplicate to the gnome-control-panel tools: system-config-date (Date & Time vs. Date and Time) system-config-printer (Printing vs. Printers) system-config-users (Users and Groups vs. User Accounts)
Thoughts?
Need to check that the GNOME / KDE tools can set these things system-wide (usually done via PolicyKit integration I think), but in principle, yes. Well, rather than remove them from the menus, we could make them NotShowIn (or whatever the keyword is) GNOME and KDE. Desktop / KDE teams, wdyt?
On Thu, 2011-06-23 at 09:59 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 11:50 -0400, Vitezslav Humpa wrote:
Gnome(and KDE), perhaps with some exceptions, seem to cover s-c-* options rather well. I think we should consider simply removing the conflicting s-c-* from the menus altogether, thus getting rid of the duplicity. Should the user need to access these particular s-c-* utilities, they will still be present in the system.
These are the ones, that are duplicate to the gnome-control-panel tools: system-config-date (Date & Time vs. Date and Time) system-config-printer (Printing vs. Printers) system-config-users (Users and Groups vs. User Accounts)
Thoughts?
Need to check that the GNOME / KDE tools can set these things system-wide (usually done via PolicyKit integration I think), but in principle, yes. Well, rather than remove them from the menus, we could make them NotShowIn (or whatever the keyword is) GNOME and KDE. Desktop / KDE teams, wdyt?
I would really rather they weren't installed at all, but that would do fine in the meanwhile.
On Thu, 2011-06-23 at 18:21 +0100, Bastien Nocera wrote:
Need to check that the GNOME / KDE tools can set these things system-wide (usually done via PolicyKit integration I think), but in principle, yes. Well, rather than remove them from the menus, we could make them NotShowIn (or whatever the keyword is) GNOME and KDE. Desktop / KDE teams, wdyt?
I would really rather they weren't installed at all, but that would do fine in the meanwhile.
Well, I don't see why we shouldn't do both. Don't install 'em by default for GNOME and KDE spins, *and* make 'em NotShowIn desktops where they're not really needed, so that if people install them for use in Xfce or LXDE or whatever, they don't show up in GNOME or KDE.
Need to check that the GNOME / KDE tools can set these things system-wide (usually done via PolicyKit integration I think), but in principle, yes. Well, rather than remove them from the menus, we could make them NotShowIn (or whatever the keyword is) GNOME and KDE. Desktop / KDE teams, wdyt?
I would really rather they weren't installed at all, but that would do fine in the meanwhile.
I wouldn't remove them completely *just yet* at least for the GNOME spin - as the s-c-* utilities offer little extra configurability not provided by the control panel applets yet (I checked for the 3 menu-duplicate items in particular), though generally they seem to intersect nicely(but not completely) both in features and scope. Additionally there are also some dependencies to them (notably anaconda and firstboot for s-c-date, s-c-users and s-c-keyboard...)
When it comes to KDE spin, I see no point in keeping them as systemsettings currently provides for then just fine. Exception being again s-c-* needed for firstboot.
Well, I don't see why we shouldn't do both. Don't install 'em by default for GNOME and KDE spins, *and* make 'em NotShowIn desktops where they're not really needed, so that if people install them for use in Xfce or LXDE or whatever, they don't show up in GNOME or KDE.
Definitely. I will try out how the NotShowIn / OnlyShowIn works in practice in different desktop environments.
Vitezslav Humpa wrote:
I wouldn't remove them completely *just yet* at least for the GNOME spin - as the s-c-* utilities offer little extra configurability not provided by the control panel applets yet (I checked for the 3 menu-duplicate items in particular), though generally they seem to intersect nicely(but not completely) both in features and scope. Additionally there are also some dependencies to them (notably anaconda and firstboot for s-c-date, s-c-users and s-c-keyboard...)
When it comes to KDE spin, I see no point in keeping them as systemsettings currently provides for then just fine. Exception being again s-c-* needed for firstboot.
Well, KDE settings are usually NOT systemwide (except for parts of date&time).
Kevin Kofler
-
Adam Williamson -
Bastien Nocera -
Kevin Kofler -
Vitezslav Humpa