Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

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

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Ambroz Bizjak]

Hi Mark,
have you seen my proposed improvement on your suggestion?

http://lists.kde.org/?l=kde-core-devel&m=131149560119520&w=2

I suggest that you consider it, because it would avoid having to
update the Freedesktop specification and any DE that doesn't name its
programs differently in other DEs (e.g. Xfce).

On Mon, Jul 25, 2011 at 1:32 PM, Mark  wrote:
> 2011/7/24 Ben Cooksley :
>> 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
>>
>
> Hi Ben,
>
> Could you read and comment on my proposal:
> http://lists.kde.org/?l=kde-core-devel&m=131142514605051&w=2
> I would like to implement this in the spec, KDE en Gnome, but i need
> some pointers on where i should make such edits and to get it
> approved.
>
> I think that is the most sane solution that doesn't require multiple
> desktop files.
>
> If you agree on this, what do i need to do next?
> Just some guesses..
> - Propose the updated standard in the freedesktop mailing list (which one?)
> - Make patched for KDE (which component? where? file?)
> - Make patches for gnome (which component? where? file?)
>
> Note: anyone is fine, not just Ben. Aiming at him since he started this 
> mailing.
>
> Regards,
> Mark
>

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Ambroz Bizjak]

Hi Mark,

Yes, you are right about the X- part. However, I now think that the
Freedesktop specification could be extended in a more generic way. I
suggest updating the spec such that any (!) non-(-X) key of form (for
example)

Specific--=

is to be interpreted as =Value, in the environment called ,
possibly overriding the generic definition of this key. Such an
extension would allow any attribute to have DE-specific values, not
just the name. For example, GenericName, and even Exec (for
DE-specific su maybe?).

A desktop file would then look like:

Name=System Settings
Specific-KDE-Name=KDE System Settings

Regards,
Ambroz

On Mon, Jul 25, 2011 at 2:37 PM, Mark  wrote:
> On Mon, Jul 25, 2011 at 1:56 PM, Ambroz Bizjak  wrote:
>> Hi Mark,
>> have you seen my proposed improvement on your suggestion?
>>
>> http://lists.kde.org/?l=kde-core-devel&m=131149560119520&w=2
>>
>> I suggest that you consider it, because it would avoid having to
>> update the Freedesktop specification and any DE that doesn't name its
>> programs differently in other DEs (e.g. Xfce).
>>
>> (sorry if you get this message twice, I only sent it to the mailing list 
>> once)
>>
>> On Mon, Jul 25, 2011 at 1:32 PM, Mark  wrote:
>>> 2011/7/24 Ben Cooksley :
>>>> 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
>>>>
>>>
>>> Hi Ben,
>>>
>>> Could you read and comment on my proposal:
>>> http://lists.kde.org/?l=kde-core-devel&m=131142514605051&w=2
>>> I would like to implement this in the spec, KDE en Gnome, but i need
>>> some pointers on where i should make such edits and to get it
>>> approved.
>>>
>>> I think that is the most sane solution that doesn't require multiple
>>> desktop files.
>>>
>>> If you agree on this, what do i need to do next?
>>> Just some guesses..
>>> - Propose the updated standard in the freedesktop mailing list (which one?)
>>> - Make patched for KDE (which component? where? file?)
>>> - Make patches for gnome (which component? where? file?)
>>>
>>> Note: anyone is fine, not just Ben. Aiming at him since he started this 
>>> mailing.
>>>
>>> Regards,
>>> Mark
>>>
>>
>
> Hi,
>
> Sorry, i haven't seen the last one (just missed it since it is there).
> Your idea is "slightly" wrong (sorry for nitpicking ;))
> It should be
> X-KDE-Name
> X-Gnome-Name
>
> That is allowed by the spec.
>
> Your idea is nice and would fix it but i still think this should be
> added to the official spec. Your suggestion is more like an unofficial
> addition to the spec that any DE should follow anyway.
> As for patches. I'm perfectly fine with making the patches for KDE,
> Gnome, XFCE and whatever.. That can't be that much of a task anyway.
>
> Kind regards,
> Mark
>

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Mark,
I've done some small research on what components would have to be
updated for the desktop-specific-names solution. I think that would
be:

- The Desktop Entry Specification,
http://standards.freedesktop.org/desktop-entry-spec/latest/
- KDE's KDesktopFile,
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp
- Xfce's libxfce4menu, in particular
http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c
- Gnome's libgnome-menu, in particular
http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c

Regards,
Ambroz

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Mark,

