Re: mouse plugins config
On November 23, 2009 17:33:03 Chani wrote: > On November 23, 2009 17:15:06 Aaron J. Seigo wrote: > > On November 23, 2009, Chani wrote: > > > 2) when I click the button, the tooltip unshows, right when the user is > > > likely to need it most. it shows up again if I move the mouse a few > > > pixels, but is there a way to manually show it? > > > > hm.. doesn't seem to be, no, which sucks. maybe a label somewhere that is > > created/shown when needed with appropriate text. a little unfortunate. > > unfortunate indeed. there's a way to manually show a tooltip, but then I > have to manually position it, and manually re-show it if the mouse moves > in&out of the widget. > unless I can fake a mouse move event :P seems like I'm doing a lot of hacky > event faking lately. well, faking a QHelpEvent works. I wish there was a way to tell it to hide a tooltip as well, so it could go away when I hit esc. I mean, I've changed the text by that point, if it's not going to update the text it should at least have the decency to hide the old text... anyways I'm still not quite satisfied with the tooltip text itself. what I have right now: a button in one of the plugin rows: "Click to change how an action is triggered" the add button at the bottom: "Add another mouse action" either kind of button when it's wanting input: "Hold down the modifier keys you want, then click a mouse button or scroll a mouse wheel here" I'm wondering if maybe there should only be a tooltip when it wants input. try it out, see how it feels. -- This message brought to you by eevil bananas and the number 3. www.chani3.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: mouse plugins config
On Mon, Nov 23, 2009 at 19:17, Aaron J. Seigo wrote: > honestly, while i understand why it was done like that in dolphin search (to > line up with the '+'), i think putting the remove on the left is incorrect in > these cases. 'remove' is neither the useful bit of information on the line nor > is it the first thing you consider doing (one first reads what the line means) Personally I find it consistent with the dialogs where you select Runners, Desktop Effects etc. (checkbox to the left), but... > imho, those interfaces should be fixed rather than spread the misfeatures to > this dialog sounds good too me. > > 3. Move remove buttons to the left-most > > when is "remove" ever left-most? Hm, I think I expressed myself wrong here. I meant that the remove button should be to the left of the other widgets, like e.g. Dolphin search. ___ 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-24 12:59:38.449340) Review request for Plasma, Aaron Seigo and Ryan Bitanga. Changes --- Do not load single runners if not selected; for now export them only if so, this will be dropped when loading-on-the-fly is implemented this still needs to load them on-the-fly, but it can be easily fixed after commit 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 1053618 trunk/KDE/kdelibs/plasma/runnercontext.cpp 1053618 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
messaging-indicator in kdereview?
Hey, It seems there's a messaging indicator applet in kdereview since the start of November. It doesn't build however (with karmic's packaged libindicate-qt) and didn't get any non-scripty activity in more than two months. Also, it's built unconditionally, even if its dependency (libindicate-qt) isn't there, another breakage. Feature freeze is looming, and I've not seen it proposed for review or at least a build fix. I'd suggest to remove it from kdereview. Any other suggestions? -- 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
Re: messaging-indicator in kdereview?
On Tuesday 24 November 2009, Sebastian Kügler wrote: > Hey, > > It seems there's a messaging indicator applet in kdereview since the start > of November. It doesn't build however (with karmic's packaged > libindicate-qt) and didn't get any non-scripty activity in more than two > months. Also, it's built unconditionally, even if its dependency > (libindicate-qt) isn't there, another breakage. Feature freeze is looming, > and I've not seen it proposed for review or at least a build fix. > > I'd suggest to remove it from kdereview. > > Any other suggestions? > yeah, should go in playground until further developments... (with the goal of making it unneeded due enhancements in the systray applet and kstatusnotifieritem) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: messaging-indicator in kdereview?
On November 24, 2009, Sebastian Kügler wrote: > Hey, > > It seems there's a messaging indicator applet in kdereview since the start > of November. It doesn't build however (with karmic's packaged > libindicate-qt) and didn't get any non-scripty activity in more than two > months. Also, it's built unconditionally, even if its dependency > (libindicate-qt) isn't there, another breakage. Feature freeze is looming, > and I've not seen it proposed for review or at least a build fix. > > I'd suggest to remove it from kdereview. yes, it should either be moved to extragear at its author's decision or back to playground. -- 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: messaging-indicator in kdereview?
On Tuesday 24 November 2009 18:02:57 Aaron J. Seigo wrote: > On November 24, 2009, Sebastian Kügler wrote: > > Hey, > > > > It seems there's a messaging indicator applet in kdereview since the > > start of November. It doesn't build however (with karmic's packaged > > libindicate-qt) and didn't get any non-scripty activity in more than two > > months. Also, it's built unconditionally, even if its dependency > > (libindicate-qt) isn't there, another breakage. Feature freeze is > > looming, and I've not seen it proposed for review or at least a build > > fix. > > I'd suggest to remove it from kdereview. > > yes, it should either be moved to extragear at its author's decision or > back to playground. It seems to be developed on Canonical's bzr, I guess just deleting it is good enough then. -- 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
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/#review3253 --- Ship it! - Aaron On 2009-11-24 12:59:38, Jacopo De Simoi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2090/ > --- > > (Updated 2009-11-24 12:59:38) > > > Review request for Plasma, Aaron Seigo and Ryan Bitanga. > > > 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 > - > > 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 1053618 > trunk/KDE/kdelibs/plasma/runnercontext.cpp 1053618 > 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
Re: messaging-indicator in kdereview?
Sebastian Kügler a écrit : > On Tuesday 24 November 2009 18:02:57 Aaron J. Seigo wrote: >> On November 24, 2009, Sebastian Kügler wrote: >>> Hey, >>> >>> It seems there's a messaging indicator applet in kdereview since the >>> start of November. It doesn't build however (with karmic's packaged >>> libindicate-qt) and didn't get any non-scripty activity in more than two >>> months. Also, it's built unconditionally, even if its dependency >>> (libindicate-qt) isn't there, another breakage. Feature freeze is >>> looming, and I've not seen it proposed for review or at least a build >>> fix. >>> I'd suggest to remove it from kdereview. >> yes, it should either be moved to extragear at its author's decision or >> back to playground. > > It seems to be developed on Canonical's bzr, I guess just deleting it is good > enough > then. Yes, it can be deleted. It was posted there some time ago but was rejected so for now development continues on Launchpad. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: taskmanager library: Manual Sorting Fix
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/ --- (Updated 2009-11-24 22:21:35.429523) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- Addresses all the points from the review of aaron (thanks for the review=). I cannot check it thoroughly since my tasks applet crashes as soon as i have to reload a group item (crash somwhere in qt code). This happens also with the applet from trunk, so i guess i have to investigate into qt once To avoid a memory leak i stopped clearing the groups (since anyway we reload the tasks, right?) Normally the empty groups are closed by the grouping strategy, the rootgroups will be destroyed as the groupmanager is destroyed since they are QObject children of the groupmanager. I will do some further testing as soon as i manage to fix my setup. 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 (updated) - /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1053463 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1053463 /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.h 1053463 /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1053463 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: Webslice applet moved to kdereview
On Friday 13 November 2009 01:51:53 Sebastian Kügler wrote: > I've just moved the webslice plasmoid to kdereview, for inclusion in KDE > 4.4. > > The webslice applet is there to put an interactive part of a webpage onto > Plasma as an applet. I've addressed all the comments (thanks, btw!) and moved it to kdeplasma-addons. > Thanks, -- 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: Moving mediawiki runner to kdereview
On Thursday 12 November 2009 20:55:56 Sebastian Kügler wrote: > I've just moved a runner that searches in Mediawikis to kdereview, for > inclusion in 4.4. > > The runner can search in arbitrary mediawikis, you need to specify which > mediawiki to search in its .desktop file. (If you want to add search for > another mediawiki, just add a .desktop file for it, and you'll be fine). Comments addressed, moved to kdeplasma-addons. I've also updated the feature plan ( http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan ) Cheers, -- 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
feature completion, polshing and bug hunting is afoot .. oh, and the Changelog-4.4
hi all ... tomorrow the 25th is feature and string freeze. get your stuff in now! ;) i've gone through and handled all the items but two in kdereview for plasma (one will get moved in a couple hours here, the other one, adjustableclock, probably needs to go to extragear or playground for 4.4; i'd recommend extragear since it's ready for use, just not for inclusion in 4.4 proper), so that's good. please, please, please remember to add items of interest to kdebase/workspace/plasma/design/CHANGELOG-4.4 so we know what interesting stuff happened. we don't need (or want) every little bug fix in there (there are too many of them), but significant improvements, new features and new plugins should all be in there. thanks :) -- 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
Review Request: popup ContextMenu at a sensible position
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2278/ --- Review request for Plasma. Summary --- unsure on this and is a bit late, even. a roadblock for klipper porting to kstatusnotifieritem is that with a global shortcut it posps up the menu and is not possible to make it pop up at the "proper" systray... this adds a slot that calls ContextMenu on the systray nearest to the mouse upon a signal ContextMenuRequested() that would be emitted from the StatusNotifierItem... i think just popping up the menu at mouse cursor position would be nicer, more correct etc, but this could be a solution too... Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 1053758 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp 1053758 Diff: http://reviewboard.kde.org/r/2278/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: popup ContextMenu at a sensible position
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2278/#review3258 --- this feels broken. i think klipper should just popup the menu where the mouse is (more clever schemes might entail finding what widget has focus ... but ... yeah, i don't think we need to get that fancy) - Aaron On 2009-11-24 23:24:07, Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2278/ > --- > > (Updated 2009-11-24 23:24:07) > > > Review request for Plasma. > > > Summary > --- > > unsure on this and is a bit late, even. > a roadblock for klipper porting to kstatusnotifieritem is that with a global > shortcut it posps up the menu and is not possible to make it pop up at the > "proper" systray... > > this adds a slot that calls ContextMenu on the systray nearest to the mouse > upon a signal ContextMenuRequested() that would be emitted from the > StatusNotifierItem... > > i think just popping up the menu at mouse cursor position would be nicer, > more correct etc, but this could be a solution too... > > > Diffs > - > > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 1053758 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > 1053758 > > Diff: http://reviewboard.kde.org/r/2278/diff > > > Testing > --- > > > Thanks, > > Marco > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: taskmanager library: Manual Sorting Fix
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/#review3259 --- Ship it! looks ok; let's get this into svn and start testing it under real working conditions. - Aaron On 2009-11-24 22:21:35, Christian Mollekopf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/ > --- > > (Updated 2009-11-24 22:21:35) > > > 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/libs/taskmanager/abstractgroupableitem.h > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.h > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1053463 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.h > 1053463 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp > 1053463 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.h > 1053463 > > /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.cpp > 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1053463 > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1053463 > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.h 1053463 > /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1053463 > > 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: popup ContextMenu at a sensible position
> On 2009-11-25 00:18:30, Aaron Seigo wrote: > > this feels broken. i think klipper should just popup the menu where the > > mouse is (more clever schemes might entail finding what widget has focus > > ... but ... yeah, i don't think we need to get that fancy) it has an option for that already. it just doesn't explicitly say what happens when that opton isn't checked... - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2278/#review3258 --- On 2009-11-24 23:24:07, Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2278/ > --- > > (Updated 2009-11-24 23:24:07) > > > Review request for Plasma. > > > Summary > --- > > unsure on this and is a bit late, even. > a roadblock for klipper porting to kstatusnotifieritem is that with a global > shortcut it posps up the menu and is not possible to make it pop up at the > "proper" systray... > > this adds a slot that calls ContextMenu on the systray nearest to the mouse > upon a signal ContextMenuRequested() that would be emitted from the > StatusNotifierItem... > > i think just popping up the menu at mouse cursor position would be nicer, > more correct etc, but this could be a solution too... > > > Diffs > - > > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 1053758 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > 1053758 > > Diff: http://reviewboard.kde.org/r/2278/diff > > > Testing > --- > > > Thanks, > > Marco > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Draft: Widgets Explorer "Add Widgets"
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2191/
---
(Updated 2009-11-25 05:30:03.553432)
Review request for Plasma.
Changes
---
Diff updated. Includes:
* "Get New Widgets" button+submenu
* Changes by Petri Damstén ("get new widgets" button between the input field
and tabbar + close button)
* close button working
Summary
---
"Add widgets" button in the new widgets explorer. There are points that need to
be defined, such as the button position / strings in the interface. In this
draft, a toolbutton and a kmenu are used like in the old explorer (Variable
names changed because IMHO the old ones weren't clear).
A known issue in the interface is the menu position: Although
corona->popupPosition returns a reasonable point, the menu appears on the top
of the screen - probably, my fault.
Suggestions and comments are welcome =)
This addresses bug 211576.
https://bugs.kde.org/show_bug.cgi?id=211576
Diffs (updated)
-
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletslist.cpp
1053621
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.h
1053621
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.cpp
1053621
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletsfiltering.h
1053621
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletsfiltering.cpp
1053621
/trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp
1053621
/trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1053621
Diff: http://reviewboard.kde.org/r/2191/diff
Testing
---
Adding widgets from GHNS works, Google Gadgets are installed but the widget
list isn't updated correctly. "From file" needs more tests.
Screenshots
---
Ger New Widgets button
http://reviewboard.kde.org/r/2191/s/267/
Menu
http://reviewboard.kde.org/r/2191/s/268/
Thanks,
Anselmo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
