Re: Fixes in Git (first in stable, then merge to master)
Nicolas Alvarez wrote: > - Figure out how to solve the scripty problem. scripty does its own > conflicting commits to .desktop files in both branches, and that won't > change[1]. We probably need a custom merge tool for .desktop-like files > that ignores translations. I *think* I managed to write such a merge tool. I still need more testing and fixing. For example, if there is an actual file conflict, I'm handling it pretty badly right now (no conflict markers or anything). Also, when merging 4.7 into master, it seems that if a .desktop file was only modified in 4.7, git will do the merge automatically, bringing those 4.7 changes into master, without running the custom merge tool. Those changes would be undone again next time scripty runs. But this seems promising anyway. Stay tuned :) -- Nicolas
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
> 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. In my experience when a user has two or more DE's installed, it is because they had one installed to begin with, then they installed a package which pulled in an entirly different DE. For me, this is the most frequent cause of multiple DE's. And it is not that rare, especially for new Linux users that don't know that there are packages sitting in the same repo's designed for one DE but not the rest.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Le 23/07/2011 12:33, Emmanuele Bassi a écrit : > On 2011-07-23 at 11:27, Dodji Seketeli wrote: >> Matthias Clasen a écrit: >> >>> I don't think Shauns proposal addresses the issue, really. >> >> Why? Do you have an example that would show where Shaun's proposal >> falls short? > > it falls short in showing: > > System Settings > KDE System Settings > > under Gnome, and: > > System Settings > Gnome System Settings > > under KDE. > > now, if you got a computer without having it installed yourself, and you > read the applications list, do you know what "KDE" or "Gnome" are? 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. > applications should not be configured through the *system* settings; and > both system settings shell should configure the same services. Agreed. > >>> If you want an app to be usable in different environments, then there >>> are some good solutions: >>> - make sure the app is self-contained and manages all of its settings itself >>> - make your app smart enough to pick up the relevant settings from the >>> different environments you want to support >>> >>> And there are bad solutions, including: >>> - making the app drag along half of its original environment, via >>> dependencies Agreed as well, but very few applications actually depends on KDE system settings. At least on my Ubuntu box, only knemo and kinfocenter do (if apt-cache rdepends is to be trusted) and they are system-related utilities. >> >> You don't say why these would better address the issue "here and now" in >> comparison with what Shaun is proposing. > > 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. Aurélien
Go Daddy root certificates
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 signature.asc Description: This is a digitally signed message part.
Re: Re: moving libkface and libkmap from kdereview to extragear/libs.
A Dimecres, 13 de juliol de 2011, Gilles Caulier vàreu escriure: > 2011/7/12 İsmail Dönmez > > > Hi; > > > > 2011/7/12 Alexander Neundorf > > > >> On Tuesday 12 July 2011, Gilles Caulier wrote: > >> > 2011/7/12 Alex Merry > >> > > >> > > On 12/07/11 08:06, Gilles Caulier wrote: > >> > >> It's fine for me to change libkmap to libkgeomap. > >> > >> > >> > >> What's about libkface, which is a KDE libface interface to perform > >> > >> facial detection on image and later (under development) facial > >> > >> recognition. > >> > >> I wouldn't mind libkfacerecognition. Makes it completely clear what it is. > >> > > > > Please decide on names & version numbers before we (distro packagers) ship > > it. > > > > Version numbers are fine. > > For name i resume by : > > - libkmap need to be changed to libkgeomap You only renamed the repository, as far as i understand what people did not like was having files named like "libkmap_export.h" being installed so probably you should rename the files (at least the "public" ones) It'd be cool if you fixed your Messages.sh too, and if you used KCatalogLoader to make sure the translations are loaded that'd be grand. Albert > > - libkface still libkface > > Fine for all ? > > If yes i will open first a file in B.K.O about moving libkface to > extragear/libs > > In second stage libkmap need to be patched (+ digiKam and kipi-plugins) > before to open a new file in B.K.O about. > > Gilles Caulier > > > > > > > Thanks, > > ismail > > > >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Saturday, July 23, 2011 04:41:05 AM Ben Cooksley wrote: > Hi, > > I find what is proposed by Shaun to be acceptable, as the distinction > between the two is clearly defined. It still allows users to determine > the correct System Settings application to use to configure KDE > applications with what is probably the most minimal level of > confusion. > > KDE System Settings will continue to be called System Settings under > KDE, but will be called "KDE System Settings" under all other > environments. > > Unfortunately, this is too late for KDE 4.7. Had I been contacted when > the decision to use the name System Settings under GNOME, this entire > issue could have been avoided - which I think everyone would have > preferred. > > If any GNOME components exist which do similar using of global names, > particularly in the space of preferences, it would be much appreciated > if you take similar steps. > > @Matthias: please explain how this doesn't solve the issue. > > If anyone has any other comments to make on this, please do. I'll make > the needed adjustments once KDE 4.7 has been released, unless > objections are raised. This will, clearly, run afoul of the KDE rebranding strategy where KDE is a community and not a piece (or collection) of software. Personally I think that says more about the rebranding strategy than this proposal, but this aspect of it should be considered. Scott K
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sat, Jul 23, 2011 at 4:41 AM, Ben Cooksley wrote: > @Matthias: please explain how this doesn't solve the issue. It certainly solves the immediate symptom of 'two things in the menu are named the same'.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sat, Jul 23, 2011 at 12:55 PM, Dodji Seketeli wrote: > Emmanuele Bassi a écrit: > >> On 2011-07-23 at 11:27, Dodji Seketeli wrote: >>> Why? Do you have an example that would show where Shaun's proposal >>> falls short? >> >> it falls short in showing: >> >> System Settings >> KDE System Settings >> >> under Gnome, and: >> >> System Settings >> Gnome System Settings >> >> under KDE. > > Oh, I see. > >> the real solution is to make it unnecessary (or even conflicting) to >> install the KDE system settings shell under a Gnome environment, and the >> Gnome system settings under a KDE environment; > > That would be a more elegant situation, IMO. > > >> these are configuring the system settings, and you can hardly have two >> systems running at the same time on the same machine. > > Agreed. > >> applications should not be configured through the *system* settings; >> and both system settings shell should configure the same services. > > This makes sense to me. > >>> You don't say why these would better address the issue "here and now" in >>> comparison with what Shaun is proposing. >> >> 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. > > My point was to have the options written down and have interested people > explicitly say why a particular point is valid or not, rather than just > bluntly dismissing someone's point as being a non-solution without > providing rationale. > > As for the "here and now", I don't personally perceive this issue as > urgent as I use GNOME only. But I could imagine that some people do. 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
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Emmanuele Bassi a écrit: > On 2011-07-23 at 11:27, Dodji Seketeli wrote: >> Why? Do you have an example that would show where Shaun's proposal >> falls short? > > it falls short in showing: > > System Settings > KDE System Settings > > under Gnome, and: > > System Settings > Gnome System Settings > > under KDE. Oh, I see. > the real solution is to make it unnecessary (or even conflicting) to > install the KDE system settings shell under a Gnome environment, and the > Gnome system settings under a KDE environment; That would be a more elegant situation, IMO. > these are configuring the system settings, and you can hardly have two > systems running at the same time on the same machine. Agreed. > applications should not be configured through the *system* settings; > and both system settings shell should configure the same services. This makes sense to me. >> You don't say why these would better address the issue "here and now" in >> comparison with what Shaun is proposing. > > 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. My point was to have the options written down and have interested people explicitly say why a particular point is valid or not, rather than just bluntly dismissing someone's point as being a non-solution without providing rationale. As for the "here and now", I don't personally perceive this issue as urgent as I use GNOME only. But I could imagine that some people do. -- Dodji
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On 2011-07-23 at 11:27, Dodji Seketeli wrote: > Matthias Clasen a écrit: > > > I don't think Shauns proposal addresses the issue, really. > > Why? Do you have an example that would show where Shaun's proposal > falls short? it falls short in showing: System Settings KDE System Settings under Gnome, and: System Settings Gnome System Settings under KDE. now, if you got a computer without having it installed yourself, and you read the applications list, do you know what "KDE" or "Gnome" are? this is a non-solution, and an abdication of responsibility. the real solution is to make it unnecessary (or even conflicting) to install the KDE system settings shell under a Gnome environment, and the Gnome system settings under a KDE environment; these are configuring the system settings, and you can hardly have two systems running at the same time on the same machine. applications should not be configured through the *system* settings; and both system settings shell should configure the same services. > > If you want an app to be usable in different environments, then there > > are some good solutions: > > - make sure the app is self-contained and manages all of its settings itself > > - make your app smart enough to pick up the relevant settings from the > > different environments you want to support > > > > And there are bad solutions, including: > > - making the app drag along half of its original environment, via > > dependencies > > You don't say why these would better address the issue "here and now" in > comparison with what Shaun is proposing. 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. 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
Denis Washington a écrit: > Am 23.07.2011 11:54, schrieb Giovanni Campagna: >> Il giorno sab, 23/07/2011 alle 11.27 +0200, Dodji Seketeli ha scritto: >>> Matthias Clasen a écrit: >>> I don't think Shauns proposal addresses the issue, really. >>> >>> Why? Do you have an example that would show where Shaun's proposal >>> falls short? >> >> You have two .desktop files, matching the same application, so it is >> possible gnome-shell, unity or kde could pick the wrong one when >> matching desktop files to windows (unless you tweak Exec to pass >> --class, but that fails again with single-instance applications) > > But one of them is hidden via [Not]OnlyShowIn. There should be code in > all desktop's .destkop file matchers to prefer the files tailored to > the respective environment, and if not, it is easy enough to add. Exactly. > I think everyone here agrees that this more a less a temporary measure > and that other long-term solutions such as better cross-desktop > settings integration is in order. I couldn't agree more. Giovanni Campagna a écrit: [please don't CC me in your replies. I am subscribed to at lease one of the lists in the To: field] >> > If you want an app to be usable in different environments, then there >> > are some good solutions: >> > - make sure the app is self-contained and manages all of its settings >> > itself >> > - make your app smart enough to pick up the relevant settings from the >> > different environments you want to support >> > >> > And there are bad solutions, including: >> > - making the app drag along half of its original environment, via >> > dependencies >> >> You don't say why these would better address the issue "here and now" in >> comparison with what Shaun is proposing. > > You get to configure your apps once for both Gtk and Qt apps, which is > better for the user and makes the system more consistent > In particular, I underline "Gtk and Qt": you don't write GNOME apps, and > you don't write KDE apps, you write Gtk and Qt (or Qt+kdelibs) apps, and > then the toolkits adapts themselves to the environment. If you can write > a Qt+kdelibs app that work on windows or mac os x, you can make it work > out of the box in GNOME, without dragging in the entire workspace. You forgot the "here and now" part in my question. You just can't do what Mathias is proposing /quickly/ enough. It would seem to me that we need a stop gap measure now, while we carefully think about something more streamlined and future proof to be crafted later. -- Dodji
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Hi, I find what is proposed by Shaun to be acceptable, as the distinction between the two is clearly defined. It still allows users to determine the correct System Settings application to use to configure KDE applications with what is probably the most minimal level of confusion. KDE System Settings will continue to be called System Settings under KDE, but will be called "KDE System Settings" under all other environments. Unfortunately, this is too late for KDE 4.7. Had I been contacted when the decision to use the name System Settings under GNOME, this entire issue could have been avoided - which I think everyone would have preferred. If any GNOME components exist which do similar using of global names, particularly in the space of preferences, it would be much appreciated if you take similar steps. @Matthias: please explain how this doesn't solve the issue. If anyone has any other comments to make on this, please do. I'll make the needed adjustments once KDE 4.7 has been released, unless objections are raised. Regards, Ben Cooksley KDE System Settings Maintainer.
Re: Re: Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 19:28:53 Ben Cooksley wrote: > >> During the stable branch freeze before a minor version release (such as > >> currently before > > the 4.7 release), it isn't possible to commit bug fixes to stable first and > > then merge to master. > > Only master can be committed to, so presumably we'll have to continue to > > commit to master > > and cherry-pick later once the freeze ends. Either that or change the > > policy on freezes. > > Seriously: is this technically enforced or is it believed that developers > > know about it? > > Technically enforced: No > > All developers should know about it, as they were sent a set of > instructions from sysadmin when they gained access to KDE SCM servers. > A copy of it can be found at > http://websvn.kde.org/trunk/kde-common/svn/svn_git_instructions.txt?view=markup > > It contains a link to > http://techbase.kde.org/Policies/SVN_Commit_Policy (which also applies > to git i'll add) > That has a section "Respect commit policies set by the Release Plans". Please understand that what I pointed out is in no way any disrespect for the release team. I just want to point out that such community rules can easily be missed if not technically enforced and that such freezes are very fuzzy and maybe unknown. In comparison for feature freezes all KDE developers are notified through the cvs mailinglist. > > > Personally I have no idea when the stable branch will be tagged or > > released. I commit to the > > stable branch in order to fix a bug and in the hope that it will some day > > end on the users' > > systems. But I do not care when this will happen and I never was blocked > > because of some > > tagging freeze. > > > > We have Release Plans published on the wiki, and available as an ics > file on www.kde.org which matches that for use in Kontact, etc. The release plan states for final tagging: "The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed." Given that all deadlines are due 23:59 UTC I understand that I can commit all the day and that the tagging appears directly at 00:00 UTC which will immediatelly unfreeze the branch for fixes to 4.7.1. That is exaggerated, but points out a problem: there is no unfreeze date specified. Given that Dirk does not tag immediatelly, it is for a developer completely imprecticale to know when it is allowed again to commit. Without technical enforcement such freezes just cannot work. For minor releases there is no freeze at all: "A KDE minor release is tagged and made available to the packagers." 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 Fri, Jul 22, 2011 at 5:53 PM, Jeremy Bicha wrote: > On 22 July 2011 17:17, Ben Cooksley wrote: > To be more specific about the problem, installing kde-workspace to a > GNOME installation results in 2 indistinguishable apps named System > Settings and 2 named System Monitor. On Ubuntu at least, if I want the > GNOME version, I have to remember to click the first System Monitor > but the second System Setting which is awfully frustrating. Here's a > screenshot from my Ubuntu install: > https://launchpadlibrarian.net/75745040/Gnome%20Shell%20screnshot.png This is what happens when you mix and match bits and pieces from different operating systems. There is really not much that can be done about it. Since that is what both KDE and GNOME are trying to do: build complete, self-contained systems. Arguably, KDE is a little further along, with their big monolithic modules like kde-workspace that drag in most of the desktop, while GNOME apps can often still be installed without much of the desktop. > I'd like to suggest that the GNOME developers consider changing the > public name of their app to "System Preferences." This matches the Mac > OS X design and arguably GNOME follows some parts of OS X design. > Furthermore, it is more in line with Gnome 2's System>Preferences and > System>Administration. That is an absurd proposal. What next, rename gnome-terminal to 'Commandline Window' because Xfce also ships a 'Terminal' ?! Generic names don't come with exclusive ownership... And as has already been pointed out, offering the user a meaningless choice between 'System Settings' and 'System Preferences' is no less of a failure than having 2 identical items.
Re: Re: Fixes in Git (first in stable, then merge to master)
On Sat, Jul 23, 2011 at 6:52 PM, Martin Gräßlin wrote: > On Saturday 23 July 2011 01:42:16 David Jarvie wrote: >> On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: >> > There is no active policy saying you're supposed to merge. Almost everybody >> > in KDE is still doing cherry-picks. KDevelop is the only KDE project I know >> > that consistently uses forward-merges from the stable branch to master. >> > >> > --- >> > >> > It *would* be good to switch to the new workflow of doing changes in the >> > lowest supported branch and up-merging, but it's not that easy. We need to: >> > >> > - Figure out how to solve the scripty problem. scripty does its own >> > conflicting commits to .desktop files in both branches, and that won't >> > change[1]. We probably need a custom merge tool for .desktop-like files >> > that >> > ignores translations. >> > >> > - Check if there is any change in 4.7 that isn't in master, and if so, see >> > if that's intentional (4.7-specific hack, or the version bumps) or an >> > oversight (never cherry-picked into master). >> > >> > - Do the initial merge from 4.7 to master, solving the conflicts. The more >> > they have diverged, the harder this is. >> > >> > - Get *everyone* to start with the new workflow for that particular >> > repository (see below). Else, if some people keep cherry-picking while >> > others expect merging, the next one to try merging may get conflicts about >> > all the cherry-picks people did since the last merge, and a merge will make >> > commits appear duplicated in the log (as ossi pointed out to me). >> >> During the stable branch freeze before a minor version release (such as >> currently before > the 4.7 release), it isn't possible to commit bug fixes to stable first and > then merge to master. > Only master can be committed to, so presumably we'll have to continue to > commit to master > and cherry-pick later once the freeze ends. Either that or change the policy > on freezes. > Seriously: is this technically enforced or is it believed that developers > know about it? Technically enforced: No All developers should know about it, as they were sent a set of instructions from sysadmin when they gained access to KDE SCM servers. A copy of it can be found at http://websvn.kde.org/trunk/kde-common/svn/svn_git_instructions.txt?view=markup It contains a link to http://techbase.kde.org/Policies/SVN_Commit_Policy (which also applies to git i'll add) That has a section "Respect commit policies set by the Release Plans". > Personally I have no idea when the stable branch will be tagged or released. > I commit to the > stable branch in order to fix a bug and in the hope that it will some day end > on the users' > systems. But I do not care when this will happen and I never was blocked > because of some > tagging freeze. > We have Release Plans published on the wiki, and available as an ics file on www.kde.org which matches that for use in Kontact, etc. > So unless this is not technically enforced, the policy are nice words which I > beleive nobody > cares about. > > Cheers > Martin Regards, Ben
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Fri, Jul 22, 2011 at 8:48 PM, Luca Ferretti wrote: > What about, instead, Shaun's proposal? It seems reasonable to me > (while I like to test it) and we could do the same in GNOME stuff > (while it's additional work for maintainers and tranlators). I don't think Shauns proposal addresses the issue, really. If you want an app to be usable in different environments, then there are some good solutions: - make sure the app is self-contained and manages all of its settings itself - make your app smart enough to pick up the relevant settings from the different environments you want to support And there are bad solutions, including: - making the app drag along half of its original environment, via dependencies
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
> This is what happens when you mix and match bits and pieces from > different operating systems. There is really not much that can be done > about it. Since that is what both KDE and GNOME are trying to do: > build complete, self-contained systems. So far we are running the same OS (for most of us it is Linux, but it can be Solaris or *BSD). DE != OS. And the system can be multiuser - which sometimes means both KDE and GNOME can be present in the same installation. Also, some, especially semi-professional apps are not going to be duplicated in both environments (I am not talking about text editors or calculators) - so there are relatively high chances that the user would need both sets of settings, for KDE and GNOME (in that sense having ShowOnlyIn can be a bad idea - some "foreign" apps would become not configurable). The best idea really would be to define the mechanism of feeding the settings into "foreign" apps. Both directions, GNOME (desktop) ->KDE (apps) and KDE (desktop) -> GNOME (apps). If we have that, in addition to ShowOnlyIn, user could never notice that the system has two variants of "System Settings". The only problem with that approach is that some settings can be defined only in one DE. In that case, sane default values could be the only choice.. Sergey
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Sat, Jul 23, 2011 at 09:17:17AM +1200, Ben Cooksley wrote: > > > > Now lets go into something more productive and perhaps we can fix this > > before the sunny Desktop Summit. > > Hi Olav, > > In terms of being productive surrounding this, I have several questions: > > Screenshots on your live wiki indicate that GNOME developers were > aware of the use of the "System Settings" name by KDE. Why did your > developers deliberately proceed with the use of this name, knowing it > would cause a conflict? (This was the primary reason why I was > particularly angry about the discovery of your use of this name) I don't own any developers, nor am I a GNOME developer (see end of the email for list of the things I do for GNOME). This said, I think it was already mentioned that 'System Settings' was purposely limited to GNOME and later Unity. So care was taken to ensure KDE would not have a confusing menu entry. The rest I'd guess is either oversight, different assumptions or just lack of time. > Is there any reason why it cannot be renamed once more as soon as is > possible so that the next release your team makes fixes this issue? This has been explained already I think. Be aware that I don't have any team. > I would prefer to resolve this issue as soon as possible, to minimise > the work packagers will inevitably do to block KDE System Settings > under GNOME, and the resulting KDE application user support issues > that will arise. I think I explained that I was speaking as a moderator. I'm also in the GNOME release team, GNOME sysadmin team and a bugmaster. In none of those things I've noticed this. Regarding release team: We almost always let developers decide things and gently steer things in the right direction. See https://live.gnome.org/ReleasePlanning if you want more background on how things are done @ GNOME. Not sure how it works in KDE, but although I have my own opinion on this topic, I prefer leave this to the developers. I've noticed some of the replies you've got are a bit harsh. This is not how a discussion should be and this is why I responded + cc'ed the mailing list (to prevent it). I really care that a discussion is being held nicely (assume people mean well + somewhat concise in the amount of messages) and step in when it is not. Regarding this topic: Various GNOME developers have already replied, suggest to continue the discussion with them and I'll just lurk. -- Regards, Olav
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Hello, Why not use Gnome System Settings and KDE System Settings instead? So this can be visible in both environments, and the user will know what he needs to change. Internally I believe both can keep System Settings. Using Gnome/KDE System Settings the user will know which one he want's to use. Regards, Arx Cruz On Fri, Jul 22, 2011 at 9:50 PM, Sergey Udaltsov wrote: > > This is what happens when you mix and match bits and pieces from > > different operating systems. There is really not much that can be done > > about it. Since that is what both KDE and GNOME are trying to do: > > build complete, self-contained systems. > So far we are running the same OS (for most of us it is Linux, but it > can be Solaris or *BSD). DE != OS. And the system can be multiuser - > which sometimes means both KDE and GNOME can be present in the same > installation. Also, some, especially semi-professional apps are not > going to be duplicated in both environments (I am not talking about > text editors or calculators) - so there are relatively high chances > that the user would need both sets of settings, for KDE and GNOME (in > that sense having ShowOnlyIn can be a bad idea - some "foreign" apps > would become not configurable). > > The best idea really would be to define the mechanism of feeding the > settings into "foreign" apps. Both directions, GNOME (desktop) ->KDE > (apps) and KDE (desktop) -> GNOME (apps). If we have that, in addition > to ShowOnlyIn, user could never notice that the system has two > variants of "System Settings". The only problem with that approach is > that some settings can be defined only in one DE. In that case, sane > default values could be the only choice.. > > Sergey > ___ > desktop-devel-list mailing list > desktop-devel-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
2011/7/23 Matthias Clasen : >> I'd like to suggest that the GNOME developers consider changing the >> public name of their app to "System Preferences." This matches the Mac >> OS X design and arguably GNOME follows some parts of OS X design. >> Furthermore, it is more in line with Gnome 2's System>Preferences and >> System>Administration. > > That is an absurd proposal. What next, rename gnome-terminal to > 'Commandline Window' because Xfce also ships a 'Terminal' ?! > Generic names don't come with exclusive ownership... > > And as has already been pointed out, offering the user a meaningless > choice between 'System Settings' and 'System Preferences' is no less > of a failure than having 2 identical items. Matthias, please, I suppose this thread doesn't need your aggressiveness. What about, instead, Shaun's proposal? It seems reasonable to me (while I like to test it) and we could do the same in GNOME stuff (while it's additional work for maintainers and tranlators).
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On 23/07/11 00:25, Shaun McCance wrote: I very much doubt users will be any less confused when confronted with "System Settings" and "System Preferences". Especially as in other languages, there are not always two words for this (e.g. German). There's a very easy way to use a different application name under different desktops. Just install two .desktop files. One looks like this: Name=System Settings OnlyShowIn=KDE The other looks like this: Name=KDE System Settings NotShowIn=KDE That seems to solve the language problem.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Fri, 2011-07-22 at 17:53 -0400, Jeremy Bicha wrote: > On 22 July 2011 17:17, Ben Cooksley wrote: > >> > >> Now lets go into something more productive and perhaps we can fix this > >> before the sunny Desktop Summit. > > > > Hi Olav, > > > > In terms of being productive surrounding this, I have several questions: > > > > Screenshots on your live wiki indicate that GNOME developers were > > aware of the use of the "System Settings" name by KDE. Why did your > > developers deliberately proceed with the use of this name, knowing it > > would cause a conflict? (This was the primary reason why I was > > particularly angry about the discovery of your use of this name) > > > > Is there any reason why it cannot be renamed once more as soon as is > > possible so that the next release your team makes fixes this issue? > > > > I would prefer to resolve this issue as soon as possible, to minimise > > the work packagers will inevitably do to block KDE System Settings > > under GNOME, and the resulting KDE application user support issues > > that will arise. > > > > Regards, > > Ben Cooksley > > KDE System Settings Maintainer > > To be more specific about the problem, installing kde-workspace to a > GNOME installation results in 2 indistinguishable apps named System > Settings and 2 named System Monitor. On Ubuntu at least, if I want the > GNOME version, I have to remember to click the first System Monitor > but the second System Setting which is awfully frustrating. Here's a > screenshot from my Ubuntu install: > https://launchpadlibrarian.net/75745040/Gnome%20Shell%20screnshot.png > > GNOME happily has the OnlyShowIn:Gnome,Unity key set for > gnome-control-center but KDE is unwilling to do the same because that > is the only way to change important preferences that affect KDE apps > in general. > > I'd like to suggest that the GNOME developers consider changing the > public name of their app to "System Preferences." This matches the Mac > OS X design and arguably GNOME follows some parts of OS X design. > Furthermore, it is more in line with Gnome 2's System>Preferences and > System>Administration. I very much doubt users will be any less confused when confronted with "System Settings" and "System Preferences". We should work on shared groundwork so that our settings are interoperable. If a user has to set his language in two different applications just because he happens to use applications written in two different toolkits, we have failed miserably. However, if the here-and-now requires this duplication, then I don't think it's right for any application to use a generic name outside its target desktop. Having the KDE System Settings show up as just "System Settings" under GNOME is confusing to GNOME users. Just as it would be confusing if I made Yelp show up as "Help" in KDE. There's a very easy way to use a different application name under different desktops. Just install two .desktop files. One looks like this: Name=System Settings OnlyShowIn=KDE The other looks like this: Name=KDE System Settings NotShowIn=KDE You just can't expect to own generic names across desktops. -- Shaun
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On 22 July 2011 17:17, Ben Cooksley wrote: >> >> Now lets go into something more productive and perhaps we can fix this >> before the sunny Desktop Summit. > > Hi Olav, > > In terms of being productive surrounding this, I have several questions: > > Screenshots on your live wiki indicate that GNOME developers were > aware of the use of the "System Settings" name by KDE. Why did your > developers deliberately proceed with the use of this name, knowing it > would cause a conflict? (This was the primary reason why I was > particularly angry about the discovery of your use of this name) > > Is there any reason why it cannot be renamed once more as soon as is > possible so that the next release your team makes fixes this issue? > > I would prefer to resolve this issue as soon as possible, to minimise > the work packagers will inevitably do to block KDE System Settings > under GNOME, and the resulting KDE application user support issues > that will arise. > > Regards, > Ben Cooksley > KDE System Settings Maintainer To be more specific about the problem, installing kde-workspace to a GNOME installation results in 2 indistinguishable apps named System Settings and 2 named System Monitor. On Ubuntu at least, if I want the GNOME version, I have to remember to click the first System Monitor but the second System Setting which is awfully frustrating. Here's a screenshot from my Ubuntu install: https://launchpadlibrarian.net/75745040/Gnome%20Shell%20screnshot.png GNOME happily has the OnlyShowIn:Gnome,Unity key set for gnome-control-center but KDE is unwilling to do the same because that is the only way to change important preferences that affect KDE apps in general. I'd like to suggest that the GNOME developers consider changing the public name of their app to "System Preferences." This matches the Mac OS X design and arguably GNOME follows some parts of OS X design. Furthermore, it is more in line with Gnome 2's System>Preferences and System>Administration. I suspect GNOME developers would rather users not install KDE apps, but that's a narrow viewpoint. As one example, GNOME has no equivalent to the educational suite that kdeedu provides. I also don't think GNOME was intentionally malicious in choosing their app's new name but it is creating an interoperability issue that ought to be resolved. Jeremy Bicha