The localization stuff you're concerned about is happening below the
desktop file layer (in KDE's case, kconfigdata.h), and should work
automatically, i.e. if you ask for some key it will automatically give
you a localized version if available.
Also, DE-specific desktop file keys would be a good thing to have in
general, so I hope people do not oppose the idea just because it's not
the ideal solution to this particular problem. Besides, it's (I think)
very easy to implement, so even if we don't manage to push it, it
wouldn't be that much time lost :) . I've done many enhancements to
open-source projects, and many of them weren't liked by the developers
- but I still think I did the right thing, and I'm not afraid of
contributing for the fear of being opposed.

Regards,
Ambroz

On Tue, Jul 26, 2011 at 12:19 AM, Mark  wrote:
> On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak  wrote:
>> Hi Mark,
>> I've done some small research on what components would have to be
>> updated for the desktop-specific-names solution. I think that would
>> be:
>>
>> - The Desktop Entry Specification,
>> http://standards.freedesktop.org/desktop-entry-spec/latest/
>> - KDE's KDesktopFile,
>> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp
>> - Xfce's libxfce4menu, in particular
>> http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c
>> - Gnome's libgnome-menu, in particular
>> http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c
>>
>> Regards,
>> Ambroz
>>
>
> Hi,
>
> Thanx for the list. I already found the spec and kde file.
> One thing i can't find though is the part that makes multilanguage
> stuff for desktop files working.. Those 3 source files all just grab
> the Name value but where does it do the magic that happens when i set
> my language to dutch.. then it grabs Name[nl] but where does it do
> that? Asking that since the properties i proposed should have multi
> language suppert as well..
>
> And besides that.. I do want to implement it, but i'm getting the
> feeling there isn't that much support for it thus wasting my time if i
> implement it since it won't get accepted anyway. (which i rather
> avoid).
>
> It's just a feeling and i hope i'm wrong...
>
> Regards,
> Mark
>

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Mark,

I am strongly opposed to the particular solution you are implementing.
You are trying to extend the desktop file specification in a very
non-generic and non-intuitive way, and people will obviously oppose
that.

The particular problems I see with your original proposed solution are:
- You are only extending the "Name" field. It will not be possible to
have a DE-specific GenericName field, for example.
- You are adding two new fields to the specification, when the same
effect could be achieved with just one new field (or class of fields)
- Anything that is not aware of the your extension (which probably
means it is not KDE) will be using the KDE-specific name rather than
the generic name, until that software was patched to understand the
extension.

Please consider my second suggestion - it is a much more generic
solution, and it does not have any of the problems I listed above.

http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2

I'm sorry, I messed up the example there; it should say:

Name=KDE System Settings
Specific-KDE-Name=System Settings

To implement this solution I guess you'd have to modify
KConfigGroup::readEntry to first look for "Specific-KDE-" and
revert to "" if the former does not exist.

Regards,
Ambroz

On Tue, Jul 26, 2011 at 9:54 AM, Mark  wrote:
> On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak  wrote:
>> Hi Mark,
>>
>> The localization stuff you're concerned about is happening below the
>> desktop file layer (in KDE's case, kconfigdata.h), and should work
>> automatically, i.e. if you ask for some key it will automatically give
>> you a localized version if available.
>> Also, DE-specific desktop file keys would be a good thing to have in
>> general, so I hope people do not oppose the idea just because it's not
>> the ideal solution to this particular problem. Besides, it's (I think)
>> very easy to implement, so even if we don't manage to push it, it
>> wouldn't be that much time lost :) . I've done many enhancements to
>> open-source projects, and many of them weren't liked by the developers
>> - but I still think I did the right thing, and I'm not afraid of
>> contributing for the fear of being opposed.
>>
>> Regards,
>> Ambroz
>>
>> On Tue, Jul 26, 2011 at 12:19 AM, Mark  wrote:
>>> On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak  wrote:
>>>> Hi Mark,
>>>> I've done some small research on what components would have to be
>>>> updated for the desktop-specific-names solution. I think that would
>>>> be:
>>>>
>>>> - The Desktop Entry Specification,
>>>> http://standards.freedesktop.org/desktop-entry-spec/latest/
>>>> - KDE's KDesktopFile,
>>>> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp
>>>> - Xfce's libxfce4menu, in particular
>>>> http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c
>>>> - Gnome's libgnome-menu, in particular
>>>> http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c
>>>>
>>>> Regards,
>>>> Ambroz
>>>>
>>>
>>> Hi,
>>>
>>> Thanx for the list. I already found the spec and kde file.
>>> One thing i can't find though is the part that makes multilanguage
>>> stuff for desktop files working.. Those 3 source files all just grab
>>> the Name value but where does it do the magic that happens when i set
>>> my language to dutch.. then it grabs Name[nl] but where does it do
>>> that? Asking that since the properties i proposed should have multi
>>> language suppert as well..
>>>
>>> And besides that.. I do want to implement it, but i'm getting the
>>> feeling there isn't that much support for it thus wasting my time if i
>>> implement it since it won't get accepted anyway. (which i rather
>>> avoid).
>>>
>>> It's just a feeling and i hope i'm wrong...
>>>
>>> Regards,
>>> Mark
>>>
>>
>
> You are completely right.
>
> However one small question.. In KDE you have a readName function that
> reads the Name value from the desktop file. But how should that behave
> if a desktop file has the following and is read from a KDE
> environment:
>
> NativeDE=Gnome
> NameNonNative=Gnome System Settings
>
> Would the readName property then return the NameNonNative value if
> it's read from a KDE environment..?
> That would seem the most easy solution but a bit dirty as well -- only
> seems nice if the spec would specifically say that the Name property
> is overwritten by NameNonNative if the NativeDE property is set and
> different from the currently used DE.
>

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

