Re: Review Request: Move activation of Present Windows effect to WindowsEffects
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1852/#review2653 --- Ship it! this is a thing that was on my todo list, +20 grom me :D - Marco On 2009-10-15 09:03:41, Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1852/ --- (Updated 2009-10-15 09:03:41) Review request for Plasma. Summary --- Added two methods to WindowsEffects to activate the Present Windows effect either for windows on a desktops or for a group of windows and replaced it in the currentappcontrol and tasks applets. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 1030597 trunk/KDE/kdebase/workspace/plasma/netbook/applets/currentappcontrol/currentappcontrol.cpp 1030597 trunk/KDE/kdelibs/plasma/windoweffects.h 1034782 trunk/KDE/kdelibs/plasma/windoweffects.cpp 1034782 Diff: http://reviewboard.kde.org/r/1852/diff Testing --- Currentappcontrol is still working. The activation for grouped tasks does not work (and didn't before) or I don't know how to trigger it ;-) Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Move activation of Present Windows effect to WindowsEffects
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1852/#review2654 --- Ship it! Besides from the comment below it seems great. We really wanted this for a long time now... :) trunk/KDE/kdelibs/plasma/windoweffects.cpp http://reviewboard.kde.org/r/1852/#comment1978 Shouldn't be if (!data.isEmpty()) ? - Artur On 2009-10-15 09:03:41, Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1852/ --- (Updated 2009-10-15 09:03:41) Review request for Plasma. Summary --- Added two methods to WindowsEffects to activate the Present Windows effect either for windows on a desktops or for a group of windows and replaced it in the currentappcontrol and tasks applets. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 1030597 trunk/KDE/kdebase/workspace/plasma/netbook/applets/currentappcontrol/currentappcontrol.cpp 1030597 trunk/KDE/kdelibs/plasma/windoweffects.h 1034782 trunk/KDE/kdelibs/plasma/windoweffects.cpp 1034782 Diff: http://reviewboard.kde.org/r/1852/diff Testing --- Currentappcontrol is still working. The activation for grouped tasks does not work (and didn't before) or I don't know how to trigger it ;-) Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Kineticscrolling: a zero api approach
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/#review2660 --- I tested it today with the following results: - uBlog X plasma-desktop = works fine - webview X plasma-desktop = kinetic scrolling is broken - plasma-netbook = works fine - uBlog X plasma-netbook = broken, is non longer possible to scroll only the plasmoid by using mouse scrollwheel (it will also scroll the newspaper together). - Adenilson On 2009-10-14 13:38:20, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/ --- (Updated 2009-10-14 13:38:20) Review request for Plasma. Summary --- this is just an experiment that has perhaps a too big disadvantage to be practical... makes use of event filters instead of explicitly forwarding mouse events. the advantage is that it would be super easy to use and woouldn't be needed to export new classes in plasma, there could just be an Animator::registerScrollingManager(QGraphicsWidget *) function the big disadvantage is that is less controllable, so widgets can't decide to -not- make use of the kineticscrolling, thing that is quite needed in WebView. Diffs - /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 Diff: http://reviewboard.kde.org/r/1840/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Kineticscrolling: a zero api approach
On 2009-10-15 16:32:57, Adenilson Cavalcanti wrote: I tested it today with the following results: - uBlog X plasma-desktop = works fine - webview X plasma-desktop = kinetic scrolling is broken - plasma-netbook = works fine - uBlog X plasma-netbook = broken, is non longer possible to scroll only the plasmoid by using mouse scrollwheel (it will also scroll the newspaper together). Correction: webview kinetic scrolling works if 'Drag to scroll the page' is enable (sorry, my mistake). - Adenilson --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/#review2660 --- On 2009-10-14 13:38:20, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/ --- (Updated 2009-10-14 13:38:20) Review request for Plasma. Summary --- this is just an experiment that has perhaps a too big disadvantage to be practical... makes use of event filters instead of explicitly forwarding mouse events. the advantage is that it would be super easy to use and woouldn't be needed to export new classes in plasma, there could just be an Animator::registerScrollingManager(QGraphicsWidget *) function the big disadvantage is that is less controllable, so widgets can't decide to -not- make use of the kineticscrolling, thing that is quite needed in WebView. Diffs - /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 Diff: http://reviewboard.kde.org/r/1840/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Forecast-only weather ion
On October 9, 2009 07:11:38 pm Thilo-Alexander Ginkel wrote: On Thursday 01 October 2009 01:48:29 Shawn Starr wrote: Now that my Weather Ion is mostly feature-complete, how does the further process look like? Should I submit a review request? Should it first go to the playground? (Feel free to point me to a Wiki page if there is any explaining the process.) The ion should go into the playground there's an ion directory for other plugins being developed. From there, we'll let the code settle and test it. I just committed an initial revision of the wetter.com Weather Ion to /trunk/playground/base/plasma/dataengines/weather/ions. Any feedback is appreciated! Thanks, Thilo Hi Thilo, I'll have a go with it soon, just been out of loop for a bit. Thanks for your contribution! Shawn. ___ 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: playground/base/nepomuk-kde/usercontext/plasmoid
On October 15, 2009, Sebastian Trueg wrote: SVN commit 1035530 by trueg: updated label and comment to more readable values M +7 -11 plasma-applet-nepomukcontextchooser.desktop [TRAILING SPACE] --- trunk/playground/base/nepomuk-kde/usercontext/plasmoid/plasma-applet-nepom ukcontextchooser.desktop #1035529:1035530 @@ -1,26 +1,22 @@ [Desktop Entry] -Name=NepomukContextChooser -Name[es]=NepomukContextChooser +Name=Task Management Widget +10 on getting rid of jargon shown to the user. unfortunately we now have a small problem: we inherited the term task bar from windows (i know, totaly *sigh* all around :/ ) and so for purely historical reasons the window picker widget is called tasks widget we can do one of the following: * rename the tasks widget to windows widget? * rename your task managment widget to activity management widget, but in that case we end up with a name collision with activities in plasma-desktop * something completely different personally, i am all for changing the name of the current tasks widget to windows. tasks is really a bad name and one we have for purely historical reasons. no new user without a background in MS Windows would know what it means, though i'm guessing everyone can guess to look for windows when looking for that widget. moreover, that widget is there by default, so it's rare that people want to go searching for it in any case. thoughts? ok, naming issue out of the way ... now, what does this nepomuk plasmoid do, exactly? and what is the goal for it? we are currently working on this exact area in plasma right now, with Ivan working on libplasma-nepomuk context bridging, kwin guys working on getting some of the window effects we need into good shape and marco and i puttering away on UI issues ... we should probably coordinate our efforts here so nobody ends up wasting time or designing in different directions :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Review Request: Plasma + Qt Kinetic GSoC Project - Attempt 2
On 2009-10-14 12:31:38, Adenilson Cavalcanti wrote: /trunk/KDE/kdelibs/plasma/animations/animation.h, line 83 http://reviewboard.kde.org/r/1512/diff/1/?file=10972#file10972line83 It should return a QAbstractAnimation so it covers the case that the animation is complex and it really is a QAnimationGroup. Since later the ::start() method will be called, it should work with both single property animation objects and composed animation groups (where more than just 1 property is transformed). I just realised now that *every* single time the animation is executed, the animation objects will be created and then destroyed. I think a more efficient design (thinking about a speed) is to create the animation objects only once and reuse it whenever the animation runs. - Adenilson --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1512/#review2647 --- On 2009-10-13 15:06:04, makmanalp wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1512/ --- (Updated 2009-10-13 15:06:04) Review request for Plasma, Aaron Seigo, Alexis Menard, and Adenilson Cavalcanti. Summary --- Okay, this is the oh cr*p Alexis is leaving Tokamak version, which means I'm missing a couple of stuff but I want to get it in in time. Sorry about this, but I have school now so I can't give my attention to this as much as I could. What's missing is: - Didn't dptr the private members yet because I got stuck trying to figure out how I'd override render() (which would be in AnimationPrivate) in the subclasses such as Grow etc. I guess I could have a function with the same name in AnimationDerivedPrivate but it wouldn't exactly be overriding? - Didn't add factory methods for each animation type yet. - Didn't map the existing enums to new stuff (eg AppearAnimation etc) - Didn't figure out checking animation status / stop and pause etc. Now that that's over, here's the good news: - Oodles of general tidying up: - Moved everything into animations/ so it's neater. - Added license headers to everything. - Tidied up includes. - Split each class into its own file. - Added missing getters. - Consted as much as I can. - No more unnecessary this-es. - BaseAnimationElement is now AbstractAnimation. - Moved the duration variable (m_duration) down the hierarchy into Animation because setting duration for groups is meaningless. - setObject() is called setWidget() now and is moved up the hierarchy into AbstractAnimation since it was doing the same for both Animation and AnimationGroup. - render() is no longer what it used to be, it's now a protected pure virtual function in Animation that the subclasses must override. getQtAnimation() does some common checking and then calls the render() of that subclass. getQtAnimation() is the exposed interface. - getQtAnimation() takes a parent object to pass to Animations and AnimationGroups to use when generating the QPropertyAnimations and QAnimationGroups. When getQtAnimation() is used on AnimationGroups, the generated sub-animations are now owned by the generated group. - The MovementDirection enum is now called AnimationDirection and is in plasma.h This is the essence of all changes. Documentation might be lagging behind, I'll try to clean it up later on and comments on what's wrong are much appreciated. Thanks a lot in advance! Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1018731 /trunk/KDE/kdelibs/plasma/animations/abstractanimation.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/abstractanimation.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animation.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animation.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animationgroup.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animationgroup.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/expand.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/expand.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/fade.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/fade.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/grow.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/grow.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/slide.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/slide.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animator.h 1018731 /trunk/KDE/kdelibs/plasma/animator.cpp 1018731 /trunk/KDE/kdelibs/plasma/deprecated/animator.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/plasma.h 1018731 Diff:
Re: plasma+nepomuk activities, take N
On Tuesday 13 October 2009 10:16:32 Ivan Čukić wrote: I've seen the thread about the activities overview. Since there are bound to be some changes in the concepts behind activities, virtual desktops etc. I'll postpone the plasma+nepomuk integration in order to introduce it alongside the new overview (I guess we'll be able to do it for 4.5?). From my point of view (that is from the implementation's point of view :) ), there exists the possibility for more than one containment to have the same activity (something Chani mentioned some time ago) - that is, to have more than one group of applets (what we now call activities) inside one activity. Panels could share the current global context and wouldn't have their own activities. I'd still like to see a minimal implementation of this to already get used to having this kind of stuff. So please, don't postpone. Plasma is not the only potential user of this ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: plasma+nepomuk activities, take N
I'd still like to see a minimal implementation of this to already get used to having this kind of stuff. So please, don't postpone. Plasma is not the only potential user of this ... Heh, Sebas, you haven't read the rest of the mails :) I was talking about the plasma-ui integration (the things like zui that is going away) not about the service and libplasma patches. Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Qt Kinetic GSoC Project - Attempt 2
On 2009-10-14 12:31:38, Adenilson Cavalcanti wrote: /trunk/KDE/kdelibs/plasma/animations/animation.h, line 83 http://reviewboard.kde.org/r/1512/diff/1/?file=10972#file10972line83 It should return a QAbstractAnimation so it covers the case that the animation is complex and it really is a QAnimationGroup. Since later the ::start() method will be called, it should work with both single property animation objects and composed animation groups (where more than just 1 property is transformed). wrote: I just realised now that *every* single time the animation is executed, the animation objects will be created and then destroyed. I think a more efficient design (thinking about a speed) is to create the animation objects only once and reuse it whenever the animation runs. Patch merged in revision 1035749. - Adenilson --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1512/#review2647 --- On 2009-10-13 15:06:04, makmanalp wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1512/ --- (Updated 2009-10-13 15:06:04) Review request for Plasma, Aaron Seigo, Alexis Menard, and Adenilson Cavalcanti. Summary --- Okay, this is the oh cr*p Alexis is leaving Tokamak version, which means I'm missing a couple of stuff but I want to get it in in time. Sorry about this, but I have school now so I can't give my attention to this as much as I could. What's missing is: - Didn't dptr the private members yet because I got stuck trying to figure out how I'd override render() (which would be in AnimationPrivate) in the subclasses such as Grow etc. I guess I could have a function with the same name in AnimationDerivedPrivate but it wouldn't exactly be overriding? - Didn't add factory methods for each animation type yet. - Didn't map the existing enums to new stuff (eg AppearAnimation etc) - Didn't figure out checking animation status / stop and pause etc. Now that that's over, here's the good news: - Oodles of general tidying up: - Moved everything into animations/ so it's neater. - Added license headers to everything. - Tidied up includes. - Split each class into its own file. - Added missing getters. - Consted as much as I can. - No more unnecessary this-es. - BaseAnimationElement is now AbstractAnimation. - Moved the duration variable (m_duration) down the hierarchy into Animation because setting duration for groups is meaningless. - setObject() is called setWidget() now and is moved up the hierarchy into AbstractAnimation since it was doing the same for both Animation and AnimationGroup. - render() is no longer what it used to be, it's now a protected pure virtual function in Animation that the subclasses must override. getQtAnimation() does some common checking and then calls the render() of that subclass. getQtAnimation() is the exposed interface. - getQtAnimation() takes a parent object to pass to Animations and AnimationGroups to use when generating the QPropertyAnimations and QAnimationGroups. When getQtAnimation() is used on AnimationGroups, the generated sub-animations are now owned by the generated group. - The MovementDirection enum is now called AnimationDirection and is in plasma.h This is the essence of all changes. Documentation might be lagging behind, I'll try to clean it up later on and comments on what's wrong are much appreciated. Thanks a lot in advance! Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1018731 /trunk/KDE/kdelibs/plasma/animations/abstractanimation.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/abstractanimation.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animation.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animation.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animationgroup.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/animationgroup.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/expand.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/expand.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/fade.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/fade.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/grow.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/grow.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/slide.h PRE-CREATION /trunk/KDE/kdelibs/plasma/animations/slide.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/animator.h 1018731 /trunk/KDE/kdelibs/plasma/animator.cpp 1018731 /trunk/KDE/kdelibs/plasma/deprecated/animator.cpp PRE-CREATION
Re: Moved kill runner to kdereview
On October 15, 2009, Jan Gerrit Marker wrote: Hello you, I moved my runner called Kill to kdereview in order to get it into the KDE libs. It's in the folder plasma/runners/kill. I added the directory of i've made a few changes to it, but i think it's ready to go now. i'd like to see this in kdebase/workspace/generic/runners -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
