Re: Review Request: Show warning when CopyJob fails to list a subdir
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
Re: Default file manager and folder associations
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 toddrme2...@gmail.com wrote: On Sun, Jun 17, 2012 at 11:13 AM, Jacopo De Simoi wilder...@gmail.com 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: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
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: Formal complaint concerning the use of the name System Settings
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 thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 13:45:26 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: (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
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 thomas.luebk...@gmail.com wrote: Hi Ambroz, (and everybody else of course) Am Tue, 26 Jul 2011 20:39:27 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: 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
Re: Formal complaint concerning the use of the name System Settings
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-develm=131160689716557w=2 Regards, Ambroz On Tue, Jul 26, 2011 at 10:31 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 21:53:48 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: 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 pretty sure all the translators problems would be solved by mailing all translators something like: ... 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). You call that technical and not social? Your approach relies on perfect communication _before_ a clashing release. That sounds more like unrealistic than generic. Sorry. You'll at best be able to resolve risen clashes. And in a quite workload causing
Re: Formal complaint concerning the use of the name System Settings
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 thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 22:27:40 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: 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
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 thomas.luebk...@gmail.com wrote: Hi Ambroz, (and everybody else of course) Am Tue, 26 Jul 2011 20:39:27 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: 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
(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 mark...@gmail.com wrote: On Tue, Jul 26, 2011 at 11:48 AM, Ambroz Bizjak ambr...@gmail.com 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-develm=131160689716557w=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-name and revert to name if the former does not exist. Regards, Ambroz On Tue, Jul 26, 2011 at 9:54 AM, Mark mark...@gmail.com wrote: On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak ambr...@gmail.com 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 mark...@gmail.com wrote: On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak ambr...@gmail.com 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
Re: Formal complaint concerning the use of the name System Settings by GNOME
Hi Mark, have you seen my proposed improvement on your suggestion? http://lists.kde.org/?l=kde-core-develm=131149560119520w=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 mark...@gmail.com wrote: 2011/7/24 Ben Cooksley bcooks...@kde.org: 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-develm=131142514605051w=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
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
Mark mark...@gmail.com 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