(Mark, sorry if you're getting this twice, I clicked the wrong Reply
button the first time...)

Hi Mark,

I understand your concern, but I don't consider it an issue.

There is a downside to your proposal compared to mine, which is that
it only allows a specific value to one (!) DE. For example, with mine,
you could have:

Name=Some Generic Name
Specific-KDE-Name=Name in KDE only
Specific-GNOME-Name=Name in GNOME only
Specific-XFCE-Name=Name in XFCE only

the result of which would be that there would be specific (possibly
different) names for KDE, Gnome and Xfce, and a default name for other
DEs. The same is not achievable with your suggestion.

I suppose it would be possible to achieve this without embedding any
value in the key itself, but it would become harder to read and to
implement. For example, the following:

Name=Some Generic Name
Specific-Name-Count=3
Specific-Name-Desktop0=KDE
Specific-Name-Value0=Name in KDE only
Specific-Name-Desktop1=GNOME
Specific-Name-Value1=Name in GNOME only
Specific-Name-Desktop2=XFCE
Specific-Name-Value2=Name in XFCE only

which I think is flawed compared to the above version. It's hard to
read and to modify, harder to implement, and introduces unnecessary
coupling between the fields.

What do you think?

Regards,
Ambroz

On Tue, Jul 26, 2011 at 1:19 PM, Mark  wrote:
> On Tue, Jul 26, 2011 at 11:48 AM, Ambroz Bizjak  wrote:
>> Hi Mark,
>>
>> I am strongly opposed to the particular solution you are implementing.
>> You are trying to extend the desktop file specification in a very
>> non-generic and non-intuitive way, and people will obviously oppose
>> that.
>>
>> The particular problems I see with your original proposed solution are:
>> - You are only extending the "Name" field. It will not be possible to
>> have a DE-specific GenericName field, for example.
>> - You are adding two new fields to the specification, when the same
>> effect could be achieved with just one new field (or class of fields)
>> - Anything that is not aware of the your extension (which probably
>> means it is not KDE) will be using the KDE-specific name rather than
>> the generic name, until that software was patched to understand the
>> extension.
>>
>> Please consider my second suggestion - it is a much more generic
>> solution, and it does not have any of the problems I listed above.
>>
>> http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2
>>
>> I'm sorry, I messed up the example there; it should say:
>>
>> Name=KDE System Settings
>> Specific-KDE-Name=System Settings
>>
>> To implement this solution I guess you'd have to modify
>> KConfigGroup::readEntry to first look for "Specific-KDE-" and
>> revert to "" if the former does not exist.
>>
>> Regards,
>> Ambroz
>>
>> On Tue, Jul 26, 2011 at 9:54 AM, Mark  wrote:
>>> On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak  wrote:
>>>> Hi Mark,
>>>>
>>>> The localization stuff you're concerned about is happening below the
>>>> desktop file layer (in KDE's case, kconfigdata.h), and should work
>>>> automatically, i.e. if you ask for some key it will automatically give
>>>> you a localized version if available.
>>>> Also, DE-specific desktop file keys would be a good thing to have in
>>>> general, so I hope people do not oppose the idea just because it's not
>>>> the ideal solution to this particular problem. Besides, it's (I think)
>>>> very easy to implement, so even if we don't manage to push it, it
>>>> wouldn't be that much time lost :) . I've done many enhancements to
>>>> open-source projects, and many of them weren't liked by the developers
>>>> - but I still think I did the right thing, and I'm not afraid of
>>>> contributing for the fear of being opposed.
>>>>
>>>> Regards,
>>>> Ambroz
>>>>
>>>> On Tue, Jul 26, 2011 at 12:19 AM, Mark  wrote:
>>>>> On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak  wrote:
>>>>>> Hi Mark,
>>>>>> I've done some small research on what components would have to be
>>>>>> updated for the desktop-specific-names solution. I think that would
>>>>>> be:
>>>>>>
>>>>>> - The Desktop Entry Specification,
>>>>>> http://standards.freedesktop.org/desktop-entry-spec/latest/
>>>>>> - KDE's KDesktopFile,
>>>>>> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/chang

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas.

> Sorry for stepping in here, but are you really discussing to present
> the users different names for applications (not the bins, but we're
> talking about joe) under different circumstances so if i'd tell a user
> to run "foo" he won't be able cause it's called "bar" in his DE?
Yes, that is what this extension would allow. It's a powerful tool,
and any powerful tool can be abused. The presumption of course that
people choosing the names will choose them sensibly. For example, in
the System Settings case, in KDE, there could be "System Settings" and
"Gnome System Settings", with the former being the KDE version;
similarly in Gnome. And I think it's better than having two
identically named "System Settings", or having both of them always
prefixed, i.e. "KDE System Settings" and "Gnome System Settings". For
example, consider the user asks you how he can change the fonts. You
would simply tell him to open "System Settings", and it would open his
desktop's native configuration tool, which should work even for
non-native applications IIRC. On the other hand, if he says that he
changed something, but it didn't work in that particular application,
you would tell him to open the other System Settings (better than
telling him "kcmshell4 whatever"!)

> The .desktop file already knows a name and a generic name and the
> representation (aka "runner") could be smart enought to detect
> pseudo doublettes and use the generic name by default and attach the
> non generic name  (or, as LLOD the binary) for clarification if
> necessary or just to be "honest".
This doesn't solve the original problem. The two "System Settings" in
fact have the same Name. It is also harder to implement, and the
behavior is non-obvious.

> You're currently only talking about solutions covering LANG=C but you
> cannot possibly expect translators to avoid such clashes in their
> translations if the application name does not contain some trademark.
> Eg. "system settings" as well as "configuration center" could easily
> end up as "Systemeinstellungen" in German - simply cause it's (iirc -
> bee a long time) the winblows term - some languages might not even
> leave any options in some cases.
My proposal is not tied to English in any way. The individual
Specific-DE- prefixed keys would come localized, just like the
non-prefixed keys. I don't see how choosing sensible names in other
languages could be much harder than in English.

