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.
