[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:       "Aaron Seigo" <aseigo () kde ! org>
Date:       2010-04-20 14:55:44
Message-ID: 20100420145544.29884.88362 () 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.
> 
> Christophe Olinger wrote:
> 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?

there are two different issues here: passing around lists of QPairs and using \
MediaCenter::AppletZone.

passing QPairs around isn't very pretty and it isn't necessary. one could use a \
QHash<QGraphicsWidget, MediaCenter::AppletZone> instead, but even then i'd probably \
just go with the simplified style of API that Allesandro suggests: \
addSubComponent(QGraphicsWidget *widget, MediaCenter::Appletzone zone); on state \
change, a series of addSubComponent calls would occur from the new state and the old \
state's components would be removed. there really is no need for lists in the API.

however, using MediaCenter::AppletZone (though personally i'll call it \
MediaCenter::LayoutZone) is definitely "the right way" to go.


- Aaron


-----------------------------------------------------------
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] 

Configure | About | News | Add a list | Sponsored by KoreLogic