Plasma/Kiosk
< Plasma
Kiosk Configuration Parameters
This page shall give you an breath 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 DOES 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 wheter 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 (eg. 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
Lets 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 2 variables are the height and width for the icon, so that plasma can rescale it |
| immutability |
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, eg. the launcher (KDE4 standard launcher), simplelauncher (KDE3 like launcher) |
| zvalue |
Immutability
Just a short deep dive into the topic of immutablity.
| Level |
||
|---|---|---|
| panel |
2 |
prevent moving, configuring the panel |
| prevents adding or moving applets, BUT 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 KDE4
We (dassIT GmbH) are currently evaluating the possibilities of KDE4 Desktop Environment, for a customer with around 2000 clients. This clients are currently running on KDE3 . This installations are based on centralized profiles.
- Version of KDE: 4.2.4
- Distribution: OpenSUSE 11.1
- Date of test: 07.07.2009
- Plasma config file:
- created as normal user with 1 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 admins): 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 uses krandrtray: 800×600 → 1024×768 | panel should adapt to 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 uses krandrtray to resize screen resolution back to 800×600 | panel should adapt to 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 than decrease automatically | + | ||
| panel: moving the panel | the user should be able, to move its panel to different positions | 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 und 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 function). Please make it invisible | (+) |
| Quicklauncher (locked) | There shall be 2 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 possibilty 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 the 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 expected that the space of the virtual desktop part becomes smaller or bigger and of course that the complete panel it self 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 | alternativly 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 changig the launcher is not possible | Because of the pre fixed plugin a new launcher can not be created and a new ID can not be given so such 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 have no 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 disappear in the menu and vise versa | + | ||
| launcher: disable menu entries | Make menues 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 menues does 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 show up in the kmenu so that their 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 do not appear for special groups/users | + |
| Specify listed appilcations 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 edit 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 icon for configuration in the systemsetting have to be hidden/invisible so that 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 icon for configuration in the systemsetting have to be hidden/invisible so that 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 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 applnk profile folder and just added a line like: Hidden=true
- to make sure that the configurations are really not merged I also tried TryExec=/bin/false the result was the same the icon in the menu still appears
- add a new programm/.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