Re: plasma-windowed moved to kdereview
On Tuesday 27 April 2010 00:31:51 Aaron J. Seigo wrote: > hi all :) > > plasma-windowed is a helper application that run Plasma widgets in their > own windows. while a nice feature for the desktop, it's fill an important > role for the mobile shell: running widgets as full screen "apps". > > it has been moved into kdereview/plasma/shells/plasma-windowed > > the plan is to move it into kdebase/workspace/plasma/generic/shells/ wow that sounds like catching a two hares at once :) Nice feature(s) :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
> On 2010-03-29 18:34:53, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp,
> > lines 59-71
> > <http://reviewboard.kde.org/r/3375/diff/3/?file=21852#file21852line59>
> >
> > all of the winIds() stuff can be gotten rid of now that there is the
> > id() method. if winIds().isEmpty(), then desktop() is going to be 0. and
> > since the winIds() list isn't beig used, then it's probably enough to just
> > do this:
> >
> > const int leftDesktop = left->desktop();
> > const int rightDesktop = right->desktop();
> > if (leftDesktop() == rightDesktop) {
> > return left->id() < right->id();
> > }
> >
> > return leftDesktop < rightDesktop;
This really should work, but it doesn't. Exactly startup items pose the problem:
if they are not in the end of the *whole* list, then tasks layouting class
1) Sees that some new task (start up one) appeared in the middle of the list
and rearranges the items, reassigning their indexes
2) At the same time it tries to keep "startup items" in the end, and because of
this user observes "strange" moves of tasks in the middle, while startup ones
are still in the end (visually).
Putting startup tasks explicitly in the end of the list and ensuring they'll
always be there solves these problems.
But I guess the real fix should be in layouting classes in tasks applet, but
it's source is not so trivial, I need to study the code more.
So perhaps it'll need to wait to fix this in the right place.
I'll try to dig in and report when done :)
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3375/#review4747
---
On 2010-03-29 17:08:22, Dmitry Suzdalev wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3375/
> ---
>
> (Updated 2010-03-29 17:08:22)
>
>
> Review request for Plasma.
>
>
> Summary
> ---
>
> This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager
> lib.
>
> Summary:
> When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of
> by_desktop+by_winTitle as it is now.
>
> More details:
> Currently in "by desktop" sorting mode tasks are sorted by desktop and then
> by name.
> This leads to inconvenient things, here are some examples:
>
> - I have a browser with several tabs open. Whenever I change a tab, browser
> changes window title.
> This makes task jump in a task bar from one position to another while I'm
> simply changing tabs.
> - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc,
> title is changed, task jumps
> - Some other situations caused this too, don't recall, but you got the idea :)
>
> What I've done:
> Instead of sorting by name, i made it to sort by winId. Tasks without winId
> are sorted out to the end of the list
> and sorted by name there. Typically these are the startup-in-progress items.
>
> As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528
> which has the same roots:
> invalid sorting order due to wrong comparison of regular items with "starting
> up" items.
>
> Long description, short patch ;)
>
>
> This addresses bug 219528.
> https://bugs.kde.org/show_bug.cgi?id=219528
>
>
> Diffs
> -
>
> trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h
> 1105271
> trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp
> 1105271
>
> trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp
> 1105271
>
> Diff: http://reviewboard.kde.org/r/3375/diff
>
>
> Testing
> ---
>
> Tested on trunk. Task items retain their sort order, not reacting to title
> changes, charming :)
>
> It affects only task applets with sort mode set to "by desktop"
>
>
> Thanks,
>
> Dmitry
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/#review4742 --- trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h <http://reviewboard.kde.org/r/3375/#comment4263> Hmm, just thought that I probably should make it non-virtual. having it to be virtual might be useful, but it will break the guarantee of non-repeatable IDs that is currently provided by a base class. - Dmitry On 2010-03-29 17:08:22, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3375/ > --- > > (Updated 2010-03-29 17:08:22) > > > Review request for Plasma. > > > Summary > --- > > This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager > lib. > > Summary: > When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of > by_desktop+by_winTitle as it is now. > > More details: > Currently in "by desktop" sorting mode tasks are sorted by desktop and then > by name. > This leads to inconvenient things, here are some examples: > > - I have a browser with several tabs open. Whenever I change a tab, browser > changes window title. > This makes task jump in a task bar from one position to another while I'm > simply changing tabs. > - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, > title is changed, task jumps > - Some other situations caused this too, don't recall, but you got the idea :) > > What I've done: > Instead of sorting by name, i made it to sort by winId. Tasks without winId > are sorted out to the end of the list > and sorted by name there. Typically these are the startup-in-progress items. > > As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 > which has the same roots: > invalid sorting order due to wrong comparison of regular items with "starting > up" items. > > Long description, short patch ;) > > > This addresses bug 219528. > https://bugs.kde.org/show_bug.cgi?id=219528 > > > Diffs > - > > trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h > 1105271 > trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp > 1105271 > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp > 1105271 > > Diff: http://reviewboard.kde.org/r/3375/diff > > > Testing > --- > > Tested on trunk. Task items retain their sort order, not reacting to title > changes, charming :) > > It affects only task applets with sort mode set to "by desktop" > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/ --- (Updated 2010-03-29 17:08:22.316461) Review request for Plasma. Changes --- Added an id() method to AbstractGroupableItem class which assigns a new int-based id to each new instance of the class. New id is based on a static field inside AbstractGroupableItem. Also note that winIds() stuff inside comparison function is still needed to correctly sort out startup tasks to the end of the list. If it won't be done, they'll spoil the party because having startup items in the middle of the list confuses layouting algorithm and makes the items "jump" as they get clicked. Summary --- This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager lib. Summary: When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of by_desktop+by_winTitle as it is now. More details: Currently in "by desktop" sorting mode tasks are sorted by desktop and then by name. This leads to inconvenient things, here are some examples: - I have a browser with several tabs open. Whenever I change a tab, browser changes window title. This makes task jump in a task bar from one position to another while I'm simply changing tabs. - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title is changed, task jumps - Some other situations caused this too, don't recall, but you got the idea :) What I've done: Instead of sorting by name, i made it to sort by winId. Tasks without winId are sorted out to the end of the list and sorted by name there. Typically these are the startup-in-progress items. As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: invalid sorting order due to wrong comparison of regular items with "starting up" items. Long description, short patch ;) This addresses bug 219528. https://bugs.kde.org/show_bug.cgi?id=219528 Diffs (updated) - trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1105271 trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 1105271 trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp 1105271 Diff: http://reviewboard.kde.org/r/3375/diff Testing --- Tested on trunk. Task items retain their sort order, not reacting to title changes, charming :) It affects only task applets with sort mode set to "by desktop" Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
> On 2010-03-23 22:05:51, Aaron Seigo wrote: > > so essentially it removes any sorting within the desktop sorting. i'm fine > > with that change (though perhaps others will now complain ;), though i have > > some thoughts below. Hmm, I just realized that some people might like to keep tasks sub-sorted by name indeed. For some reason I don't care about that a bit, but otoh this constant "jumping" of tasks always made me eager to write this patch :) So now i'm really confused - will the majority of people be like me or the opposite? :) Usability advice needed. If i'm in the minority, then I guess I can perfectly keep these changes local > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 66 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line66> > > > > so window groups will shuffle randomly when windows leave or join or > > anything else that may cause winIds() to shift order. seems like trading > > one issue for another. > > > > i wonder if it wouldn't be nicer to have a stable way to identify > > AbstractGroupableTasks (a QUuid? or an integer based sequence?) for such > > occasions. > > > > that would also make things such as leftWinIdIsValid unecessary. the > > winId is just as random to the user; the only downside i can see is a small > > amount more memory consumption. Yes, this would be better indeed. In my klipper experiments i used QUuids to identify history items. but are there some downsides of simply assigning each new task an integer id++ as it's ID? That would be lighter that quuid :) > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 70 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line70> > > > > can be just "else if (leftWinIdIsValid)" since we know both aren't due > > to the initial if. yes, thanks > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 78 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line78> > > > > why storing in a temp var which is returned? nice one :) will change. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/#review4637 --- On 2010-03-23 20:48:15, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3375/ > --- > > (Updated 2010-03-23 20:48:15) > > > Review request for Plasma. > > > Summary > --- > > This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager > lib. > > Summary: > When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of > by_desktop+by_winTitle as it is now. > > More details: > Currently in "by desktop" sorting mode tasks are sorted by desktop and then > by name. > This leads to inconvenient things, here are some examples: > > - I have a browser with several tabs open. Whenever I change a tab, browser > changes window title. > This makes task jump in a task bar from one position to another while I'm > simply changing tabs. > - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, > title is changed, task jumps > - Some other situations caused this too, don't recall, but you got the idea :) > > What I've done: > Instead of sorting by name, i made it to sort by winId. Tasks without winId > are sorted out to the end of the list > and sorted by name there. Typically these are the startup-in-progress items. > > As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 > which has the same roots: > invalid sorting order due to wrong comparison of regular items with "starting > up" items. > > Long description, short patch ;) > > > This addresses bug 219528. > https://bugs.kde.org/show_bug.cgi?id=219528 > > > Diffs > - > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp > 1105743 > > Diff: http://reviewboard.kde.org/r/3375/diff > > > Testing > --- > > Tested on trunk. Task items retain their sort order, not reacting to title > changes, charming :) > > It affects only task applets with sort mode set to "by desktop" > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/ --- Review request for Plasma. Summary --- This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager lib. Summary: When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of by_desktop+by_winTitle as it is now. More details: Currently in "by desktop" sorting mode tasks are sorted by desktop and then by name. This leads to inconvenient things, here are some examples: - I have a browser with several tabs open. Whenever I change a tab, browser changes window title. This makes task jump in a task bar from one position to another while I'm simply changing tabs. - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title is changed, task jumps - Some other situations caused this too, don't recall, but you got the idea :) What I've done: Instead of sorting by name, i made it to sort by winId. Tasks without winId are sorted out to the end of the list and sorted by name there. Typically these are the startup-in-progress items. As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: invalid sorting order due to wrong comparison of regular items with "starting up" items. Long description, short patch ;) This addresses bug 219528. https://bugs.kde.org/show_bug.cgi?id=219528 Diffs - trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp 1105743 Diff: http://reviewboard.kde.org/r/3375/diff Testing --- Tested on trunk. Task items retain their sort order, not reacting to title changes, charming :) It affects only task applets with sort mode set to "by desktop" Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-21 15:50:26.488754) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- Updated patch as discussed with mart on irc: removed the API addition, left only logic that disables auto-addition of subtitles to non-unique items - disabling is done if model does provide some valid data for SubTitleMandatoryRole. This indicates model wants to have a full control for subtitle visibility. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs (updated) - trunk/KDE/kdelibs/plasma/delegate.h 1010706 trunk/KDE/kdelibs/plasma/delegate.cpp 1010706 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
> On 2009-08-20 10:03:58, Aaron Seigo wrote: > > why isn't the model returning an appropriate negative value for the > > subtitle? This whole discussion raised because of this: by default, Plasma::Delegate has the policy of automatically adding subtitles if two adjasent items are of the same content. I questioned why this should be the default - for example while writing a klipper plasmoid I found this as a surprise - and we discussed the addition of such api. Though later (after i published the review), me and mart agreed that maybe it's not really necessary to have the api changed, maybe the only change in the end would be the addition of that part of logic which would not try to be that clever if QVariant() is returned for SubTitleMandatoryRole (i.e. if model doesn't implement returning something for this role). Otherwise it appears that model cannot have exact control where to show and where not to show title. For example, even if it implements returning 'true' for some items and 'false' for other items, the items with 'false' will still be auto-disambiguated inside a delegate. So the main point now is to leave only checking for data validity of SubTitleMandatoryRole, and do disambiguating *only* if model doesn't care. I've yet to update this review with the actual patch. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/#review2091 --- On 2009-08-18 21:59:39, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1357/ > --- > > (Updated 2009-08-18 21:59:39) > > > Review request for Plasma and Aaron Seigo. > > > Summary > --- > > This adds more control of showing subtitles with Plasma::Delegate by adding a > setSubtitlePolicy() method to its API. > Discussed briefly on #plasma with notmart, now on to review :) > > > Diffs > - > > trunk/KDE/kdelibs/plasma/delegate.h 1011618 > trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 > > Diff: http://reviewboard.kde.org/r/1357/diff > > > Testing > --- > > Tested with klipper applet by putting it in all modes possible (at least all > i can come up with :)) > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-18 21:59:39.951021) Review request for Plasma and Aaron Seigo. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- Review request for Plasma. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet and setFocus() behaviour
On Tuesday 18 August 2009 02:20:25 Aaron J. Seigo wrote: > ugly; perhaps we should allow plasmoids to set a keyboard focus widget .. > thinks Yep, but the only workaround I found currently working is this: - In my KlipperApplet::focusInEvent() call mywidget->setFocus(). This ensures focus gets set when clicking on an icon in a panel with mouse. Or else I can't get the focus set right while clicking (at least in the ways i tried) - In KlipperApplet::popupEvent() call mywidget->setFocus() too. This ensures that focus gets set when invoking popup with a global shortcut assigned to it. If I'm not calling it here, focus doesn't get set on keyboard invocation of the popup. Yeah, these are workarounds, not very good. > actually, when a popup occurs, we should probably shift keyboard focus to t > he > first widget in the keyboard focus chain automatically. then it would simp > ly be up to you to ensure that the list view is the first item in the tab- > switching order :) Would be nice I think. But we'll need to ensure that focus gets set only after d->dialog inside a popupapplet will be activated. Or any other possible (temporary or offscreen for ex) widget on the scene. That is we don't wont a focusOut event coming to the widget right after we told it to focusIn :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet and setFocus() behaviour
On Friday 14 August 2009 00:32:09 Marco Martin wrote: > On Thursday 13 August 2009, Dmitry Suzdalev wrote: > > Hi guys and girls! > > > > While making some progress on klipper engine+applet I discovered some > > oddities with focus behavior. I hope you can give me some hints about my > > situation (don't get scared by amount of text below, i tried to make it > > simple to follow). > > in the microblogging plasmoid the focus to the input field seems to be > correctly given. > it sets the focus to the input field in the focusIn event of the applet > (that always happens after a popup event) would be useful to you? I just tried that. This works ok when I invoke popup by clicking on the applet's icon in a panel - focus is set correctly. But if I assign a keyboard shortcut for the applet, focus isn't being set to my widget in focusInEvent(). On the contrary, if I use my previous method of calling setFocus() in a popupEvent(), this works when I trigger a popup by a shortcut, but doesn't work when I click on icon in panel :) Any ideas why is this so? > i am wondering if a setMainInputWidget() api call could be added to the > popupapplet api, if it's a common case enough If this is indeed a common case, that would be nice. Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PopupApplet and setFocus() behaviour
Hi guys and girls! While making some progress on klipper engine+applet I discovered some oddities with focus behavior. I hope you can give me some hints about my situation (don't get scared by amount of text below, i tried to make it simple to follow). General layout of applet widgets is the following: Applet is a PopupApplet. It has a QGraphicsProxyWidget as graphicsWidget(), which has embedded QWidget (named KlipperWidget) which has a QListView inside (it displays clipboard history entries). What I'm trying to do is to make sure that this QListView will always have keyboard focus when popup is shown. I'm doing it by overriding a PopupApplet::popupEvent() and calling KlipperWidget's setFocus() function. KlipperWidget has a QListView set as a focus proxy for this to work. And it works... but only when I launch applet in "plasmoidviewer -f horizontal klipper". Problem: When applet is inside plasma-desktop, no focus gets set. I tried to debug this and found that when running as a part of plasma-desktop, QListView actually gets only FocusOut event, and not a single FocusIn. After looking through souces of a popup applet and debugging a bit, i also found that probably the following happens when running in plasma-desktop: 1. PopupApplet::popupEvent() arrives before popup gets WindowActivated event 2. I call setFocus() 3. Immediately after this eventloop delivers WindowActivated event ( for "dialog" widget inside popupapplet.cpp) 4. WindowActivated event gets inside a QGraphicsScene, after this scene sends FocusOut event to any active focus item inside it 5. FocusIn is sent to popupapplet's toplevel dialog, but my widget gets only FocusOut Somehow this doesn't happen for plasmoidviewer. Maybe order of Activation/FocusIn event differs there, dunno. Anyway, if someone has read until here, let me and with a question: What to do? :-) It might be a bug somewhere, it might be not. I'm not sure. I can't find a mechanism to defer my setFocus() until i know that popup dialog has been shown. I don't want to use a timer as that's not 100% fix and can lead to users noticing a slight delay. In the end I want to simply ensure that my widget will always have focus when shown in a popup. Is this possible? Is there some potential workaround you see? Thanks in advance, Dmitry. PS. If you want to look at the code it can be found here: http://websvn.kde.org/trunk/playground/base/klipper-ng/plasmoid/applet/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PopupApplet and setFocus() behaviour
Hi guys and girls! While making some progress on klipper engine+applet I discovered some oddities with focus behavior. I hope you can give me some hints about my situation (don't get scared by amount of text below, i tried to make it simple to follow). General layout of applet widgets is the following: Applet is a PopupApplet. It has a QGraphicsProxyWidget as graphicsWidget(), which has embedded QWidget (named KlipperWidget) which has a QListView inside (it displays clipboard history entries). What I'm trying to do is to make sure that this QListView will always have keyboard focus when popup is shown. I'm doing it by overriding a PopupApplet::popupEvent() and calling KlipperWidget's setFocus() function. KlipperWidget has a QListView set as a focus proxy for this to work. And it works... but only when I launch applet in "plasmoidviewer -f horizontal klipper". Problem: When applet is inside plasma-desktop, no focus gets set. I tried to debug this and found that when running as a part of plasma-desktop, QListView actually gets only FocusOut event, and not a single FocusIn. After looking through souces of a popup applet and debugging a bit, i also found that probably the following happens when running in plasma-desktop: 1. PopupApplet::popupEvent() arrives before popup gets WindowActivated event 2. I call setFocus() 3. Immediately after this eventloop delivers WindowActivated event ( for "dialog" widget inside popupapplet.cpp) 4. WindowActivated event gets inside a QGraphicsScene, after this scene sends FocusOut event to any active focus item inside it 5. FocusIn is sent to popupapplet's toplevel dialog, but my widget gets only FocusOut Somehow this doesn't happen for plasmoidviewer. Maybe order of Activation/FocusIn event differs there, dunno. Anyway, if someone has read until here, let me and with a question: What to do? :-) It might be a bug somewhere, it might be not. I'm not sure. I can't find a mechanism to defer my setFocus() until i know that popup dialog has been shown. I don't want to use a timer as that's not 100% fix and can lead to users noticing a slight delay. In the end I want to simply ensure that my widget will always have focus when shown in a popup. Is this possible? Is there some potential workaround you see? Thanks in advance, Dmitry. PS. If you want to look at the code it can be found here: http://websvn.kde.org/trunk/playground/base/klipper-ng/plasmoid/applet/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Difficult to drop icons to autohidden panel
Hi! How hard it would be to make autohidden panel to show when I drag something that it can accept? For example, I want to drag some icon from kickoff to panel. Currently I need to make its type "always visible", then drag&drop, then make it auto-hidden again. Not very straighforward. I know a little about panel internals, perhaps there's something preventing showing when I drag smth to a screen edge? Or just not implemented yet? Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug update
On Wednesday 19 November 2008 17:22:36 Aaron J. Seigo wrote: > > - I had vertical panel on right side of the second screen, now it's > > vanished. konsole is maximized so windows still think it's there. > > which means the panel still thinks its there too. look for debug output on > konsole about view creation and panels near the start of plasma.. Btw, there are many of us now with the same breakage :) At least Morpheuz and annma and me. Panel is on the first desktop only. Others have no panel and desktop bkgnd is gray. Cachew is on the left instead of the right. I spotted these lines in log, can they be related? plasma(8894) PlasmaApp::createView: Containment name: "Panel" | type 1 | screen: 0 | desktop: -1 | geometry: QRectF(0,-155 1600x67) | zValue: 150 plasma(8894)/libplasma Plasma::ViewPrivate::updateSceneRect: ! setting the scene rect to QRectF(0,-155 1600x67) associated screen is 0 plasma(8894) PanelView::pinchContainment: pinching QRect(0,0 1600x1200) 1600 plasma(8894) PanelView::updatePanelGeometry: New panel geometry is QRectF(0,-155 1600x67) plasma(8894) PanelView::updatePanelGeometry: PanelView(0x9a409d8) thinks its panel is at QRect(0,0 1600x67) was QRect(0,0 800x480) plasma(8894) PanelView::pinchContainment: Done pinching, containement's geom QRectF(0,-155 1600x67) own geom QRect(0,0 1600x67) plasma(8894) PanelView::PanelView: Panel geometry is QRectF(0,-155 1600x67) plasma(8894) PanelView::resizeEvent: QSize(-1, -1) QSize(1600, 67) plasma(8894) PlasmaApp::corona: --> 1131 plasma(8894)/libplasma Plasma::PopupAppletPrivate::popupConstraintsEvent: graphics widget is Plasma::Extender(0x97fcf68) plasma(8894) Image::setSingleImage: "" "/home/ulet/.kde4/share/wallpapers/72286- DreamlandB.jpg" ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug update
On Tuesday 18 November 2008 20:22:22 Aaron J. Seigo wrote: > i have a saved search on bugs.kde.org for plasma, and it's a great time > saver. it shows all non-wishlist, still open bugs for the plasma component. Perhaps it would be nice to share it using new bugzilla's sharing abilities? :) It's on MyAccount=>Edit my Preferences=>Saved Searches=>Share With a Group. Then plasma team people can go to the same page as above and put a checkbox in front of your shared saved search in corresponding table and voila! :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Uninstalling applets from GUI
On Sunday 16 November 2008 23:41:15 Aaron J. Seigo wrote: > > I think there really whould be an option to do this from gui or this is a > > major flow. > > patch? Nope :) But if functionality to do this exists, I'll look into this eventually. You say it is possible to uninstall GetHotNewStuff-installed packages, but what about hand-compiled and then installed applets? How would be this accomplished? For example I have a lot of applets from playground. Use case: I want to uninstall one of them. Is this supported API-wise? Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Uninstalling applets from GUI
Hi guys and girls :) Tell me am i right that currently there's no way to uninstall some plasma applet using GUI (appletbrowser or whatever)? I know I can rm -rf related files from command line, but imo it's not very user friendly way of doing things :) Is it really so or am i missing some way to do this? I think there really whould be an option to do this from gui or this is a major flow. Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make sure that focused result item is visible when navigating with Tab key
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/245/ --- (Updated 2008-10-26 16:13:07.755803) Review request for Plasma and Aaron Seigo. Summary --- This patch makes krunner's ResultScene correctly update current page when navigating through items using Tab key. Without this patch it works correctly (i.e. page is changed as user focuses some item on a next page) only if Up/Down/Left/Right keys are pressed. As we can't catch Key_Tab in keyPressEvent, we'll watch for item selection events. Diffs - /trunk/KDE/kdebase/workspace/krunner/resultscene.h /trunk/KDE/kdebase/workspace/krunner/resultscene.cpp Diff: http://reviewboard.vidsolbach.de/r/245/diff Testing --- Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make sure that focused result item is visible when navigating with Tab key
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/245/ --- (Updated 2008-10-26 16:11:43.080868) Review request for Plasma and Aaron Seigo. Summary --- This patch makes krunner's ResultScene correctly update current page when navigating through items using Tab key. Currently it works correctly (i.e. page is changed as user focuses some item on a next page) only if Up/Down/Left/Right keys are pressed. As we can't catch Key_Tab in keyPressEvent, we'll watch for item selection events. Diffs - /trunk/KDE/kdebase/workspace/krunner/resultscene.h /trunk/KDE/kdebase/workspace/krunner/resultscene.cpp Diff: http://reviewboard.vidsolbach.de/r/245/diff Testing --- Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 19:26:22 Sebastian Kügler wrote: > Only the ones that open popups automatically. The power management control > extender from the battery and the calendar should have focus. (But I think > it's fine to make that explicit in the applet itself.) Ok, so we need some function in popup applet which will allow its subclasses to specify desired behavior. Before that I guess we need to find some combination of Qt::WindowFlags or NET::* flags which make popups focusless and don't break extenders at the same time :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [CRASH] Can't start plasma - crash at startup
On Sunday 26 October 2008 17:12:33 Alexis Ménard wrote: > so you edit you .kde/share/config/plasma-appletrc > > remove eyes inside, then you can restart plasma properly. Try to add eyes > again. If it crash then the problem is in Eyes. Not exactly. I meant that it may be the case that Eyes is using libplasma in some unexpected way that triggered some unpredicted codepath that resulted in a crash :) But giving this bt a second look it seems like it's not libplasma's fault though. Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[CRASH] Can't start plasma - crash at startup
Hi! I've just updated kdebase and now I can't start plasma - it repeatedly
crashes on each startup. Something to do with Eyes applet or it's some
plasmalib error...
Here's the backtrace:
Application: Plasma Workspace (plasma), signal SIGSEGV
[Current thread is 0 (LWP 12145)]
Thread 2 (Thread 0xb308bb90 (LWP 12148)):
#0 0xb7f1d424 in __kernel_vsyscall ()
#1 0xb6820025 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/i686/cmov/libpthread.so.0
#2 0xb68835d2 in QWaitCondition::wait (this=0x8bf6688, mutex=0x8bf6684,
time=4294967295) at thread/qwaitcondition_unix.cpp:88
#3 0xb7c607ca in QHostInfoAgent::run (this=0x8bf6678) at
kernel/qhostinfo.cpp:247
#4 0xb6882840 in QThreadPrivate::start (arg=0x8bf6678) at
thread/qthread_unix.cpp:191
#5 0xb681c4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#6 0xb667961e in clone () from /lib/i686/cmov/libc.so.6
Thread 1 (Thread 0xb4a856e0 (LWP 12145)):
[KCrash Handler]
#6 0xb7e21801 in Plasma::Svg::paint (this=0x0, painter=0xbfb346c4,
[EMAIL PROTECTED], [EMAIL PROTECTED]) at
/home/ezhik/kdesvn/kdebase/workspace/libs/plasma/svg.cpp:386
#7 0xb319bde8 in Eyes::paintInterface () from
/opt/kde4/lib/kde4/plasma_applet_eyes.so
#8 0xb7dc444e in Plasma::Applet::paint (this=0x8b26480, painter=0xbfb346c4,
option=0xbfb34284, widget=0x0) at
/home/ezhik/kdesvn/kdebase/workspace/libs/plasma/applet.cpp:990
#9 0xb726e9d2 in _q_paintItem (item=,
painter=0xbfb346c4, option=0xbfb34284, widget=0x0, useWindowOpacity=false,
painterStateProtection=true)
at graphicsview/qgraphicsscene.cpp:3789
#10 0xb727597d in QGraphicsScenePrivate::drawItemHelper (item=0x8b26488,
painter=0xbfb352fc, option=0x8c92be8, widget=0x8c58850,
painterStateProtection=)
at graphicsview/qgraphicsscene.cpp:3954
#11 0xb7275ee0 in QGraphicsScene::drawItems (this=0x8a4b3f8,
painter=0xbfb352fc, numItems=20, items=0x8c35748, options=0x8c92954,
widget=0x8c58850) at graphicsview/qgraphicsscene.cpp:4042
#12 0xb728439c in QGraphicsView::drawItems (this=0x8c660d8,
painter=0xbfb352fc, numItems=20, items=0x8c35748, options=0x8c92954) at
graphicsview/qgraphicsview.cpp:3357
#13 0xb728cbe1 in QGraphicsView::paintEvent (this=0x8c660d8, event=0xbfb3586c)
at graphicsview/qgraphicsview.cpp:3102
#14 0xb7eeb38a in PanelView::paintEvent (this=0x8c660d8, event=0xbfb3586c) at
/home/ezhik/kdesvn/kdebase/workspace/plasma/shells/desktop/panelview.cpp:812
#15 0xb6db0891 in QWidget::event (this=0x8c660d8, event=0xbfb3586c) at
kernel/qwidget.cpp:7307
#16 0xb7099633 in QFrame::event (this=0x8c660d8, e=0xbfb3586c) at
widgets/qframe.cpp:657
#17 0xb71236af in QAbstractScrollArea::viewportEvent (this=0x8c660d8,
e=0x8b26480) at widgets/qabstractscrollarea.cpp:949
#18 0xb728b1ef in QGraphicsView::viewportEvent (this=0x8c660d8,
event=0xbfb3586c) at graphicsview/qgraphicsview.cpp:2343
#19 0xb7125ad5 in QAbstractScrollAreaFilter::eventFilter (this=0x8c59088,
o=0x8c58850, e=0xbfb3586c) at widgets/qabstractscrollarea_p.h:102
#20 0xb695c74a in QCoreApplicationPrivate::sendThroughObjectEventFilters
(this=0x89d3f48, receiver=0x8c58850, event=0xbfb3586c) at
kernel/qcoreapplication.cpp:700
#21 0xb6d5e1ca in QApplicationPrivate::notify_helper (this=0x89d3f48,
receiver=0x8c58850, e=0xbfb3586c) at kernel/qapplication.cpp:3805
#22 0xb6d646fa in QApplication::notify (this=0x89b6910, receiver=0x8c58850,
e=0xbfb3586c) at kernel/qapplication.cpp:3774
#23 0xb77bca85 in KApplication::notify (this=0x89b6910, receiver=0x8c58850,
event=0xbfb3586c) at
/home/ezhik/kdesvn/kdelibs/kdeui/kernel/kapplication.cpp:307
#24 0xb695d541 in QCoreApplication::notifyInternal (this=0x89b6910,
receiver=0x8c58850, event=0xbfb3586c) at kernel/qcoreapplication.cpp:589
#25 0xb6db720e in qt_sendSpontaneousEvent (receiver=0x8c58850,
event=0x8b26480) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:218
#26 0xb6dad3a0 in QWidgetPrivate::drawWidget (this=0x8c591b8, pdev=0x8c597d4,
[EMAIL PROTECTED], [EMAIL PROTECTED], flags=,
sharedPainter=0x8b389b0) at kernel/qwidget.cpp:4642
#27 0xb6dadc14 in QWidgetPrivate::paintSiblingsRecursive (this=0x8c66148,
pdev=0x8c597d4, [EMAIL PROTECTED], index=2, [EMAIL PROTECTED],
[EMAIL PROTECTED], flags=4, sharedPainter=0x8b389b0)
at kernel/qwidget.cpp:4741
#28 0xb6dad117 in QWidgetPrivate::drawWidget (this=0x8c66148, pdev=0x8c597d4,
[EMAIL PROTECTED], [EMAIL PROTECTED], flags=4, sharedPainter=0x8b389b0) at
kernel/qwidget.cpp:4683
#29 0xb6efd7dc in QWidgetBackingStore::cleanRegion (this=0x8c59038,
[EMAIL PROTECTED], widget=0x8c660d8, recursiveCopyToScreen=true) at
painting/qbackingstore.cpp:1040
#30 0xb6efdb25 in qt_syncBackingStore (rgn={d = 0xbfb35cac, static
shared_empty = {ref = {_q_value = 335}, rgn = 0x0, xrectangles = 0x0, qt_rgn =
0x0}}, widget=0x8c660d8,
recursive=) at painting/qbackingstore.cpp:238
#31 0xb6efdb90 in qt_syncBackingStore (rgn={d = 0xbfb35d9c, static
shared_empty = {ref = {_q_value = 335}, rgn = 0x0, xrectangles = 0x0, qt_rgn =
0x0}}, widget=0x8c660d8)
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 19:13:01 Aaron J. Seigo wrote: > On Wednesday 22 October 2008, Rob Scheepmaker wrote: > > > So I'm thinking what's the best way to do this? A parameter to popup() > > > function? A new function PopupApplet::setPopupAsTooltip(bool)? > > > something else? > > > > I think the don't steal focus behavior should be default for all > > popupapplets. > > .. that popup automatically. > > for popups that are trigerred by user interaction, this could get annoying > in all new ways. Ok, but workaround against wrong behaviour of Qt::Popup that Rob talked about still has to be found. That brings us to the question of introducing setPopupWindowFlags(Qt::WindowFlags) - if user will set Qt::Popup, he'll break extenders stuff... Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 18:54:28 Rob Scheepmaker wrote: > Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly > when you want to be able to drag widgets away from the window, as is > possible with extender items. But I agree we should avoid the dialog > stealing focus. I assume there is some window flag to accomplish that. I > will look into that. That would be very nice, thanks! Perhaps use some NET:: flags would help? > I think the don't steal focus behavior should be default for all > popupapplets. Ah, this makes thing easier (no api modifications required) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 17:31:15 Dan Meltzer wrote: > Readers digest version for those of you that don't have lotsa free time: > > Popup notifications should not steal focus, ever. They are the new > round of passivePopups and should behave as so. Hehe, thanks! :) It's great to have our bug-issue in a two forms :) Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PROBLEM] New systray notifications and kwin
Hello! I just found a real problem with new notifications system. Let me describe it. New notifications are shown using a PopupApplet which is a full-blown window from the KWin POV. So what happens is the following: dimsuz is touch-typing with amazing speed in his kmail window. at the same time he often alt-tabs to kopete to chat with friends, and also types much in konversation in #plasma channel :) At the same time a lot of notifications arrive, and guess what - each of them steals focus from dimsuz's current input widget! Because each of them has a default window role. What do you think dimsuz thinks on each notification appearance? Yeah, he thinks: "#%#!!!?#?!!!" And then clicks back on the widget he is typing into :) I tried to fix this one, but quickly found that systray (being a PopupApplet) just uses PopupApplet::popup() function. That is systray has no control on the dialog that pops up. I think that it should be able to somehow tell the popup() that this particular popup should be of Qt::Tooltip type or something like that. So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? Note, that i think this is a problem that really needs to be fixed, as it may potentially annoy a lot of our users :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray rewrite ready for review
On Thursday 21 August 2008 11:57:36 Aaron J. Seigo wrote: > the idea is to prevent having to have two widgets, each taking up space, > and coming up with a sensible icon for the notifications. Oh, now I see! So the only thing that needs to be done is to move most of my code to systray applet while removing panel icon bits from it :) And I guess dataengine should stay as it is, right? Ok, i'm currently in process of kdesvn-build, so i'll take a look at new systray and see how we should progress further. Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray rewrite ready for review
On Wednesday 20 August 2008 16:43:45 Aaron J. Seigo wrote: > * we need to start thinking about merging this widget with the > notifications widget... Again, I'd say that I have no clear vision on what is planned. Me and Jason had a chat on irc about this and iiuc he has no clear understanding either (but that may have already changed :) ). So, hey, i-was-at-Akademy guys, could you please-please describe how do you envision this merge? :) Perhaps by describing different situations and how applet should behave or maybe doing a quick mockup. Do understand that when i hear "oh, they should be merged" or "notifications should be shown instead of icons" or "systray changes, notify applet should be made iconless", I have a hard times trying to see the whole picture :-) Perhaps it's only me, i'm not sure :-P Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