Regards,
Ambroz

On Tue, Jul 26, 2011 at 8:14 PM, Thomas Lübking
 wrote:
> Am Tue, 26 Jul 2011 13:45:26 +0200
> schrieb Ambroz Bizjak :
>
>> (Mark, sorry if you're getting this twice, I clicked the wrong Reply
>> button the first time...)
>>
>> Hi Mark,
>>
>> I understand your concern, but I don't consider it an issue.
>>
>> There is a downside to your proposal compared to mine, which is that
>> it only allows a specific value to one (!) DE. For example, with mine,
>> you could have:
>>
>> Name=Some Generic Name
>> Specific-KDE-Name=Name in KDE only
>> Specific-GNOME-Name=Name in GNOME only
>> Specific-XFCE-Name=Name in XFCE only
>
> Sorry for stepping in here, but are you really discussing to present
> the users different names for applications (not the bins, but we're
> talking about joe) under different circumstances so if i'd tell a user
> to run "foo" he won't be able cause it's called "bar" in his DE?
>
> The .desktop file already knows a name and a generic name and the
> representation (aka "runner") could be smart enought to detect
> pseudo doublettes and use the generic name by default and attach the
> non generic name  (or, as LLOD the binary) for clarification if
> necessary or just to be "honest".
>
> If the runner isn't smart enough to avoid presenting clashes to the
> user, that's a runner bug - no matter what caused it in this particular
> case.
>
> You're currently only talking about solutions covering LANG=C but you
> cannot possibly expect translators to avoid such clashes in their
> translations if the application name does not contain some trademark.
> Eg. "system settings" as well as "configuration center" could easily
> end up as "Systemeinstellungen" in German - simply cause it's (iirc -
> bee a long time) the winblows term - some languages might not even
> leave any options in some cases.
>
> Cheers,
> Thomas
>

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas,

I hope you are aware that my proposal is a technical solution and not
a social one. I cannot predict the social aspects of it. More
specifically, it is mechanism that allows for solutions to problems.

If the problem is "two things from different DEs have the same name",
then a direct solution to the problem is "make the names different".
And I have proposed a mechanism for doing exactly that, and doing it
in a simple an intuitive way.

Moreover, the mechanism is really generic as it would apply to all
keys in a .desktop file, not only a Name, so you can't ever claim that
it's a hack.

> If an application has a different name under different DEs, that's not
> "abuse" but error by design (sorry, i don't mean to be offensive)
Just no. It's abuse by the application author.
Additionally, please stop arguing my solution based on purely
hypothetical cases. Applications DON'T AND WOULD NOT have different
names under different DEs, except for the very few specific cases
where disambiguation is required.

> > This doesn't solve the original problem.
> Yes it does. They will certainly not share the same binary name or
> we've a _real_ problem. (Or not, since there will be only one target
> for the application link anyway ;-)
I'm not too sure what solution you're arguing here for, but I believe
that if you looked at this specific case (in particular the .dekstop
files) with a little more detail you would realize you're talking
nonsense.

> To repeat the example, if translator (a) translates the KDE .desktop
> file, translator (b) the gnome one and they don't coordinate
> ...
I'm pretty sure all the translators problems would be solved by
mailing all translators something like:

"Please take a look at systemsettings.desktop, and choose the
Specific-KDE-Name translation to what the System Settings application
should be called from within KDE (probably what was previously used
for Name), and then choose the Name translation to what the System
Settings application should be called from other desktop environments,
which would probably mention KDE somewhere for disambiguation with the
other desktop's settings application."

