On Friday, May 1, 2020 at 11:09:10 AM UTC-4, vitalije wrote: > > Dear Edward, > I find that it was very difficult to discuss code improvement ideas with > you. The most noticeable road-block for such discussions was your habit of > not reading and therefore not understanding the idea. Of course it may be > just my inability to express the idea clearly enough. After all I am not a > native English speaker. In most cases our discussions were ended with you > claiming that everything is sound and good enough in Leo's code. In your > recent ENB post about Leo's outline redraw code you wrote again some claims > that I truly believe are wrong. For as long as you keep saying such claims > to yourself there won't be any serious improvement possible. If you really > want for us to have a meaningful discussion you have to be open to hear > some critiques and to take necessary time to fully understand what the > critique is about. >
[long snip] I cannot give any practical suggestions as to changing or refactoring Leo's GUI code since I have not studied it. But perhaps I can say something useful here anyway. First of all, I haven't yet seen a compelling reason why a big effort in this area would be worthwhile. Why, for example, would I care if the load time for LeoPyRef dropped to 80ms? On my machine, the outline loads in about two seconds. I'm happy with that - I don't see how a faster load time would matter. Yes, I have a fast computer, but even say 10 seconds wouldn't bother me too much, since I don't have to load it often. I have not been hindered by delays in navigating the outline, large though it is. Yes, easier maintenance and reduction of technical debt would be good, but Leo works pretty well as it is. I'm not saying there isn't a good case to be made, just that it's not apparent to me yet. Second, because reworking large chunks of Leo's internals would be such a large job, I suggest seeing if there is a smaller piece of it that would make sense to focus on. For example, Edward had written several times about how clones make the outline display much harder than, say, for pyzo's equivalent. Try concentrating just on that point for a while. It's not so obvious to me, but I don't know anything about the code. To my naive brain, I would think that one would collect the nodes of interest in a temporary list or tree, and then walk that tree to create the display. The clone or otherwise status of nodes wouldn't play a part. The list would only contain object references, not copies of actual nodes. Yes, it's hard to know if a node would be off the bottom of the display, but we know how much vertical space a node requires to display, and so we can stop displaying when we have done than number (or more by some margin). This is analogous to clipping lines when they would draw off screen. Yes, It may not be so easy, but once the code has been set up, it just quietly does its job. Well, maybe this is exactly how Leo already does it, I don't know. My point is not about these details, but rather that maybe looking at *why* the clones make the drawing task hard - or really, if a different approach could be rather simpler - would be a profitable thing to do. Third, when I read suggestions about changing Leo's GUI internals, I get concerned that some current plugins or other code won't work anymore. Before any proposals for large changes were accepted, I would like to know that this issue had been looked at. For example, I believe that the forward/backward arrows are provided by a plugin. I would hate to lose them for a few years while Leo's GUI was being redone. So my input here, for what it is worth, is that in principle I think that a more complete separation of GUI from non-GUI, and GUI from QT, would be desirable; I would like to see a stronger look at the practical benefits, an effort to find a more limited area to concentrate on to serve as a proof of principle or at least to make the tangible benefits more evident, and a more system-oriented approach to make sure that we don't inadvertently lose important functionality. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/4fb667c0-bfb9-4e1c-8aec-c1bae0211297%40googlegroups.com.
