Chuck Burns posted on Thu, 19 Jul 2012 00:27:07 -0500 as excerpted: > My little girl has her own login (she's 5) and she manages to unlock the > widgets, remove taskbar from the panel, and then launches her games. > Over and over.. since she doesn't see them running any more. > > Is there any way of: > > a) Making it where she can't unlock the widgets without a password > > and > > b) Prevent launching any of the kdegames more than once? If you try to > launch another, the one that is already running is brought back into > view, ala Restore Window ? > > I'm not above scripting this behavior if it's even possible. Thanks
Given that you mentioned scripting, it's certainly possible, at least the multiple running instances bit (b). I don't know about (a), tho it is of course possible to set the various config files read-only, so at least the changed config can't be saved and a new login brings back the saved config. With reasonably new versions of kde4 (I'm not sure when it was introduced, but kde 4.5 or so seems about right, maybe the possibility was their before that, but without anything implementing it), it's also possible to javascript plasma, and in fact, if your version of kde/plasma has (with widgets unlocked) the option to add panel, default panel, what that function actually does is invoke a javascript that adds an empty panel and adds the default set of widgets, etc, to it. I remember reading about this on the blogs when they were first implementing it. However, you'd probably have to ask on the plasma list for more details or just investigate that script and create your own, but see below for additional resources to check first. Back to (b). There is a command-line application called wmctrl (window-manager control), that is likely in your distro's package tree (I installed and use it in my own scripts here on gentoo, for instance). This app lets you bash/shell-script various window actions, generally matched on window title. You can resize and place windows, minimize, maximize, close, move them to different virtual desktops, add or delete virtual desktops, switch the current virtual desktop, etc. wmctrl homepage: http://tomas.styblo.name/wmctrl/ FWIW, there's another app, wmiface, with similar but more advanced functionality, actually developed by a kde dev, Lubos Lunak, and hosted at kde-apps.org. However, while it does have more advanced functionality, it's more suited to those who think in C/C++ type code even when they're shell scripting, as you'll see if you try reading its documentation (manpage, etc). I tried it, but decided wmctrl did what I needed and was easier for me to use, so uninstalled this app and kept wmctrl. FWIW wmiface is also available in gentoo, but I'd guess it's less commonly available in distros than wmctrl. wmiface homepage: http://kde-apps.org/content/show.php/WMIface?content=40425 What you'd do here, would be to create a wrapper script that when launched, uses wmctrl (or wmiface) to try to match an existing window for that app and bring it forward and into focus. If no existing window matches, it would launch a new instance of the app. With wmctrl and even a bit of basic shell-scripting knowledge, this should be reasonably simple. Of course, don't forget to set the executable bit on your scripts, but if you know anything about scripting, that's already a given. Next, you edit the menu entries for the desired apps (kmenuedit does this, run it from krunner or kickoff, or from the context menu of the various launch menu widgets, kickoff, classic kmenu, etc), pointing them at the wrapper script instead of the original kde app, so when they're launched, the script raises and activates the app's main window if it exists (switching to a different virtual desktop if necessary to do so, or bringing the app onto the current virtual desktop if desired instead... tho you can ignore this bit if your daughter hasn't discovered virtual desktops yet), and launches a new instance of the app, if not. Alternatively and perhaps easier for someone who you might prefer to have a more limited launcher, you can delete kickoff/classic-menu/lancelot plasmoids and replace them with one of several icon-based app-launchers, changing it to point to the wrapper script instead of editing the menu. Yet another (system level, root privs required) alternative would involve moving the actual binaries from their normal location in, probably, /usr/ bin, to a different directory not on the normal path (say /usr/wrapped- bin), replacing them with the wrapper-scripts, which could then launch them via absolute path (/usr/wrapped-bin/kpat, for example). FWIW, this type of wrapper script is a reasonably common solution to this sort of problem, and one I use regularly here, tho generally to solve different problems. For instance, I have two separate instances of claws- mail, one for handling my mail (after kmail akonadified and got hugely buggy, so I had to dump it), one (with the feed plugin) as my feed reader. Most folks would just use the one instance for both, but I wanted my feeds handled separately. So I have wrapper scripts for both instances, one that sets up a few environmental vars to point claws at the mail dir, one that sets them up differently to point it at the feeds dir and keep the two from interfering with each other. Similarly, I use pan for news (nntp), but have three different instances and wrapper scripts for it, one for text groups (mostly mailing lists followed as newsgroups, including this one, via gmane's list2news service), one for binaries, and one for testing, as I'm a regular on the pan lists and sometimes need to check posts that are giving people trouble, without screwing up my normal pan config. Wrapper scripts are thus a quite common generally routine solution to such issues. Additional resources: http://techbase.kde.org ... has a number of additional resources you may find useful. In particular, there's a whole mini-site's worth of pages on kde system administration that's WELL worth reading. http://techbase.kde.org/KDE_System_Administration The sections on the file system, kde and xdg hierarchy, and environmental variables have been QUITE some help here, in understanding and customizing my configuration. But the kiosk information should be more direct to what you're trying to do here, since the idea is to lock down settings in a public kiosk environment, and that's basically what you're interested in doing for your daughter, as well. I won't link that specifically here as there are several kiosk related links under user and group profiles, plus the kiosk tool under tools, at the above sysadmin link. So several pages/links for that, at the above. Additionally, there's more information on the plasma desktop javascripting I mentioned above. That's covered here: http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting Someday I need to read thru that and see what I can make use of from it... I'm more a shell-scripter than a javascripter, but with the examples and such, I could probably do something with it, at least... Meanwhile, the plasma techbase section moved to the community.kde.org wiki, and can be found here: http://community.kde.org/Plasma -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
