status of kde/plasma kiosk framework in kf5

Mon Feb 5 05:20:34 UTC 2018

Am 4. Februar 2018 22:33:02 MEZ schrieb Thomas Weissel <valueerror at gmail.com>:
>Hello everybody,
>Because this topic is still very important for me i continued to work
>on -
>and with the KDE Kiosk framework.
>
>I wanted to inform you about my latest project:
>
>https://github.com/valueerrorx/life-kiosk
>
>The github page has all the information so i'll try keeping it short:
>
>I started to work on an userinterface for the kiosk configuration. As
>you
>can see in the .gif on the github page the userinterface is almost
>ready.
>the kiosk keys are still untested (i took the liberty of copying the
>.kiosk
>files from the old kiosk application that existed 13 years ago)  so
>there
>is still a lot of work to do.. those .kiosk files (and therefore a
>major
>part of the UI) are a little bit "disordered"
>
>it's written in python and qt (spagetthi code for now) and the ui
>autogenerates itself for the most part by parsing the .kiosk files...
>so this low barrier entry hopefully means that this project will easily
>find someone to keep it running if - for some reason - i stop working
>on it
>i just started working on it a few days ago and i do not have unlimited
>time... unfortunately... but i will definitely continue refining it
>
>i am still searching for a good way to make plasma (widgets) and kwin
>re-read the configuration files other than
>kquitapp5 ksmserver
>
>so if you have good ideas and want to help - very much appreciated  :-)
>
>i searched for options in qdbus but without success...
>
>qdbus org.kde.KWin /KWin org.kde.KWin.reloadConfig
>Error: org.freedesktop.DBus.Error.UnknownMethod  (even if its listed -
>this
>happens very often unfortunately)

In case of KWin there is a dbus signal you can emit and KWin listens to it. Best check the examples in kcmkwin.

Cheers
Martin

