Re: Visions of Leo 5.0
Hi, El 29/06/11 10:46, Josef escribió: Thanks. As I was using Leo until 2 years ago, I never bothered to open the quickstart.leo. Perhaps it should be a bit higher in the Help menu? - note: I am still running 4.8, perhaps this has changed already. - Josef To me it was the same. Long leo user and follower of this list, never used quickstart.leo and when I discovered, I increase my understanding of Leo in minutes. A readmefirst.leo will be a more appealing name and also a upper position on the help menu will help. I remember that TeXmacs uses a default first document for newbies (that can also be located in the help menu after) that introduce the environment. Would be nice to have some version file on .leo directory and on opening leo checks against it seeing if this is a first opening or an upgrade and in that case open an updated quickstart/readmefirst leo file explaning new features and giving examples in a hands on tutorial do it your self fashion, like the ones that Ville gives in his excellent quickstart.leo, so this file not only integrate the information on: http://webpages.charter.net/edreamleo/what-is-new.html but also put practical examples about the new features. Cheers, Offray ps: more to come in a detailed mail in the same thread and I'm preparing a living inside leo post in a short while. -- 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.
Re: Visions of Leo 5.0
Leo is a very useful program and environment. Thanks Edward. Functionally it feels fairly complete. So I agree with Ville: Continuing the improvement of its polish, appearance, documentation and setting interfaces get my votes for the focus of a 5.0 release. Rod On Jun 20, 12:11 am, Ville M. Vainio vivai...@gmail.com wrote: Sorry for not analyzing the whole thread. Still busy time in my life ;-) More than anything else, Leo would benefit from polish, polish, polish: - Get the completion story in shape (perhaps something I can code in july/august) - Simplifications / clarifications. Rename @nosent to @write, wider @url support (for local files)... - Improve quickstart.leo - UI polish where needed (not much, perhaps more mainstream colors, better icon bar etc) large data model changes are probably not needed. @auto-rst, @nosent, @file, @edit, @path, @url get you a long way, On Mon, Jun 20, 2011 at 1:22 AM, Terry Brown terry_n_br...@yahoo.com wrote: On Sun, 19 Jun 2011 12:53:49 -0700 taa, Leo Newbie starman...@gmail.com wrote: 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. I was probably over-generalizing. A one-click install would be good for its own sake. Even for hardcore Leo users / coders it would sure be nice to be able to get it running on other machines that easily. And a one-click install would definitely increase the number of people who try Leo, which is obviously essential if we're going to increase user base, so yes, one-click install IS critical for more widespread use of Leo. My comment came from thinking that almost all the uses I make of Leo depend on at least simple scripts to glue stuff together. In a way that's not really true, seeing a lot of the time I'm just using it to write code, which doesn't require any scripting. If all you do is use Leo for writing code, I guess I don't really know how it stacks up against other environments, since the only other one I've used is Emacs, which I gave up for Leo. For me, the ability to script Leo, the python access to nodes, and the possibilities for non-coding uses etc. would make me choose Leo over other systems even if they were stronger on the coding aspect. But that's just me. I agree with aeromorrison that a period of user experience refinement would be good for Leo, it's just a question of people wanting to work on that. I'd like to work on the free layout stuff, the icon bar could probably be spiffed up, an installer would be nice, and a simple interface to the @auto / @nosent / @shadow / @file / @edit / @auto-rst would probably help a lot of people. Plugin management could also be refined. The documentation has improved, although to be fair I think it was always better than the average open source projects. But it could be improved more, particularly with respect to plugins and how users access the documentation (What's this? kind of tools). Perhaps we could have a little animated character which pops up and asks you what you're trying to do :-) Kidding. Maybe some bug-report / wish list items would be a place to start on some of this? 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 athttp://groups.google.com/group/leo-editor?hl=en. -- 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.
Re: Visions of Leo 5.0
On Wed, Jun 29, 2011 at 4:41 PM, Josef joe...@gmx.net wrote: It also wasn't entirely clear to me how to set up a myLeoSettings.leo file. I think Leo should offer to create a template file, if none exists yet, or this should be documented for the new and inexperienced user. Check out help - open quickstart.leo. This should in general be consulted as the first thing you do with Leo, before reading the documentation even. -- 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.
Re: Visions of Leo 5.0
Thanks. As I was using Leo until 2 years ago, I never bothered to open the quickstart.leo. Perhaps it should be a bit higher in the Help menu? - note: I am still running 4.8, perhaps this has changed already. - Josef On Jun 29, 3:53 pm, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jun 29, 2011 at 4:41 PM, Josef joe...@gmx.net wrote: It also wasn't entirely clear to me how to set up a myLeoSettings.leo file. I think Leo should offer to create a template file, if none exists yet, or this should be documented for the new and inexperienced user. Check out help - open quickstart.leo. This should in general be consulted as the first thing you do with Leo, before reading the documentation even. -- 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.
Re: Visions of Leo 5.0
Dear Edward, if you want to increase the user base, there are 2 user groups I could think of: the ones using all these different editors will be often also people using LaTeX, and so far I find TeX support is a bit weak. I wish TeX support would be similar to ReST support, although there is an added complexity when implementing @auto for TeX, because LaTeX users tend to split up the source code into muliple files using \input, and that would somehow need to be mapped sensibly to the representation in Leo (probably using inputfile or so). If I ever find the time I will work on this, but I am too busy to promise anything. The second group are those who are using lots of non-text files, e.g. MS Office or similar, CAD tools, etc. These would benefit of a good integration of binary files. For example, when dragging a binary file to Leo, it should not attempt to create an @edit or @auto node, but an @mime node (needs the mime plugin). Alteratively an @url node would work. Note: I think this should result in a RELATIVE link. In my opinion, Leo should provide a way to specify what is a binary file and what is not, as this would be more portable, and also because I can immediately think of files which I want my system to treat differently as Leo does: TaskJuggler project files for example. I want Leo to open these as text (@edit or @file), but the OS should open these with the TaskJuggler program. The same should also work for the active_path plugin, which currently allows to specify only one type of default file directive, but it would be better to be able to specify the file directive per file type. Btw: I have just used Leo as a project management tool, handling a couple of hundred LaTeX, TaskJuggler, Excel, JPEG, PDF files and (ad hoc) Python scripts to generate with a team of 5-6 people a 600 page proposal. I could not have done it without Leo. - Josef -- 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.
Re: Visions of Leo 5.0
There are many very good comments here! I have some things of my own laundry list to add. In a quick re-read before posting the list rings more of complaint than helpful feedback. Please understand that's not the tone I mean to impart. I really like Leo, but I do have a hard time getting completely comfortable with it. ;-) 1. The goal is to increase the number of Leo's users. As others have said, one click install would be very very nice. I'd like to extend that thinking to include one click use. I'm not being literal, I talking about the feeling of a one click install carried over to smoothly and easily using Leo. For example: Why do I have to edit a file, or multiple files, and read a whole bunch of stuff which only vaguely makes sense because a lot of it is new, to explore plugins? It would be so much easier if there were a menu/page/something which presented the list of available plugins with enable/disable checkboxes, a short description of what they do and clickable link for more information. http://lifehacker.com/5789781/step-up-your-notepad%252B%252B-game-with-powerful-plugins how many steps (clicks, types, etc.) does it take to build a myLeoSettings.leo on a new machine? What if personal preferences were automatically built from an dialog like the plugins manager floated above? (e.g. if user enables a plugin, the setting for that is copied from LeoSettings.leo to myLeoSettings.leo and saved. or something). Make edit node in external editor work out of the box seamlessly so people who are just testing the water don't feel like they're being asked to give up what they're familiar with. The search and replace experience is broken. My #1 use of external editor is in order to do simple s+r like a global rename fooBar to foobar in one step. Rich text (html) renderding enabled by default so that when looking at things like About plugin the [html] [text] buttons actually do something and the first thing one sees is not pre and gt; lt; etc. People like toolbars. Make it easy to add frequently used commands to a toolbar, maybe by dragging and dropping from the menus? (or nodes?) Helper text, defaults. For a while I thought the [Nav] pane was broken because the initial view is a completely blank area and I didn't realize it was search function. A simple phrase would help type and press enter to locate occurences of The confusion was minor and short lived, but it needn't have occurred at all. This is a good example of how a one-click install feeling could be carried over. Make the leo website a first class citizen: - acquire www.leo-editor.org (or variant) - fix the broken search - apply server side redirects so old links can find the new home page (for example the Flattr link is broken), or use a custom 404 that suggests alternatives (http://sixrevisions.com/design-showcase-inspiration/beautiful-and-useful-404-error-pages-for-inspiration/; I like #14 because it includes a search box) - fix the wiki or find a new one where user contributed recipes and documentation can be worked on (make sure it's hosted on leo-editor.org) Video's, screencasts, recipes, demos! Leo is unlike anything else. Reading the docs, asking questions on the forum, and the like is a great way to learn things but there is so much of what makes Leo useful that just can't be conveyed easily in words. Setup a ShowMeDo channel (http://showmedo.com/). Stories. It's things like this that first caught my attention http://webpages.charter.net/edreamleo/testimonials.html (the long ones). There were one or two by Edward that were inspirational but I can't find right now; perhaps they're buried in the mailing list. A faster fancier glitzier way of doing X is interesting but only for a moment or three. Far more intriguing is seeing how Leo enables things which just weren't possible before, or changes how one works or looks at data forever (regardless of whether Leo is actually used in X). cheers, -matt -- 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.
Re: Visions of Leo 5.0
Does the edit in external editor not work seamlessly from rclick menu? On Wed Jun 29 21:09:43 2011 Matt Wilkie wrote: There are many very good comments here! I have some things of my own laundry list to add. In a quick re-read before posting the list rings more of complaint than helpful feedback. Please understand that's not the tone I mean to impart. I really like Leo, but I do have a hard time getting completely comfortable with it. ;-) 1. The goal is to increase the number of Leo's users. As others have said, one click install would be very very nice. I'd like to extend that thinking to include one click use. I'm not being literal, I talking about the feeling of a one click install carried over to smoothly and easily using Leo. For example: Why do I have to edit a file, or multiple files, and read a whole bunch of stuff which only vaguely makes sense because a lot of it is new, to explore plugins? It would be so much easier if there were a menu/page/something which presented the list of available plugins with enable/disable checkboxes, a short description of what they do and clickable link for more information. http://lifehacker.com/5789781/step-up-your-notepad%252B%252B-game-with-powerful-plugins how many steps (clicks, types, etc.) does it take to build a myLeoSettings.leo on a new machine? What if personal preferences were automatically built from an dialog like the plugins manager floated above? (e.g. if user enables a plugin, the setting for that is copied from LeoSettings.leo to myLeoSettings.leo and saved. or something). Make edit node in external editor work out of the box seamlessly so people who are just testing the water don't feel like they're being asked to give up what they're familiar with. The search and replace experience is broken. My #1 use of external editor is in order to do simple s+r like a global rename fooBar to foobar in one step. Rich text (html) renderding enabled by default so that when looking at things like About plugin the [html] [text] buttons actually do something and the first thing one sees is not pre and gt; lt; etc. People like toolbars. Make it easy to add frequently used commands to a toolbar, maybe by dragging and dropping from the menus? (or nodes?) Helper text, defaults. For a while I thought the [Nav] pane was broken because the initial view is a completely blank area and I didn't realize it was search function. A simple phrase would help type and press enter to locate occurences of The confusion was minor and short lived, but it needn't have occurred at all. This is a good example of how a one-click install feeling could be carried over. Make the leo website a first class citizen: - acquire www.leo-editor.org (or variant) - fix the broken search - apply server side redirects so old links can find the new home page (for example the Flattr link is broken), or use a custom 404 that suggests alternatives (http://sixrevisions.com/design-showcase-inspiration/beautiful-and-useful-404-error-pages-for-inspiration/; I like #14 because it includes a search box) - fix the wiki or find a new one where user contributed recipes and documentation can be worked on (make sure it's hosted on leo-editor.org) Video's, screencasts, recipes, demos! Leo is unlike anything else. Reading the docs, asking questions on the forum, and the like is a great way to learn things but there is so much of what makes Leo useful that just can't be conveyed easily in words. Setup a ShowMeDo channel (http://showmedo.com/). Stories. It's things like this that first caught my attention http://webpages.charter.net/edreamleo/testimonials.html (the long ones). There were one or two by Edward that were inspirational but I can't find right now; perhaps they're buried in the mailing list. A faster fancier glitzier way of doing X is interesting but only for a moment or three. Far more intriguing is seeing how Leo enables things which just weren't possible before, or changes how one works or looks at data forever (regardless of whether Leo is actually used in X). cheers, -matt -- 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. -- 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.
Re: Visions of Leo 5.0
Does the edit in external editor not work seamlessly from rclick menu?
It does now, but I had to set it up in myLeosettings.leo.
...{does some tests}
...and it still works after removing my custom editor string. I guess
I'm remembering pain from before, which is now fixed. Happily we can
cross that one out!
-matt
--
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.
Re: Visions of Leo 5.0
On Mon, Jun 20, 2011 at 7:25 AM, Edward K. Ream edream...@gmail.com wrote: On Sun, Jun 19, 2011 at 2:46 PM, aeromorrison adam.morri...@sportplanedesign.com wrote: We use leo quite a lot here at our company. I would say we are moderately technical users, but still have a lot to learn about leo! This is the key problem, however. We do a fair amount of Python coding in our business, but don't have time to constantly dig through the source code of every tool we use. It seems quite difficult to get up to speed on all of the capabilities of leo. Hmm. My intention is that it should *not* be necessary to understand all the intricacies of Leo in order to be able to use it. There are many features of Leo that I use seldom, if ever. I read, and sympathized with, the comment as seeking answers to questions like: - how do I get a list of children of this node? - how do I generate this subtree of data? - how do I get the filename that this @auto tree represents? - how do I place focus on the node with this headline? - ... As a long time Leo user and scripter, I still burn up time answering these. I should study the organization of existing doc, maybe it's optimal, but I think a well organized recipe book would be grand. This reminds me about the most important Aha I ever had about Emacs, namely that one does not have to pay attention to all of Emacs's alt-x commands in order to use Emacs effectively. The situation is similar, I think, because I modeled Leo's minibuffer of the Emacs minibuffer (and all the Emacs alt-x commands). True, there has been a lot of development on Leo over the past several years, but my own work flow has remained almost completely unchanged. For me, the biggest improvement has been the qttabs gui. At first I was unimpressed; now, I don't know how I ever lived without it. Even by frequent, careful reading of the online help and a couple of years of everyday work with leo, we come away feeling like there is so much more there that we can't readily access. We monitor these forums and occasionally post questions and comments, but it feels like to really have an awareness of leo's feature set, you have to spend significant time reading the code and understanding it and continuously keep track of this forum. To repeat, you should absolutely feel free to ignore the vast majority of Leo's features, as long as you have a work flow that suites you. Much of capability discussions on this forum address really interesting items which don't seem to be addressed in documentation anywhere. This leaves the moderately technical to pure users wanting. What you are really seeing, I think, is that this forum mostly gets developer-level discussions. There is a separate help forum, but it has low traffic. It would be fantastic if all the great things about leo could be documented thoroughly so that potential new users could readily access these capabilities. It seems that the code and features within leo develop pretty rapidly, but much of it gets left undocumented. It's documented in the what's new section: http://webpages.charter.net/edreamleo/what-is-new.html But your point is well taken. There may well be important features that aren't very well documented. Feel free to file bug reports about such sections, or just ask about them here: I typically use my responses here as pre-writing for more documentation. The only 'documentation' seems to be snippets of discussion threads on this forum. Much of the documentation is probably adequate for professional computer scientists, but leaves a significant gap for people like me (an engineer who uses code to get other work done). Thus, it seems that each time I want to explore a new feature of leo, I spend a bunch of time in trial and error trying to figure out how it works. This could be an opportunity for us both. When this happens again, please do ask question here, and remind me of this conversation. That way you can get your answers more quickly, and I will be encouraged to add the missing documentation. I thinks this is the only real way to improve the documentation. It can't be done in general; it can only be done step by specific step. Edward -- 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. -- 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.
Re: Visions of Leo 5.0
On Mon, Jun 20, 2011 at 7:12 AM, Edward K. Ream edream...@gmail.com wrote: On Sun, Jun 19, 2011 at 2:53 PM, taa, Leo Newbie starman...@gmail.com wrote: 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? For me, the target audience are the users of Emacs, Vim, Eclipse, Visual Studio and the rest of the heavy-duty editors/IDE's that programmers typically use. Others, like Kent, I suspect, see a somewhat different audience, with more web-oriented interests. My proclivity is not necessarily web oriented, but different in that I see Leo as very advanced data manager, more than an editor. 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. Interesting point of view :-) Leo's users can already completely ignore Leo's Python underpinnings if they choose. We developers, however, live in the world of Python code, Python plugins and Python scripts, so it's natural that Python comes up a lot in our discussions. But users really need to know almost nothing about Python to use Leo. Edward -- 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. -- 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.
Re: Visions of Leo 5.0
On Jun 18, 8:20 am, Edward K. Ream edream...@gmail.com wrote: 8. Super-slim .leo files At present, .leo files contain v elements for all nodes that are *not* descendants of @file nodes. In the new world, no (computed) descendants of @view nodes would be written to .leo files. Already, this would slim down .leo files considerably. Upon further review, this seems like a very bad idea. It is inflexible (it would give users less choice, not more), and it would drastically alter existing .leo files. There is no way we can allow this. It's all pain and no gain. Edward -- 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.
Re: Visions of Leo 5.0
On Jun 21, 6:54 am, Edward K. Ream edream...@gmail.com wrote: 5.0 is completely speculative. It may turn out that @view nodes aren't worth doing. But if they do turn out to be interesting, 5.0 a1 might be released sometime in July. To clarify, the release will simply be a merge of a to-be-created 5.0 branch into the trunk. The next scheduled official/packaged release will be in January or February of next year. Edward -- 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.
Re: Visions of Leo 5.0
Sorry for not analyzing the whole thread. Still busy time in my life ;-) More than anything else, Leo would benefit from polish, polish, polish: - Get the completion story in shape (perhaps something I can code in july/august) - Simplifications / clarifications. Rename @nosent to @write, wider @url support (for local files)... - Improve quickstart.leo - UI polish where needed (not much, perhaps more mainstream colors, better icon bar etc) large data model changes are probably not needed. @auto-rst, @nosent, @file, @edit, @path, @url get you a long way, On Mon, Jun 20, 2011 at 1:22 AM, Terry Brown terry_n_br...@yahoo.com wrote: On Sun, 19 Jun 2011 12:53:49 -0700 taa, Leo Newbie starman...@gmail.com wrote: 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. I was probably over-generalizing. A one-click install would be good for its own sake. Even for hardcore Leo users / coders it would sure be nice to be able to get it running on other machines that easily. And a one-click install would definitely increase the number of people who try Leo, which is obviously essential if we're going to increase user base, so yes, one-click install IS critical for more widespread use of Leo. My comment came from thinking that almost all the uses I make of Leo depend on at least simple scripts to glue stuff together. In a way that's not really true, seeing a lot of the time I'm just using it to write code, which doesn't require any scripting. If all you do is use Leo for writing code, I guess I don't really know how it stacks up against other environments, since the only other one I've used is Emacs, which I gave up for Leo. For me, the ability to script Leo, the python access to nodes, and the possibilities for non-coding uses etc. would make me choose Leo over other systems even if they were stronger on the coding aspect. But that's just me. I agree with aeromorrison that a period of user experience refinement would be good for Leo, it's just a question of people wanting to work on that. I'd like to work on the free layout stuff, the icon bar could probably be spiffed up, an installer would be nice, and a simple interface to the @auto / @nosent / @shadow / @file / @edit / @auto-rst would probably help a lot of people. Plugin management could also be refined. The documentation has improved, although to be fair I think it was always better than the average open source projects. But it could be improved more, particularly with respect to plugins and how users access the documentation (What's this? kind of tools). Perhaps we could have a little animated character which pops up and asks you what you're trying to do :-) Kidding. Maybe some bug-report / wish list items would be a place to start on some of this? 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. -- 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.
Re: Visions of Leo 5.0
On Sun, Jun 19, 2011 at 2:46 PM, aeromorrison adam.morri...@sportplanedesign.com wrote: We use leo quite a lot here at our company. I would say we are moderately technical users, but still have a lot to learn about leo! This is the key problem, however. We do a fair amount of Python coding in our business, but don't have time to constantly dig through the source code of every tool we use. It seems quite difficult to get up to speed on all of the capabilities of leo. Hmm. My intention is that it should *not* be necessary to understand all the intricacies of Leo in order to be able to use it. There are many features of Leo that I use seldom, if ever. This reminds me about the most important Aha I ever had about Emacs, namely that one does not have to pay attention to all of Emacs's alt-x commands in order to use Emacs effectively. The situation is similar, I think, because I modeled Leo's minibuffer of the Emacs minibuffer (and all the Emacs alt-x commands). True, there has been a lot of development on Leo over the past several years, but my own work flow has remained almost completely unchanged. For me, the biggest improvement has been the qttabs gui. At first I was unimpressed; now, I don't know how I ever lived without it. Even by frequent, careful reading of the online help and a couple of years of everyday work with leo, we come away feeling like there is so much more there that we can't readily access. We monitor these forums and occasionally post questions and comments, but it feels like to really have an awareness of leo's feature set, you have to spend significant time reading the code and understanding it and continuously keep track of this forum. To repeat, you should absolutely feel free to ignore the vast majority of Leo's features, as long as you have a work flow that suites you. Much of capability discussions on this forum address really interesting items which don't seem to be addressed in documentation anywhere. This leaves the moderately technical to pure users wanting. What you are really seeing, I think, is that this forum mostly gets developer-level discussions. There is a separate help forum, but it has low traffic. It would be fantastic if all the great things about leo could be documented thoroughly so that potential new users could readily access these capabilities. It seems that the code and features within leo develop pretty rapidly, but much of it gets left undocumented. It's documented in the what's new section: http://webpages.charter.net/edreamleo/what-is-new.html But your point is well taken. There may well be important features that aren't very well documented. Feel free to file bug reports about such sections, or just ask about them here: I typically use my responses here as pre-writing for more documentation. The only 'documentation' seems to be snippets of discussion threads on this forum. Much of the documentation is probably adequate for professional computer scientists, but leaves a significant gap for people like me (an engineer who uses code to get other work done). Thus, it seems that each time I want to explore a new feature of leo, I spend a bunch of time in trial and error trying to figure out how it works. This could be an opportunity for us both. When this happens again, please do ask question here, and remind me of this conversation. That way you can get your answers more quickly, and I will be encouraged to add the missing documentation. I thinks this is the only real way to improve the documentation. It can't be done in general; it can only be done step by specific step. Edward -- 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.
Re: Visions of Leo 5.0
We use leo quite a lot here at our company. I would say we are moderately technical users, but still have a lot to learn about leo! This is the key problem, however. We do a fair amount of Python coding in our business, but don't have time to constantly dig through the source code of every tool we use. It seems quite difficult to get up to speed on all of the capabilities of leo. Even by frequent, careful reading of the online help and a couple of years of everyday work with leo, we come away feeling like there is so much more there that we can't readily access. We monitor these forums and occasionally post questions and comments, but it feels like to really have an awareness of leo's feature set, you have to spend significant time reading the code and understanding it and continuously keep track of this forum. Much of capability discussions on this forum address really interesting items which don't seem to be addressed in documentation anywhere. This leaves the moderately technical to pure users wanting. It would be fantastic if all the great things about leo could be documented thoroughly so that potential new users could readily access these capabilities. It seems that the code and features within leo develop pretty rapidly, but much of it gets left undocumented. The only 'documentation' seems to be snippets of discussion threads on this forum. Much of the documentation is probably adequate for professional computer scientists, but leaves a significant gap for people like me (an engineer who uses code to get other work done). Thus, it seems that each time I want to explore a new feature of leo, I spend a bunch of time in trial and error trying to figure out how it works. A new user with other work to do just cannot justify the overhead required to do that. If there was up-to- date reference material available to quickly get going with different features, we would be much 'smarter' about using leo, much more likely to spread the word, and much more likely to contribute to its ongoing development. Terry said, much of the coolness of Leo is only relevant to at least somewhat technical users. I think we are relatively technical users, but still find it difficult. It may be a 'self-fulfilling prophecy' -- if the tool is complex to install, understand, and use, you will only attract the small audience of those with the time, energy, and skillset to work through it themselves. For 5.0, I would suggest focusing less on features and underlying architecture and much more of usability, ease of access for non-Python programmers, and comprehensive documentation of all core features, plugins, and dependencies. My 2 cents, Adam On Jun 18, 9:20 am, 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. Alternatively, we could skip 5.0 entirely, and concentrate on effective YouTube demos ;-) For example, here is the Code Bubbles demo:http://www.andrewbragdon.com/codebubbles_site.asp -- 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.
Re: Visions of Leo 5.0
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. Reamedream...@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.
Re: Visions of Leo 5.0
On Sun, 19 Jun 2011 12:53:49 -0700 taa, Leo Newbie starman...@gmail.com wrote: 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. I was probably over-generalizing. A one-click install would be good for its own sake. Even for hardcore Leo users / coders it would sure be nice to be able to get it running on other machines that easily. And a one-click install would definitely increase the number of people who try Leo, which is obviously essential if we're going to increase user base, so yes, one-click install IS critical for more widespread use of Leo. My comment came from thinking that almost all the uses I make of Leo depend on at least simple scripts to glue stuff together. In a way that's not really true, seeing a lot of the time I'm just using it to write code, which doesn't require any scripting. If all you do is use Leo for writing code, I guess I don't really know how it stacks up against other environments, since the only other one I've used is Emacs, which I gave up for Leo. For me, the ability to script Leo, the python access to nodes, and the possibilities for non-coding uses etc. would make me choose Leo over other systems even if they were stronger on the coding aspect. But that's just me. I agree with aeromorrison that a period of user experience refinement would be good for Leo, it's just a question of people wanting to work on that. I'd like to work on the free layout stuff, the icon bar could probably be spiffed up, an installer would be nice, and a simple interface to the @auto / @nosent / @shadow / @file / @edit / @auto-rst would probably help a lot of people. Plugin management could also be refined. The documentation has improved, although to be fair I think it was always better than the average open source projects. But it could be improved more, particularly with respect to plugins and how users access the documentation (What's this? kind of tools). Perhaps we could have a little animated character which pops up and asks you what you're trying to do :-) Kidding. Maybe some bug-report / wish list items would be a place to start on some of this? 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.
Re: Visions of Leo 5.0
On Jun 18, 8:20 am, Edward K. Ream edream...@gmail.com wrote: B. @structure-view (or just @view) Here, we imagine an add-node-to-view command. The user selects a node, and then the command describes a node in terms of outline structure. For example, the x method of the y class in file z. Thus, the body text (or uA) of @view nodes will be a list of such descriptions. Perhaps more simply, we could allow users to add elements, including clones to @view nodes as usual. Leo's *write* logic would compute the descriptions of the nodes and add those descriptions to the body text or uA of the @view node. EKR -- 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.
Re: Visions of Leo 5.0
On Jun 18, 8:20 am, Edward K. Ream edream...@gmail.com wrote: 5. Patterns (and other techniques) can define views. I ran across this brilliant idea from another editor. Alas, I don't remember what it was. Does anyone recall? I don't believe it was the Code Bubbles project, but I strongly suspect that Code Bubbles must use similar techniques so that they don't pollute the sources. Code bubbles has the advantage of being an Eclipse plugin, so it can use the Eclipse class browser as the foundation for it's node descriptions. EKR -- 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.
Re: Visions of Leo 5.0
On Sat, Jun 18, 2011 at 9:37 AM, Terry Brown terry_n_br...@yahoo.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 :-) It relates only in so far as it may reduce the pollution of source files. I think one click install would do more to increase the number of Leo users than anything else. Yes, that would certainly help. 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 ;-) The idea of creating the soft link automatically when the user drags a node under an @view node relates to your next point... UNLs UNLs UNLs don't get anywhere near as much credit as they deserve. In essence, my posting is groundwork for giving UNL's their due. Soft links, like UNL's, can fail. The point of my posting is that isn't necessarily such a bad thing: provided we don't expect view nodes to carry uA's. Personally I think [UNL's] can replace clones and eliminate all the complexity clones introduce, but I don't expect that to happen :-) This is why I emphasized point 4. Internally, Leo's data structures are perfect, stable and capable. So *internal* clones (Leo's DAG) is not going to change. But from the user's point of view, the Aha is that I don't use clones that require uA's, so soft links, @view nodes, etc, would do as well. 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. It is exactly this kind of script that could be built into an @view-pattern node (automatically by Leo) or built into an @view-script node (on a custom basis, by the user). The point is that Leo's read code would execute this script automatically on loading one or more .leo files--the scripts would populate their respective @view nodes. 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 Thanks for all these comments. Imo, we are saying very similar things. Edward -- 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.
