Re: Review Request: taskmanager library: Manual Sorting Fix
> On 2009-09-04 20:16:52, Aaron Seigo wrote: > > this results in a "leak" in that every window ever created will have an > > item that stays forever, no? shouldn't it only keep track of winIds that > > still exist, and do so in the manual grouping strategy? > > Christian Mollekopf wrote: > Yes this would result in a "leak" (as long the groupmanager instance > exists). > I just noticed that also manual grouping is broken since it also relies > on the pointers to remain. > > I will work on a new patch where manual grouping and sorting keep track > of the windows/groups by winIds. > > Aaron Seigo wrote: > any progress on this? > > Christian Mollekopf wrote: > yes, but since i'm rather busy atm. it takes some more time. > I'll try to finish it until next week. > > Cheers > > jedd wrote: > Out of curiosity, will this change affect how new applications are > displayed/handled in the taskbar? Ideally they'd just appear (and stay > unless moved) to the right of any extant tasks. If not, can I ask a big > favour ... ? ;) any work on this patch? would be nice to have one of the more reported taskmanager bugs fixed for 4.4 - Beat --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/#review2247 --- On 2009-10-19 21:10:07, Christian Mollekopf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/ > --- > > (Updated 2009-10-19 21:10:07) > > > Review request for Plasma, Aaron Seigo and Marco Martin. > > > Summary > --- > > this fixes the manual sorting strategy, which is broken atm if the desktop is > changed. > > Since the manual sorting strategy relies on AbstractGroupableItem pointer not > to change, we cannot remove it from the bookkeeping in case it returns (after > a desktop change for instance). > I don't know if this is acceptable because this results in the item never > being removed from the itemList until the groupmanager instance is deleted > (lifetime of the applet which created the instance). > > Another option would be to identify tasks and groups by WId, which is a bit > more complicated, but if you think it would be better/cleaner, i could supply > a patch. > > > This addresses bug 200255. > https://bugs.kde.org/show_bug.cgi?id=200255 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.h 1034424 > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.h > 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.h > 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.h > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h > 1034424 > > Diff: http://reviewboard.kde.org/r/1526/diff > > > Testing > --- > > Tried it, works. > > > Thanks, > > Christian > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: taskmanager library: Manual Sorting Fix
> On 2009-09-04 20:16:52, Aaron Seigo wrote: > > this results in a "leak" in that every window ever created will have an > > item that stays forever, no? shouldn't it only keep track of winIds that > > still exist, and do so in the manual grouping strategy? > > Christian Mollekopf wrote: > Yes this would result in a "leak" (as long the groupmanager instance > exists). > I just noticed that also manual grouping is broken since it also relies > on the pointers to remain. > > I will work on a new patch where manual grouping and sorting keep track > of the windows/groups by winIds. > > Aaron Seigo wrote: > any progress on this? > > Christian Mollekopf wrote: > yes, but since i'm rather busy atm. it takes some more time. > I'll try to finish it until next week. > > Cheers > > jedd wrote: > Out of curiosity, will this change affect how new applications are > displayed/handled in the taskbar? Ideally they'd just appear (and stay > unless moved) to the right of any extant tasks. If not, can I ask a big > favour ... ? ;) > > Beat Wolf wrote: > any work on this patch? would be nice to have one of the more reported > taskmanager bugs fixed for 4.4 The patch is basically ready since quite some time. Unfortunately i cannot test it at the moment, since my setup always crashes due to a bug in QT (https://bugs.kde.org/show_bug.cgi?id=211591). - Christian --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/#review2247 --- On 2009-10-19 21:10:07, Christian Mollekopf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/ > --- > > (Updated 2009-10-19 21:10:07) > > > Review request for Plasma, Aaron Seigo and Marco Martin. > > > Summary > --- > > this fixes the manual sorting strategy, which is broken atm if the desktop is > changed. > > Since the manual sorting strategy relies on AbstractGroupableItem pointer not > to change, we cannot remove it from the bookkeeping in case it returns (after > a desktop change for instance). > I don't know if this is acceptable because this results in the item never > being removed from the itemList until the groupmanager instance is deleted > (lifetime of the applet which created the instance). > > Another option would be to identify tasks and groups by WId, which is a bit > more complicated, but if you think it would be better/cleaner, i could supply > a patch. > > > This addresses bug 200255. > https://bugs.kde.org/show_bug.cgi?id=200255 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.h 1034424 > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.h > 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.h > 1034424 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.h > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h > 1034424 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h > 1034424 > > Diff: http://reviewboard.kde.org/r/1526/diff > > > Testing > --- > > Tried it, works. > > > Thanks, > > Christian > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add action support to krunner default interface
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2259/ --- Review request for Plasma and Aaron Seigo. Summary --- This patch adds action support to the default interface by adding a button for each one of actionsForMatch given by the runnerManager. Hovering (and focusing) over a button changes the subtext of the item according to the selected action. The logic is all there, it has still some rough edges from the graphical side (e.g. we should make sure that there are not "too many" displayed actions) and focusing with the keyboard is missing (it should be done togheter with the configuration button) but these can be fixed quite easily once it gets committed. Diffs - trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.h 1052428 trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 1052428 trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.h 1052428 trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.cpp 1052428 trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.h 1052428 trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 1052428 Diff: http://reviewboard.kde.org/r/2259/diff Testing --- the only runner supporting actions I am aware of is the Devices (solid) runner (in kdereview); tested with that and it works. Screenshots --- Actions for the device runner http://reviewboard.kde.org/r/2259/s/269/ Thanks, Jacopo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New idea for plasmoid locking and floating plasmoids.
On Friday 20 November 2009 11:55:13 Gerhard Gappmeier wrote: > Hi all, > > I've a little proposal for the plasmoid locking on the desktop. > > Here is the problem: > I often stumble over the same usability problem. > Normally I have my plasmoids locked, because I don't like it when this > "edit- bar" (don't know the name) appears when the mouse is hovering over > a plasmoid. But then I want to add a new plasmoid. To do that I've first > to unlock the desktop, add the new plasmoid, move it to the correct > location, and lock the desktop again. That could be easier. > > Here is my proposal: > It would be nice if adding plasmoids would be possible even if the desktop > is locked. After dropping a new plasmoid it should be in a kind of > "floating" state (like when pasting in GIMP). This state allows to move > this single plasmoid around on the locked desktop. When finishing moving, > e.g. by clicking somewhere else on the desktop, the plasmoid should loose > this "floating" state and is locked on the desktop at the current position > like all other plasmoids. The "floating" state could be highlighted with > some "glowing border" or shadow to show that it is "floating". > > What do you thinnk about this idea? > Is it possible to implement something like that? > > regards, > Gerhard > I would not mind this at all! Locking to avoid inadvertent changes is good. This idea would be a nice functionality for plasma. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New idea for plasmoid locking and floating plasmoids.
Or could there be way to move plasmoids on "Alt+mouse-left-button", resize on "Alt+mouse-right-button" disregarding lock-state ? Just like for kwin does for frameless windows ? Just asking ... Hugo >> I've a little proposal for the plasmoid locking on the desktop. >> >> Here is the problem: >> I often stumble over the same usability problem. >> Normally I have my plasmoids locked, because I don't like it when this >> "edit- bar" (don't know the name) appears when the mouse is hovering over >> a plasmoid. But then I want to add a new plasmoid. To do that I've first >> to unlock the desktop, add the new plasmoid, move it to the correct >> location, and lock the desktop again. That could be easier. >> >> Here is my proposal: >> It would be nice if adding plasmoids would be possible even if the desktop >> is locked. After dropping a new plasmoid it should be in a kind of >> "floating" state (like when pasting in GIMP). This state allows to move >> this single plasmoid around on the locked desktop. When finishing moving, >> e.g. by clicking somewhere else on the desktop, the plasmoid should loose >> this "floating" state and is locked on the desktop at the current position >> like all other plasmoids. The "floating" state could be highlighted with >> some "glowing border" or shadow to show that it is "floating". >> >> What do you thinnk about this idea? >> Is it possible to implement something like that? >> >> regards, >> Gerhard >> >> > I would not mind this at all! Locking to avoid inadvertent changes is good. > This idea would be a nice functionality for plasma. > ___ > 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: Review Request: Add support for single Runner queries to krunner (part I: libplasma)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2090/ --- (Updated 2009-11-21 18:49:12.791648) Review request for Plasma, Aaron Seigo and Ryan Bitanga. Changes --- forgot to add the relevant changes to the private header Please let me know if the logic is ok (loading selected + singlequerymode at startup) or if I should load SQM runners on the fly despite possibly long initialization times (yes I know we're working on that) Summary --- This is the API needed by the new single Runner mode for krunner (more on usecases in part II:krunner) for kdelibs; A runner can now optionally define a Default syntax; if this is the case, the runner will be exposed as single-runner-mode capable. On request, the default syntax will be replaced to the empty query in RunnerManager::launchQuery. The context is aware of the fact that we are in single runner query mode in case the runners need to change their behaviour accordingly (e.g. to _not_ discard queries with less than 3 chars) Diffs (updated) - trunk/KDE/kdelibs/plasma/abstractrunner.h 1052445 trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1052445 trunk/KDE/kdelibs/plasma/private/abstractrunner_p.h 1052445 trunk/KDE/kdelibs/plasma/runnercontext.h 1052445 trunk/KDE/kdelibs/plasma/runnercontext.cpp 1052445 trunk/KDE/kdelibs/plasma/runnermanager.h 1052445 trunk/KDE/kdelibs/plasma/runnermanager.cpp 1052445 Diff: http://reviewboard.kde.org/r/2090/diff Testing --- Thanks, Jacopo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
About KDE/plasma on small devices
Hi , I've sent this request to the kde-devel mailing list before and would like to get back to it with you guys here as Aaron suggested on kde-devel. I've been tinkering about KDE on smaller devices such s the n900 Aaron luckily informed me about the playground project that is in place and will probably be out on 4.4 (the plasma keyboard as far as I'm aware). In my humble opinion the best suited for the job is the netbook shell.Things that are used on the mobile phone could be developed as a plsmoid which would then just be added to the newspaper containment. This would have the issue that you would get quite scared because most of the mobilephone apps would have to be placed there. Another , more userfriendly, approach could be to add containments/activities for sms/phonecalls/videos or what ever somebody would want to use there. These would then added dynamically as a new Activity you would switch them by providing the activities-switch-plasmoid in each activities panel. Unfortunately I am not fully aware about how easy/hard it is to do things like that. Other suggestions how to do this would be highly appreciated. So one of the things that would need to be inplace would be information for people who are not yet involved in the development. For now small wrap up on the mailing list would help to get first pointers upon from where to tackle all these issues. Cheers , Andreas Marschke. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