>
>hopefully A LOT of the kiosk keys are going to be tested in the near
>future
>and i can make an extensive list of what works and what not and i hope
>i
>can still count on your help... thx a million !
>
>greetings from austria,
>thomas
>
>
>
>
>
>
>
>On Thu, Sep 28, 2017 at 1:44 PM Thomas Weissel <valueerror at gmail.com>
>wrote:
>
>> after further testing it seems that SHORTCUTS (in general) are a
>problem
>> now..    with meta+Q it is now possible to see the "activities
>> configuration" again..  it seems those kde global shortcuts don't
>listen to
>> what is written in /etc/kde5rc anymore  :-(
>>
>> thx in advance
>> thomas
>>
>> On Thu, Sep 28, 2017 at 1:30 PM, Thomas Weissel
><valueerror at gmail.com>
>> wrote:
>>
>>> Hello everybody.
>>>
>>> Short update:  I'm presenting the "life-exam" (secure exam
>environment)
>>> in lower austria on monday and i worked hard on fixing bugs an
>implementing
>>> features the last 2 weeks.
>>>
>>> KDE KIOSK system is making a lot of this possible :-)
>>>
>>>
>>>
>>> There is ONE important thing that came up during the last test with
>10
>>> students where i could need your help.
>>>
>>>
>>> In kde 5.10 this suddenly stopped working and frankly - it's a VERY
>bad
>>> idea to allow students access to the run command interface during an
>>> exam..  :-)
>>>
>>> ______________________________
>>> action/run_command=false
>>> run_command=false
>>> ______________________________
>>>
>>> one student accidentially hit ALT+SPACE  and started the run command
>>> interface during the test exam..
>>> those two lines should restrict that..
>>>
>>> could you please have a look at that ?
>>>
>>> thanks to all of you..  and if you think this is better placed into
>a bug
>>> report. please tell me
>>> cheers thomas
>>>
>>>
>>> PS:  Still showing context menus (or parts of it)  are:
>>>
>>> - device manager
>>> - date and time
>>> - networksettings
>>>
>>> this should be restricted by:
>>> ______________________________________
>>> plasma/allow_configure_when_locked=false
>>> action/plasma/containment_actions=false
>>> _______________________________________
>>>
>>>
>>>
>>> On Tue, Dec 6, 2016 at 9:35 PM, Thomas Weissel
><valueerror at gmail.com>
>>> wrote:
>>>
>>>> Hello mighty plasma developers!
>>>>
>>>> I just wanted to give you a short update on the status of the kiosk
>>>> framework in kde/plasma 5.8.4 and i'm hoping for a little feedback
>of yours
>>>> ;-)
>>>>
>>>>
>>>> With all of the following restrictions in place my users are still
>able
>>>> to see at least one context menu entry on every widget in the main
>panel.
>>>>
>>>>
>>>> Still showing context menus (or parts of it) are:
>>>>
>>>> - Menu for "Edit Applications"  in the launcher called
>>>> "Anwendungsübersicht" and "Anwendungsmenü" (its working in
>>>> "Anwendungs-Starter")
>>>>
>>>> - device manager
>>>>
>>>> - date and time
>>>>
>>>> - networksettings
>>>>
>>>> - konsole (launcher icon )
>>>>
>>>>
>>>> these are the current restrictions:
>>>>
>>>> ------------------------------------------------------
>>>>
>>>> [KDE Action Restrictions][$i]
>>>>
>>>> action/switch_user=false
>>>> action/lock_screen=false
>>>> action/logout=false
>>>> action/kwin_rmb=false
>>>>
>>>> action/plasma/containment_actions=false
>>>>
>>>> action/run_command=false
>>>> action/options_show_toolbar=false
>>>> plasma/plasmashell/unlockedDesktop=false
>>>> plasma/allow_configure_when_locked=false
>>>> plasma-desktop/add_activities=false
>>>> unlockedDesktop=false
>>>> logout=false
>>>> movable_toolbars=false
>>>> run_command=false
>>>> start_new_session=false
>>>>
>>>> shell_access=false
>>>> ------------------------------------------------------
>>>>
>>>>
>>>> I also found out that restricting the user from entering any other
>>>> folder than $home  (kde url restricitons) is working very well for
>typical
>>>> kde applications.
>>>>
>>>> libreoffice (even when using the kde file open dialogs -
>libreoffice kde
>>>> integration ) still allows to enter any folder you like..
>>>>
>>>>
>>>> i also kinda hacked my own secure environment where shell access is
>not
>>>> allowed by placing a .desktop file in
>.local/share/kservices5/ServiceMenus/
>>>> that allows me to open a terminal in the current folder ^^
>>>>
>>>> dolphin shouldn't allow this.. right?
>>>>
>>>> _______________________
>>>>
>>>> [Desktop Entry]
>>>>
>>>> Type=Service
>>>>
>>>> Icon=konsole
>>>>
>>>> Actions=openterminal
>>>>
>>>> X-KDE-Priority=TopLevel
>>>>
>>>>
>ServiceTypes=KonqPopupMenu/Plugin,inode/directory,inode/directory-locked
>>>>
>>>>
>>>> [Desktop Action openterminal]
>>>>
>>>> Exec=/usr/bin/konsole --workdir %U
>>>>
>>>> Icon=konsole
>>>>
>>>> Name=Open Terminal Here
>>>>
>>>> ______________________________
>>>>
>>>>
>>>>
>>>> i even placed an xorg.conf file  to supress opening ttys (works as
>>>> expected) but this little desktop file above did the job :-)
>>>>
>>>> __________________________
>>>>
>>>> Section "ServerFlags"
>>>>
>>>>     Option "DontVTSwitch" "true"
>>>>
>>>> EndSection
>>>>
>>>> __________________________
>>>>
>>>>
>>>>
>>>> Should i make a bug report out of this ?
>>>>
>>>> Getting "dolphins" places panel locked too when other toolbars are
>>>> locked - is this a featurerequest or a bugreport?
>>>>
>>>> it is really hard to lockdown a system completely..   if i'm done
>with
>>>> it i'm definitely going to write an extensive howto and a little
>program :-)
>>>>
>>>> thank you very much in advance.
>>>>
>>>> thomas w.
>>>>
>>>>
>>>> PS: i am working on a plasma based "secure exam environment" (for
>>>> austrian schools) which i'm going to present at the "day of digital
>>>> education" at klagenfurt's university in 2 months.
>>>>
>>>> nothing special...just a few shellscripts with a small UI (most of
>it is
>>>> kdialog for now ) and a lot of preconfigured files - but it heavily
>relies
>>>> on the kiosk framework and a the live usb installation i'm already
>using in
>>>> my school..
>>>>
>>>> i'm just working out the kinks.. it's almost ready to go..
>>>>
>>>> wouldn't be possible without you.. so thx again!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 25.05.2016 16:16, Mag. Weissel Thomas wrote:
>>>>
>>>> hello everybody..
>>>>
>>>> first of all... wow!   this list of fixes is awesome.. thank you!
>>>>
>>>> i have a question about this "hide toolbars" restriction..
>>>>
>>>>
>>>> as you can see in the following screenshot  (testing with dolphin
>>>> 16.04.0)
>>>>
>>>> http://test.xapient.net/STUFF/dolphin.jpg
>>>>
>>>> i tried to restrict unocking the toolbar (look at the terminal)
>>>> also visible in the screenshot is, that "lock toolbar positions" is
>not
>>>> checked but the handle for moving
>>>> the toolbars is hidden..  so it works!  although the menu entry to
>>>> unlock is still there...
>>>>
>>>> you can also see that "show toolbar" (rightclick on the toolbar)
>and
>>>> "Main Toolbar" (rightclick on the menubar) is still visible so
>hiding the
>>>> toolbar is possible...
>>>> i'm a little bit confused because i read what kai wrote and it
>seems
>>>> that on his installation only the entry in the menubar context menu
>is/was
>>>> visible..
>>>> are we talking about the same thing here?  just checking!
>>>>
>>>>
>>>> i tested:
>>>> action/manage activities=false
>>>>
>>>> and it properly hides all entries to configure activities..
>"Meta+Q"
>>>> doesnt open the activities configuration panel either... yay!!
>>>> but "Meta+Tab" shows the activity switcher...  holding down "Meta"
>and
>>>> using the mouse on the activity switcher lets me open the configure
>>>> dialog.. no configurations are stored so this is not a big
>problem..
>>>>
>>>> best regards,
>>>> thomas
>>>>
>>>>
>>>>
>>>>
>>>> Am 2016-05-25 um 14:00 schrieb <enterprise-request at kde.org>
>>>> enterprise-request at kde.org:
>>>>
>>>> Send Enterprise mailing list submissions to
>>>>      <enterprise at kde.org>enterprise at kde.org
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>      <https://mail.kde.org/mailman/listinfo/enterprise>
>>>> https://mail.kde.org/mailman/listinfo/enterprise
>>>> or, via email, send a message with subject or body 'help' to
>>>>      <enterprise-request at kde.org>enterprise-request at kde.org
>>>>
>>>> You can reach the person managing the list at
>>>>      <enterprise-owner at kde.org>enterprise-owner at kde.org
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of Enterprise digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>>     1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe
>Broulik)
>>>>
>>>>
>>>>
>----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Wed, 25 May 2016 11:22:32 +0200
>>>> From: Kai Uwe Broulik
><kde at privat.broulik.de><kde at privat.broulik.de>
>>>> <kde at privat.broulik.de>
>>>> To: Plasma <plasma-devel at kde.org><plasma-devel at kde.org>
>>>> <plasma-devel at kde.org>," <enterprise at kde.org>enterprise at kde.org"
>>>>      <enterprise at kde.org><enterprise at kde.org> <enterprise at kde.org>
>>>> Subject: Re: status of kde/plasma kiosk framework in kf5
>>>> Message-ID:<E1b5WtM-000269-LO at smtprelay03.ispgateway.de>
>>>> <E1b5WtM-000269-LO at smtprelay03.ispgateway.de>
>>>> Content-Type: text/plain; charset=utf-8
>>>>
>>>> Hi Thomas,
>>>>
>>>> just wanted to give you a quick update. I have just merged the last
>>>> patch of our big kiosk fixes pile.
>>>>
>>>> The following fixes will land in the next Plasma and/or kde
>frameworks
>>>> release :
>>>>
>>>> * Leave option in desktop toolbox honors kiosk restriction
>>>> * KRunner will be completely disabled (eg won't start at all) when
>>>> restricted, so you can't bypass that by calling over DBus directly
>>>> * Typing on empty desktop will not try to call krunner if
>restricted
>>>> * krunner history will be disabled if lineedit_text_completion is
>>>> restricted
>>>> * Kickoff favorites cannot be rearranged/added/removed when
>>>> unlockedDesktop is restricted
>>>> * Kickoff applications cannot be edited or added as launcher to
>task bar
>>>> when unlockedDesktop is restricted, the "edit applications" context
>menu
>>>> will also be hidden then
>>>> * most applets now won't offer context menu entries about modules
>>>> restricted via kde control module restrictions. Clicking would
>already not
>>>> do anything as we already block launching them but we now avoid a
>dead menu
>>>> entry
>>>> * right-clicking menu bar can no longer bypass "hide toolbars"
>>>> restriction
>>>>
>>>> (Hope I didn't forget anything)
>>>>
>>>> As for the always-shown Activities entry, can you try whether
>>>> action/manage activities=false (note the space) works? I'm not sure
>if we
>>>> handle spaces there properly.
>>>>
>>>> David is also currently patching all of our applications so they
>use the
>>>> kiosk keys in the documentation (most erroneously used action/
>prefix for
>>>> everything).
>>>>
>>>> If you have any further questions or problems, don't hesitate to
>ask,
>>>> we're happy to help you.
>>>>
>>>> Kai Uwe
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> Enterprise mailing list
>>>> <Enterprise at kde.org>Enterprise at kde.org
>>>> https://mail.kde.org/mailman/listinfo/enterprise
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of Enterprise Digest, Vol 3, Issue 11
>>>> *****************************************
>>>>
>>>>
>>>>
>>>>
>>>
>>