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