Plasma/Kiosk

Kiosk Configuration Parameters

This page shall give you a brief overview over the main variables which can be set in the plasma-appletsrc. They might be helpful for centralized configurations like Kiosk. The normal users do not need them in their daily business.

I will now just shortly cover the main variables which can be found in the configuration file.

Coding of a Panel

Variables	Explanation
desktop
fmrmfactor
immutability	This number indicates whether a panel is locked (Value: 2) or if the panel is editable (Value:1)
location	The value which is set with this variable describes the location of the containment on the desktop (e.g., Value: 4, this indicates that the panel is at the bottom)
plugin	Type of plugin. In this example, it is the definition of a panel for the Plasma desktop
screen	This variable indicates whether a plugin (in this case the panel) shall be always on top (Value: 1) or if overlapping is possible (Value: 0)

Coding a Plasmoid

Let’s assume we integrated a plasmoid into our panel.

Variable	Explanation
geometry X,Y,H,W	With this variable, we tell the plasmoid at which place we can find it in the panel. It is set through the X-position, y-position. The following last two variables are the height and width for the icon, so that Plasma can rescale it
immutability	The default value is 1. Setting it to 2 disables the possibilities to configure it (configuring includes moving and deleting).
plugin	Defining the type of plugin which should be integrated into the panel, e.g., the launcher (KDE 4 standard launcher), simplelauncher (KDE 3-like launcher)
zvalue

Immutability

Just a short deep dive into the topic of immutability.

	Level
panel	2	prevent moving, configuring the panel
		prevents adding or moving applets, but it does not prevent to delete an applet (as long as it is itself not immutable=2)
applet	2	prevents configuring and deleting this applet

Configuration tests with KDE 4

We (dass IT GmbH) are currently evaluating the possibilities of KDE 4 desktop environment, for a customer with around 2,000 clients. These clients are currently running on KDE 3. These installations are based on centralized profiles.

• Version of KDE: 4.2.4
• Distribution: openSUSE 11.1
• Date of test: 07.07.2009
• Plasma configuration file:
  • Version
  • created as normal user with one screen in resolution 800×600
  • manually changed applets IDs to our standard
  • manually removed some settings (by comments)
  • manually locked some settings
• KDE profile directories:
  • Basic settings: vermkv_base
  • Restrictions (for all users, except administrators): vermkv_kiosk
  • Additional settings and menu entries for Headquarter: lvermgeo_menu
  • a default user in the headquarter uses following KDE configurations: will follow!

component	Aim of Test	Changes	Expected Behaviour	Observed Behaviour	Result
panel: resizing	The desktop must stay usable after changing the screen resolution	Users use krandrtray: 800×600 → 1024×768	The panel should adapt to the new screen resolution	The panel does not adapt itself directly to the new resolution. Initially, it stays at the configured size, but if more applications are opened (plugin=tasks), the panel gets broader. But the panel stays at the left side of the screen. An auto positioning like „center“ would help	(+)
		Users use krandrtray to resize screen resolution back to 800×600	The panel should adapt to the new screen resolution	The panel adapts itself without any problem to a smaller size of the panel. This works also in case there were many windows open. The panel will then decrease automatically	+
