> On 2010-01-14 18:18:26, Chani Armitage wrote: > > :/ this feels wrong. > > > > for the screensaver, I just created a separate mouse plugin. > > I suppose the netbook shares actions like "log out" and "lock screen" > > though, which makes this a bit trickier... > > we don't really want to duplicate all that code, but nor do we want a > > special hack for the contextmenu plugin... > > really, all those plugins were written with just the desktop in mind, they > > should be in desktop/ not generic/. > > > > *thinks* > > > > abusing kauthorized wouldn't be much better, I guess? > > Marco Martin wrote: > yeah, this was just as an experiment to see what options there could be. > in the netbook a right mouse button menu makes sense, just that single action > shouldn't be here... > > so, i see at the moment 2 possibilities: > -every shell will have its own menu implementation, like DesktopMenu, > NetbookMenu ScreensaverMenu etc. quite code duplication but would avoid not > too pretty new api > -there is a single menu plugin, but is the list of qactions that depends > from te shell, so a qlist of ContamentContextActions(ugh what an ugly name) > will be provided by the implementations, so the ndividua coronas... ugly api > less duplication. > > hmmm, fscinating problem :) > > Aaron Seigo wrote: > i don't think it's worth adding to the libplasma API for what really > amounts to one plugin and a subset of its features. > > for the particular case mentioned, it suggest that the action should come > from the corona. and i agree with that :) in that case the plugin could check > if the corona has a "add panel" action and if so include it, otherwise don't. > > at the worst, simply duplicating this one plugin would be a better answer > imho than the API proposal, but distributing the actions around sounds even > better to me. (that particular plugin's code could also likely end up being a > lot simpler than it is right now; there are a number of collection classes > that are being kept in sync with each other, for instance) > >
yes, this is a muuuuch cleaner way. done as in revision 1079633 - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2580/#review3697 ----------------------------------------------------------- On 2010-01-14 11:03:23, Marco Martin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2580/ > ----------------------------------------------------------- > > (Updated 2010-01-14 11:03:23) > > > Review request for Plasma and Chani Armitage. > > > Summary > ------- > > This approach doesn't look that right, but is the only way i could think of: > in the netbook shell there really shouldn't be the "add panel" context menu > entry since it isn't supported (what happens right now is the panel > containment being created and no views assigned to it. > we could also decide that yeah, indeed the netbook should support multiple > panels too (was thinking about that for unrelated reasons) but the problem > would propose itself again when we do another shell without panels but that > still make sense to have context menus (like the screensaver) > i tried to do a generic mechanism: all actions will be enabled by default and > the corona keeps a blacklist of them (corona or containment? some actions > make sense to be enabled or disabled only globally, like add panel, others > could be containment dependent?) > setContaimentActionEnabled() adds the action to the blacklist > > this is just a stub, all actions should check their availability in the future > > > Diffs > ----- > > > /trunk/KDE/kdebase/workspace/plasma/generic/containmentactions/contextmenu/menu.cpp > 1070354 > /trunk/KDE/kdebase/workspace/plasma/netbook/shell/netcorona.cpp 1070354 > /trunk/KDE/kdelibs/plasma/containment.h 1074119 > /trunk/KDE/kdelibs/plasma/containment.cpp 1074119 > /trunk/KDE/kdelibs/plasma/corona.h 1074119 > /trunk/KDE/kdelibs/plasma/corona.cpp 1074119 > > Diff: http://reviewboard.kde.org/r/2580/diff > > > Testing > ------- > > > Thanks, > > Marco > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
