These are a few points that come to mind: The configuration is indeed the most troublesome aspect of Leo. Now that qt is well on its way to being usable, I can imagine a nice graphical front end (automatically generated) that would allow users to choose and test their keyboard bindings, add, remove and test the plugins, adjust the qt layout and display options (spacings borders, colours, fonts ect..), and various other options related to leo's commands like find options.
With regards to gui design, I suspect with the move to qt it may be easy to make the layout of Leo quite flexible and dynamic. Specifically, it would be nice to separate out the various components of the leo interface into different windows for use with multiple desktops, or quick switching to save screen real estate. On another topic, it would be nice to display files in multiple ways: For instance, it is often convenient to work with your routines separated into different nodes, but sometimes it is helpful to view and edit the entire derived file (with line numbers). To facilitate this I can imagine a special type of flattened clone that displays the contents of the external file (derived file) exactly as it would appear in another editor. The asymmetry in the clone can be circumvented by turning the (or one of the) flattened clone(s) back into its original form if the last nodal clone is deleted. Related to this idea is the facility to print out sections of code with the various display options available in many editors. Leo has the chance to really shine in this area as we can view the code in many many ways, but currently I find myself using other editors to print out sections of my external files. Perhaps the new qt front end will facilitate the interface to a nice printing dialog. That is all for now. David On Oct 31, 8:25 pm, Mike Crowe <[EMAIL PROTECTED]> wrote: > Ville M. Vainio wrote: > > On Fri, Oct 31, 2008 at 3:45 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > > >> I won't call this off topic, because the same kind of question could > >> apply to Leo: how to make Leo the default editor of most programmers. > > > To do that, leo needs to become easy for easy tasks like: > > > - Quickly edit a single file > > - Quickly edit a large file > > - Do the typical thing for tyical keypresses (tab, shift+tab comes to mind) > > - Drag-and-drop a file from file manager works - now this is easy at least > > > On a more advanced side (off the top of my head): > > > - Good "find in files" (grep) feature > > - Easily import project trees > > - Fast for large project trees (lazy loading or caching). > > - Integration with gcc (read - you can run make, and click on the > > resulting colored error messages) > > - Integration with gdb (as with emacs) > > - Integration with ctags > > - Mylyn-like "most interesting nodes" list (count how much time you > > spend with nodes, which nodes you actually edit, etc). > > As a returning user, I can offer some fresh insight, I think. I'm > pumped about Leo because I'm starting to see the deep power it has, > which I wasn't willing to find in prior experiences. > > * Documentation: > o Leo is overwhelming, and it's difficult to take a user from > a new user to a productive Leo user. We need better > tutorials and more up-to-date examples. > o Example use-cases: Show how to use the cloning features to > write a program (but a more advanced section) > o I'm learning the joys of rst and writing documentation. We > need a few downloadable examples to help out. I found a lot > from reading the LeoDocs.leo. > * Community: > o Edward is fantastic, but a vibrant community is critical to > not drive people away. We need more participation from > people helping new people out. Quick responses to n00b's > asking for simple questions would be great. > o Ability to collaborate on plugins, etc. This may be > available, but it isn't necessarily obvious. I groan to say > this, but we almost need some wiki based collaboration area > where we can all contribute. > o IRC Channel. I think this would help, again, if we had a > willing community. > * Languages: > o We need evangelists for each language. The python support > is rock solid (naturally). However, importing projects in > other languages is not really supported yet, nor easy. I'm > trying to tackle php and lua, but we need more people within > those communities expanding our support. > * Leo > o I think qt might be the answer. Tk (though I run on > windows) make it feel old, somehow. > o A true find/replace with regex support. I'm learning how to > use the existing support, but man, it's frustrating for new > people. > o Shadow trees: IMO, this is the future. I think most will > use this mode as they develop. > o Dynamic keyboard mapping: We all have different key > choices, but I hate searching for what I want to change, > updating, exiting everything, then going back to see if that > was right. Currently, I was trying to remap F2 to change > the Headline. I put that in my myLeoSettings.leo, but got > this message: redefining shortcut F2 from > edit-headline (all) to find-prev (all). I have no idea why, > but hate the process enough to not bother with it. > o Vim: I'm not a programming novice by any means, but > configuring things like Vim keyboard emulation should be > easy for new folks. I had so many problems with it that I > abandoned it and went back to the old keyboard binding. > o OK, configuration: The more I think about what I don't like > it really is the configuration. > > HTH > Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
