Talk:OBX proposals

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)

I didn't quite understand the example linked to, but my impression is things break because templates are expanded from the inside out, and have no general quoting concept (just some case by case workarounds), so expanding an argument or sub-template can result in text which breaks an enclosing template. Yes? Is there another source of breakage? If not, things which expand to known html can be made robust. So having several levels of abstraction (mumble_activity->mumble->frotztop) should be ok, no? And my impression is most of the time things work, so what we are attempting is to create a pair of "something pretty which works most of the time", and "a not-too-ugly fallback, so when you hit the problem, you don't have to fallback to writing all the raw html yourself". Hmm, so then maybe the objective is just to have top/bottom pairs which let you easily get down to writing a raw tr line, perhaps both for a table line, and for an obx icon/text? So maybe: MitchellNCharity 11:21, 10 August 2007 (EDT)

common case {olpcbox for activity |name = Kuku |icon = Kuku.png ... } <!-- all done, no more boxes, no quoting problems to work around -->	extending with boxes {olpcbox for activity |name = Kuku ... |there are more boxes=} ... more boxes here... {olpcboxbottom}
Workaround expansion bugs in a table {olpcbox for activity |name = Kuku |lookout = text which expands ok ... |there are more entries=} {obx activity tr lookout} text which doesn't expand ok </tr> {obx box bottom} {olpcboxbottom}	Workaround expansion bugs in an arbitrary obx {obx foo|troublesome text} becomes ... something :( (do we really need this case?)

As an aside, since it seems mediawiki is capable of unicode, I'm surprised someone hasn't taken a quote pair and created a "things in quotes are treated as opaque objects by template expansion, and are removed once expansion is done (and inside text comparisons, etc)".

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)