[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: KControl brainstorming in all its aspects
From: Frans Englich <frans.englich () telia ! com>
Date: 2004-01-07 17:41:11
Message-ID: 200401071841.11629.frans.englich () telia ! com
[Download RAW message or body]
On Wednesday 07 January 2004 15:12, Dominique Devriese wrote:
> Frans Englich writes:
> > First off, a list of name changes, feel free to answer with an ACK
> > or reject it(with explanation :)
> >
> > O:ld name N:ew name
> >
> > O: Component Chooser N: Default Applications
>
> Agree
>
> > O: Vim Component Configuration N: Vim
> > //Shouldn't this one be moved out anyway?
>
> As someone already said, Vim Embedding is better
>
> > O: KDE Wallet N: Wallet
> > //this one relies heavily on the metaphor..
>
> Again, as someone already said: Password management or sth like that
>
> > O: Peripherals N: Hardware
>
> What's wrong with Peripherals ?
>
> > O: Display Power Control N: Monitor
> > //assuming it stays in "Power Control"
>
> Yes, and move it into the hardware category, together with the laptop
> power management kcm ( you suggest this at the bottom too.. )
>
> > O: KDE Components N: ?
> > // A lot of it moved to other places anyway.
>
> Not sure either.
>
> > O: k3bsetup2 N: CD Writing
> > // or burning? This have been discussed before, I think there were
> > // some
> > translation issues..
>
> CD & DVD burning, I guess
>
> > O: Country/Region & Language N: Country & Language
>
> ACK
>
> > O: Sony Vaio Laptop Hardware N: Sony Vaio Laptop
>
> ACK
>
> > O: System Administration N: I don't know.. it sounds so
> > serious.. especially Administration..
>
> Not sure either
>
> > * We must standardize on whether to use Display or Monitor.
>
> ACK
>
> > * As William points out, in a lot of cases there's unnecessary use
> > of "Manager" and "Configuration" which is already clear. Should we
> > settle on something, allow or disallow it? In either case, it must
> > apply consistenly.
>
> ACK
>
> > ------------- Moves/Refactoring/Merging --------------
> >
> > * Merge "Appearance & Themes/Panel" and, ehh, "Desktop/Panel". I
> > have a patch for this.
>
> I haven't looked at the patch, but the idea seems good.
>
> > * Remove "Peripherals/Monitor Gamma" - it's available as a tab in
> > Display(!). It's amazingly that this duplication have not been
> > discovered before. A NoDisplay=true for 3.2?
>
> I'm still running 3.1, so I have no idea. Mail core-devel about it if
> it's really urgent and not yet fixed.
>
> > * Move everything in "Power Control" to "Peripherals"("Hardware")
>
> ACK
>
> > * Merge "Power Control/Display Power Control" with
> > "Peripherals/Monitor"
>
> ACK
>
> > * "Internet & Network/Preferences" must somehow be removed.. Come
> > on.. the timeout values really doesn't need to be changeable and
> > "Mark partially uploaded files" can be set as default. I don't
> > know about passive FTP.
>
> Very much ACK ! Passive FTP can probably always be used too. Maybe
> the ftp kioslave can detect if a server does not support passive ftp,
> and fall back to normal ftp in that case.
Nice! If we step as side from any implementation issues this is a perfect
example of how to reduce options - instead of having the user do the decision
the app acts intelligently. Computing in it essence.
>
> > * "Sound & Multimedia/Mixer" will probably be removed. Christian
> > Esken will see to it if I understood him correctly.
>
> Please see this bug too:
> http://bugs.kde.org/show_bug.cgi?id=72003
>
> > * Remove "System Administration/Linux Kernel"(into "KAdmin"). This
> > is too much demanded by a regular KDE user..
>
> I disagree with the entire idea behind this KCM. This doesn't even
> qualify the definition for a KCM. It's an app to configure the linux
> kernel at compile time. There currently is a Qt based configuration
> system in the linux kernel itself ( starting at 2.6 ), that can
> replace this thing very properly. No user will understand what this
> is for, unless he's familiar with the linux kernel compile-time
> ocnfiguration scheme. I propose removing it.
You're right on all points. Perhaps we can get a NoDisplay=true for 3.2 as
well as for LILO..
>
> > * Remove "System Administration/Boot Manager(LILO)"(into "KAdmin")
> > for the same reasons as "Linux Kernel".
>
> ACK
>
> > * Move "System Administration/Sony Vaio Laptop Hardware" to
> > "Hardware".
>
> ACK
>
> > * Remove "Desktop/Size & Orientation" - that one's too available in
> > "Peripherals/Display". A NoDisplay=true for 3.2?
>
> I'm still running 3.1, so I have no idea. Duplication is of course
> bad, and should be removed.
>
> > * Move "Spell Checker" to "Country & Accessibility".
>
> ACK.
>
> > * We distinguish between "KDE Components" and "System
> > Administration" - KDE stuff in KDE Components and everything else
> > in Sys Admin. The user can't see this difference and that's why
> > these two has to be merged.
>
> I agree for some, although IMHO, in the long term, a lot ( all ? ) of
> these need to move to KAdmin.
>
> > * The kcmshell call done by <left click desktop>->Configure Desktop
> > should include monitor-hardware settings. 3.2 change?
>
> I'm not sure if it belongs there.
The reason I proposes it is that it's the behavior of MS Windows
IIRC(consistency in other words) and I think the user when trying to do
something about the monitor will go for "Desktop". We, of course, would say
"But that's the KDesktop, not your monitor" but is a developers/advanced
users view instead of a typical user. My two cents.
>
> > * Merge "System Administration/user" account and "Internet
> > Network/Email".
>
> I disagree. I don't see the relation ?
>
> > Put it in security and privacy? (remove smtp
> > setting)
>
> Sorry ?
The settings in "User Account" and "Email" are duplicate and thus confusing
for the user. Furthermore, KDE has no global mail system and we can thus
leave the SMTP and Reply-To settings out(mail configuration out to the MUAs).
AFAIK KMail only uses it and if the user is going to configure his/her mail
the old way it will be 1) KControl->Email and then 2)KMail - it is illogical.
We basically collect the Name, Email and password settings in one place and
let both affect KDE's settings and the system settings(with descriptive tool
tips).
>
> > * In the long run a merge of "Desktop" and "Appearance & Themes".
>
> IIUC, this is being worked on in kdenonbeta/kthememanager. IMHO, the
> icons, colors, kwin themes, themes and kicker config should all be
> merged into one big kcm, where you can only select a few coherent and
> all-encompassing themes. But I guess this isn't going to happen any
> time soon :)
Yes, a big blow must be done in that area.. But as you say, a lot of stuffing
is going on so let's not interfere :)
>
> > * "KDE Performance" is konqueror specific, AFAICT. It should be
> > moved to konqueror.
>
> Doesn't seem present in 3.1.
>
> > * Merge "System administration/Font Installer" and "Appearance &
> > Themes/Fonts"
>
> I disagree. A&T/Fonts is about which fonts are used, Sysadmin/F-I is
> about installing fonts. Two completely different things imho, the
> latter should be moved to KAdmin imho.
Ok.. If the user needs to install fonts, all font stuff should be in one
place. But as you implies, it is perhaps not needed by the average
user(distros mostly take care of it) and thus can be moved out. I think it
was added because at that time font issues was very unstable and you siimply
had to configure your fonts manually, the problem is perhaps gone and will
diminish further in the future.
>
> > ---------------------- Miscellaneous -----------------------
> >
> > * Somehow Sony Vaio and Laptop Battery and possible others must be
> > made conditional, it makes no sense displaying those things on a
> > system which does not have the relevant hardware. Wild suggestion:
> > A plugin system in KPersonalizer where the plugins detects the
> > relevant hardware and do NoDisplay=true on the relevant
> > modules(but those checks may not fail or be uncertain - it will
> > then create a lot of confusion). Preferably without GUI ofcourse.
>
> ACK.
>
> > * /*_A_*/ /*_lot_*/ of options in the different modules can be
> > removed or merged(centralized) but that can wait and will generate
> > a lot of noise. Those claiming less information is not faster and
> > easier to parse than more information is just talking bullshit,
> > IMHO. As part of this cleanup and merging of kcms, lessen the
> > amount of options is essential.
>
> I agree. I propose we start filing bug reports on the worst cases. I
> have already filed two, and received more or less positive replies on
> them.
But I hesitate on this :) If we come up with tons of good suggestions to bring
order and conistency to KControl and then go filing bug reports it will
result in so much discussing - every maintainer having his own view on the
issue. That 's why I suggest "robbing" the kcm's even physically and then
taking care of them. Also, we must eat our own dog food :) That's the most
efficient way of get rid of it(it is hard getting people getting good work
done when treating them as cubicle peons... as we know). Anyway, it's not
that hard, the code is often light and non-technical(with exceptions).
>
> > * Then there's this "Local Network Chat", "File Sharing" and
> > "MLDonkey" in "Internet & Network". Should some/all be moved to
> > "KAdmin"?(and if not, isn't it then application specific?) Should
> > it be in kde at all? I remember some of this(kchat) was discussed
> > long ago but can't recall anything useful. I hardly know what the
> > things is.
>
> Maybe we should try to get this stuff implemented within kopete
> somehow ? In any case, it confuses users, since it's a pretty generic
> name. 'Hey, I want to chat on the network, how do I use this ?'
Yes, perhaps. But I still don't know what I'm talking about so /I/ will have
to leave that for the moment :O
>
> > Feel free to make some noise about it. I also wonder
> > about this "Image Index" in "System Administration".
>
> Agreed.
>
> > * I also think it's important to see and compare to how ArkLinux,
> > SuSE, Mandrake etc does to KDE/KControl because it reveals some
> > important opinions on how people don't want it. The day they leave
> > it untouched is when we have succeeded..
>
> ACK
>
> > * Remove "Internet & Network/Web Browser", William discusses it
> > throughly - I agree. AFAICT, all the settings are Konqueror
> > specific and shouldn't be in kcontrol. It reminds me of
> > Microsoft's antitrust case(especially considering its generic
> > wording - "Web Browser")... Any reason to keep it? 3.2 change?
>
> Not all of them are technically konqueror specific. Things like
> cache, cookies are kio_http specific, web shortcuts are global in KDE,
> most of the others are KHTML specific. I haven't read all of
> William's discussion on this though, so I will abstain from commenting
Yes.. You're right, didn't catch that. That needs more pondering. One
important issue is how the user percept things - if the settings
are /percepted/ as being konqueror specific or global.
> > ;)
>
> > * If the above proposals (roughly) play out well the remaining
> > options in Internet & Network can be moved to System
> > Administration. BTW, I think blurring the lines between root kcm's
> > and regular's is ok, it's unavoidable. No matter where we put
> > root-kcm's the user will have to use them and from the user's
> > perspective it's illogical structuring having kcms in one place
> > because they're root kcms.
>
> I don't think so, as I argued before, a split between "System
> configuration" ( KAdmin ) and "Desktop preferences" ( KControl ) can
> be very clear for the user and improve categorization in KControl,
> especially if distro's start moving their configuration tools into the
> System Configuration thing. Please note that this doesn't require
> writing a new application. It can very well be KControl handling the
> KAdmin modules. However, IMHO, it has to appear to the user as two
> separate "actions" to perform on his system: one is to adapt colors
> and themes, and personal preferences and data in his Desktop, whereas
> the other is to setup his system, install new software, hardware etc.
Hm.. I will clarify my position on this in another mail.
Thanks,
Frans
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic