Sys admins, KDE distributors and power users can now write small ECMA Script snippets and execute them in the new interactive scripting console:
They can also be put in share/plasma-desktop/init/ to set up Plasma layouts on first log-in (or whenever there is no existing configuration) or in share/plasma-desktop/updates/ to alter the plasma-desktop configuration on its next start.
I did up a screen cast to show some of the things that can be done, which you can watch on BlipTV (OGG video version) or in the embedded player below:
The current API can be seen here and I'm looking for input as to what else to add. For instance, in the current plasma-desktop defaults we check to see if there are any batteries by asking the battery dataengine; that's currently not possible in plasma-desktop ECMA Script environment, but would be pretty easy to add. What's there now is what I consider the bare minimum to be useful (and it's a fair amount already), but I know we'll need/want some more things in there. Your input, particularly if you are a sys admin or KDE distributor, will be instrumental in helping put together the list of use cases the scripting needs to accommodate.
In other Plasma news, you can now drag-and-drop images, or any other file that a wallpaper plugin might in future support, to the desktop and have it become your wallpaper.
Both of these features landed during Tokamak 3.
16 comments:
Here's at jumped out at me when I saw the screenshot:
1. Is there a reason why this does not look like a normal KDE application (buttons are not in the toolbar?
2. Why is the edit area in sans-serif? Wouldn't it be better to make it monospace for easier readability or, even better, use a Kate KPart to also have syntax highlighting?
@Alec:
1) it's not actually an application, but a dialog that is running in the plasma-desktop process. there was jut the "Run Script" button to begin with so a toolbar really didn't make sense. as the number of actions grow, i may end up creating a toolbar.
as a side note, this dialog was originally just something for me to test the scripting for initial layout and update scripts. i kept and extended it to what it is now because i figured it could be of interest to others. it's a great way to test things for us developers, and i hope some of our power users will also enjoy it.
2) it's a regular text edit area. but in kdebase/workspace/plasma/shells/interactiveconsole.cpp you'll find this:
//TODO:
// use text editor KPart for syntax highlighting?
// interative help?
patches welcome ;)
Oh, OK :)
By the way, having now watched the video, this looks amazing. I can only start to imagine all the cool "hacks" that could be done with this...
I'm part way though Douglas Crockford's "Javascript: The Good Parts" (highly recommended, btw).
One of the criticisms it levels at Javascript is the language's reliance on the global namespace, and the subsequent namespace pollution/collisions that occur when APIs add their methods as global functions.
Would you consider (at this stage) adding the 6 or so API methods to a single global object that represents the Plasma API, instead of adding those methods to (effectively) the Global object?
Someone has an OpenGLES driver... I guess it's for the Mistery Device!
Great screencast btw :)
Is it planned to make this feature accessible to other local applications? Something like a D-Bus executeScript(QString scriptSourceCode) method or even a command line tool (plasma-desktop-exec or something) would be nice to have. That way Plasma could be very easily controlled by external applications with the full power of its JavaScript API.
Such a functionality could be used to interact with remote systems too, though security must be considered in those cases.
For example, a website could put a link to a "Plasma Configuration Script" saying "click here to add an activity with a set of pre-configured widgets for this website" or "click here to add KDE news to your RSS Reader widget".
One could also build a network with one controller that instructs the sub-desktops in the configuration of their workspace, etc etc.
Would something like this break any model followed by the development of Plasma?
@Tony: there's no reason the global functions couldn't be put into one or more objects; however, this runtime is not meant to be extended with other APIs. this is a purpose-built env that has a "final form", rather than a full development environment of some sort.
so in this case, i'm not sure what would be gained, really.
i do generally agree that namespace pollution is really easy with JS and other similar languages.
@fmontesi: the reason there is no automatic execution is security. scripts that can quietly change widget settings or throw potentially unwanted widgets on your desktop seem like ungood ideas to open to the world at large.
fortunately, both of the use cases you mention can be achieved through other means.
Awesome work!
But caught my eye however was that blank second, when you were showing the configuration dialogs. Why does the window pop-up, stay an ugly grey box for a complete second, then paint itself!
Nice and impressive. I am struggling to find a use-case for this, though. Should it not be the other way around BTW).
Would you care to explain how you arrived at JS? Python would seem more obvious... Or can we change between scripting languages here?
@Ahmed Kamal: a combination of a small bug/inneficiency in the new wallpaper settings dialog (it was about a week old when i did that screencast i think?) and the screencast capture software.
the wallpaper settings dialog does need to have some performance work done to it still at this point.
@Snirp: "I am struggling to find a use-case for this"
the primary aim is for sys admins managing multi-machine deployments and KDE distributors wanting a more expressive way to define default layouts.
the interactive console window was originally a debugging/development aid for me while working on the project.
but it's become quite useful for debugging issues in plasma-desktop on the one hand and nice for power users who wish to do things like "set my panel to be EXACTLY 24 px high".
still, the primary users will only use the interactive dialog to devevlop and test their scripts for deployment.
"Would you care to explain how you arrived at JS?"
it's widely known (probably more so than any other scripting language out there), QScript makes creating custom bindings like these beyond trivial, it has very little overhead and comes with Qt meaning no additional dependencies.
"Python would seem more obvious..."
there is no benefit to Python's bindings to additional system libraries here, and everything else is a downside for python.
"Or can we change between scripting languages here?"
no, and i don't see why one would need or want to.
I've just upgraded to 4.4.3 (debian sidux)
How do I start the interactive console?
Perhaps I miss a package; I have no "desktop console"
in krunner type "desktop console" (make sure the Plasma Desktop runner is enabled in the KRunner configuration) or with dbus, it is: qdbus org.kde.plasma-desktop /MainApplication showInteractiveConsole
Yes, it worked.
This script resizes the plasma panel for a vertical orientation after it it moved to an external monitor (I always wanted to do this automatically)
p = panelById(panelIds[0]);
if (typeof p === "undefined") {
print("E: Couldn't find first panel");
exit();
}
p.length = screenGeometry(p.screen).height;
I try to create vertical panel via init script. The maximum panel height i can get is equal to 1/3 of my screen height (i.e. 256=768/3) even if i set
panel.height=700
for example.
How can i override this limit?
(p.s.: via update script i can set height as i wish)
I really like this new way of interacting with plasma-desktop.
It makes maximizing the plasma panel much faster. My panel doesn't automatically resize after switching to a external monitor.
I use this line:
panelById(panelIds[0]).length = 1920;
But how can It be executed with for example a hot key?
I have some questions regarding http://techbase.kde.org/KDE_System_Administration/PlasmaDestkopScripting#Running_Scripts
It would be great, if someone could help me.
1) What ist the meaning off $APPDATA ?
In kubuntu 10.10 $APPDATA = /usr/share/kde4/apps/ ?
2) Howto run a script "on first run"?
Do I have to put the script in the directory /usr/share/kde4/apps/plasma-desktop/init/ ?
3) And howto run a script "on update"?
Just put it in /usr/share/kde4/apps/plasma-desktop/updates/ ?
Post a Comment