> 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
