Leo as a compound document

[Edward K. Ream]

Continuing the "Post vacation thoughts" thread, one way to have Leo
"reach out" to the world is to make Leo a compound document. See,
e.g., http://en.wikipedia.org/wiki/Compound_document The idea is to
be able to embed pictures, movies, spreadsheets and other documents
into a Leo outline.

Several plugins already support this to a limited extent. And jyLeo,
LeoUser's jython version of Leo, allows you to play movies in the
background of the body pane while editing text there(!)

Leo is an excellent framework for compound documents, for several
reasons:

1. Leo's headlines are the natural way to "declare" kinds of data.
For example, @movie <url>

2. Leo's .xml file format neither knows nor cares about the kinds of
data the outline can contain. Data can be physically stored in the
outline in uA's, or can be incorporated by reference using url's as in
point 1 above.

I mentioned OpenOffice in the "Post vacation thoughts" thread because
OpenOffice has a python interface. See http://udk.openoffice.org/python/python-bridge.html
Thus, it would be straightforward to interface to OpenOffice in the
same way that Leo can interface to networkx graphs. Leo doesn't have
to do what OpenOffice or networkx do, Leo can just provide a clean way
of moving data to and from Leo and the external program.

But in fact it would be possible to do some nifty things with Leo.
Let us consider making Leo a spreadsheet. This is actually a smallish
project!

A spreadsheet would be represented by @spreadsheet, @row, @column,
@cell and @formula nodes. Already this is a much more flexible
organization that traditional spreadsheets, though iirc there are some
non-tabular spreadsheets in existence. @row and @column nodes are
"organizer nodes". @cell nodes contain the actual data, but if an
@cell node has an @formula node the @cell node will contain the result
of the computation specified in the @formula node. All nodes would
have a name: @spreadsheet <spreadsheet-name> @row <row-name>, @column
<column-name>, @cell <cell-name>, etc.

We have several options for the contents of @formula nodes. It could
contain just python code, which would be flexible but a bit clumsy to
use. The contents would be evaluated as a python script, augmented by
accessor functions, say row, column, cell... row(row-name) would
return a list of all the items (columns or cells) in the named row.
Similarly for column(column-name). Yes, this would be a bit clumsy to
use. This is the simplest possible prototye.

The next step might be to define a spreadsheet language as usual. The
most complex (and maybe the least useful) step would be to embed an
actual tabular spreadsheet into Leo's body pane.

I've just sketched some ideas here. Feel free to modify if you are
interested. The take-away message is that adding new kinds of data to
Leo can be done in simple plugins.

Edward

P.S. The point of the spreadsheet prototype is that we can expand the
kinds of Python (or python-like) scripts that can appear in Leo.
Extending this idea further, we can imaging Leo outlines being
generated automatically. @auto and @shadow do not exhaust the
possibilities!

Leo is an enormously flexible scripting environment. @test nodes
contain scripts that *are* unit tests; @suite nodes contain scripts
that *create* unit tests. Again, @formula, @test and @suite nodes do
not exhaust the possibilities.

P.P.S. I am leery of frameworks for making compound documents. The
problem with ActiveX, OLE, KParts and OpenDoc is that they are
platform specific. The ideas sketched here use Leo as the platform.
To put it another way, the Leo plugins that would implement these
features would likely work on any platform.

EKR

EKR

[Ville M. Vainio]

I'm a bit late to this party - I've been terribly busy with work
lately, and haven't had time for much of "freetime" work.
Incidentally, this is something I could benefit from for my thesis
work that I can tinker with this summer (my holiday just started), but
I doubt it will be "ready" in time ;-).

On Mon, Jul 28, 2008 at 6:01 PM, Edward K. Ream <edre...@gmail.com> wrote:

> A spreadsheet would be represented by @spreadsheet, @row, @column,
> @cell and @formula nodes. Already this is a much more flexible

I don't think the @row and @column thing is really needed.

The "spreadsheet" approach is directly supported in ILeo using
"normalized" headline names. It doesn't make sense to specify column /
row ranges when you can do list(wb.NewHeadline) to got all the
children.

> The next step might be to define a spreadsheet language as usual. The
> most complex (and maybe the least useful) step would be to embed an
> actual tabular spreadsheet into Leo's body pane.

I think this would be the "best" solution that would really boost the
expressivity of leo. You don't need to embed an actual spreadsheet -
just use a grid control as the body pane of nodes that want to be
presented that way (and possibly use xml as the inner body content of
those nodes).

Obviously this should be done if/when leo gets ported to another gui toolkit.

--
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'

[Edward K. Ream]

On Wed, Aug 6, 2008 at 2:28 PM, Ville M. Vainio <viva...@gmail.com> wrote:

I'm a bit late to this party - I've been terribly busy with work
lately, and haven't had time for much of "freetime" work.
Incidentally, this is something I could benefit from for my thesis
work that I can tinker with this summer (my holiday just started), but
I doubt it will be "ready" in time ;-).

On Mon, Jul 28, 2008 at 6:01 PM, Edward K. Ream <edre...@gmail.com> wrote:

> A spreadsheet would be represented by @spreadsheet, @row, @column,
> @cell and @formula nodes.  Already this is a much more flexible

I don't think the @row and @column thing is really needed.

The "spreadsheet" approach is directly supported in ILeo using
"normalized" headline names. It doesn't make sense to specify column /
row ranges when you can do list(wb.NewHeadline) to got all the
children.

Ok.  The main point is that Leo can represent any metadata as needed.  We don't have to worry about exactly what that metadata is.

> The next step might be to define a spreadsheet language as usual.  The
> most complex (and maybe the least useful) step would be to embed an
> actual tabular spreadsheet into Leo's body pane.

I think this would be the "best" solution that would really boost the
expressivity of leo. You don't need to embed an actual spreadsheet -
just use a grid control as the body pane of nodes that want to be
presented that way (and possibly use xml as the inner body content of
those nodes).

Yes.  The Eclipse framework shows how cool using xml as content can be.  I would definitely like to do this for Leo.

There is always a tension between "use" and "mention" in content.  Sometimes we want to refer to content, say with a url, and sometimes we want to include the actual content directly in the .leo file.
 

Obviously this should be done if/when leo gets ported to another gui toolkit.

It will happen, unless I get hit with a truck.

Edward