\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ **************************** Plasma Meeting ************************************ //////////////////////////////////////////////////////////////////////////////// --- 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 o review-board: continue with it or no? - slowness: can we speed it up? - clarity on purpose (e.g. core changes, new devs, unsure changes) - contact r-b project to find out their roadmap if any - and ensure that the maintainer of the patch is subscribed to review board before upsetting people - generally we like it, but it needs some additional work o backporting policy - No BIC (Binary Incompatible Changes)/ABI changes - No new i18n strings - Only important bug fixes (for the others just ask ruphy to do that) Will do two backport days, one for 4.0.2 and one for 4.0.3 - get major missing features back into 4.0.x - need to alert i18n people (aseigo) - try to avoid BC problems, test against 4.0 libs o interim release: full release from trunk/ prior to 4.1 http://lists.kde.org/?l=kde-panel-devel&m=120228833517668&w=2 we're going to do big backport days instead of a fully separate release o a libplasma to kdelibs strategy - 4.2 (code is changing too rapidly for 4.1) o April Plasma sprint http://ev.kde.org/rules/reimbursement_policy.php arrive thursday, start friday the 11th, end monday the 14th people flying should arrive at MXP and.. take a train? (ruphy will send out more details) hotel: http://www.hotellatorretta.it/Ing/Inglese/NF-home_ntorretta_01.htm o review of http://techbase.kde.org/Projects/Plasma/4.1_Roadmap - in addition to the stuff on the roadmap so far, i'll be adding support for the rest of the script engine api to the qtscript support * Design o keyboard shortcuts - a shortcut manager in libplasma - each applet can register a shortcut - the user can define the shortcut for that applet - UI for picking between shortcuts, defining them - some sort of "global plasma" shortcut, so as not to swamp the global shortcut space o menu handling in containments - new plugin class for popups - location (x,y) and context (containment, applet, etc) provided by Containment - UI left up to the plugin itself - use cases include: application menu, window list, custom menus, current DefaultDesktop context menu... - maybe the "global plasma" shortcut could trigger one of these things o mutable data in DataEngines - add a generic (e.g. hidden behind API) mechanism for applets to pass additional query information to a source request - DataSink can provide a way of writing data (eg: posting twitters) - factory for DataService (each DataService is unique to caller) - eg: - Plasma::Service *twitterService = service("twitter"); - twitterService->setProperty("username", "foo") - twitterService->send( ...) <-- something - exampleService->setProperty("foo", QVariant(bar))? - exampleService->sendQuery("foo", QVariant(bar))? - one-to-one correlation between (a type of) DataService and applet - not enforced - up to DataSink what it returns - serviceUpdated() slot, like with DataEngines - service->result() - async queries (results should be pushed to the applet so that the applet does not have to poll for them) - 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 not covered: o per-desktop Views (aka "the desktop grid problem") o applets for 4.1 (welcome applet, timeline, etc) - Does kdm become an applet? o panel config interaction o accommodating low resource (embedded) platforms o Widgets on Canvas (WoC) Changes o More documentation * Implementation o package support (scripts, wallpapers, themes) o form factor (esp vertical) correctness in applets o zoom o kickoff o reorganize applet categories o color scheme usage o ˝Oxygenization˝ of Plasma --- Summary --- 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. Anything else? 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, neither 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. Some people think we should do an interim release, others think we should backport a bunch of features into 4.0.x instead. After some discussing, we've decided to go for a massive backport strategy. 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 marathone in the next two days where we'll do that. Things to take care of when backporting: a) enumerating which changes to backport (probably not that hard =) Proposed things to backport: - 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 [uh, how can we backport things that don't exist? ;)][That's a good question.] [there will be 2 backports days I thought, and time before second to implement?] -- anything else to add? b) getting blessing from the i18n teams so they don't send hit men out after me * not a problem if done more than one or two weeks before tagging c) 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. After that, there's the libplasma->kdelibs strategy discussion. We won't rush and wait 'til 4.2. For the April plasma sprint, dates will be 11-14, with arrivals on 10th and departures the 15th. We will probably need to rent a car, to ease the transportations. 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). 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). Menu handling in containments was discussed: a menu plugin that was given a location and a context was agreed on. This would be used for application menus, desktop context menu etc. 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"); Some sort of error-reporting mechanism would be required. The meeting was ended at this point, due to having lasted three and a half hours.