The meeting was held on IRC, channel #plasma, irc.freenode.net, at 13:00 UTC.
Contents |
So, we started talking of the review board, and possible things we could do to improve it. Speed seemed a major problem for some of us.
Possible changes include: RSS feed, and more bandwidth/more powerful server.
It was also decided we need to make the purpose clear: core changes, new devs, anything people are unsure about and would like someone to look at.
We will mail the developers to see what their plans for further development are In general, seems that everyone is pretty satisfied with how it works (apart from the fact that it does not work with our beloved konqui or with lynx ;-) ).
Then we discussed about a backporting policy, and the idea of doing interim releases. We discussed those items toghether because they kind of overlap.
There were suggestions we should do an interim release, but we decided to backport a bunch of features into 4.0.x instead.
Riccardo will take care of doing that thanks to the great git cherry pick command, others need to help him spotting the right commits to backport. We'll set up a marathon in the next two days where we'll do that.
Things to take care of when backporting:
After that, there's the moving libplasma to kdelibs strategy discussion. We won't rush and wait until 4.2, to make sure the code and API are both solid. We'll treat 4.1 as though it was kdelibs code, though.
For the April plasma sprint, dates will be 11th - 14th, with arrivals on 10th and departures the 15th. We will probably need to rent a car, to make transporting people around easier.
If annma or darktears come with theirs, it would be great. Ruphy and Sebas are organizing it, and they will let know more details in the future. Book your tickets to fly to Milano Malpensa (MXP).
Check out the wiki page with all the instructions that Riccardo is making.
See Projects/Plasma/4.1_Roadmap
This was skimmed over with little fuss. Rich Moore said he would be adding in support for the rest of the script engine API to the QtScript [1] support.
Next, we moved onto some design issues.
It was decided that some sort of "global plasma" shortcut (such as super-p [win-p]) would be needed, which would make plasma "grab focus", and accept further key strokes (such as tab for moving between applets).
There should be some sort of shortcut manager in libplasma. Each applet should be able to register a shortcut. The user should be able to define a shortcut for that applet. Needs UI.
Menu handling in containments was discussed: a menu plugin that was given a location (x,y) and a context (containment, applet, etc.) provided by a Containment was agreed on. The UI would be left up to the plugin. This would be used for application menus, window list, custom menus, desktop context menu etc.
It was suggested the global plasma shortcut could trigger such a menu that listed the potential further actions that could be taken.
The meeting finished off with "mutable data engines". Currently, source requests for data engines are abused for sending data to an engine, potentially violating the "one source/engine, multiple visualizations" idea of engines. In addition, this required engines to implement their own token parser, even when doing something sensible such as returning data in a given format.
For the latter problem (parsing queries), it was decided that a generic api for passing parameters to sources would be useful. The parameters would obviously need to be passed to the dataUpdated() slot.
For the issue of sending tweets in the twitter applet, for example, it was decided that a new interface was required. This was named DataService, and each applet would receive a unique data service (ie: calling dataservice("foo") multiple times from a given applet would give the same object, but calling it from a different applet would give an independent object).
Example API was given:
KDE TechBase Plasma::Service *twitterService = service("twitter");
twitterService->setProperty("username", "foo");
twitterService->send("I attended the Plasma meeting");
or:
service("juk")->sendQuery("play");
(Is some sort of list of available services needed?)
Some sort of error-reporting mechanism would be required. A serviceUpdated() slot was suggested. Also maybe a service->result() method - but this must not require polling.
DataSink was suggested as an interface that could be a factory for DataSource.
Distinctions between engines and services:
The meeting was ended at this point, due to having lasted three and a half hours.
