Talk:OBX proposals: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Use a large icon-free obx to replace Status_box?)
(.XOL Bundle OBX)
 
(4 intermediate revisions by 2 users not shown)
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)

::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: [[User:MitchellNCharity|MitchellNCharity]] 11:21, 10 August 2007 (EDT)

::: The 'example' tries to show the mess needed (at the code level) to generate a reasonably-decent-looking box where lines 'pop-in' when data (parameters) is fed to the template... it wasn't nice, and a CR out of place can create a mindboggling treasure hunt... iow, a new 'feature' we may want in the box (like l10n was in the original) is quite hard to get included.
::: There are basically two problems:
:::# the parameters themselves (ie: use of '=' or '|' is a no-no in parms unless escaped or otherwise dealt with);
:::#: ''this is particularly nasty as many URLs do have '=' signs in them''
:::# the dynamic-lines (ie: the source code of the template) are not easily added.
::: Your alternative of using raw html in the template seems to be a nice alternative. Humm... checking the history I note that I tried the [http://wiki.laptop.org/index.php?title=Template:Sandbox&oldid=46739 HTML alternative] without success... :( It was a light test, maybe a more 'stubborn' approach may yield better results.
::: Your top/bottom alternative (the way I read it) is back to OBXs... isn't it? Cheers, [[User:Xavi|Xavi]] 12:15, 10 August 2007 (EDT)

<table style="font-size:80%">
<tr valign="top">
<td> common case
<pre>
{olpcbox for activity
|name = Kuku
|icon = Kuku.png
...
} &lt;!-- all done, no more boxes, no quoting problems to work around --&gt;
</pre>
</td>
<td> extending with boxes
<pre>
{olpcbox for activity
|name = Kuku
...
|there are more boxes=}
... more boxes here...
{olpcboxbottom}
</pre>
</td>
</tr>
<tr valign="top">
<td> Workaround expansion bugs in a table
<pre>
{olpcbox for activity
|name = Kuku
|lookout = text which expands ok
...
|there are more entries=}
{obx activity tr lookout} text which doesn't expand ok &lt;/tr&gt;
{obx box bottom}
{olpcboxbottom}
</pre>
</td>
<td> Workaround expansion bugs in an arbitrary obx
<pre>
{obx foo|troublesome text}
becomes
... something :(
</pre>
(do we really need this case?)
</td>
</tr>
</table>
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! [[User:Xavi|Xavi]] 10:11, 9 August 2007 (EDT)

== .XOL Bundle OBX ==

There's an .xo bundle box category, but what about library bundles? - [[User:Ericvh|Ericvh]] 11:10, 15 January 2008 (EST)

Latest revision as of 16:10, 15 January 2008

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)
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)
The 'example' tries to show the mess needed (at the code level) to generate a reasonably-decent-looking box where lines 'pop-in' when data (parameters) is fed to the template... it wasn't nice, and a CR out of place can create a mindboggling treasure hunt... iow, a new 'feature' we may want in the box (like l10n was in the original) is quite hard to get included.
There are basically two problems:
  1. the parameters themselves (ie: use of '=' or '|' is a no-no in parms unless escaped or otherwise dealt with);
    this is particularly nasty as many URLs do have '=' signs in them
  2. the dynamic-lines (ie: the source code of the template) are not easily added.
Your alternative of using raw html in the template seems to be a nice alternative. Humm... checking the history I note that I tried the HTML alternative without success... :( It was a light test, maybe a more 'stubborn' approach may yield better results.
Your top/bottom alternative (the way I read it) is back to OBXs... isn't it? Cheers, Xavi 12:15, 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)

.XOL Bundle OBX

There's an .xo bundle box category, but what about library bundles? - Ericvh 11:10, 15 January 2008 (EST)