I've been wondering about what's next for me recently. Today it all came together in a sequence of Aha's.
1. I'll be doing programming tools "forever". I've always been fascinated by programs and their complexity, and I doubt I will ever be able to do much else :-) Happily, Python and Leo provide almost unlimited opportunity for tools that aid programming. 2. The recent ui work is exciting, but as I said in another thread, the proliferation of Leonine features is also a symptom that something is missing. For example, there are "too many" tabs now in my Leo outline. The immediate problem is that there is no easy way to select a tab without using the mouse. Sure, there are workarounds, but something smoother is needed. 3. At present, adding ui features requires significant code. It's never elegant to do things with more and more code. The latest tab improvements are a kludge. It's not horrible by itself, but again its a symptom of an underlying problem. 4. This morning in the shower I saw a possible approach. Later, I realized it may be related to the thread, "Showing and editing multiple leo files in a single outline". The main idea is that panes, tabs and buttons are really "stand-ins" for data that is most elegantly represented by an outline. I don't mean that panes, tabs and buttons are useless, just the reverse: we need ways of having more of them. However, we need *general* ways of having more of them, not ad hoc ways. Putting this all together, we have the following: **We want to expand the role of outlines in several dimensions.** A. It's time to consider .leo files to be "true" project files, that may include other .leo files. Conceptually, we might want to distinguish Leo project files (.leop) from "ordinary" .leo files, but in practice the format will likely remain unchanged. B. Within .leop files, @leo trees will cause other .leo files to be loaded. A **single** outline can represent arbitrarily many .leo files C. The most general way of understanding the Leo main **window** is as a collection of programming tools. - @leo nodes, and their associated views - Collections of buttons - Panes containing tools. We have standard panes/tabs (log, find, spell, etc) and plugin-defined panes/tabs (the Graph and Link tabs) D. Within a .leop (or probably any .leo file), we want the user (plugin writer?) to define the layout of the main window. The obvious way to do this is with @layout trees. I disparaged this idea previously, iirc, but now it occurs in a more general context, the context of programming tools embedded into Leo's main window. In this context, it seems essential that we be able to translate @layout trees directly into working code. As recent experience shows, Leo is near the limit of our ability to add ui elements "by hand". In other words, it's time to take advantage of the dynamic nature of Qt, Python and Leo. The raw materials of @layout trees will be the highest level items that can do the job: outline-panes, buttons and button areas, body panes, log panes, user-defined areas, etc. In other words, the components being laid out in @layout trees will be a bit higher level than Qt widgets. E. Given a more dynamic framework, "rendering" panes becomes simply another kind of screen area associated with a programming tool. Ditto for multiple body panes. Etc. Conclusions This is a major project: it will require a redesign and major refactoring of Leo's Commander and Frame classes so that the data can be viewed in several ways simultaneously. Almost all of this will take behind the scenes. The look and feel of Leo will remain pretty much as it is by default. Otoh, users and plugin writers will be able to create a screen whose layout **changes dynamically** based on what part of the outline the user selects. For example, one might imagine that selecting a suboutline will cause new areas of the screen to appear, containing new panes or new groups of buttons. Imo, the first Aha is the most important: Leo is, and (for me) will always be primarily about programming tools. But this is hardly a limitation. Documentation and analysis graphs require sophisticated rendering. We want Leo to be able to handle almost any tool that might arise. 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.
