Plasma/Kiosk
< Plasma
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:
- 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
- created a .desktop file with an identical name in the applnk profile folder and just added a line like: Hidden=true
- 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
- 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