Link (impossibly generic systemsettings and system monitor): GNOME & KDE Developers Go To Battle Over A Name

[Duncan]

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 all actually sounds pretty simple when it's explained that way, but as 
I said, it wasn't all that obvious to me even tho I sort of understood 
that there was a grouping, until I just now stopped to think about it 
long and hard enough to put it down in writing.  And I'd describe myself 
as sort of half way between a user and a dev, not having the skills to 
actually do much coding, but having done enough trivial stuff and admin 
stuff and hung around with and read enough developer stuff that I 
generally understand the lingo and the thought patterns (tho do NOT ask 
me to explain that "system settings" thing, 'cause I can't!).  You know 
what I was doing right before refreshing the list and seeing this post?  
Wading thru some 65k-lines of the kernel log for my latest git kernel 
pull, the commits between the kernel 3.0.0 tag and now.  I don't pretend 
to understand it all, by far, but the point is, I understood enough of it 
to actually wade thru 65-thousand-lines of kernel commit logs.  So while 
I'm not a dev, I'd say I qualify as understanding dev-speak.  Yet still, 
the distinction between "common" and "workspace" was sufficiently 
unintuitive that I didn't understand it until I tried to reply to your 
post and had to stop and think about it.

So for an ordinary user, I'm quite sure it's an /entirely/ unintuitive 
distinction.  As such, you're right, they do need to reorganize that 
again, either simply combining those two under appearance and behavior, 
or redividing it some other way, maybe splitting it into THOSE groups, 
"appearance" and "behavior", with all the colors/fonts/themes/etc under 
"appearance", and desktop effects, workspace behavior, accessibility, 
shortcuts, notification, etc, under "behavior".

> To me the whole thing needs breaking down to further levels to allow
> people to get to what ever they are after. Eg The 2 I mentioned might
> come under Desktop, we know we are in settings so there is no need for
> anything else. Desktop can then be broken down further. Other top level
> names might be Admin, Network,

...
> and yes even System to cover things like
> launches at start up, back ground searches, associations etc.

... But those aren't "system", which is part of my point.  Those are kde, 
configured for an individual user.  With certain noted exceptions, it 
doesn't make sense for kde to even ship "system" settings configuration 
options, since those simply vary too much from distro to distro to make 
it practical for kde to ship them.  (Noted exceptions would include kdm's 
settings, the clock settings in admin mode, maybe grub settings if they 
have a GUI app for that, which I wouldn't know as I'm on gentoo and 
configure that at the cli, etc.  If it's really system settings, why 
isn't kuser a kcm available under system administration?  Etc.)

> Software
> is likely to be another candidate as well but many regard KDE's attempts
> at that with disdain. I have already had problems with it so have
> others. It's best left to the distro's really and they should maintain
> it,

You mean package management?  Yes, I agree.  KDE's not the appropriate 
place for that, at least not in system settings.  kpackage or whatever is 
fine for some stuff (FLOSS is generally volunteer and if a dev has that 
itch, let them scratch it), but I don't expect it to manage debs and 
ebuilds and rpms and whatever other distro formats, including 
dependencies, building the packages for from-source distros like gentoo, 
etc, anywhere CLOSE to as well as the distro-specific or multi-distro 
format-specific tools.  kde simply isn't going to have the application-
specific knowledge and skills to pull that off properly for the wide 
variety of distros and their package-management methods out there, so 
they'll inevitably have a tool that's too broad and shallow to manage the 
task demanded of it properly.

(FWIW, this concept relates to why I recently switched to firefox as 
well.  Firefox has a large enough user base that simply by reason of 
numbers, it's going to have and does have people skilled and interested 
enough to create some pretty incredibly useful and specialized 
extensions.  One of them I use, and ultimately decided I couldn't do 
without, is no-script.  It alone must surely have nearly as much 
functionality as many basic browsers, particularly those that are simply 
shells around webkit or the like, and it's simply not being realistic to 
expect that konqueror's devs have that kind of functionality, including 
supplying scripting surrogates for stuff like google-analytics so other 
scripts that assume the google-analytics scripts are working, won't 
themselves break, even when google-analytics is disallowed because I like 
to keep a bit of privacy.  It's not realistic to ask kde devs to provide 
that based on their more general target and the size of their user base, 
and it's not realistic to expect them to magically replicate the gentoo 
portage setup that has taken a decade to develop, either.  In both cases, 
kde can provide tools that sort-of half-way manage the basics, but they 
simply aren't going to be able to compare to the very specialized tools 
iteratively developed over many years.)

-- 
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.