Re: Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Mon, Jul 25, 2011 at 4:36 PM, Martin Gräßlin wrote: > On Monday 25 July 2011 15:57:16 Ben Cooksley wrote: >> > >> >> Otherwise our users will be the ones who will suffer. >> > >> > I really doubt anyone is going to 'suffer'... This NamingClashCrisis is >> > more >> >> They will. As an example, KMyMoney users for instance depend on System >> Settings to be able to set their locale, and therefore the default >> currency, date format, etc. > In that case KMyMoney has to depend on systemsettings and has to become a > workspace > application which I think the workspace coordinators will rightfully refuse. > If this is a must have > configuration for KMyMoney it has to add the KCM to its own configuration > options. In > comparison you are also able to configure Phonon from within Amarok. > > If you think that systemsettings is a required runtime dependency for other > applications, then > systemmsettings should move from kde-workspace to kde-runtime. I didn't choose it to be a runtime dependency. Ideally it wouldn't have to be. It became a "defacto" requirement as applications for KDE are usually developed under KDE, therefore developers don't know to add all the needed panels to their application. Whilst the panels themselves are mostly part of runtime - many users aren't capable of using kcmshell4 - so need to use System Settings. Regards, Ben
Re: Formal complaint concerning the use of the name "System Settings"
> The only point that I would like to add is that the 'System' part of
> System Settings should be dropped since the settings listed there are
> not for the system but for the DE('s).
Well it depends, Networking Bluetooth, Service startup are not DE('s) stuff
Re: Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Monday 25 July 2011 15:57:16 Ben Cooksley wrote: > > > >> Otherwise our users will be the ones who will suffer. > > > > I really doubt anyone is going to 'suffer'... This NamingClashCrisis is more > > They will. As an example, KMyMoney users for instance depend on System > Settings to be able to set their locale, and therefore the default > currency, date format, etc. In that case KMyMoney has to depend on systemsettings and has to become a workspace application which I think the workspace coordinators will rightfully refuse. If this is a must have configuration for KMyMoney it has to add the KCM to its own configuration options. In comparison you are also able to configure Phonon from within Amarok. If you think that systemsettings is a required runtime dependency for other applications, then systemmsettings should move from kde-workspace to kde-runtime. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Mon, Jul 25, 2011 at 12:37 PM, Friedrich W. H. Kossebau wrote: > Dimanche, le 24 juillet 2011, à 23:07, Ben Cooksley a écrit: >> Dropping GNOME out of this, as it seems quite clear they aren't >> interested in co-operating at all. Which is fairly typical for them, >> they're insular and only care for themselves. > > This is quite insulting, I do not think many share your broad accusations, I > least I hope not many do. > > Sorry, Ben, but someone who names his program with that general term "System > settings" and expects it to have this name in all of the shells/workspaces > (Gnome Shell, Unity, XFCE, Enlightenment, $WINDOWMANAGER, even in Windows and > OS X?), while it only basically controls settings of the KDE runtime > env/platform, is at least also one who is insular and only cares for himself > (or his workspace), no? Think about it. At least to me System = > Shell/Workspace or OS/Computer even. I didn't choose the name. It was chosen a long time ago, when KDE 4.0 was originally forged. I rewrote it to add features, and became maintainer around KDE 4.2. I kept the original name to avoid changing things, and therefore creating user criticism. I have already been criticised for changing the layout of modules in System Settings. I am fairly sure that changing it's name would bring similar criticism. > > And with my user hat on I would think this "Linux" is utterly shitty if I have > to use different setting programs for all the existing toolkits out there, to > do the same settings again and again. > I am only looking out to also see Tcl Settings, EFL Settings, Gnustep > Settings. Perhaps also some Motif Settings, to be old-school. Perfect! Not. I haven't written any of the modules. I just know what is actually the case. > > If Joe user uses Unity and wants to use that hex editor Okteta someone > recommended to him, would/should he need to know about "KDE" and that Okteta > is implemented based on another toolkit than most of the default programs? > I say No, and guess most users don't care as well (unless "toolkit racists"). > And thus he should also not need to know he has to use that other "System > Settings" then the general system settings. > >> In any case, we need a short term solution to this. Basically, we are >> going to have to provide a different name under GNOME, because >> otherwise GNOME users will complain to distros, who will patch GNOME >> to ignore System Settings (I refuse to acknowledge their app). > > Well, the two desktop file solution might work, no? Name it "KDE System > Settings" or similar for non-Plasma envs in one file, and "System Settings" > for Plasma envs in the original one. Make that other file a patch for 4.7.1. > Or did I miss something? I already said it would. However certain people have complained that this violates the branding, as "KDE" is the community rather than the product. > >> A long term solution > > ... is to continue all the work that has been done to share as many settings > as possible, and to support running programs in not-the-native environments, > ideally without the need for a separate settings program for the toolkit in > use, using some sane defaults there if needed. > A big thanks for everyone who has done before or/and keeps pushing on this, > like Aurélien with the "kdeui/kernel: Use platform palette and fonts" commit > only last friday. Of course that is the proper solution. Assuming they comply as well, so their apps follow our settings in a KDE Workspace. > > And otherwise I completely agree with Cornelius. > > Cheers > Friedrich > -- > Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Mon, Jul 25, 2011 at 12:26 PM, marcel partap wrote: >> KDE 4.7 will probably be shipped by distributions alongside GNOME 3.0. >> A short term solution is required at the bare minimum to fix that - >> which can be done as I noted. > > Where's the problem? Have the release tarballs already and irrevocably been > forged and fed into some unstoppable mechanism? Per the KDE Release Schedule, we are frozen for everything except build compilation failures, as the KDE 4.7.0 release process is underway. > >> On 23/07/11 00:25, Shaun McCance wrote: >>> >>> Name=System Settings >>> OnlyShowIn=KDE >>> >>> The other looks like this: >>> >>> Name=KDE System Settings >>> NotShowIn=KDE > > Why not just SVN_SILENTly add these tree lines in the .desktop file and > include in 4.7 gold? Two more days seem to give plenty time for that. That is a violation of the release schedule. See above. The translation freeze started a long time ago. > >> Otherwise our users will be the ones who will suffer. > > I really doubt anyone is going to 'suffer'... This NamingClashCrisis is more They will. As an example, KMyMoney users for instance depend on System Settings to be able to set their locale, and therefore the default currency, date format, etc. > ridiculous ego tussle then a real problem. For comparison, hunger crisis in > Somalia is a real problem where people actually do suffer. > #peace/marcel. > Regards, Ben
Re: Formal complaint concerning the use of the name "System Settings"
On 23 July 2011 15:20, Ambroz Bizjak wrote:
> Mark wrote:
>> Just a small suggestion on how i think this should be "fixed" (since 2
>> desktop files for one app seems just ugly to me).
>> Perhaps it's better to extend the desktop file specification:
>> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
>>
>> And i would propose adding 2 entries:
>> NativeDE - This one holds the desktop environment name where the app
>> would be "native". So GNOME, KDE or whatever.
>> NameNonNative - This one holds the app name when it's shown in a
>> desktop environment that is not native. When not set fallback to
>> "Name"
>>
>> So for example the "System Settings" app in KDE looks somewhat like
>> this in a .desktop file:
>>
>> Name=System Settings
>> NativeDE=KDE
>> NameNonNative=KDE System Settings
>>
>> The same applies for gnome system settings and also for the system
>> monitor (that also has the naming issue)
>> Isn't this a good solution?
>>
>> Regards,
>> Mark
>
> I think this is the right idea - have a generic name and a
> native-desktop-specific name. But I think it could be implemented more
> nicely. I suggest the following:
>
> Name=KDE System Settings
> KDE-Name=System Settings
>
> Name=Gnome System Settings
> Gnome-Name=System Settings
>
> This would be a little easier to implement, and has the advantage that
> the non-native name will be used for any DE that doesn't specifically
> know about the "extension". For example, in Xfce, you will get "KDE
> System Settings" and "Gnome System Settings" without Xfce having to
> implement anything; with Mark's suggestion however, Xfce would give
> you two "System Settings" until it was patched.
I agree completely. And with Lorenz idea (and other's idea) to have a
unified backend that offers one control panel/system settings this
problem can be solved and interoperability between different DE's can
be made more efficient.
The only point that I would like to add is that the 'System' part of
System Settings should be dropped since the settings listed there are
not for the system but for the DE('s).
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Dimanche, le 24 juillet 2011, à 23:07, Ben Cooksley a écrit: > Dropping GNOME out of this, as it seems quite clear they aren't > interested in co-operating at all. Which is fairly typical for them, > they're insular and only care for themselves. This is quite insulting, I do not think many share your broad accusations, I least I hope not many do. Sorry, Ben, but someone who names his program with that general term "System settings" and expects it to have this name in all of the shells/workspaces (Gnome Shell, Unity, XFCE, Enlightenment, $WINDOWMANAGER, even in Windows and OS X?), while it only basically controls settings of the KDE runtime env/platform, is at least also one who is insular and only cares for himself (or his workspace), no? Think about it. At least to me System = Shell/Workspace or OS/Computer even. And with my user hat on I would think this "Linux" is utterly shitty if I have to use different setting programs for all the existing toolkits out there, to do the same settings again and again. I am only looking out to also see Tcl Settings, EFL Settings, Gnustep Settings. Perhaps also some Motif Settings, to be old-school. Perfect! Not. If Joe user uses Unity and wants to use that hex editor Okteta someone recommended to him, would/should he need to know about "KDE" and that Okteta is implemented based on another toolkit than most of the default programs? I say No, and guess most users don't care as well (unless "toolkit racists"). And thus he should also not need to know he has to use that other "System Settings" then the general system settings. > In any case, we need a short term solution to this. Basically, we are > going to have to provide a different name under GNOME, because > otherwise GNOME users will complain to distros, who will patch GNOME > to ignore System Settings (I refuse to acknowledge their app). Well, the two desktop file solution might work, no? Name it "KDE System Settings" or similar for non-Plasma envs in one file, and "System Settings" for Plasma envs in the original one. Make that other file a patch for 4.7.1. Or did I miss something? > A long term solution ... is to continue all the work that has been done to share as many settings as possible, and to support running programs in not-the-native environments, ideally without the need for a separate settings program for the toolkit in use, using some sane defaults there if needed. A big thanks for everyone who has done before or/and keeps pushing on this, like Aurélien with the "kdeui/kernel: Use platform palette and fonts" commit only last friday. And otherwise I completely agree with Cornelius. Cheers Friedrich -- Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
KDE 4.7 will probably be shipped by distributions alongside GNOME 3.0. A short term solution is required at the bare minimum to fix that - which can be done as I noted. Where's the problem? Have the release tarballs already and irrevocably been forged and fed into some unstoppable mechanism? On 23/07/11 00:25, Shaun McCance wrote: Name=System Settings OnlyShowIn=KDE The other looks like this: Name=KDE System Settings NotShowIn=KDE Why not just SVN_SILENTly add these tree lines in the .desktop file and include in 4.7 gold? Two more days seem to give plenty time for that. Otherwise our users will be the ones who will suffer. I really doubt anyone is going to 'suffer'... This NamingClashCrisis is more ridiculous ego tussle then a real problem. For comparison, hunger crisis in Somalia is a real problem where people actually do suffer. #peace/marcel.
Re: Go Daddy root certificates
On Sunday, 24 de July de 2011 14:51:34 Gary Greene wrote: > On Jul 23, 2011, at 10:33 AM, Martin Koller wrote: > > Hi, > > > > can anyone answer the case https://bugs.kde.org/show_bug.cgi?id=277319 , > > please ? > Honestly, I really wish that Mozilla/KDE/Google/Wget/ has their own root certificate store here> would get together on fdo and > create a common project that the root certificates could be aggregated at > instead of each project doing it themselves... The answer is: STOP distributing our own certificates. Rely on Qt's support, which also doesn't distribute certificates. The burden then falls on the system integrator (the distros), which will select a root CA package that they feel confident about. They're also the ones who can roll out security updates directly to the users. We can't. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
2011/7/25 Cornelius Schumacher : > On Sunday 24 July 2011 Ben Cooksley wrote: >> Dropping GNOME out of this, as it seems quite clear they aren't >> interested in co-operating at all. Which is fairly typical for them, >> they're insular and only care for themselves. > > I don't want to let a statement like this stand as it is. There are a lot of > people in the GNOME community who do want to cooperate. There certainly are > also people who don't. That's the same in our community. Not everybody cares > about cross-desktop collaboration, and this creates issues, as we have seen. In this case, they have not surfaced it seems. Only the ones who don't want to co-operate have surfaced. > > Still, we should treat each other with respect. I understand that it makes you > angry, if things break because of decisions outside your control, which you > consider to be wrong. But being angry doesn't solve problems, especially not > when communication about a common solution is required. > > There are a lot of technical things we can do to address this specific > problem, taking settings from the platform, making configuration available in > context, making KDE applications and frameworks more modular and less > interdependent. Not everything can be done easily, but we should look for the > right solutions and persue them. They will take time to implement. And can only be done in the next release anyway - assuming people work on it. KDE 4.7 will probably be shipped by distributions alongside GNOME 3.0. A short term solution is required at the bare minimum to fix that - which can be done as I noted. Otherwise our users will be the ones who will suffer. > > Additionally we need to talk about how to do integration across desktops. We > should not be content with having insular desktops, neither on the GNOME side, > nor on our side, nor anywhere else. This only limits us, how we are perceived, > and what users think what they can do with KDE software. We aren't the > monolithic desktop, which only runs KDE software, and which is required by all > KDE applications. That's exactly the misconception we are trying to get rid > of. > > So let's have a constructive conversation with GNOME and others how to share > settings, how to integrate applications running on different workspaces > independent of the toolkit they are implemented with. The desktop summit > provides a great opportunity for that. > > But again, please act with respect for your own and other communities. Being > aggressive doesn't help in finding good solutions for users, and it's really > not the atmosphere, I'd like to see in KDE. Whilst not an atmosphere I like either, the short term solution appears to have been totally rejected on both sides. How do you suggest this is solved? > -- > Cornelius Schumacher > Regards, Ben
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Still, we should treat each other with respect. [...] being angry doesn't solve problems, especially not when communication about a common solution is required. [...] Not everything can be done easily, but we should look for the right solutions and persue them. There is no established mechanism to rate mailing list posts, but i'd mod this one up. (:
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011 Ben Cooksley wrote: > Dropping GNOME out of this, as it seems quite clear they aren't > interested in co-operating at all. Which is fairly typical for them, > they're insular and only care for themselves. I don't want to let a statement like this stand as it is. There are a lot of people in the GNOME community who do want to cooperate. There certainly are also people who don't. That's the same in our community. Not everybody cares about cross-desktop collaboration, and this creates issues, as we have seen. Still, we should treat each other with respect. I understand that it makes you angry, if things break because of decisions outside your control, which you consider to be wrong. But being angry doesn't solve problems, especially not when communication about a common solution is required. There are a lot of technical things we can do to address this specific problem, taking settings from the platform, making configuration available in context, making KDE applications and frameworks more modular and less interdependent. Not everything can be done easily, but we should look for the right solutions and persue them. Additionally we need to talk about how to do integration across desktops. We should not be content with having insular desktops, neither on the GNOME side, nor on our side, nor anywhere else. This only limits us, how we are perceived, and what users think what they can do with KDE software. We aren't the monolithic desktop, which only runs KDE software, and which is required by all KDE applications. That's exactly the misconception we are trying to get rid of. So let's have a constructive conversation with GNOME and others how to share settings, how to integrate applications running on different workspaces independent of the toolkit they are implemented with. The desktop summit provides a great opportunity for that. But again, please act with respect for your own and other communities. Being aggressive doesn't help in finding good solutions for users, and it's really not the atmosphere, I'd like to see in KDE. -- Cornelius Schumacher
Re: Go Daddy root certificates
On Jul 23, 2011, at 10:33 AM, Martin Koller wrote: > Hi, > > can anyone answer the case https://bugs.kde.org/show_bug.cgi?id=277319 , > please ? > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at Honestly, I really wish that Mozilla/KDE/Google/Wget/ would get together on fdo and create a common project that the root certificates could be aggregated at instead of each project doing it themselves... -- Gary L. Greene, Jr. smime.p7s Description: S/MIME cryptographic signature
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Dropping GNOME out of this, as it seems quite clear they aren't interested in co-operating at all. Which is fairly typical for them, they're insular and only care for themselves. In any case, we need a short term solution to this. Basically, we are going to have to provide a different name under GNOME, because otherwise GNOME users will complain to distros, who will patch GNOME to ignore System Settings (I refuse to acknowledge their app). A long term solution, sharing settings isn't even counted, as they are bound to screw us over yet again in some way. They are not to be trusted. Adding the panels apps need to them isn't exactly workable either due to the number of applicable panels and apps. As was proposed earlier, System Settings would call itself "System Settings" under KDE, but would prefix "KDE" to the name under all other environments. ie. KDE System Settings under xfce. I have recieved objections that this collides with the "branding policy" however. Given such an objection, what do those of you who object propose? A solution must be reached, otherwise it is the users of our applications who will ultimately suffer - and we will probably get blamed for it. Regards, Ben Cooksley System Settings Maintainer
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Le 24/07/2011 17:11, Emmanuele Bassi a écrit : > GTK+ applications use the XSETTINGS keys: > > http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html > > so every key that is shared using that specification is picked up > automatically by GTK+ applications. > > we can definitely talk about extending the set of shared keys: we > routinely do that on xdg-list -- for instance when the sound theme > spec was introduced. The spec does not provide a list of shared keys, does such a list exist? If there is no such list I don't see how we could share anything. I don't know what is shared right now but it is definitely not enough: a GTK application running on a KDE workspace does not follow KDE keybindings, palette, fonts, icon theme, label alignment or dialog button order. Additionally I don't believe a shared keys system is enough to share a widget theme. Otherwise the Oxygen devs probably wouldn't have created the Oxygen GTK theme. >> Do they use kwallet instead of gnome-keyring? > > applications using the org.freedesktop.Secrets API will ask for the > well-known bus name, and get to talk to the daemon implementing it; > that means using the gnome-keyring daemon or kwallet, depending on > which is installed. the same mechanism of auto-activation is used for > many other things. Unfortunately kwallet does not implement org.freedesktop.Secrets yet as far as I understand it. I was also under the impression that the spec was not ready, since its version number is "0.1 DRAFT". Aurélien
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011, Olav Vitters wrote: > On Sun, Jul 24, 2011 at 01:38:34PM +0200, Martin Sandsmark wrote: > > My two cent is that Gnome should rename it's configuration > > application to something that reflects what it is, instead of > > stealing the name from the KDE system configuration application. > > I've already mentioned in the first reply that I'd appreciate a > polite discussion. I think that was enough warning. As moderator of kde-core-devel I fully agree. Please keep the discussion constructive. As user I wish that you get together during the Desktop Summit and come up with a solution/plan for joined system settings which can be edited on each desktop with the corresponding system settings app. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Le 24 juil. 2011 14:35, "Aurélien Gâteau" a écrit : > Le 24/07/2011 12:55, Giovanni Campagna a écrit : >> Which is a KDE bug. You should use GNOME shortcuts when possible. I >> mean, Gtk has emacs and Mac OS modes for keybindings, I doubt Qt hasn't >> something similar. > > >> It is true that you can change KDE theme without changing the GTK one, >> but why would one want that? I want the look and feel of my system to be >> consistent, even when different apps or toolkits are used, and I want >> one place to configure the theme. >> (or none, if I'm using GNOME3 ) > > >> KDE apps under GNOME should use gnome-keyring, not kwallet: that's what >> org.freedesktop.Secrets is for. > > > What about the other way around BTW? Do GNOME applications running on a > KDE workspace follow KDE keybindings, theme, palette, fonts and icon > theme? Do they use kwallet instead of gnome-keyring? If they don't I > guess there is also a use for running GNOME System Settings on a KDE > workspace. Well, I wrote xsettings-kde http://svn.mandriva.com/viewvc/soft/theme/xsettings-kde/ in 2007 which exports kde settings as xsettings and causes GNOME/GTK applications to follow KDE settings. Unfortunately, this code has never been integrated in KDE... -- Frédéric Crozat
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
hi; 2011/7/24 Aurélien Gâteau : > What about the other way around BTW? Do GNOME applications running on a > KDE workspace follow KDE keybindings, theme, palette, fonts and icon > theme? GTK+ applications use the XSETTINGS keys: http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html so every key that is shared using that specification is picked up automatically by GTK+ applications. we can definitely talk about extending the set of shared keys: we routinely do that on xdg-list -- for instance when the sound theme spec was introduced. > Do they use kwallet instead of gnome-keyring? applications using the org.freedesktop.Secrets API will ask for the well-known bus name, and get to talk to the daemon implementing it; that means using the gnome-keyring daemon or kwallet, depending on which is installed. the same mechanism of auto-activation is used for many other things. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
hi; On 24 July 2011 10:00, Ben Cooksley wrote: >> the short-term fix is to make the KDE system settings OnlyShowIn=KDE, >> so that users running KDE will not have any issue, and every other >> desktop will correctly not show the KDE system settings shell. > > Wrong. Emmanuele, read my initial email to see why that is not an > acceptable solution under any circumstances. > It has to be shown in some form, regardless of the name, under all > desktop environments. this is utterly ridiculous. you're saying that anyone using a KDE application should also install the KDE system settings shell because it is the only way to configure KDE *applications*? Qt, like GTK+ uses the same XSETTINGS protocol, to allow interoperability between toolkits on the same environment -- that's what we use to bridge stuff like the icon theme, the application font name, and other settings shared across desktops. this is no more a simple matter of user-facing names: your position is that only the KDE system settings can change those settings; this is factually wrong, and ignores what's been done in the past 10 years to allow interoperability between toolkits and environments. if we want to add new shared XSETTINGS key we can definitely talk about that; forcing the hand of users and saying that you require KDE system settings, and the half of KDE they string along, to configure a KDE application is not an acceptable solution in any scenario -- unless you start making every single KDE application strictly depend on the KDE system settings package. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011 20:27:58 Martin Gräßlin wrote: > On Sunday 24 July 2011 14:12:21 Aurélien Gâteau wrote: > > If there is no need for KDE System Settings on a Gnome desktop, then > > adding a OnlyShowIn=KDE; key to the desktop file would be appropriate. > > If on the other hand there is a need for KDE System Settings on a Gnome > > desktop, then Shaun solution is correct IMO and we should start to think > > about adding support for OnlyShowIn to KCM desktop files, because it > > makes no sense for example to be able to define Plasma Desktop wallpaper > > when running on Gnome. > > Technically seen systemsettings lives in kde-workspace which means it is > only relevant to the KDE Plasma Workspaces. Non Workspace applications > should not depend on its availability and if they require it, I would > consider this as an application bug. E.g. the mentioned kinfocenter is a > Workspace app. > > Kcmshell on the other hand, which is required to run a single KCM, lives in > kde-runtime and all KDE applications can rely on it being around. So an > application having an external KCM can even be configured if systemsettings > is not around. E.g. fonts can be configured using kcmshell4 fonts > even without systemsettings. > > Given that, I agree with Aurélien that the most appropriate solution is to > not show our KDE Plasma systemsettings in a non Plasma environment (with > the exception of Microsoft Windows). > > I find this whole discussion rather depressing, especially the fact that it > ended up on Slashdot&Co. Let's try to take something out of it and try in > future to discuss such points each other before possible harm is done. This > of course applies to both KDE and GNOME developers :-) I btw. agree that a kde application outside of a kde workspace should be self contained. We could solve that problem btw inside of the kde framework even. As Martin masterfully proved systemsettings is a workspace application and should not be be required outside of a full kde workspace (if someone decides to install it intentionally it should still work so the original problem has to be solved anyway.) A application could recognize that it is run outside of an active kde workspace and add all needed kcms (which should be as less as possible ) to its settings menu in that case. But we should really try to respect of the active workspaces settings as possible therefore making as muss kcms as possible useless in such an environment. Mike > > Cheers > Martin Gräßlin > > KWin Maintainer
Re: Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011 14:12:21 Aurélien Gâteau wrote: > If there is no need for KDE System Settings on a Gnome desktop, then > adding a OnlyShowIn=KDE; key to the desktop file would be appropriate. > If on the other hand there is a need for KDE System Settings on a Gnome > desktop, then Shaun solution is correct IMO and we should start to think > about adding support for OnlyShowIn to KCM desktop files, because it > makes no sense for example to be able to define Plasma Desktop wallpaper > when running on Gnome. Technically seen systemsettings lives in kde-workspace which means it is only relevant to the KDE Plasma Workspaces. Non Workspace applications should not depend on its availability and if they require it, I would consider this as an application bug. E.g. the mentioned kinfocenter is a Workspace app. Kcmshell on the other hand, which is required to run a single KCM, lives in kde-runtime and all KDE applications can rely on it being around. So an application having an external KCM can even be configured if systemsettings is not around. E.g. fonts can be configured using kcmshell4 fonts even without systemsettings. Given that, I agree with Aurélien that the most appropriate solution is to not show our KDE Plasma systemsettings in a non Plasma environment (with the exception of Microsoft Windows). I find this whole discussion rather depressing, especially the fact that it ended up on Slashdot&Co. Let's try to take something out of it and try in future to discuss such points each other before possible harm is done. This of course applies to both KDE and GNOME developers :-) Cheers Martin Gräßlin KWin Maintainer signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sun, Jul 24, 2011 at 01:38:34PM +0200, Martin Sandsmark wrote: > My two cent is that Gnome should rename it's configuration application to > something that reflects what it is, instead of stealing the name from the KDE > system configuration application. I've already mentioned in the first reply that I'd appreciate a polite discussion. I think that was enough warning. -- Regards, Olav (moderator)
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Le 24/07/2011 12:55, Giovanni Campagna a écrit : > Which is a KDE bug. You should use GNOME shortcuts when possible. I > mean, Gtk has emacs and Mac OS modes for keybindings, I doubt Qt hasn't > something similar. > It is true that you can change KDE theme without changing the GTK one, > but why would one want that? I want the look and feel of my system to be > consistent, even when different apps or toolkits are used, and I want > one place to configure the theme. > (or none, if I'm using GNOME3 ) > KDE apps under GNOME should use gnome-keyring, not kwallet: that's what > org.freedesktop.Secrets is for. What about the other way around BTW? Do GNOME applications running on a KDE workspace follow KDE keybindings, theme, palette, fonts and icon theme? Do they use kwallet instead of gnome-keyring? If they don't I guess there is also a use for running GNOME System Settings on a KDE workspace. Aurélien
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Le 24/07/2011 10:25, Emmanuele Bassi a écrit : > hi; > > 2011/7/24 Aurélien Gâteau : >> Most distributions split KDE packages so if you get a pre-installed >> computer with Gnome and a few KDE applications installed, KDE System >> Settings would not be installed. >> >> You are only likely to get both System Settings pre-installed if your >> computer was shipped with both KDE and Gnome desktops. In this >> situation, I assume you would be provided with some explanation as to >> what KDE and Gnome are. > > installing both Gnome and KDE is not equivalent to running both at the > same time. Indeed, but still, if there is a use for KDE System Settings to appear on the Gnome desktop, then Shaun solution is appropriate IMO, but that actually brings another interesting question: Which KCM (KDE Control Module, the elements shown in KDE System Settings) are actually useful when running on Gnome? As I said, to the best of my knowledge, very few applications must be configured from a KCM. The only two applications I found on Ubuntu are KInfoCenter and KNemo, which are both KDE workspace-specific. A regular (meaning with a main window) application should show its configuration through its "Settings" menu. A window-less application is most likely workspace-specific and would probably not be useful on a different workspace. Do we have examples of KDE window-less applications which are useful on Gnome? Another use for KDE System Settings on Gnome is the configuration of the palette, font and icon settings of KDE applications. Interestingly I pushed yesterday a commit which makes KDE applications follow the workspace settings for palette and font (I have yet to do icons) when not running on a KDE workspace, just like Qt-only applications do (BTW, would be awesome if you Gnome devs could do the same for Gnome applications running on a KDE workspace). So this is not relevant anymore. If there is no need for KDE System Settings on a Gnome desktop, then adding a OnlyShowIn=KDE; key to the desktop file would be appropriate. If on the other hand there is a need for KDE System Settings on a Gnome desktop, then Shaun solution is correct IMO and we should start to think about adding support for OnlyShowIn to KCM desktop files, because it makes no sense for example to be able to define Plasma Desktop wallpaper when running on Gnome. Aurélien
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011 17:55:54 Giovanni Campagna wrote: > Il giorno dom, 24/07/2011 alle 22.37 +1200, Ben Cooksley ha scritto: > > Wrong, wrong and wrong. > > Phonon backend cannot be configured without System Settings. > And that's a feature, I suppose. As a GNOME user, I want GStreamer at > all times (and as a Fedora user, I can't even install xine). The Xine backend is not maintained anymore, so the choice is between the libvlc backend and gstreamer backend for most users, and many users actually prefer the libvlc backend (for many reasons, none of which are relevant here :-). I am not familiar with what additional restrictions your distro puts on you wrt. multimedia applications, so this might not be relevant to you, though. My two cent is that Gnome should rename it's configuration application to something that reflects what it is, instead of stealing the name from the KDE system configuration application. -- Martin Sandsmark
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Il giorno dom, 24/07/2011 alle 22.37 +1200, Ben Cooksley ha scritto: > On Sun, Jul 24, 2011 at 10:25 PM, Giovanni Campagna > wrote: > > Il giorno dom, 24/07/2011 alle 21.00 +1200, Ben Cooksley ha scritto: > >> 2011/7/24 Emmanuele Bassi : > >> > hi; > >> > > >> > 2011/7/24 Aurélien Gâteau : > >> >> Most distributions split KDE packages so if you get a pre-installed > >> >> computer with Gnome and a few KDE applications installed, KDE System > >> >> Settings would not be installed. > >> >> > >> >> You are only likely to get both System Settings pre-installed if your > >> >> computer was shipped with both KDE and Gnome desktops. In this > >> >> situation, I assume you would be provided with some explanation as to > >> >> what KDE and Gnome are. > >> > > >> > installing both Gnome and KDE is not equivalent to running both at the > >> > same time. > >> > > >> > if you managed to get yourself into the scenario where KDE and Gnome > >> > have been installed at the same time then the KDE system settings > >> > shell should be marked as NotShowIn=Gnome, and the Gnome one should be > >> > NotShowIn=KDE. currently, gnome-control-center uses: > >> > > >> > OnlyShowIn=GNOME;Unity; > >> > > >> > so a menu rendered under KDE won't show it. now, googling a bit I found > >> > this: > >> > > >> > https://git.reviewboard.kde.org/r/102038/ > >> > > >> > which is, I guess, what really prompted this thread. so, if the KDE > >> > system settings shell appears alongside any other system settings > >> > shell it means that the users are not running KDE, but are running any > >> > other XDG-recognised desktop. > >> > > >> >>> there is no "here and now" — that would be a hack. I hardly think we > >> >>> have to solve this *quickly*, so we should solve it correctly. > >> >> > >> >> Releases are conflicting right *now*, so yes, I think there is a need to > >> >> solve it quickly, even if the first fix is a short-term one. > >> > > >> > the short-term fix is to make the KDE system settings OnlyShowIn=KDE, > >> > so that users running KDE will not have any issue, and every other > >> > desktop will correctly not show the KDE system settings shell. > >> > >> Wrong. Emmanuele, read my initial email to see why that is not an > >> acceptable solution under any circumstances. > >> It has to be shown in some form, regardless of the name, under all > >> desktop environments. > > > > Again, no. There is nothing you want to configure, running under GNOME, > > in KDE system settings. Qt apps, running under GNOME, should use Gtk+ > > style (already done by Qt), GNOME preferred apps and mime-type > > associations (already done by shared-mime-info), GNOME networking > > preferences (already done by NetworkManager and libproxy), GNOME fonts > > (already done by fontconfig). Everything else (desktop effects, hardware > > settings, date and time, users...) should not be configurable by KDE > > system settings, and will likely conflict if changed. > > Wrong, wrong and wrong. > Phonon backend cannot be configured without System Settings. And that's a feature, I suppose. As a GNOME user, I want GStreamer at all times (and as a Fedora user, I can't even install xine). > Standard keyboard shortcuts for KDE applications cannot be configured > without System Settings. Which is a KDE bug. You should use GNOME shortcuts when possible. I mean, Gtk has emacs and Mac OS modes for keybindings, I doubt Qt hasn't something similar. > We don't share Date/Time/Localisation/etc - you need System Settings for that. You don't have $LANG? or org.freedesktop.Accounts? Both are KDE bugs. > Theme - we both have our own stores of it - you need System Settings > again (in case you don't believe me, read ~/.gtk2rc) It is true that you can change KDE theme without changing the GTK one, but why would one want that? I want the look and feel of my system to be consistent, even when different apps or toolkits are used, and I want one place to configure the theme. (or none, if I'm using GNOME3 ) > KDE Wallet has some of it's configuration stored in System Settings > too - and it is used by KDE applications even outside KDE for secure > password storage. KDE apps under GNOME should use gnome-keyring, not kwallet: that's what org.freedesktop.Secrets is for. Giovanni signature.asc Description: This is a digitally signed message part
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sun, Jul 24, 2011 at 10:25 PM, Giovanni Campagna wrote: > Il giorno dom, 24/07/2011 alle 21.00 +1200, Ben Cooksley ha scritto: >> 2011/7/24 Emmanuele Bassi : >> > hi; >> > >> > 2011/7/24 Aurélien Gâteau : >> >> Most distributions split KDE packages so if you get a pre-installed >> >> computer with Gnome and a few KDE applications installed, KDE System >> >> Settings would not be installed. >> >> >> >> You are only likely to get both System Settings pre-installed if your >> >> computer was shipped with both KDE and Gnome desktops. In this >> >> situation, I assume you would be provided with some explanation as to >> >> what KDE and Gnome are. >> > >> > installing both Gnome and KDE is not equivalent to running both at the >> > same time. >> > >> > if you managed to get yourself into the scenario where KDE and Gnome >> > have been installed at the same time then the KDE system settings >> > shell should be marked as NotShowIn=Gnome, and the Gnome one should be >> > NotShowIn=KDE. currently, gnome-control-center uses: >> > >> > OnlyShowIn=GNOME;Unity; >> > >> > so a menu rendered under KDE won't show it. now, googling a bit I found >> > this: >> > >> > https://git.reviewboard.kde.org/r/102038/ >> > >> > which is, I guess, what really prompted this thread. so, if the KDE >> > system settings shell appears alongside any other system settings >> > shell it means that the users are not running KDE, but are running any >> > other XDG-recognised desktop. >> > >> >>> there is no "here and now" — that would be a hack. I hardly think we >> >>> have to solve this *quickly*, so we should solve it correctly. >> >> >> >> Releases are conflicting right *now*, so yes, I think there is a need to >> >> solve it quickly, even if the first fix is a short-term one. >> > >> > the short-term fix is to make the KDE system settings OnlyShowIn=KDE, >> > so that users running KDE will not have any issue, and every other >> > desktop will correctly not show the KDE system settings shell. >> >> Wrong. Emmanuele, read my initial email to see why that is not an >> acceptable solution under any circumstances. >> It has to be shown in some form, regardless of the name, under all >> desktop environments. > > Again, no. There is nothing you want to configure, running under GNOME, > in KDE system settings. Qt apps, running under GNOME, should use Gtk+ > style (already done by Qt), GNOME preferred apps and mime-type > associations (already done by shared-mime-info), GNOME networking > preferences (already done by NetworkManager and libproxy), GNOME fonts > (already done by fontconfig). Everything else (desktop effects, hardware > settings, date and time, users...) should not be configurable by KDE > system settings, and will likely conflict if changed. Wrong, wrong and wrong. Phonon backend cannot be configured without System Settings. Standard keyboard shortcuts for KDE applications cannot be configured without System Settings. We don't share Date/Time/Localisation/etc - you need System Settings for that. Theme - we both have our own stores of it - you need System Settings again (in case you don't believe me, read ~/.gtk2rc) KDE Wallet has some of it's configuration stored in System Settings too - and it is used by KDE applications even outside KDE for secure password storage. Regards, Ben Cooksley
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Il giorno dom, 24/07/2011 alle 21.00 +1200, Ben Cooksley ha scritto: > 2011/7/24 Emmanuele Bassi : > > hi; > > > > 2011/7/24 Aurélien Gâteau : > >> Most distributions split KDE packages so if you get a pre-installed > >> computer with Gnome and a few KDE applications installed, KDE System > >> Settings would not be installed. > >> > >> You are only likely to get both System Settings pre-installed if your > >> computer was shipped with both KDE and Gnome desktops. In this > >> situation, I assume you would be provided with some explanation as to > >> what KDE and Gnome are. > > > > installing both Gnome and KDE is not equivalent to running both at the > > same time. > > > > if you managed to get yourself into the scenario where KDE and Gnome > > have been installed at the same time then the KDE system settings > > shell should be marked as NotShowIn=Gnome, and the Gnome one should be > > NotShowIn=KDE. currently, gnome-control-center uses: > > > > OnlyShowIn=GNOME;Unity; > > > > so a menu rendered under KDE won't show it. now, googling a bit I found > > this: > > > > https://git.reviewboard.kde.org/r/102038/ > > > > which is, I guess, what really prompted this thread. so, if the KDE > > system settings shell appears alongside any other system settings > > shell it means that the users are not running KDE, but are running any > > other XDG-recognised desktop. > > > >>> there is no "here and now" — that would be a hack. I hardly think we > >>> have to solve this *quickly*, so we should solve it correctly. > >> > >> Releases are conflicting right *now*, so yes, I think there is a need to > >> solve it quickly, even if the first fix is a short-term one. > > > > the short-term fix is to make the KDE system settings OnlyShowIn=KDE, > > so that users running KDE will not have any issue, and every other > > desktop will correctly not show the KDE system settings shell. > > Wrong. Emmanuele, read my initial email to see why that is not an > acceptable solution under any circumstances. > It has to be shown in some form, regardless of the name, under all > desktop environments. Again, no. There is nothing you want to configure, running under GNOME, in KDE system settings. Qt apps, running under GNOME, should use Gtk+ style (already done by Qt), GNOME preferred apps and mime-type associations (already done by shared-mime-info), GNOME networking preferences (already done by NetworkManager and libproxy), GNOME fonts (already done by fontconfig). Everything else (desktop effects, hardware settings, date and time, users...) should not be configurable by KDE system settings, and will likely conflict if changed. Giovanni signature.asc Description: This is a digitally signed message part
Re: Formal complaint concerning the use of the name "System Settings"
At Sat, 23 Jul 2011 21:43:16 +0200, Lorenz Quack wrote: > So how can this be resolved? … > TLDR: > For this release: GNOME back off > For the next release: KDE and GNOME unify your settings infrastructure > and pick non-generic names for your apps. Why can’t the Gnome System Settings simply be shown in KDE as “Gnome Systemsettings” and in KDE as “Systemsettings” - and the same the other way round. Put the other desktop as brand before the name; that even scales to an unlimited number of desktops using generic names, and I can tell new users, who are trying this “Linux-thing” for the first time to just open Systemsettings, without having to ask first, if they use Gnome, KDE or . Generic names are good: they facilitate desktop switching and cross-desktop support. And a prefix for non-native applications in case of name clashes should not be too hard. Best wishes, Arne
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sunday 24 July 2011, Ben Cooksley wrote: > 2011/7/24 Emmanuele Bassi : > > hi; > > > > 2011/7/24 Aurélien Gâteau : > >> Most distributions split KDE packages so if you get a pre-installed > >> computer with Gnome and a few KDE applications installed, KDE System > >> Settings would not be installed. > >> > >> You are only likely to get both System Settings pre-installed if your > >> computer was shipped with both KDE and Gnome desktops. In this > >> situation, I assume you would be provided with some explanation as to > >> what KDE and Gnome are. > > > > installing both Gnome and KDE is not equivalent to running both at the > > same time. > > > > if you managed to get yourself into the scenario where KDE and Gnome > > have been installed at the same time then the KDE system settings > > shell should be marked as NotShowIn=Gnome, and the Gnome one should be > > NotShowIn=KDE. currently, gnome-control-center uses: > > > > OnlyShowIn=GNOME;Unity; > > > > so a menu rendered under KDE won't show it. now, googling a bit I found > > this: > > > > https://git.reviewboard.kde.org/r/102038/ > > > > which is, I guess, what really prompted this thread. so, if the KDE > > system settings shell appears alongside any other system settings > > shell it means that the users are not running KDE, but are running any > > other XDG-recognised desktop. > > > >>> there is no "here and now" — that would be a hack. I hardly think we > >>> have to solve this *quickly*, so we should solve it correctly. > >> > >> Releases are conflicting right *now*, so yes, I think there is a need to > >> solve it quickly, even if the first fix is a short-term one. > > > > the short-term fix is to make the KDE system settings OnlyShowIn=KDE, > > so that users running KDE will not have any issue, and every other > > desktop will correctly not show the KDE system settings shell. > > Wrong. Emmanuele, read my initial email to see why that is not an > acceptable solution under any circumstances. > It has to be shown in some form, regardless of the name, under all > desktop environments. Yes, Ben is absolutely right here. It is used for setting up a whole lot of stuff like widget style, colors, printing, file associations etc. for application which link against KDE libraries, but can be run perfectly fine not only in Plasma, but also in other window managers/desktop environments. Alex
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
2011/7/24 Emmanuele Bassi : > hi; > > 2011/7/24 Aurélien Gâteau : >> Most distributions split KDE packages so if you get a pre-installed >> computer with Gnome and a few KDE applications installed, KDE System >> Settings would not be installed. >> >> You are only likely to get both System Settings pre-installed if your >> computer was shipped with both KDE and Gnome desktops. In this >> situation, I assume you would be provided with some explanation as to >> what KDE and Gnome are. > > installing both Gnome and KDE is not equivalent to running both at the > same time. > > if you managed to get yourself into the scenario where KDE and Gnome > have been installed at the same time then the KDE system settings > shell should be marked as NotShowIn=Gnome, and the Gnome one should be > NotShowIn=KDE. currently, gnome-control-center uses: > > OnlyShowIn=GNOME;Unity; > > so a menu rendered under KDE won't show it. now, googling a bit I found this: > > https://git.reviewboard.kde.org/r/102038/ > > which is, I guess, what really prompted this thread. so, if the KDE > system settings shell appears alongside any other system settings > shell it means that the users are not running KDE, but are running any > other XDG-recognised desktop. > >>> there is no "here and now" — that would be a hack. I hardly think we >>> have to solve this *quickly*, so we should solve it correctly. >> >> Releases are conflicting right *now*, so yes, I think there is a need to >> solve it quickly, even if the first fix is a short-term one. > > the short-term fix is to make the KDE system settings OnlyShowIn=KDE, > so that users running KDE will not have any issue, and every other > desktop will correctly not show the KDE system settings shell. Wrong. Emmanuele, read my initial email to see why that is not an acceptable solution under any circumstances. It has to be shown in some form, regardless of the name, under all desktop environments. > > ciao, > Emmanuele. Regards, Ben > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi/ >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
hi; 2011/7/24 Aurélien Gâteau : > Most distributions split KDE packages so if you get a pre-installed > computer with Gnome and a few KDE applications installed, KDE System > Settings would not be installed. > > You are only likely to get both System Settings pre-installed if your > computer was shipped with both KDE and Gnome desktops. In this > situation, I assume you would be provided with some explanation as to > what KDE and Gnome are. installing both Gnome and KDE is not equivalent to running both at the same time. if you managed to get yourself into the scenario where KDE and Gnome have been installed at the same time then the KDE system settings shell should be marked as NotShowIn=Gnome, and the Gnome one should be NotShowIn=KDE. currently, gnome-control-center uses: OnlyShowIn=GNOME;Unity; so a menu rendered under KDE won't show it. now, googling a bit I found this: https://git.reviewboard.kde.org/r/102038/ which is, I guess, what really prompted this thread. so, if the KDE system settings shell appears alongside any other system settings shell it means that the users are not running KDE, but are running any other XDG-recognised desktop. >> there is no "here and now" — that would be a hack. I hardly think we >> have to solve this *quickly*, so we should solve it correctly. > > Releases are conflicting right *now*, so yes, I think there is a need to > solve it quickly, even if the first fix is a short-term one. the short-term fix is to make the KDE system settings OnlyShowIn=KDE, so that users running KDE will not have any issue, and every other desktop will correctly not show the KDE system settings shell. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/
Re: Formal complaint concerning the use of the name "System Settings"
Hi, I am non-partisan user of both GNOME and KDE and wanted to add my my humble two cents. I belive that picking a generic name such as "System Settings" for such a common place application and then claiming unique ownership of that name is a bit brazen. On the other hand now that we have this conflict on our hands I think the GNOME community should back of the name for this release and try to resolve this conflict in an bilaterale way everyone can live with. So how can this be resolved? From an users perspective I do not want two different control centers/system settings applications. One should be enough! So If the too comunities could agree on a way to provide interoperability so that the apps are merely frontends to the same underlying settings infrastructre this problem would be really only about nameing issues and the user would be a happy one. I realize that this might be harder to do than it is said but isn't a good user experience what devs in both communities should be striving for? TLDR: For this release: GNOME back off For the next release: KDE and GNOME unify your settings infrastructure and pick non-generic names for your apps. Keep up the good work and have respect for each others great work! //Lorenz (a thankful user)
Re: Formal complaint concerning the use of the name "System Settings"
Mark wrote: > Just a small suggestion on how i think this should be "fixed" (since 2 > desktop files for one app seems just ugly to me). > Perhaps it's better to extend the desktop file specification: > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html > > And i would propose adding 2 entries: > NativeDE - This one holds the desktop environment name where the app > would be "native". So GNOME, KDE or whatever. > NameNonNative - This one holds the app name when it's shown in a > desktop environment that is not native. When not set fallback to > "Name" > > So for example the "System Settings" app in KDE looks somewhat like > this in a .desktop file: > > Name=System Settings > NativeDE=KDE > NameNonNative=KDE System Settings > > The same applies for gnome system settings and also for the system > monitor (that also has the naming issue) > Isn't this a good solution? > > Regards, > Mark I think this is the right idea - have a generic name and a native-desktop-specific name. But I think it could be implemented more nicely. I suggest the following: Name=KDE System Settings KDE-Name=System Settings Name=Gnome System Settings Gnome-Name=System Settings This would be a little easier to implement, and has the advantage that the non-native name will be used for any DE that doesn't specifically know about the "extension". For example, in Xfce, you will get "KDE System Settings" and "Gnome System Settings" without Xfce having to implement anything; with Mark's suggestion however, Xfce would give you two "System Settings" until it was patched. Regards, Ambroz
