On Tue, 12 Jun 2018 09:30:51 -0500 "Edward K. Ream" <[email protected]> wrote:
> > And I say Leo's architecture could be way more simpler and more > > modular, allowing people to more easily contribute with less > > control from anyone. There is only a minimal neccessary core for > > what leo is doing, the rest is just bloat for comfort, though leo > > is not designed that way. Or more exactly, it did not grow that > > way, after all this is the original problem here. Historical grown > > design. Today everyone here want's to do way more with leo than you > > originally planned for it of what the architecture can easily > > deliver. > > > No way is this even remotely true. Leo's classes are mostly what > they were 20 years ago. To my knowledge, there is no significant > interactions between classes or modules. That's what modularity > means. This is what allows me, say, to contemplate rewriting Leo's > undo code. > > This kind of general criticism, without any grounding in fact, is > disrespectful and unhelpful. If you have specific suggestions to > make, then make them. I think the existence of this problem is perhaps a matter of perspective or perception. It may not be specifically an interaction between classes or modules, but to me there does seem to be a high level of interconnectedness in Leo which can make development challenging. For example Leo has a text editor component that has some really cool features, like abbreviation expansion and general integration with Leo such that keystrokes can invoke Python scripts etc. But, and this has been the challenge I've run into in the Leo edit pane project, Leo's text editor component (I believe, this is were the issue of perception comes in) edits not some abstract piece of text, but the text at c.p.b. Which makes it hard to use it in pop up reference sticky notes or extra editor windows that don't change the current tree selection. There are other examples - the way the logging subcomponent is tied in with start up code (because of the need to accept log messages before there's a place to put them) and managing other widgets like Find and Spell tabs - this is an issue I still need to work on in the dock layout project. The find functionality is another one, several different actions on found nodes are possible by passing in instructions to the find machinery, but it would be more flexible the machinery to just report what was found and have the actions on that collection handled separately. And of course it's easy to complain about these things :-} when you're not actually dealing with the complexities involved, like implementing find-next given the possibility that the outline changed since the last find. I don't think these scleroses, as Edward has perhaps termed them in the past, are fatal flaws, but I do think the impede development and the future of Leo, and require major work to remove. Which is one of the reasons I'd like to have seen Vitalije's prototype demonstration as a whole rather than piecemeal - the interconnection between vnodes and commanders (needing c to instantiate v) may be one of the less intrusive, but is still jarring design wise and perhaps an impediment to alternate back ends / interfaces. 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.
