FWIW, I think I generally agree with Vitalije. First, seeing everyone's apologizing ;-) let me apologize for dragging an attempt at general discussion into the weeds of specifics, I know that's annoying. I know that the point doesn't rest on the particular history of uAs or VNodes or whatever.
>From a general design principle, I find it extremely jarring to need a Commands object to instantiate a VNode. 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. 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. In my first attempt at using QDocks as a more accessible layout system to replace free_layout I repeatedly got bogged down in trying to untangle the GUI initialization code, which has a lot of delayed initialization and cross linking of components through ivars. In my current attempt, I've simply side-stepped all that by letting regular GUI initialization occur, then moving everything around with a delayed execution callback - far from ideal but the only way I could find to move forward. As an aside, the current QDocks effort has just returned from a long and ultimately unfruitful attempt on my part to persist dock layout, I've finally realized that to restore dock geometry you can call QMainWindow.restoreState(), and QMainWindow.restoreGeometry() is just there to confuse you :-} I think the leo-edit-pane project has struggled for similar reasons. It seems there's a similar cross linking of layers in the Find code. I forget the details, but i wanted to get a list of found nodes and do something with it, but it seemed that what is to be done with found nodes is passed down into the inner layers of the find code. So whereas 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. Which doesn't work well for a plugin, so I just went with a more simplistic recursive find. 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). 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? 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. 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. Kind of a long email to wrap up by questioning the productivity of the discussion, but oh well :-) Cheers -Terry -- 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.
