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.
