>Being able to run your data through a script is not a selling point
>for people who have no idea what a script is, so maybe one click
>install isn't critical.
I respectfully disagree. One-click install IS critical for more
widespread use of Leo.
I don't understand why a user's knowledge (or lack thereof) of the
concept of scripts would have any bearing on whether there should be a
one-click installer.
> 1. The goal is to increase the number of Leo's users.
PLEASE, before too much time and energy is put into Leo 5.0, PLEASE
define what kind of new users you want? Who exactly is the target
audience? What do you want/expect their technical skills to be? What
problems can Leo help with that these users would appreciate?
If you could make one of the goals for Leo 5.0 to be that it has less
emphasis on its Python underpinnings and less emphasis on users needing
to know something about Python to use it effectively, I think new users
will get excited.
-------- Original Message --------
Subject: Re: Visions of Leo 5.0
From: Terry Brown <terry_n_br...@yahoo.com>
To: leo-editor@googlegroups.com
Date: Saturday, June 18, 2011 7:37:03 AM
On Sat, 18 Jun 2011 06:20:12 -0700 (PDT)
"Edward K. Ream"<edream...@gmail.com> wrote:
1. The goal is to increase the number of Leo's users.
This is really the *only* goal. Leo is already good enough for what I
do, so Leo 5.0 must focus on what others might want.
Not sure how this relates to points 2-5 :-) I think one click install
would do more to increase the number of Leo users than anything else.
OTOH, much of the coolness of Leo is only relevant to at least somewhat
technical users. Being able to run your data through a script is not a
selling point for people who have no idea what a script is, so maybe
one click install isn't critical. It would certainly increase the
number of people who try Leo, anyway.
5. Patterns (and other techniques) can define views.
I think there's potential here but not sure if there's a single simple
way of making views - not that you're suggesting there should be, but
just pointing out that ways of generating them may be as varied as
their uses. Which are not, of course, restricted to ways of looking at
source code ;-)
UNLs UNLs UNLs
don't get anywhere near as much credit as they deserve. What does it
stand for (have to branch contrib branch to find out... :-):
Uniform Node Locators. Personally I think they can replace clones and
eliminate all the complexity clones introduce, but I don't expect that
to happen :-)
I use leo/external/leosax.py to zip through a list of 20-30 .leo files
and generate a view of all the todo nodes found therein. The script
builds the view so that there's a node for each file searched, and
below that a kind of sparse tree of all the todo nodes found in the
file, which maintains the hierarchy among todo nodes, but ignores all
others. E.g. if one file contained:
A
B
C
C1
D
D1
D2
D3
D4
where A, C1, D, D1, and D4 where todo nodes, the resulting view would
be
node-for-file
A
C1
D
D1
D4
with the priority of D adjusted to the max. of its own priority and the
priorities of its descendants.
Also, each node in the view is an @url node using an UNL to jump the
user back to the original node in whichever outline.
So:
- don't forget UNLs
- leosax can parse dozens of .leo files in seconds, the time is in
building the view tree, not parsing the files. It does not expand
@file nodes (which I don't use)
- there are lots of kinds of possible views, of source, of summaries
of .leo files as above, of database records, etc.
- don't forget UNLs
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