possibly mentioning other clashing cases.

> -> If clashes are (apparently) an existing problem, they need to be
> avoided at the end of the chain where they can be spotted for sure and
> not on the start where we just hope we (and everybody else!) did
> everything ok
My proposal does not provide a mechanism for detecting clashes, only
one for resolving them. I'm sure that with a little attention from
application developers and listening to users, relevant clashes will
quickly be detected (as was the System Settings case).

Regards,
Ambroz

On Tue, Jul 26, 2011 at 9:10 PM, Thomas Lübking
 wrote:
> Hi Ambroz, (and everybody else of course)
>
> Am Tue, 26 Jul 2011 20:39:27 +0200
> schrieb Ambroz Bizjak :
>
>> Yes, that is what this extension would allow. It's a powerful tool,
>> and any powerful tool can be abused.
> If an application has a different name under different DEs, that's not
> "abuse" but error by design (sorry, i don't mean to be offensive)
> Leaving aside systemsettings, what if i tell somebody to run marble
> ("it's like google-earth!") but he then starts some solitaire game
> (because there is eg. a solitaire game like this on "OtherDE" and
> marble is named "KDE's google-earth clone" ;-) he'll be pissed and i'll
> be lost.
>
>> This doesn't solve the original problem.
> Yes it does. They will certainly not share the same binary name or
> we've a _real_ problem. (Or not, since there will be only one target
> for the application link anyway ;-)
>
> It would also be possible to choose "System Settings" as generic name
> and "KDE Settings" as non generic one. The latter would only be
> presented for clarification (if the runner wanted)
>
>> It is also harder to implement, and the behavior is non-obvious.
> a) "i don't think so"
> b) that's not an excuse.
>
>> My proposal is not tied to English in any way.
> No, but it is tied to the ppl, knowing about an and resolving an actual
> clash which i doubt translators can be expected to be.
>> The individual Specific-DE-
> I wasn't restricting my concerns to the "we already know about an
> existing clash in LANG=C".
> The very same issue can _easily_ arise onlny in a particular
> translation.
>
> To repeat the example, if translator (a) translates the KDE .desktop
> file, translator (b) the gnome one and they don't coordinate, they
> might pick the very same translation for "control center&

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas,

I'm not saying that the issues you have exposed do not exist. They are
however minor in nature and do not invalidate my solution.

> You call that "technical" and "not social"?
My proposal is technical. I have only mentioned the social aspects
when you have risen social issues about it.

> You'll at best be able to resolve risen clashes.
Yes, exactly. That's what the original problem was. The original
problem was not "We have to prevent ALL name clashes"; rather, it was
"System Settings clashes with a Gnome application". So I think we
should stay on point here and not wander into some utopian land you
seem to be imagining.

> And in a quite workload causing way - systemsetting would eg. require
> an "KDE System Settings" entry for _every_ desktop but KDE ...
You are mistaken here. I am afraid you just got a glimpse of my idea
which was really a case pointing out an issue in some other inferior
idea. Actually only this would be required in the System Settings
case:

Name=KDE System Settings
Specific-KDE-Name=System Settings

and would result in the program being called "System Settings" in KDE,
and "KDE System Settings" in everything else, including DEs which do
not know anything about my proposed extension.

I suggest you look at the whole mail history. My original proposal is
here (but I reversed the names there accidentally, sorry about that):
http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2

Regards,
Ambroz

On Tue, Jul 26, 2011 at 10:31 PM, Thomas Lübking
 wrote:
> Am Tue, 26 Jul 2011 21:53:48 +0200
> schrieb Ambroz Bizjak :
>
>> Hi Thomas,
>>
>> I hope you are aware that my proposal is a technical solution and not
>> a social one.
> No, it's probably not - see end of mail.
>
>> If the problem is "two things from different DEs have the same name",
>> then a direct solution to the problem is "make the names different".
> No, the solution of ambiguity is disambiguation - not adding more
> strings which could easily end up as ambigious.
>
> Again: the .desktop files already contain various identifying
> attributes.
> a) name
> b) generic name
> c) executable
> d) description
> e) (icon, but we'll leave that out)
>
> Whether your representation prefers the generic or non generic name is
> matter of pers. pref. but you can detect a clash and resolve it by
> adding more info. LLOD is the binary executable (in doubt including
> path & parameters) since that /has/ to differ for different entries.
>
>> And I have proposed a mechanism for doing exactly that, and doing it
>> in a simple an intuitive way.
> By adding an extra key for every possible DE...
>
>> Moreover, the mechanism is really generic as it would apply to all
>> keys in a .desktop file, not only a Name, so you can't ever claim that
>> it's a hack.
> a) how does that make/resolve it being a hack?
> b) where did I imply it was?
>
>> > If an application has a different name under different DEs, that's
>> > not "abuse" but error by design (sorry, i don't mean to be
>> > offensive)
>> Just no. It's abuse by the application author.
> So having different names on different DEs is not the intention of your
> approach (then why do you?) but abuse by the application author (where
> you drop accidents by the author/the translators...)
>
>> except for the very few specific cases where disambiguation is
>> required.
> Ans this is what i'm discussing. I didn't think of
> developers/translators deliberately confusing users at all.
>
>> > > This doesn't solve the original problem.
>> > Yes it does. They will certainly not share the same binary name or
>> > we've a _real_ problem. (Or not, since there will be only one target
>> > for the application link anyway ;-)
>> I'm not too sure what solution you're arguing here for, but I believe
>> that if you looked at this specific case (in particular the .dekstop
>> files) with a little more detail you would realize you're talking
>> nonsense.
> So you imply that (in this particular case) the gnome application and
> the KDE application share the exact same binary executable path as
> well as each and every other identifying attribute?
>
> Well, as mentioned before there is then no problem at all, since the
> user will run the very same application regardless of which icon (of
> that only one should exist anyway) he clicks. (of course the new problem
> would be that installing gnome would wipe parts of KDE...)
>
> Otherwise i am not talking nonsense at all.
>
>> I'm pret

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas.

