On Tuesday 14 April 2009, Marco Martin wrote: > On Tuesday 14 April 2009, Aaron J. Seigo wrote: > > b) should a setHandleParentAsPopup(bool) method, which would internalize > > this behaviour and all it's intricacies? this way there could also be two > > code paths: one for the legacy mode and one for the new mode > > position would have to be passed anyways tough...
yes... > > c) is there someway to avoid having to support this at all? ;) kmix is > > using it rather .. uhm .. creatively. but it seems like a valid use case > > in that situation. > > klipper too, where left and right mouse buttons do the same thing another good example indeed ... > or maybe the icon could constantly inform the app about its geometry when > changes? this would remove x and y parameters from contextmenu too... this would break with multiple visualizations and would cause a lot of traffic on the bus when moving the icons around (with the benefit of keeping shown popups "next to" the icons as they move) > maybe the default impl will take it into account for context menu and not > for activate, if for activate is rare enough it could be subclassed in > application that need it hm.. true, that's what we already do in fact. still, we need geometry information available to do it. > > * activateRequested() signal - unused? > > > > the activateRequested() signal doesn't seem to be used; is there a > > purpose for it? > > aaaw, could be a piece i forgotten, was to give the application a way to > know when the user activated the icon clicking on it (useful? not?), > thinking about it could be avoided reimplementing the show event in the > main widget... that makes sense, yes, though shouldn't it have a bool then for whether it was actually activated or not? > > * context menu handling > > > > when using KSystemTrayIcon there are some additional items added > > (activate, quit). thinking about how to handle this, we could either do > > exactly what KSystemtrayIcon does when in "new and improved" mode and add > > these items after aboutToShow is called the first time or we could > > improve on this somewhat ;) > > > > the thing with KSystemTrayIcon is that if you clear the menu after it's > > shown once, you won't get those actions in the menu anymore. nobody does > > this it seems, however., so that's all good so far. so maybe this is Good > > Enough(tm) > > > > however, we could do thing a few different ways: > > > > - provide a KActionCollection to register actions with, and then when the > > menu shows clear it and populate it with the context of the action > > collection plus our own > > couldn't be that apps could -not- want the default actions (no quit action > sounds nasty hmm, but could even make sense for system stuff?) it could be, yes. but i think they should have to take specific steps to get that behaviour, rather than randomly end up there because they repopulate on aboutToShow() ;) in any case, the standard items are only there if a parent widget is handed in. well, that's not entirely true: the quit action is currently hardcoded in there in KSystemTrayIcon. we could come up with some nice way of handling this i suppose ... -- 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 Software
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
