'Re: Review Request: Return 80% functionality to PMC,'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Return 80% functionality to PMC,
From:       "Christophe Olinger" <olingerc () binarylooks ! com>
Date:       2010-04-20 8:39:32
Message-ID: 20100420083932.19673.63451 () localhost
[Download RAW message or body]

> On 2010-04-19 07:59:49, Alessandro Diaferia wrote:
> > I just had a quick look at the patch, i'm rather busy atm :/
> > 
> > Anyway, i still have concerns about the subcomponents placement stuff.
> > Rather than having WidgetAndZone approach imho we should enhance MediaController \
> > API in order to have methods like the followings: 
> > void insertSubComponent(MediaCenter::SubComponentType, QGraphicsWidget *);
> > 
> > /**
> > * This method is used to have access to a MediaController SubComponent.
> > * @see MediaCenter::SubComponentType to know which classes are associated
> > * with each SubComponentType.
> > */
> > QGraphicsWidget* subComponent(MediaCenter::SubComponentType) const;
> > 
> > void setSubComponentLocation(MediaCenter::SubComponentType, Plasma::Location);
> > Plasma::Location subComponentLocation() const;
> > 
> > This way we can insert subcomponents into it specifying their preferred position. \
> > Then, we might associate a Plasma widget to each SubComponentType in order to \
> > allow type casting when returning the component through the subComponent() \
> > method. I don't know if we should somehow force the specific class to the \
> > specific SubComponentType. Anyway i think subcomponents should be all specified \
> > inside the mediacenter.h header file or at least mediacenterstate.h but not \
> > specifically for each state. 
> > I'll keep reviewing the rest of the patch.

I agree that the current approach using the 4 zones is quite limited and might not \
give us enough control over how PMC looks later on. To implement Alessandro's idea I \
                would have to do two things:
- First:
At the moment the state configures the subComponents and adds them to a list. The \
containment asks for that list on each state change and then tells the controller to \
take that list and layout the subComponents. The list contains QPairs made of a \
widget and a zone. Alessandro's approach would mean to not have the containment ask \
for a list and give that to the controller but instead the state itself would send \
the widget along with a type to the controller immediately after configuring it. This \
approach would be easy to implement, but I am not sure if there are advantages to \
sending something multiple times or collecting it in a list and sending it once. We \
could also just replace the "zone" information in the QPair with the actual widget \
                type.
- Second:
The applet currently has several layouts and adds widgets to these layouts according \
to the zone information. If instead of a zone I send a widget type, I would not have \
4 if/thens (for 4 zones) but as many if/thens as there are widget types defined. This \
would give us a much more fine grained control over the layout, but OTOH would mean \
lots of if/thens. One advantage of having the widget type available would be to \
actually replace a widget with another widget of the same type if later a developer \
decicdes to for example write a new volume slider. Is the latter actually true? Is it \
even needed?

The other comment is about having the widget types defined in one spot. Instead of \
having an enum in each state, have one big enum somewhere else. Currently this is \
very easy, because there is no overlapping of names, and the state objects have \
access to mediacenter.h or/and mediacenterstate.h anyway. The widgets themselves \
would still be created in the state objects themselves.

What do you think?

- Christophe

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3552/#review5105
-----------------------------------------------------------

On 2010-04-19 19:43:39, Christophe Olinger wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3552/
> -----------------------------------------------------------
> 
> (Updated 2010-04-19 19:43:39)
> 
> 
> Review request for Plasma and Alessandro Diaferia.
> 
> 
> Summary
> -------
> 
> The state calsses now have less functions. Only one for connections and one for \
> configuration. The first one is only called once at PMC initialization, the second \
> one is called at each state switch. Some connections can conflict between states. \
> Those are connected at entry() and disconnected at exit(). Thanks to Alessandr's \
> work we can now also configure the layout from within the state class (I only had \
> to correct some namespace stuff in the medialayout class, I hope that was correct). \
> This patch also gets basic functionality back. The modes are not really useful yet. \
> Video mode is the most complete and can be used to view everything at th moment. \
> Next step: Clean this up a bit Think about subclassing plasma widgets to get the \
> widget type into the widget. This is necessary to be able to tell the controller to \
> layout into zones. Start work on information bar.
> 
> 
> Diffs
> -----
> 
> trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/applets/mediaplayer/config.ui \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/applets/mediaplayer/mediaplayer.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/applets/mediaplayer/mediaplayer.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenter.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/medialayout.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/medialayout.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/playbackcontrol.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/playbackcontrol.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/player.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/player.cpp \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.h \
> 1113370  trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.cpp \
> 1113370  
> Diff: http://reviewboard.kde.org/r/3552/diff
> 
> 
> Testing
> -------
> 
> Lots and lots. Seems to be quite slow, but I think that is a problem in the player. \
> It always iterates over all the queue even if it should only show a picture. 
> 
> Thanks,
> 
> Christophe
> 
> 

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread] 