Talk:OBX proposals: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Other obx ideas)
(agree on comments, need 'lighter' obxes for status)
Line 39: Line 39:
Hmm, and actually, we still haven't used the "|more=}" ''dont close the box!'' concept.
Hmm, and actually, we still haven't used the "|more=}" ''dont close the box!'' concept.


<table style="font-size:80%">
So those two might be combined as
<tr valign="top">
<td> So those two might be combined as
<pre>
{olpcboxtop for activity|name=Kuku}
{olpcboxtop for activity|name=Kuku}
{obx activity overview
{obx activity overview
Line 51: Line 54:
{obx box bottom}
{obx box bottom}
{olpcboxbottom}
{olpcboxbottom}
</pre>

</td>
Or perhaps even better, as
<td> Or perhaps even better, as
<pre>
{olpcbox for activity
{olpcbox for activity
|name = Kuku
|name = Kuku
Line 61: Line 66:
{obx box bottom}
{obx box bottom}
{olpcboxbottom}
{olpcboxbottom}
</pre>
and also
</td>
</tr>
<tr valign="top">
<td> and also
<pre>
{olpcbox for activity
{olpcbox for activity
|name = Kuku
|name = Kuku
Line 69: Line 79:
... more boxes here...
... more boxes here...
{olpcboxbottom}
{olpcboxbottom}
</pre>
and often
</td>
<td> and often
<pre>
{olpcbox for activity
{olpcbox for activity
|name = Kuku
|name = Kuku
Line 75: Line 88:
...
...
} &lt;!-- all done, no more boxes, no quoting problems to work around --&gt;
} &lt;!-- all done, no more boxes, no quoting problems to work around --&gt;
</pre>
</td>
</tr>
</table>

But... While implementation should be easy, I'm not sure it's worth the user complexity cost. Ie, adding a box may require adding a "there are more boxes" argument.
But... While implementation should be easy, I'm not sure it's worth the user complexity cost. Ie, adding a box may require adding a "there are more boxes" argument.


Sigh. So much pain because mediawiki was poorly designed. [[User:MitchellNCharity|MitchellNCharity]] 02:11, 9 August 2007 (EDT)
Sigh. So much pain because mediawiki was poorly designed. [[User:MitchellNCharity|MitchellNCharity]] 02:11, 9 August 2007 (EDT)

: I '''totally agree''' on many things you note here! And even liked the idea of summoning the OBXes by means of a normal-template-invoking-obxes-templates... until I remembered how ''fragile'' that code ended up being (See the source code in this Sandbox experiment: http://wiki.laptop.org/index.php?title=Template:Sandbox&oldid=48378)&mdash;btw, said fragility and mess was what triggered the OBX concept originally ;)
: Still, I do agree that many of the OBXes intended for the OBX-Status-Box are excessively wordy, and probably a minimalistic OBX should be worked out, probably (as you say) just text [<tt>'''l10n''': link</tt>] and that would take much less vertical space, and be more table-like. [[User:Xavi|Xavi]] 10:11, 9 August 2007 (EDT)


== Other obx ideas ==
== Other obx ideas ==
Line 84: Line 105:
*I run emulation on {qemu} on {fedora}.
*I run emulation on {qemu} on {fedora}.
*I have an XO {(B4)}.
*I have an XO {(B4)}.

: I like them! [[User:Xavi|Xavi]] 10:11, 9 August 2007 (EDT)

Revision as of 14:11, 9 August 2007

Coooooooooooooooooooooool

Use a large icon-free obx to replace Status_box?

Looking at the two activity boxes in Kuku, it seems the Status_box version is unavoidably more attractive than the obx version, simply because it has less "excess ink" not conveying information. But having box-based extensibility would be nice. And we still need a work-around for the argument passing problems. So maybe Status_box could be made into a large icon-free obx? Eg,

{olpcboxtop for activity|name=Kuku}
{obx activity overview
|activity = Kuku
|icon     = Kuku.png
|status   = In Development/XO Testing
|version  = 0.1
|base     = 0.1
|source   = ...
|l10n     = ...
|contributors = ...
}
... other obxes could go here ...
{olpcboxbottom}

Just two ideas here:

  • obx_activity_overview (or whatever one calls it) is a modified Status_box which generates an obx-like div (but one without the icon concept).
  • olpcboxtop_for_activity calls olpcboxtop, setting the box color and header, as the test version does explicitly.

So the above code would look exactly like the current Status_box version (well, slightly wider), but when something runs afoul of mediawiki's argument passing, one could simply drop that line from obx_activity_overview, and add a separate obx for it then. Incremental just-in-time ugliness.

Another alternative might be

{olpcboxtop for activity|name=Kuku}
{obx box top}
{obx activity icon|Kuku.png}
{obx activity status|In Development/XO Testing}
{obx activity version|0.1}
{obx activity base|0.1}
{obx activity source|name=Kuku|...}
{obx activity l10n|...}
{obx activity contributors|...}
{obx box bottom}
{olpcboxbottom}

where the obx_activity_foo are basically just <tr><td><b>{1}</b></td><td>{2}</td></tr>. This makes things a little uglier and less flexible up front, in order to buy more graceful degredation (ie, one is never forced to bail out to a true obx).

Hmm, and actually, we still haven't used the "|more=}" dont close the box! concept.

So those two might be combined as
 {olpcboxtop for activity|name=Kuku}
 {obx activity overview
 |activity = Kuku
 |icon     = Kuku.png
 |status   = In Development/XO Testing
 |version  = 0.1
 |base     = 0.1
 |there is more=}
 {obx activity contributors|...}
 {obx box bottom}
 {olpcboxbottom}
Or perhaps even better, as
 {olpcbox for activity
 |name     = Kuku
 |icon     = Kuku.png
 ...
 |there are more entries=}
 {obx activity contributors|...}
 {obx box bottom}
 {olpcboxbottom}
and also
 {olpcbox for activity
 |name     = Kuku
 |icon     = Kuku.png
 ...
 |there are more boxes=}
 ... more boxes here...
 {olpcboxbottom}
and often
 {olpcbox for activity
 |name     = Kuku
 |icon     = Kuku.png
 ...
 } <!-- all done, no more boxes, no quoting problems to work around -->

But... While implementation should be easy, I'm not sure it's worth the user complexity cost. Ie, adding a box may require adding a "there are more boxes" argument.

Sigh. So much pain because mediawiki was poorly designed. MitchellNCharity 02:11, 9 August 2007 (EDT)

I totally agree on many things you note here! And even liked the idea of summoning the OBXes by means of a normal-template-invoking-obxes-templates... until I remembered how fragile that code ended up being (See the source code in this Sandbox experiment: http://wiki.laptop.org/index.php?title=Template:Sandbox&oldid=48378)—btw, said fragility and mess was what triggered the OBX concept originally ;)
Still, I do agree that many of the OBXes intended for the OBX-Status-Box are excessively wordy, and probably a minimalistic OBX should be worked out, probably (as you say) just text [l10n: link] and that would take much less vertical space, and be more table-like. Xavi 10:11, 9 August 2007 (EDT)

Other obx ideas

  • I run sugar-jhbuild on {Ubuntu}.
  • I run emulation on {qemu} on {fedora}.
  • I have an XO {(B4)}.
I like them! Xavi 10:11, 9 August 2007 (EDT)