<br><br><div class="gmail_quote">2010/4/8 Marco Martin <span dir="ltr">&lt;<a href="mailto:notmart@gmail.com">notmart@gmail.com</a>&gt;</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>
&gt; 2010/4/8 Aaron J. Seigo &lt;<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>&gt;<br>
&gt;<br>
&gt; &gt; On April 8, 2010, Christophe Olinger wrote:<br>
&gt; &gt; &gt; One thing missing is the layout of the actual subComponents in the<br>
&gt; &gt;<br>
&gt; &gt; applets.<br>
&gt; &gt;<br>
&gt; &gt; &gt; Currently they are just added in a row. For this we need the API. The<br>
&gt; &gt; &gt; layout should recognize which type of applet arrives and lay it out<br>
&gt; &gt; &gt; accordingly. That means lots of if/thens within tha applet code. This<br>
&gt; &gt;<br>
&gt; &gt; also<br>
&gt; &gt;<br>
&gt; &gt; &gt; means adding new states with new subcomponents would mean adding<br>
&gt; &gt; &gt; if/tehns to the actual addToLayout functions in the applets.<br>
&gt; &gt;<br>
&gt; &gt; what i&#39;d recommend is to provide a way to tag subcomponents with values<br>
&gt; &gt; (e.g.<br>
&gt; &gt; an enum) that says something about what they do.<br>
&gt; &gt;<br>
&gt; &gt; divide up each MainComponent into &quot;zones&quot; (navigation, media playing,<br>
&gt; &gt; status,<br>
&gt; &gt; whatever :) and then each sub component can be tagged by the creator of<br>
&gt; &gt; the sub component (e.g. a state) with what it is.<br>
&gt; &gt;<br>
&gt; &gt; then the main components will know which zone they belong in.<br>
&gt; &gt;<br>
&gt; &gt; from there, i&#39;d go with a naive implementation, at least at first, that<br>
&gt; &gt; just<br>
&gt; &gt; puts things into the respective zones on a first-come-first-placed basis.<br>
&gt;<br>
&gt; This makes me thinking about the MediaLayout object. Now it resides inside<br>
&gt; the containment implementation.<br>
&gt; Probably we should have something that specifies wher the subComponent is<br>
&gt; suggested to be placed; this<br>
&gt; can likely be:<br>
&gt; - Fullscreen<br>
&gt; - AppearingFromLeftEdge<br>
&gt; - AppearingFromTopEdge<br>
&gt; - AppearingFromBottomEdge<br>
&gt; - AppearingFromRightEdge<br>
&gt; - Invisible<br>
<br>
</div></div>no i don&#39;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&#39;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>