> I think you didn't get what I said in the first place.
> The runner (the menu, whatever) has to ensure the disambiguation.
> Whether starting form the generic or non generic name doesn't matter at
> all.
Okay, I get it now, thanks for clarifying. But please provide an
example of how you would use it to resolve the System Settings case,
for instance. I can't think of one.

Assume that both applications have "Name=System Settings" - that is if
KDE refuses to change its name and Gnome doesn't back away and revert
to some other name.
What would the .desktop files look like?

Maybe something like this (KDE):

Name=System Settings
GenericName=KDE desktop configuration

and Gnome:

Name=System Settings
GenericName=GNOME desktop configuration

Suppose the user has the menu in the "Name" mode. Then your solution
would, assuming both are present, result in there being "KDE desktop
configuration" and "GNOME desktop configuration" - both (!) in KDE and
GNOME (Name was ambiguous so GenericName was displayed instead). I
hope we agree that is confusing for new users. Alternatively, there
would be "System Settings (KDE desktop configuration)" and "System
Settings (GNOME desktop configuration)", possibly the text in
parentheses being subscribed instead. This is a little less confusing,
but still confusing compared to just "System Settings" and "GNOME
System Settings", where "System Settings", the native tool, is clearly
preferred.

And if the menu is in the "GenericName" mode, you would get "KDE
desktop configuration" and "GNOME desktop configuration", which is,
again, confusing.

Regards,
Ambroz

On Tue, Jul 26, 2011 at 10:39 PM, Thomas Lübking
 wrote:
> Am Tue, 26 Jul 2011 22:27:40 +0200
> schrieb Ambroz Bizjak :
>
>> Additionally, I make the following points on your proposed solution:
>>
>> My solution can do everything that the solution you are proposing
> No. Can't. The runner/startmenu (call it whatever you want) can
> effectively prevent clashes - what some extra string can only hope to
> achive (based on social engineering)
>
>> Your solution (as far as I get it) assumes a specific interpretation
>> of the Name and GenericName fields.
> No. It assumes that the .desktop files differ in some identifying
> attribute,
>
>> It's just that some DEs (and distributions)
>> use the Name field for the primary name in the menu, while some use
>> the Name field.
> I think you didn't get what I said in the first place.
> The runner (the menu, whatever) has to ensure the disambiguation.
> Whether starting form the generic or non generic name doesn't matter at
> all.
>
> Cheers,
> Thomas
>

Re: Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas,

Additionally, I make the following points on your proposed solution:

My solution can do everything that the solution you are proposing (if
that is a solution at all). So if anything, it is techically on the
same level.

Your solution (as far as I get it) assumes a specific interpretation
of the Name and GenericName fields. It's just that some DEs (and
distributions)
use the Name field for the primary name in the menu, while some use
the Name field. Personally, I prefer the Name option where the menu
shows the actual name
of the application. This is also the case in other desktops, for
instance Windows. Any disambiguation you attempt to do only on the
basis of the
Name and GenericName will behave differently, depending on what menu
representation is in use (and there is *no* standard - some DEs use
one, some the other,
most allow you to switch, and even some distros change the default),
and you won't have full control over the naming of the menu entry -
which you
do have with my solution (except for the Name-vs-GenericName thing),
and which is necessary for proper disambiguation of clashes.

Regards,
Ambroz

On Tue, Jul 26, 2011 at 9:10 PM, Thomas Lübking
 wrote:
