Re: Review Request: Preconfigurable plasmoids
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101251/ --- (Updated May 4, 2011, 12:52 a.m.) Review request for Plasma. Changes --- Added unit test. Summary --- There is some code duplication in that some plasmoids share very much of program logic but actually differ in just a setting. E.g. the recently made ShowActivityManager plasmoid, which just is a DBus call launcher. The Icon plasmoid is an example of this made right. I'd like to have more generic plasmoids. Even better, I'd like to have an easy way to configure them. Let's see the code. config.patch shows a way to load a config metadata file and fill a designated plasmoid with the configuration data (metadata.desktop). We search for a X-Plasma-ConfigApplet property that defines the plasmoid to configure and load. Additional properties define the plasmoid settings. This allows us, for example, to easily provide access to any webservice without code duplication. Diffs (updated) - plasma/data/servicetypes/plasma-applet.desktop 8fabddb plasma/pluginloader.cpp 43a5b7c plasma/tests/CMakeLists.txt 1d04aa5 plasma/tests/plasmoidconfigtest.h PRE-CREATION plasma/tests/plasmoidconfigtest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/101251/diff Testing --- Loading of plasmoids works. Testcase: Install these widgets: http://kde-look.org/content/show.php/Label?content=99881 http://kde-look.org/content/show.php?content=141270 Add configlabel to desktop. Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma::Svg::paint
I have a question about the way Plasma::Svg::paint is supposed to work
when an elementId is given, but a size is not.
The context for this is a bug I was fixing in bubblemon. The bubblemon
SVG has three elements; the background, the glass and the bubble. The
bubble is smaller than the other two elements.
The bubblemon applet resizes the bubblemon SVG to fit, and can retreive
the scaled size of the bubble using Plasma::Svg::elementSize. This
works as expected: if the SVG has been scaled to half its natural size,
m_svg->elementSize("bubble") will return a size half the natural size of
the bubble element.
The problem comes when doing m_svg->paint(p, QPointF(x, y), "bubble").
This will not paint the bubble at the scaled size. Nor will it paint
the bubble at the bubble's natural size. Instead, it will paint the
bubble at the size m_svg->size(); the scaled size of the whole SVG.
My question is: what is intended to happen here? bubblemon was assuming
that the bubble element would be scaled appropriately. However, the
systemtray applet, for example, assumes the current behaviour when
drawing the "show hidden tasks" arrow. The API documentation doesn't
say either way.
Alex
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
GSoC student introduction
Hi everyone, I want to introduce myself to the development teams of KWin and Plasma. My name is Arthur Arlt and I am participating in Google Summer of Code for the project "Modularization of KWin". My mentor is Martin. I am studying Applied Computer Science (MSc) at the University of Heidelberg in Germany. I achieved my Bachelor degree at the University of Mannheim where I studied Software- and Internettechnology. I still live in Mannheim, since I have all my friends around here and Heidelberg is not very far away. I am really looking forward working together with you helping to prepare KWin to be ready for Wayland. Best regards, Arthur ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: May sprint planning
On Tuesday 3 May 2011 14:15:36 Marco Martin wrote: > On 5/3/11, Kevin Ottens wrote: > > On Tuesday 3 May 2011 13:25:24 Daker Fernandes wrote: > >> I would like to keep the plasma components tracked in the icescrum. > >> Should I put them as a feature and split them as stories? > > > > Sound like a good plan, you might want to be slightly verbose in > > explaining the scope of the feature. Also I would advise one story per > > component, except > > > if: > +1 > i think most components are pretty simple. > some of them, text box or a slightly more complex web view should be > stories with the component name as prefix Not necessarily as prefix, but necessarily somewhere in the title. Also it'll for sure appear in the "I can" part of the user story template. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: May sprint planning
On 5/3/11, Kevin Ottens wrote: > On Tuesday 3 May 2011 13:25:24 Daker Fernandes wrote: >> I would like to keep the plasma components tracked in the icescrum. >> Should I put them as a feature and split them as stories? > > Sound like a good plan, you might want to be slightly verbose in explaining > the scope of the feature. Also I would advise one story per component, > except > if: +1 i think most components are pretty simple. some of them, text box or a slightly more complex web view should be stories with the component name as prefix Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: May sprint planning
On Tuesday 3 May 2011 13:25:24 Daker Fernandes wrote: > I would like to keep the plasma components tracked in the icescrum. > Should I put them as a feature and split them as stories? Sound like a good plan, you might want to be slightly verbose in explaining the scope of the feature. Also I would advise one story per component, except if: a) the interaction model of the component is slightly complex, in which case this particular component would have several user stories (one per interaction); b) the input data of the component is complex, in which case the component would have several user stories as well (one per family of data set, be it based on its type, its size or other distinctive aspects). Obviously a and b are note mutually exclusive. ;-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: May sprint planning
Hello guys, I would like to keep the plasma components tracked in the icescrum. Should I put them as a feature and split them as stories? Cheers, Daker Fernandes Pinheiro 2011/5/3 Kevin Ottens > On Monday 2 May 2011 20:53:44 Martin Gräßlin wrote: > > On Sunday 01 May 2011 17:52:49 Aaron J. Seigo wrote: > > > hi all :) > > > > > > the May devel sprint is starting tomorrow: > > > > http://contour-scrum.basyskom.org/icescrum/p/PLASMA#sprintBacklog/43 > > > > > > starting immediately, you can add new features and stories to the > Sandbox > > > or request existing ones that aren't already scheduled for this sprint > > > to be added to this sprint. > > > > > > to request something to be scheduled, please reply to this email so we > > > can keep all sprint plan requests and planning in one thread for easier > > > tracking. > > > > I just added one story for the Plasma Compositor to the sandbox and would > > like to see it scheduled for this sprint. > > Added a comment to it. Just in case the notification didn't work (I know > iceScrum has this feature, not sure if that's enabled on our installation). > > For reference the comment says: > "This one sounds like a feature to be split in several stories to me. Such > stories would be seen from the effect developer point of view." > > If you need any help with the splitting itself just get in touch with me on > IRC, we can go through that together. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud patron of KDE, http://www.kdab.com > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default Effects for Plasma Active
hi Martin, On Friday, April 29, 2011 10:13:51 Martin Gräßlin wrote: > for the Plasma Active shells not all KWin effects seem usefull. Below are a > list of effects I think we should ship, some I am not sure, and some we > shouldn't ship. > > Effects to ship: > * fade > * login > * presentwindows (till window strip is implemented) > * slidingpopups > * taskbarthumbnail > * blur Probably, although it doesn't work on our current hardware. Useful in the fututre, though. > * screenshot > Effects maybe to ship: > * dialogparent (if dialogs are not maximized it can be useful) > * dimscreen (same as above for system changes) > * outline (used in Alt+tab and quick tile, but might be useful in general) > * logout (currently broken for gles and only useful if there is the normal > logout dialog) > * startupfeedback (depends whether we want to provide feedback, but bouncing > cursor without a cursor might be strange) > > Effects not to ship: > * boxswitch > * dashboard > * desktopgrid > * diminactive > * fadedesktop > * fallapart > * highlightwindow > * magiclamp > * translucency > * minimizeanimation > * resize > * scalein > * showfps > * showpaint > * slide > * slideback > * thumbnailaside > * windowgeometry > * zoom > * coverswitch > * cube > * explosion > * flipswitch > * glide > * invert > * lookingglass > * mousemark > * sheet > * snaphelper > * trackmouse > * wobblywindows These lists look good, provide the set of features we need from the effects. So for me it's fine to disable compilation for the others with a flag. > Those in the last list are also on my kill-list for desktop, too ;-) > > I recommend a new build-flag KWIN_MOBILE_EFFECTS to exclude the effects > from build. That would be good, yes. Thans for looking into this! Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix build of libkdeclarative with ENABLE_FINAL.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101278/ --- Review request for Plasma. Summary --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. One of the problems is in libkdeclarative, where there's two file-static functions with the same name (ctor) and different code. These functions are used as function pointers when creating the QScript function objects. Fixed by renaming the two functions to icon_ctor and url_ctor. Diffs - experimental/libkdeclarative/bindings/icon.cpp 24885fa9d55b01388c681ec1766b659474fc40d7 experimental/libkdeclarative/bindings/url.cpp 21c7aa2227ea4ee10a15239905553bab40687fc5 Diff: http://git.reviewboard.kde.org/r/101278/diff Testing --- Compilation of kdelibs with and without final. Didn't try installing or running. Thanks, Nicolas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
