Idea for re-arangin systemSettings / Kcontrol inc some KIOSK functions

SMIT ROBERT robert.smit at alcatel-lucent.com.au
Thu Sep 18 01:11:09 CEST 2008


Hi I'm a bit of newbie still especially when it comes to KDE development
But I'm looking into getting involved and so have started learning a bit
of QT and C++.

Enough about me  . . .  

I have a suggestion that I think might improve kiosk and system config
in KDE. I have no doubt many people are already working on bringing KDEs
system config utility up to the high KDE4 standards but I hope my
suggestion will make a difference.

I think the advanced tab should be gotten rid of (it seams ubuntu agree
with me on this). Instead the tabs at the top of the system config
window should be =>

*	user settings	settings that effect ONLY this users KDE desktop

This tab requires no admin rights. Settings here relate only to the
individual users settings on the KDE desktop.

*	Global settings	settings for all users

For the most part this would be a 1 for 1 match for user settings but
settings set here would apply to ALL users and disable its counter part
in user settings with a tool tip explaining why it's disabled.
Additional to these mirrored user settings would be basic KIOS settings
like disabling the addition of plasmoids, turn of or limit alt-F2 etc.
Maybe a link here could even link to the KIOSK tool for more advanced
KIOS functions.

*	System settings	Settings not related to KDE directly

These would be settings related to the underlying system. Here you would
have user admin, package management, font management, Network, printers
etc. These settings will affect all users and all desktops and would
often be OS specifics (when running on windows settings here would be
different then in Linux). Distribution tools like package management and
ubuntu's restricted drivers dialog could be linked here.

Many settings here would still need to be accessible by individual users
for changing environmental needs e.g. Display settings when plugging in
external monitors, Network changes when moving to new WiFi area, add
printers etc . . . But I would argue that these sort of dynamic settings
would be better handled by other tools like the Knetworkmanager for
dynamic Network changes or right clicking on the desktop to change
display resolution or extended desktop to external monitor. The settings
in System settings would be used when the network settings were fixed
(e.g. office desktop) and to enable/disable the dynamic tools (eg turn
off knetworkmanager or restrict changes to the default printer.).

By dividing the user settings and Global settings we would allow users
to make changes without concern about what settings might affect other
users and allow admins to have some KIOS like functions. KIOSK might be
a specialized tool but I would think many of its more basic
settings/lockdowns would be useful to desktop admins.

By separating System settings we make it easier to adapt to different
distos or even OSs while still being consistent everywhere else. In
Windows for instance this could be linked to windows control-panel
icons. In ubuntu the restricted drivers tool could be link or embedded
here. The distros package management tool could be linked here or maybe
adept embedded here instead. The idea would be that this tab would be
flexible to allow for distros to change/add what they want here.

I think this arrangement would also achieve a more clearly defined
boundary between the tabs and separate settings of different access
levels.

I would be more than willing to help with this (should anybody think
this is a good idea and someone not already be working on a better idea
:-) ) but like I said I've never done anything like this before and
would need quite a bit of guidance.

There are other areas where I think settings grouping could be more
consistent which I would also like to help fix but I think that is
enough for my 1st email to the mailing list.

Regards Robert Smit
Parramatta, Sydney Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-utils-devel/attachments/20080918/20257d0a/attachment.htm 


More information about the Kde-utils-devel mailing list