> Hi Ambroz, (and everybody else of course)
>
> Am Tue, 26 Jul 2011 20:39:27 +0200
> schrieb Ambroz Bizjak :
>
>> Yes, that is what this extension would allow. It's a powerful tool,
>> and any powerful tool can be abused.
> If an application has a different name under different DEs, that's not
> "abuse" but error by design (sorry, i don't mean to be offensive)
> Leaving aside systemsettings, what if i tell somebody to run marble
> ("it's like google-earth!") but he then starts some solitaire game
> (because there is eg. a solitaire game like this on "OtherDE" and
> marble is named "KDE's google-earth clone" ;-) he'll be pissed and i'll
> be lost.
>
>> This doesn't solve the original problem.
> Yes it does. They will certainly not share the same binary name or
> we've a _real_ problem. (Or not, since there will be only one target
> for the application link anyway ;-)
>
> It would also be possible to choose "System Settings" as generic name
> and "KDE Settings" as non generic one. The latter would only be
> presented for clarification (if the runner wanted)
>
>> It is also harder to implement, and the behavior is non-obvious.
> a) "i don't think so"
> b) that's not an excuse.
>
>> My proposal is not tied to English in any way.
> No, but it is tied to the ppl, knowing about an and resolving an actual
> clash which i doubt translators can be expected to be.
>> The individual Specific-DE-
> I wasn't restricting my concerns to the "we already know about an
> existing clash in LANG=C".
> The very same issue can _easily_ arise onlny in a particular
> translation.
>
> To repeat the example, if translator (a) translates the KDE .desktop
> file, translator (b) the gnome one and they don't coordinate, they
> might pick the very same translation for "control center" and "system
> settings" (unless as mentioned there's a trademark in the string what
> renders the entire approach useless since that could be added
> automatically anyway)
> This might happen even though there are similar strings in German
> (surprise, since english is just degene... strike that ;-) because as
> mentioned the translators might have other references in mind.
> In other languages there might not even be any variants of this item.
>
> -> If clashes are (apparently) an existing problem, they need to be
> avoided at the end of the chain where they can be spotted for sure and
> not on the start where we just hope we (and everybody else!) did
> everything ok.
>
> Cheers,
> Thomas
>

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Ambroz Bizjak]

If anyone is interested in my proposal for DE-specific keys, I've
written a proposal for how the Desktop Entry Specification could be
updated. This support could be used to implement the naming mentioned,
that is calling it "System Settings" in KDE, and "KDE System Settings"
elsewhere - without new desktop files.

I'm attaching the proposal. However, I do not have the time or
willpower to argue for it. If someone finds it useful, feel free to
make something out of it. (implementing it, however, is trivial)

For my original suggestion, see
http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2 (but the
example there is accidentally inverted).

On Thu, Aug 11, 2011 at 7:48 PM, Shaun McCance  wrote:
> On Wed, 2011-08-10 at 13:47 +0200, todd rme wrote:
>> On Wed, Aug 10, 2011 at 1:42 PM, Richard Hughes  wrote:
>> > On 4 August 2011 07:27, George Spelvin  wrote:
>> >> I think what is needed is a series of more specific alternate names in
>> >> a .desktop file, with more levels than the current GenericName and Name.
>> >
>> > I think the KDE system settings desktop file just needs an addition of:
>> >
>> > OnlyShowIn=KDE;
>> >
>> > Richard.
>> >
>>
>> It has already been explained why this is not sufficient.  System
>> settings is needed to configure many aspects of KDE programs.  Doing
>> this will leave Gnome users unable to configure any KDE programs they
>> use.
>
> I already pointed out a solution that makes it "System Settings" in KDE
> and "KDE System Settings" in other desktops. The KDE developers seemed
> to agree to this. The problem is solved. Please let's end this thread
> and get back to writing great free software.
>
> Thanks,
> Shaun
>
>
>
>


desktop-spec-update2
Description: Binary data

Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Ambroz Bizjak]

>> > if we start from an all-privileged daemon like systemd. It's privilege
>> > elevation that suffers.
>>
>> does the session systemd run privileged in the first place?
>
> I have no clue. I don't even know if there's a session systemd.
>

I'm not sure exactly how you people are planning to make use of
systemd; but hopefully:

- It won't require the operating system to be running systemd as an
init system. Any OS/user should be free to use a different/custom init
system and still be able to use KDE.
- It won't require root privileges to start KDE (including setuid
programs). I don't see how dropping privileges from a user account
wouldn't work (except perhaps the "not implemented" part, in which
case the right way is to implement it).