panel: moving the panel	The user should be able to move its panel to different positions	The location variable must not be locked with $i. Simply moving the panel by hand	The ordering of the panel icons should stay in the same order and they should not overlap	Moving the panel works without any damage on the panel (damage in this case means complete destruction or at least it becomes unusable)	+
panel: Lock panel for user	We want to be able, to modify the central panel configuration later on. Therefore it is required, that the applet IDs don't change. Therefore we disallow the user to add plasmoids or to move an applet in the panel	Lock the panel by setting like here	We expected that the user can not add a new plasmoid and that the user can not unlock the panel	Indeed the user was not able to add a new plasmoid to the panel and it was not possible as well to unlock the panel. But still, on right-click, the option „unlock panel“ is visible (but without a function). Please make it invisible	(+)
Quicklauncher (locked)	There shall be two quicklaunchers one for the system configuration and one for the users. The one for the system shall be fixed.	Locked the configuration of the quicklauchner with [$i]	The user shall not be able to remove or add any icon	Indeed the user is not able to add/remove any icon which is saved afterwards, but during the normal session the user is able to modify it. After restarting Plasma the Quicklauncher resets to it configured icon set. But we would like to have that the user do not even have the possibility to click on such a button to add or remove	(-)
Quicklauncher: centrally adding icons	The administrator should be able to add new icons later on	I add a new icon for Firefox into the definition of different files in the configuration of the applet.	The place where I add the new icon in the row of files, is also the place where it is later on shown in the launchbar. So it shall be very easy for the admin to add a new icon.	The quicklauchner behaves as expected, it adds the new icon exactly at the place where I added it in the plasma-appletsrc.	+
Quicklauncher: users taskbar	The user shall have the possibility to add/remove icons from its own quicklauncher	the configuration of the second quicklauncher isn't locked	The user shall be able to add and remove icons from its taskbar, either through the button Add/Remove which you can access through a right click on the quicklauncher or by drag and drop	The user is able to add/remove icons by right-click. Drag-and-Drop is not supported in KDE 4.2.4, but it should be supported in KDE 4.3	(+)
Plasma: Dynamic number of virtual desktops	The user should be able to change the number of virtual desktops	Increase and decrease the number of virtual desktops	I would expect that the space of the virtual desktop part becomes smaller or bigger and of course that the complete panel itself becomes more space or less.	The panel behave as expected without any problem, it also safe the different number of desktop so that when for the next session they are restored.	+
lauchner: administrator change the type of launcher	Exchange the launcher with the old „traditional“ launcher	Change the plugin from launcher to simplelauncher. Lock the launcher plugin [$i]	The Panel shall simply show the traditional launcher instead of the new one.	The panel behaves as expected, instead of the big launcher it shows the simple small one	+
lauchner: user change the type of launcher	Alternatively, the administrator changing the lauchner type, allow the user to change it to old „traditional“ launcher	Right-click on the launcher button and change it to „traditional“	The panel shall show the traditional launcher instead of the new one, but if the plugin is locked in the beginning with $i, changing the launcher is not possible	Because of the prefixed plugin, a new launcher can not be created and a new ID can not be given, so such a problem does not occur.	+
launcher: disable menu entries	Disable icon or programs in the launcher (kmenu) for a specific group	set TryExec to a program, for which the user doesn't have any execute rights	The icon should not come up in the menu, unless your are a member of a program for which the program defined in TryExec is accessible	The menu point (.desktop file), which I move to /usr/share/applications/kde4/ was visible if the TryExec was accessible for the user. If not, it was indeed invisible.	+
		Set the permissions for the user so that the .desktop file is not accessible for the user/group	The icon should not come up in the menu, because the user does not have the necessary permissions	The menu point (.desktop file), which I move to /usr/share/applications/kde4/ was not visible for the user or a group.	+
		Set the hidden variable to true so that the icon disappear in the menu	The icon where hidden=true is set should not appear in the menu either for this group (if I connect it with a test for groups) or at all	Works. If you edit and add the line Hidden=true in a .desktop file in /usr/share/applications/kde4, the icon disappears in the menu and vice versa	+
launcher: disable menu entries	Make menus accessible for	Make changes to existing applications in additional .desktop files in profil directory	Menupoints in the Kmenu shall appear or disappear, whether they are accessible for the user/group or not	If the changes are made in the .directory file of the applnk folder, indeed the menus do appear, depending on the group or the user. Merging .desktop files does not work currently	(+)
launcher: additional folders for specific users	add a menu folder where specific programs are shown	Add the folder in the profile applnk. In this directory I specified other folder with the content of .desktop files	For a specific user group, another folder shows up in the kmenu, so that there are additional programs for the user	The folder appears in the Kmenu, and with the variable .directory, it is possible to do something like a test, so that the folder does not appear for special groups/users	+
		Specify listed applications through the directory applications (the xdg way). Modify the file/files in /etc/xdg/menus/applications.menu.kde* and add a new menu point	The Kmenu should show the new submenu, together with desktop icons which are related to the category	It does not work at all. The Kmenu/panel/Plasma crashed immediately if I edited the xdg menu files.	-
action restrictions: menu entries			KDE shall block parts of settings such as kmenuedit through the KDE globals. As it is implied on the KDETechbase.	This does not work. Currently, just the restrictions for the konsole are working.	-
configuration restrictions: systemsettings	Make icons in the systemsettings invisble for certain users or groups	Create a settings-*.desktop file in file and add a TryExec=/bin/false	The icons for configuration in the systemsetting have to be hidden/invisible, so that the user can not modify them	As expected, the icons disappear, and the user is not able to reach it for his/her usage.	+
		Create a settings-*.desktop file in file and add a Hidden=false/true. You can also connect it to a test. If you choose a test, you have to add the [$e], otherwise the test is not executable	The icons for configuration in the systemsetting have to be hidden/invisible, so that the user can not modify them	As expected, the icons disappear and the user is not able to reach it for his/her usage. Connected with a test, a special group can be checked through a additional Hidden[$e]=	+

Comments, work in progress:

Currently, it is not working in our test environment.

Combine configurations

• combine configurations of .desktop files in your own profile with the ones which are set in /usr/share/applications
  1. created a .desktop file with an identical name in the applnk profile folder and just added a line like: Hidden=true
  2. to make sure that the configurations were really not merged, I also tried TryExec=/bin/false. The result was the same; the icon in the menu still appeared
• add a new program/.desktop file to a special category in the KDE menu
  1. if I set the category variable in a .desktop file to the name of the categories, like games or office, but the icon does not appear. I saved the .desktop file to applnk