Hi all,
As we have seen in this past period, there are quite a few issues with
the layout.js plasma script and its execution. Most the issues stem
from the fact that the scripting code was created in the era where
each screen, each virtual desktop was able to have a different
containment in it (back in the day, those containments were externally
called 'activities' for some strange reason).
After that, we switched to the idea of one-activity at a time, and all
these per-screen containments belong to it. Plasma Scripting never
adapted to this.
Now, from what I've gathered these few days, these are the use-cases
for layout.js:
UC1. (the common one) Distributions want to be able to change the
default layout, containment type etc.
UC2. (not common) Distributions want to create a few activities like
'Internet browsing', 'Multimedia', 'Photos'.
UC1
------
First we need to cover UC1, since it is the common use-case.
For UC1, calling createActivity from layout.js is a *hack* that allows
creating a new activity whose containments will use a specific plugin
like FolderView, and needs to go away. We need to provide a way for
distros to set the default containment type both as a config file
option when they just want to change the containment plugin (seems the
global package configuration option does not work properly - needs to
be fixed) and via layout.js when they want to have more customization
options.
In a nutshell:
- scripting needs to allow changing everything related to the main /
current containments.
- scripting needs to block any activity-related calls in this use-case*
UC2
------
This one is not as common. For this one, we need to allow actually
creating the activities, and for the layout.js to set properties for
each of them like UC1 allowed to do for the main one.
In a nutshell:
- scripting needs to allow activity-related calls for this use-case
- scripting needs to allow changing everything related to all containments
The idea
------------
The requirements for these two are different - UC1 should not have
access to activity-related calls, UC2 should. Also, UC1 does not need
for kamd to be running (layout.js can be executed even if plasma is
not yet aware of kamd running), and UC2 does require it.
So, this is the proposal:
- create scripting API for changing the containment type so that we do
not need the createActivity/removeActivity hack for UC1;
- create isActivitiesEnabled() function which, if not called from
layout.js, all activities-related functions would assert with a
detailed message along the lines of 'you need to check whether
activities are available before using any of the calls';
- create reloadOnActivitiesEnabled() function;
- layout.js would be invoked regardless of whether kamd is running or
not, *and* it would be called again if the status changes to 'Running'
and the script requested to be called again in that case (only for
UC2);
The behaviour
--------------------
How should this all work?
Plasma starts, if kamd is running, it has a normal current activity,
if not, it thinks there is an activity with a null UUID
(00000000-0000-0000-0000-000000000000).
If plasma gets the null activity, and it has already been started
before, it will load the containments for the last activity it
remembered being in (plasma will need to save it in its config).
If plasma has not already been run (this is the first-run), it will
create containments for this activity and layout.js is allowed to
change them as needed for UC1.
When the kamd status becomes Running, plasma will get a proper current
activity. If that current activity is not known to plasma,
containments created for the null one will be assigned to it. If it is
known (which should not happen since layout.js should not be called in
this case - just covering all the corner-cases), this means that the
new current activity has already been confiigured by the user and that
it should not be overwritten by the one that was created for the null
activity.
If the script actually wants to create a default set of activities for
the user (UC2), it will be called when isActivitiesEnabled becomes
true.
The benefits
-----------------
- This will force the script authors (us included) to stop abusing
createActivity from layout.js
- Should provide faster initialization since for the most common
use-case, plasma does not need to wait for kamd to start
- We should not need to do the corner-case-bug-patching dance we did recently
- And (a personal benefit for me :) ) scripting (including us, since
our layout.js is using the same hack) people will stop thinking
activities are containments, and that activities have anything to do
with layouts and scripting
A small rant
------------------
> scripting needs to block any activity-related calls in this use-case*
First, we can not really predict for which things a user is going to
use her computer in order to predict which activities she will need.
Unless we are making a really focussed distribution like a
3d-animation-only-distro where we could guess that they will want a
'Texture creation', '3d modelling', 'Post-processing' activities.
Other than this slim use-case, plasma should *never* create or remove
activities unless explicitly requested by the user ('user clicks a
remove activity button').
Activities should most of the time have a name that is either a name
of a project that the user is working on, or a verb like 'Internet
browsing'. The exepmtion to the rule is the
default/main/desktop/whatever activity.
Cheers,
Ivan
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