I suggest you think well whether systemd is indeed the right solution.
As far as I see it, it was designed to be used for system services
only, and not as a generic framework for controlling services and
dependencies (hopefully I'm wrong).

I've written some software which might also be used in this place.
Please, read it through: http://code.google.com/p/badvpn/wiki/NCD .
Yes, it doesn't have everything that would be needed to plug it into
KDE right now, but it might be worth looking into because of its
simplicity, compared to systemd.

Regards,
Ambroz

Re: Default file manager and folder associations

[Ambroz Bizjak]

That doesn't quite work, for me at least. See the bug I reported
https://bugs.kde.org/show_bug.cgi?id=297720
Nobody seems to care though.

On Sun, Jun 17, 2012 at 12:21 PM, todd rme  wrote:
> On Sun, Jun 17, 2012 at 11:13 AM, Jacopo De Simoi  wrote:
>> Dear kcd,
>>
>>  I am thinking for a possible fix for bug #293576 [1], but I could not make
>> up my mind so far. As far as I understand the situation is as follows:
>>
>> - There is no explicit way of setting the default file manager for the KDE
>> workspace; however, there is an implicit way of doing that by selecting the
>> desired program as the default file association for folders.
>
> What about system settings -> Default Applications -> File Manager?
>
> -Todd

Re: Review Request: Show warning when CopyJob fails to list a subdir

[Ambroz Bizjak]

> On Aug. 16, 2012, 1:10 p.m., Frank Reininghaus wrote:
> > kdeui/jobs/kdialogjobuidelegate.cpp, line 92
> > 
> >
> > I'm afraid the users suffering from 
> > https://bugs.kde.org/show_bug.cgi?id=206500 will kill us if they get a 
> > message box for every single file. Right now, they have the option to wait 
> > until the operation is completed, then close the first (and only) message 
> > box and be happy.

How about aggregating all the errors/warnings in a single dialog box as a list? 
E.g. the list would have fields like "message" and "file", and would allow the 
user to easily see all that went wrong and what files were involved. He could 
then select multiple entries and perform the same action on them, if 
applicable. E.g. if the message was "destination already exists, replace or 
skip?" he could select some of the entries and perform "ignore", but perform 
"replace" on others. The copying could continue in the background, and the 
replacements would be performed only once the user confirms then.


- Ambroz


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106052/#review17531
---


On Aug. 16, 2012, 12:18 p.m., Dan Vratil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106052/
> ---
> 
> (Updated Aug. 16, 2012, 12:18 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Description
> ---
> 
> Display a warning when CopyJob fails to enter a subdirectory and thus can't 
> copy it's content.
> 
> 
> Diffs
> -
> 
>   kdeui/jobs/kdialogjobuidelegate.cpp fe48f87 
>   kio/kio/copyjob.h eb88c7a 
>   kio/kio/copyjob.cpp 8dde763 
>   kio/kio/job.cpp a7e1baf 
>   kio/kio/jobclasses.h de27f40 
> 
> Diff: http://git.reviewboard.kde.org/r/106052/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Vratil
> 
>

Re: Review Request: Show warning when CopyJob fails to list a subdir

[Ambroz Bizjak]

> On Aug. 16, 2012, 1:10 p.m., Frank Reininghaus wrote:
> > kdeui/jobs/kdialogjobuidelegate.cpp, line 92
> > <http://git.reviewboard.kde.org/r/106052/diff/1/?file=78076#file78076line92>
> >
> > I'm afraid the users suffering from 
> > https://bugs.kde.org/show_bug.cgi?id=206500 will kill us if they get a 
> > message box for every single file. Right now, they have the option to wait 
> > until the operation is completed, then close the first (and only) message 
> > box and be happy.
> 
> Ambroz Bizjak wrote:
> How about aggregating all the errors/warnings in a single dialog box as a 
> list? E.g. the list would have fields like "message" and "file", and would 
> allow the user to easily see all that went wrong and what files were 
> involved. He could then select multiple entries and perform the same action 
> on them, if applicable. E.g. if the message was "destination already exists, 
> replace or skip?" he could select some of the entries and perform "ignore", 
> but perform "replace" on others. The copying could continue in the 
> background, and the replacements would be performed only once the user 
> confirms then.
> 
> Dan Vratil wrote:
> But you can get multiple kinds of warnings during the operation. How 
> would you separate them? You would either have to have a separate dialog for 
> each kind of error or a very complex UI dialog. In general I like the idea of 
> a box "These files failed to copy" (similar to the Delete Files dialog), but 
> I think that simple 'OK' would be enough. Ideas?

Yes, that's a good idea. When a file fails to copy, pop up the "These files 
failed to copy" dialog, but when another file fails, just add it to the list in 
the existing dialog. User can click "OK" which closes the dialog, and if more 
files fail, another one pops up. Small problem though: what happens if the user 
clicks OK, without noticing that another file was added to the list just before 
he closed the dialog? Maybe a safeguard should be added that no less than N 
seconds may pass from the time the last file was added to when the user clicks 
OK.


- Ambroz


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106052/#review17531
---


On Aug. 16, 2012, 12:18 p.m., Dan Vratil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106052/
> ---
> 
> (Updated Aug. 16, 2012, 12:18 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Description
> ---
> 
> Display a warning when CopyJob fails to enter a subdirectory and thus can't 
> copy it's content.
> 
> 
> Diffs
> -
> 
>   kdeui/jobs/kdialogjobuidelegate.cpp fe48f87 
>   kio/kio/copyjob.h eb88c7a 
>   kio/kio/copyjob.cpp 8dde763 
>   kio/kio/job.cpp a7e1baf 
>   kio/kio/jobclasses.h de27f40 
> 
> Diff: http://git.reviewboard.kde.org/r/106052/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Vratil
> 
>