Review Request: a way for a custom corona to forbid some standard context menu entries

Marco Martin notmart at gmail.com
Sat Jan 16 07:42:29 CET 2010


On 1/15/10, Aaron Seigo <aseigo at kde.org> wrote:
>
>
>> 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 :)
>
> 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.

yeah, totally agree

> 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)
>
>
> - Aaron
>
>
> -----------------------------------------------------------
> 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
>>
>>
>
>


More information about the Plasma-devel mailing list