[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
Kevin Krammer posted on Tue, 26 Jul 2011 10:58:55 +0200 as excerpted: > It is less a matter of shipping system level configuration modules as > part of a KDE product release (though there are some that can suitably > implemented across distributions/platforms), but more about providing > the infrastructure for integration of distribution/platform specific > tools. > > The general idea was that users would have a central point of access for > changing settings, similar to what known proprietary platforms have. > Unfortunately but understandably differentiation needs between vendors > makes providing distinctly recognizable system configuration tools a > higher priority than integration. What about taking John Woodhouse's idea, going the full distance and simply calling it... Settings ...? That gets rid of the the "system settings that aren't system" problem entirely, while still enabling distros to add their own non-kde- related kcms, etc, if desired? If we're going hopelessly generic, run with it! The damage is already done, so we might as well go the full distance and eliminate the other problems of trying to qualify what the settings are, as well. Either that or go back to a clearly kde name, and let system settings appear somewhere else, keeping the concepts separate. But I really like his idea. So simple and powerful. The only thing wrong with it, if the aim is indeed to "genericize" things, is I didn't think of it first! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
On Sunday, 2011-07-24, Duncan wrote: > One thing that was pointed out on the thread (by a gnome guy, AFAIK, but > I believe he was right) is that kde-anything (and by extension k- > anything) rather short-circuits the big kde software collection or > whatever it is they call it (kde-sc, but I never remember what the "c" > is, collection, collaboration, some such) rebranding, where kde doesn't > stand for K desktop environment any longer (I've read that the K was for > Kool at one point, but that predates me), but rather, the project behind > it, with the "software collection" or whatever it is being the primary > common output of the project. I don't think that's related. Getting rid of the k-something notation predates the clarification of product names and not matter which of the products a program created by KDE belongs to it is a KDE program. > Another argument that I believe I've seen is that some distributions > wanted to include their own kcms (kcontrol modules, BTW, and last I > checked, /that/ bit hadn't changed) for (real) system settings. > > But that doesn't hold water here because (1), that's not what kde ships, > nor does it really make a lot of sense for kde to try to ship distro- > specific system tools, so (2) distros can and some actually are or were > with 3.x already renaming it, as part of their customizations, and that's > hardly a reason in itself to change upstream kde, when it's not system > settings as they ship it. It is less a matter of shipping system level configuration modules as part of a KDE product release (though there are some that can suitably implemented across distributions/platforms), but more about providing the infrastructure for integration of distribution/platform specific tools. The general idea was that users would have a central point of access for changing settings, similar to what known proprietary platforms have. Unfortunately but understandably differentiation needs between vendors makes providing distinctly recognizable system configuration tools a higher priority than integration. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
John Woodhouse posted on Mon, 25 Jul 2011 09:43:28 -0700 as excerpted: > I didn't have any problem with Kcontrol really and in real terms there > is no reason why it shouldn't still be called that but in my view a more > apt title would be Settings. That can grow without problem and bears no > relationship to control panel or the like. That's actually a very reasonable idea. =:^) It could then be kde, while including more global settings as appropriate, without being mislabeled at all. Just... Settings. If they're going to be generic, be generic. That would indeed eliminate much of the mislabeling problem. I still think it's too generic, but if you can't beat them playing against them, join them and beat them at their own game! =:^) > Not that I hate windoze and everything to do with it. Um... was that supposed to be "Note"? Because that could be read as that you do /not/ hate it, or as a misspelling of "note"... that you /do/ hate it. =:^\ > Once in it as it stands I have to wonder. Account details for instance, > surely that should be admin. Not really. Admin would be if you were managing /other/ user's accounts. Of course, in the context of /system/ settings, that's what one might take it to be... until they looked and saw differently. The point being it's not system settings after all. (But your idea works great, just call it "Settings" and poof, that problem vanishes!) The password and user access and kwallet settings are primarily identity management and authentication, so account details... works. So does social desktop, for the same reason. What doesn't quite work there is web shortcuts. IMO they belong elsewhere. > Then there is "Common Appearance and > Behaviour" against "Workspace Appearance and Behaviour". Both sound > vaguely similar to me - Desktop Settings. And then there is File > Associations, now just where should that be. To a developer's way of thinking, there's a distinction. Unfortunately it's not one a user tends to care about or even consider, even when their nose is rubbed in it, as here. I only sort of understood the distinction myself, and often ended up looking in both locations for whatever module, until just now, triggered by your reply forcing me to think about it more myself. Here's the distinction. Remember, think of it as a kde developer would and it should make more sense: "_Common_ appearance and behavior" refers to settings that would normally be individual app settings, except that in kde, the (default) settings are /common/ to many applications. If any of the main kde apps wasn't part of kde, it would still be useful for that app to have appearance settings (fonts, colors, icons, etc), control how it notified you of various events (the notifier settings, if it's an app that logs in to an account somewhere, user-name and password settings for that (the account details), language and measurement unti settings (locale), shortcuts and gestures (these could be seen as corresponding to notifications, but going the other way, user notifying the app, not app notifying the user), and what files are associated with the app. Now for an individual app to have all the settings available here wouldn't be practical as it'd be simply too much to manage for every individual app, both for the user and the developer. However, there'd very likely be some subset of all these. But because the settings here are held in common across a whole bunch of apps, the per-app investment of resources is far lower even as the amount of customization available is far higher, making it far more practical to manage both from the developer and the user perspective. But the key here is that these settings are something MOST KDE APPS HAVE IN *COMMON*. That brings us to "_workspace_ appearance and behavior". In contrast with the above, these are NOT settings controlling attributes of individual applications, but of the supporting infrastructure itself, mainly of the window manager (kwin) and the desktop/panel app (plasma- desktop). Desktop effects? X/kwin. Window decorations? kwin. Cursor theme? X/kwin. Desktop theme? plasma. Splash screen? I'm not actually sure on that, but it's obviously kde infrastructure, not a quality of a bunch of apps in common. Accessibility? I'd actually argue that one's in the wrong place and that it should be in Common... . Default applications and desktop search? Obviously both kde infrastructure. Window behavior? Those are all kwin again. Virtual desktops? kwin. Screen edges? I /think/ that's kwin, but I /know/ it's not individual apps. Workspace? plasma again. So there *IS* a logic to it; it's just a developer oriented logic that few users are likely to grok, as users don't care whether it's a general kde infrastructure component or a part of a bunch of apps, as long as it works and they can figure out where to configure it if they don't like the default settings. It al
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
Felix Miata posted on Sun, 24 Jul 2011 05:35:40 -0400 as excerpted: > On 2011/07/24 08:45 (GMT+0100) Peter Nikolic composed: > >> WHat was wrong with the old " Personal Settings " name as in KDE >> 3.x.x i > > Personal Settings was not a KDE moniker, but one used by openSUSE and > maybe some other distros. /That's/ why I didn't remember that, but kcontrol. >> could never understand the need for change except to pre-empt this >> exact problem, After all the settings in question are for the >> individual user so if user 1 logs out and user 2 logs in user2 may >> want/need different stiings hence thay are not System but on a Per >> user basis > > Not that there's any justification for what Gnome devs did, but what > _was_ wrong with KControl? KControl still makes more sense to me, as it > doesn't imply global settings management, as opposed to user-specific > settings management, which is most of what they do. One thing that was pointed out on the thread (by a gnome guy, AFAIK, but I believe he was right) is that kde-anything (and by extension k- anything) rather short-circuits the big kde software collection or whatever it is they call it (kde-sc, but I never remember what the "c" is, collection, collaboration, some such) rebranding, where kde doesn't stand for K desktop environment any longer (I've read that the K was for Kool at one point, but that predates me), but rather, the project behind it, with the "software collection" or whatever it is being the primary common output of the project. And of course kde-sc-system-settings gets a bit long... and kdesc- settings doesn't exactly roll off the tongue either, besides looking like an app for configuring the description (long-name?) of things. =:^( I've suggested before that we take a hint from how the media dealt with very famous name-change by an equally certain famous singer, and call it "The app formerly known as kcontrol." =:^) Meanwhile, it can be noted that the recent trend, instead of starting the name with a k or at least ensuring it's in the name somewhere (amarok), has been anti-k, caligra instead of kaligra, system settings, even sometimes c in place of k altho IDR the specific example there where I saw a kde dev actually point out that they were deliberately anti-k now, with new names. That probably has something to do with the totally generic names in some cases. (I believe I also noted at one point that they could even call it the-price-of-tea-in-China-settings or some such, that's not much less accurately descriptive than system settings, especially if they had a module for setting the tea-timer toy times, for those that point out that there's a /few/ real system settings there, like the time.) Another argument that I believe I've seen is that some distributions wanted to include their own kcms (kcontrol modules, BTW, and last I checked, /that/ bit hadn't changed) for (real) system settings. But that doesn't hold water here because (1), that's not what kde ships, nor does it really make a lot of sense for kde to try to ship distro- specific system tools, so (2) distros can and some actually are or were with 3.x already renaming it, as part of their customizations, and that's hardly a reason in itself to change upstream kde, when it's not system settings as they ship it. But I don't know the real reason, except for the obvious "out with the old, in with the new", even if the old was quite accurate, descriptive and googlable/unique, while the new is none of the three. That's the most likely real reason I've come up with, even if it drives us logical types that also happen to know a DVD drive from a retractable cup holder up the wall. Heh, maybe /that's/ why the did it, precisely to try to drive their former users to something else. Makes abut as much sense as the other reasons... and does seem to match all the other behavior associated with early kde4, claiming it was ready for normal use while their own bugs stated many features weren't yet ported, or the ports were still variously broken, while pulling the support rug out from users who tried to stick with only reasonable alternative many users had, the old and still quite workable 3.5 version, after making a very big and public promise about support continuing as long as there were users. Certainly /seems/ like a calculated campaign to drive away the existing users, and which it was rather effective at doing, for many of them. So it certainly seems to match the other facts and behavior at the time. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
On 2011/07/24 08:45 (GMT+0100) Peter Nikolic composed: > WHat was wrong with the old " Personal Settings " name as in KDE 3.x.x i Personal Settings was not a KDE moniker, but one used by openSUSE and maybe some other distros. > could never understand the need for change except to pre-empt this exact > problem, After all the settings in question are for the individual user so if > user 1 logs out and user 2 logs in user2 may want/need different stiings > hence > thay are not System but on a Per user basis Not that there's any justification for what Gnome devs did, but what _was_ wrong with KControl? KControl still makes more sense to me, as it doesn't imply global settings management, as opposed to user-specific settings management, which is most of what they do. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name
On Sunday 24 July 2011 02:30:56 Duncan wrote: > GNOME & KDE Developers Go To Battle Over A Name > > http://www.phoronix.com/scan.php?page=news_item&px=OTY5OQ > > Argh! > > I've been saying both "system settings" and "system monitor" are > impossibly generic names, all along! Now this... how to put this > politically correctly... "entirely foreseeable" namespace pollution and > misrepresentation is coming home to rest! > > Seems the short term solution (at least for the settings tools) as hashed > out on the relevant lists is going to be dual names for both gnome and kde > versions. The native DE version (regardless of whether one is running kde > or gnome) will be simply "system settings", while the other one will be > labeled with the DE name. > > But, the gnome folks don't (at least presently) show their settings app > in other than gnome and unity anyway. kde system settings is shown in > all DEs because it's the way certain options in common to all kde apps > are configured, and users may wish to configure them regardless of the DE > they're running at the time. > > So, in gnome, the gnome version will be system settings, while the kde > version will be kde system settings. In kde, the gnome version doesn't > show up, and the kde version will be simply system settings. > > I don't like that idea for a couple reasons. One, an app should have a > consistent identity to avoid confusion. Two, as Emmanuele Bassi mentions > on the thread (he also mentioned my first point, but less clearly I > > thought, so I didn't quote him there): > > 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; > > He explains... > > > these are configuring the system settings, and you can hardly have two > > systems running at the same time on the same machine. > > Actually, you can; that's the whole point of virtual machines, where the > system running inside the VM doesn't even necessarily know it's running > in a VM, but the point is valid and is one I've made repeatedly on the > topic myself: global settings should be global settings and shouldn't be > confused with application (or DE specific) settings. > > As he then states... > > > applications should not be configured through the *system* settings; > > and both system settings shell should configure the same services. > > Exactly. Why should I find settings applying only to kde apps in an app > called system settings at all? Those aren't system settings, they're kde > settings, and recognizing and labeling them exactly that would have > prevented this situation in the first place. > > If I'm configuring system settings, they should apply to gnome and kde > (and generic X and qt and gtk and tk and fltk and ncurses and CLI and... > as well, where appropriate) universally. If I'm configuring only kde > settings, the name of the configuration tool (or dedicated category > within a common tool) should reflect exactly that. > > The same principle holds for user-specific vs system-global settings as > well. If it applies to only the current user, the name should reflect > that. If it applies to the system as a whole, including other users, the > name should reflect /that/. > > Simple namespace rules, really. Devs have been working with them for > years and the techniques for doing it right are well known and NOT > particularly difficult. Simply be scope aware and consistently choose > names reflecting that. It's NOT rocket science! > > But regardless of my disagreement with the short term solution, it's > quite fortunate this came up now, as the desktop summit is coming up and > now that the subject has been raised and the principles laid down, it's > quite likely that a reasonably decent longer term agreement can be > hammered out there, or at least reasonable progress made toward that end. > > It'll be interesting to watch as further developments occur in kde 4.8 > and beyond. =:^) WHat was wrong with the old " Personal Settings " name as in KDE 3.x.x i could never understand the need for change except to pre-empt this exact problem, After all the settings in question are for the individual user so if user 1 logs out and user 2 logs in user2 may want/need different stiings hence thay are not System but on a Per user basis Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.8-0.2-desktop KDE Development Platform: 4.6.00 (4.6.0) 08:39 up 1 day 10:23, 4 users, load average: 0.10, 0.03, 0.01 ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
