On Sun, Apr 29, 2018 at 4:00 PM, Terry Brown <[email protected]> wrote:
>From a general design principle, I find it extremely jarring to need a > Commands object to instantiate a VNode. Interesting. This has never bothered me (before now). > This is the (general) question > > of layering I've tried to express before. > > Back here I was trying to express the idea of layers (I was > calling them levels) within the GUI layer: > https://groups.google.com/d/topic/leo-editor/Cgzy6CYGJ8w/discussion > > But the GUI layer itself is just one layer in a higher lever set of > layers I started to try and list a couple of days ago: > > - node storage and mutation > - outline storage / representation / manipulation > - outline loading / session stuff (Commands object here?) > - importers here? or as plugins? > - collection of outlines > - maybe now the GUI layer (with sub-layers as in above linked thread) > - plug-ins and FNMW like paste-as-xml > > Not suggesting this is complete or optimal or anything. Key point is > that things higher on the list know nothing of things lower on the list. > Again, interesting. I've never thought that way. > Nodes knowing about outlines doesn't ruin Leo, perhaps that has no > impact at all from a user perspective. But I do think a lot of the > vertical integration between layers makes it hard to develop Leo, > from the point of view of understanding code flow and working out where > changes can be made. > I think the Find code may be the best example of this. It seems there's a similar cross linking of layers in the Find > code. I agree. > I'd expect clone-find-all, mark-finds, regular user interaction > type find etc. to call a generic find function that returns a list or > generator and is completely ignorant of the client code's use of the > result, the call to the find code includes kwargs etc. indicating what > is to be done with the found nodes, and I would have needed to add my > action in with the existing options. Parts of the find code are horrible, because that code has to maintain interactive find state. That's really really tricky. However, there is now a super easy way to find anything: c. cloneFindByPredicate. Yes, it has lots of kwargs, but it's a Swiss Army Knife. In practice, it works well. See, for example, c.cloneFindMarkedHelper. Which doesn't work well for a > > plugin, so I just went with a more simplistic recursive find. > The code of c. cloneFindByPredicate is probably just as simple/simplistic. I don't think these issues are because Leo is badly designed or > implemented, I think it's because Leo's nearly twenty years old(?) and > has evolved, perhaps from something unusual (a literate code editor) to > something quite unique (a tree based information manager / environment). > Yes, Leo has evolved, and the VNode class contains some of the most important "evolutionary" details. I'll explain in great detail in my reply to Vitalije's original post. So GUI startup for example. Leo used to be a three widget app. - tree, > log, and body. Then over time a bunch more widgets got jammed into the > log pane, and suddenly startup logging and plugins loading widgets is > interrelated. And it works fine, it's just hard to change. Who could > have known, back at the beginning, that managing a bunch more widgets > no one had thought of could be a consideration? > Imo, some parts of Leo do suffer from code that has to consider the types of widgets on a case-by-case basis. The VR plugin is one example, parts of the key handler are another, and as you say, parts of the outline-widget-management code are another. I don't think we are going to define a base LeoWidget class and use standard Object-Oriented inheritance to eliminate the case statements. It just isn't worth it. > Finally though another point that I think Vitalije also touches on - > these discussions are not unhealthy, but they're not really productive > either, unless there's serious interest in major restructuring. > Let's be very clear here. These discussions are productive because they expose design and coding details that otherwise would not come to the surface. As my mentor, Bob Fitzwater, constantly stressed, design is far more important than code, and design is only tangentially apparent in the code. But some of the code details I'll discuss in my reply to Vitalije are also quite important. True, I see no reason to change the actual code, for reasons I'll explain fully in my next reply, but that in no way means this discussion is unproductive! I think we'd really need to consider whether these changes could be > made within Leo, or more efficiently as LeoII - either way is a scary > amount of work. > It's easy to *consider* giant reorgs, but the VNode class will remain exactly as it is. Kind of a long email to wrap up by questioning the productivity of the > discussion, but oh well :-) > To repeat, this kind of discussion is extremely valuable even thought the code isn't going to change. I'm thinking of my legacy now. I want all devs to understand what I think is important. After I'm gone, you will make your own decisions, but imo it would be a pity if you all decided to rewrite large parts of the code merely because you didn't understand it. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
