On Tue, Jun 12, 2018 at 11:15 AM, Terry Brown <terrynbr...@gmail.com> wrote:
> On Tue, 12 Jun 2018 09:30:51 -0500 > "Edward K. Ream" <edream...@gmail.com> 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. > Yes. You and I agree about this. But many people, including you, have overcome these difficulties and contributed code. Leo's code base is huge, and parts of it are complex. That does not prove that the code could is defective in any significant way. 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. > Yes. Furthermore, there are built-in "connections" between the outline an body panes. 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. > Exactly. We want the find-next/find-prev commands to be "stateless", but that's really tricky when the outline itself changes. Maybe there is a brilliant way around this problem, but nobody has suggested one yet. This is an example of huge complexities arising from creating the *illusion* of simplicity for the user. That was the big Aha of MacOS. I have little patience with would-be devs who don't understand this basic fact of life. This does not give me a free pass to do stupid things. Conversely, not every complication is evidence of stupidity. 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. > I agree with all of this. Leo's code base isn't ever going to be perfect. One reason is that there are much more interesting things to do. Like adding indices to Leo's DAG, and like supporting client-server architectures in Leo. BTW, I have been meaning to ask. Somewhere, don't remember now where, you seemed to imply that you needed my approval for the Leo edit pane project. Imo, you don't. Of course, we'll all evaluate it when you think it's ready... 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
