Plasma/20080209

The meeting was held on IRC, channel #plasma, irc.freenode.net, at 13:00 UTC.

Attendees

Beineri
Chani
Riccardo "ruphy" Iaconelli
Anne-Marie "annma" Mahfouf
dani_l
Thomas "tmske" Coopman
Luka "Lure" Renko
aseigo
cheko
Shawn "spstarr" Starr
jpwhiting
Alex "randomguy3" Merry
Marco "notmart" Martin
Dirk "dirk" Müller
Chris "jackrabbit" Blauvelt
Henry "hdevalence" de Valence

Agenda

Process
- review-board: continue with it or no?
- backporting policy
- interim release: full release from trunk/ prior to 4.1
- a libplasma to kdelibs strategy
- April Plasma sprint
- review of plasma roadmap

Design
- keyboard shortcuts
- menu handling in containments
- mutable data in DataEngines
- per-desktop Views (aka "the desktop grid problem")
- applets for 4.1 (welcome applet, timeline, etc) (kdm?)
- panel config interaction
- accommodating low resource (embedded) platforms
- Widgets on Canvas (WoC) Changes
- More documentation

Implementation
- package support (scripts, wallpapers, themes)
- form factor (esp vertical) correctness in applets
- zoom
- kickoff
- reorganize applet categories
- color scheme usage
- "Oxygenization" of Plasma

Summary

Process

Review Board

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 ;-) ).

Backporting Policy / Interim Release

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:

enumerating which changes to backport (probably not that hard =)
- dashboard improvements (including the "new" animation introduced post 4.0)
- panel config (size/span/location, adding/removing of panels)
- systray (if it's not already)
- taskbar improvements
- color scheme fixes (?)
- icon alignment algorithms
- drag&drop panel-desktop in both directions, with visual feedback (?)
- being able to move applets (like somewhere added apps) on the panel
there will be 2 backports days, one for 4.0.2 and one for 4.0.3
aseigo will get blessing from the i18n teams so they don't send hit men out after him - not a problem if done more than one or two weeks before tagging
scheduling a day or two where we keep plasma in trunk/ static so we can have people more concentrated on the marathone instead of development.

Moving libplasma to kdelibs

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.

April Plasma Sprint

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.

Roadmap Review

See 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.

Design Issues

Next, we moved onto some design issues.

Keyboard Shortcuts

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

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.

Mutable Data Engines

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:

  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:

engines:
- one applet's actions on a data engine don't affect what other applets get from that engine - purely passive
- engines are "read only" from the point of view of the applets - as far as they are concerned, the data might be stored permanently and statically in the engine
- the same source [with the same parameters, if we have them] is shared between applets, and each will get exactly the same data
- eg: the "twitters from friends" data for the twitter applet
services:
- each applet has it's own service (because they might want different parameters)
- querying a service can change the "outside world", including what is returned by any given engine
- not meant for fetching data, but has a reply mechanism for, eg, status info (like if a query failed)
- eg: the "send a tweet" function of the twitter applet

End of Meeting

The meeting was ended at this point, due to having lasted three and a half hours.