Review Request: common delegate for listviews

Aaron Seigo aseigo at kde.org
Tue Mar 18 03:00:27 CET 2008


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://mattr.info/r/305/#review308
-----------------------------------------------------------

Ship it!


i like it =)

as for just using the same Plasma roles, i considered this briefly at one point but then realized that this means that we couldn't use third party models, but only models we write ourselves with the delegate. i don't know if that will ever actually be an issue, but with setRole at least one is free to do so.

setRole can, of course, be a fallback. if the standard role #s are used, if setRole isn't called it should just use the roles as it expects them. this allows our own models to re-use the 'standard' role #s while not constraining us to them in the case of third party models.

as for a shared view .. i'm on the fence on that one. writing custom views should probably be avoided if possible in the first place. *shrug*

- Aaron


On 2008-03-17 15:55:10, Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://mattr.info/r/305/
> -----------------------------------------------------------
> 
> (Updated 2008-03-17 15:55:10)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> This is a preliminary version of an item delegate that lives in libs/plasma to be used for all the listviews that are used as a menu, that at the moment are kickoff and devicenotifier.
> at the moment is used only by devicenotifier, maybe some changes will be needed.
> if a subclass wants to paint over the item can retrieve empty aeas with rectAfterTitle, rectAfterSubTitle and emptyRect functions
> 
> some thing i'm still unsure:
> at the moment the roles are mapped from the model with the function setRole(SpecificRoles role, int actual) like discussed on the ml.
> i'm thinking about another way: forcing the models to use the roles defined in Plasma::Delegate and the custom roles to not conflict with them should be defined as PlasmaUserRole+1 +2 and so on. how is that?
> 
> the view of devicenotiview has become way more complex (to handle highlight on mouse over) should moved to a common view also that? (wonder if it would be useful, some will have to reimplement everything nevertheless, like flipscrollview of kickoff...)
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/workspace/libs/plasma/CMakeLists.txt
>   /trunk/KDE/kdebase/workspace/libs/plasma/delegate.h
>   /trunk/KDE/kdebase/workspace/libs/plasma/delegate.cpp
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/CMakeLists.txt
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/itemdelegate.h
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/itemdelegate.cpp
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.h
>   /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.cpp
> 
> Diff: http://mattr.info/r/305/diff
> 
> 
> Testing
> -------
> 
> tested with devicenotifier applet
> tested also with rtl layout, fixed some problems the kickoff has with it.
> 
> 
> Screenshots
> -----------
> 
> new look
>   http://mattr.info/r/305/s/36/
> 
> 
> Thanks,
> 
> Marco
> 
>



More information about the Panel-devel mailing list