The medialayout mistake was a very small one, I just removed the class MediaLayout from the mediacenterstate.h, and took the includes for the medialyout from mediacenterstate.cpp into mediacenterstate.h
Little C++ mistake from my side. Sorry On Thu, Apr 8, 2010 at 7:30 PM, Alessandro Diaferia <alediafe...@gmail.com>wrote: > > > 2010/4/8 Marco Martin <notm...@gmail.com> > >> On Thursday 08 April 2010, Alessandro Diaferia wrote: >> >> > 2010/4/8 Aaron J. Seigo <ase...@kde.org> >> > >> > > On April 8, 2010, Christophe Olinger wrote: >> > > > One thing missing is the layout of the actual subComponents in the >> > > >> > > applets. >> > > >> > > > Currently they are just added in a row. For this we need the API. >> The >> > > > layout should recognize which type of applet arrives and lay it out >> > > > accordingly. That means lots of if/thens within tha applet code. >> This >> > > >> > > also >> > > >> > > > means adding new states with new subcomponents would mean adding >> > > > if/tehns to the actual addToLayout functions in the applets. >> > > >> > > what i'd recommend is to provide a way to tag subcomponents with >> values >> > > (e.g. >> > > an enum) that says something about what they do. >> > > >> > > divide up each MainComponent into "zones" (navigation, media playing, >> > > status, >> > > whatever :) and then each sub component can be tagged by the creator >> of >> > > the sub component (e.g. a state) with what it is. >> > > >> > > then the main components will know which zone they belong in. >> > > >> > > from there, i'd go with a naive implementation, at least at first, >> that >> > > just >> > > puts things into the respective zones on a first-come-first-placed >> basis. >> > >> > This makes me thinking about the MediaLayout object. Now it resides >> inside >> > the containment implementation. >> > Probably we should have something that specifies wher the subComponent >> is >> > suggested to be placed; this >> > can likely be: >> > - Fullscreen >> > - AppearingFromLeftEdge >> > - AppearingFromTopEdge >> > - AppearingFromBottomEdge >> > - AppearingFromRightEdge >> > - Invisible >> >> no i don't think those names should depend to appearance, but rather be >> more >> semantic, like mediabrowsing, control, informations, playing >> > > Ok agreed, and then the layout will decide accordingly to the type rather > than the appearance. > > >> in the future i can see applets that register themselves as one of those >> so >> the central layout would know what to allow for each category, either for >> which forst come or for what the user configured, if he wants to use a >> different browser for instance (they could change for different >> formfactors >> perhaps), but that still has not so much point. >> > > Yeah. Currently the containment doesn't allow more than one applet of the > same type to be present at the same time. > But which particular applet is still not decided by the containment and > this is how it should be. > > >> >> Cheers, >> Marco Martin >> _______________________________________________ >> Plasma-devel mailing list >> Plasma-devel@kde.org >> https://mail.kde.org/mailman/listinfo/plasma-devel >> > > > > -- > Alessandro Diaferia > KDE Developer > KDE e.V. member > > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel