On Fri, May 1, 2020 at 10:09 AM vitalije <vitali...@gmail.com> 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. > I'm not sure what idea you are talking about. I often don't understand complex ideas, which does not mean I want to reject them out of hand. > Recently someone on this list wrote some critique using poorly choice of > words like "bad as usual" and similar. Your reaction was to almost ban him > and there wasn't any further discussion. > I never said I would ban anyone. I simply said I stopped reading the offensive post. You were recently looking for a juicy problem to solve. I think there are > quite a few juicy refactorings that should be done to improve Leo's code. > However it seems that you are not particularly fond of refactoring Leo's > code. > Refactoring is difficult and dangerous, especially when the code is not covered completely by unit tests. Imo, there should be a strong reason for refactoring. That said, I think refactoring is the only way to improve or simplify code. Our communication was sometimes enjoyable and successful like when we > recently discussed deletePositionsInList method. To me the code looked > obviously correct. I couldn't write any clearer explanation. The curse of > knowledge left me helpless. Then you took your time and you dived into the > problem and proved yourself that the code is correct. > Yes, that was a good collaboration. > I would like if you do this for any code improvement idea we discuss. Take > some time and dive into the problem before rejecting the idea or critique. > My first thought is usually whether the idea seems important enough to devote the extra time. I don't recall ever rejecting an idea without reading it. Now let's get back to your post about outline redraw code. You wrote: > > It's all too easy to lose data when switching from one node to another. >> > > and I would agree with this claim. It is too easy to lose data. However I > believe you meant to say that this is the fact that can't be changed. To me > this is true at the moment in Leo's present state, but it is not something > we can't do anything about. > I'm open to suggestions in this area. This is a new discussion, one that we've never had before. > Rather to me this is the code smell...I am certain that Leo's tree select > can be greatly simplified and improved providing that we make all necessary > refactorings. > That would be great! > I almost hear you saying that the selection code is complex because it has > to be and there is nothing we can/should do about it. > Please do not put words in my mouth. > One of the biggest sources of complexity in this area is Leo's GUI > wrapper/widget machinery. Over the years you have convinced yourself that > this is the good idea. > How else is Leo's core to remain unchanged while supporting multiple guis? You may say that this architecture allows a string GUI that is used for > testing, but this is another story. Many of the unit tests in their present > implementation are useless because they are not testing the production code > but some other code that is never used. > I disagree. In any case, this is yet another discussion. >> The interface between Leo's code is minimal. > This is another claim that I believe to be false. Before some recent changes I have made in this area, the outline drawing code was surprisingly spending more than 40% time in os.path.norm_path. Those are removed now but they are signs of deeper interconnection between the core and drawing code than you claimed to be. The interface to which I was referring are the calls to c.redraw(). That is pretty close to the simplest api that could possibly work. The calls to os.path.normpath look like a performance bug. This bug does not seem to affect Leo's class design in any way. I have not looked at the code in question. I am willing to trust your fix. > Drawing outline still has some calls to c.setCurrentPosition which really shouldn't be there If the principle of doing only one thing is followed. The presence of these calls in the drawing code to me is obviously wrong. Yet another topic for discussion. I don't remember anything about those calls or why they are there. > ...I am sure if you dive into the problem with open mind you'll see that there can't be any logical explanation why these calls would be necessary inside the drawing code. It's not a question of me having an open mind. This code is completely off my radar, and it's not something I care anything about *at the present time.* I emphasize those last words because I have no investment in the old code. If you have ideas for better redrawing code, I would be willing to listen to *specific* ideas, or better, to look at actual code. > I could add many more items on the list of necessary refactorings but it would be useless unless you accept the fact that the code is not rock solid as you claim it is and there is in fact a great need to revise the code. Perhaps we disagree about what the term "rock solid" means. What *I* mean is that in the past decade or so there have been no credible reports of people having lost data as the result of bugs in Leo's Qt code. This is a statement of reliability, not a statement of code simplicity or any other code metric. > Fixing bugs and adding new features almost always leads to sub-optimal code and refactoring is necessary from time to time to keep code manageable. However you wrote: The present code is reasonable and rock solid. There is no great need to > revise it, and I have no plans to do so. > I'll summarize my attitude as follows. I am not aware of any reliability issues with the present Qt drawing code. I am open to specific suggestions for improving the code, but no change to the Qt code must ever lose data. > For such large scale refactorings you are the only one who can approve them. I am willing to do the necessary work, but I am not prepared to spend hours and weeks on the refactorings if you are not willing to accept them in the end. We have to at least agree that some refactoring is necessary. I can not comment about ideas that haven't been presented to me, nor about code that does not exist. General statements about the Qt code base won't convince me. I need something I can understand. > There was a discussion on rewriting from scratch or using some other strategy for refactoring code. I have read about the mikado method as the good way to tackle refactoring of large projects. Basically it suggests to change any part of code and see what parts of the application are broken. Then revert the code in the initial state and make change somewhere else and record what is broken by this change. Using this technique one can learn quickly about hidden interconnections between modules. An interesting idea. > With this knowledge acquired it is usually possible to make some refactoring with greater confidence. When I read about this method I couldn't help but see the Leo as the perfect example of large project which needs to be refactored. This kind of general statement is neither illuminating nor convincing. We are talking about Leo's data integrity here. > In the past I have made several attempts to improve drawing code. Most recently I worked on the tree-refresh branch which avoids deleting tree items and uses a fast diffing algorithm to find which items should be changed. It gives some improvements but not enough to be proposed as the way to go. Yes, I am convinced that you understand the general scope of the problems. > However I am sure that in combination with some other refactorings like moving hoisting logic and chapter logic from core to the view and cleaning the drawing code from the calls to tree.select and c.setCurrentPosition this approach can be very good. Actually both ideas using diff algorithm to change the tree and not to recreate it from the scratch and the idea of drawing only handful of nodes that user can actually see can't give enough performance gain unless these other refactorings are done. Once they are done the drawing won't be a problem any more. Both of these ideas can't really shine until these refactorings are done. I have said several times that I have no objection to qualified devs such as yourself attempting to improve and simplify Leo's code. However, I can not express an opinion about vague strategies or unseen code. > There are many more possible improvements that depend on some of these large scale refactorings that can't be done without your approval. What, exactly, do you want me to do? I have *already* given you approval to refactor any part of Leo's code on an experimental basis. Your fast read code was a spectacular success. Your proposal to redefine positions was a spectacular failure. Your prototype Tk gui code was way way better than my old Tk gui code. There is no way for me to know what your Qt gui code will be like until I see it. Even then, the only way to know whether the new code will preserve data will be to use it for a few months. > For example I've been working on the binary python extension written in rust and one written in cython. Both of them are very promising. Yet another topic, with another set of considerations, the most important of which, to me, is the question of how to distribute binary code. Matt may have something to say about this. *Summary* Please do not generalize about my willingness to consider new ideas. I frequently misunderstand ideas. *Sometimes *I am willing to do extra work on my own to understand proposals. Whether I am willing to do extra work depends on my *guess *about the importance of each proposal. That guess might be wrong. I know that. Don't give up. To help me out: - Do not assume I understand the implications of all of Leo's code. I don't. - Make your proposals as clear, concrete and intuitive as possible. It often take me sustained, protracted work to understand new ideas. - Do not lump proposals together! Give me a chance to understand each separately. 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2pd%3DmKBevx6O6bYpTiCz7F%2BicG9TO%3DPsPM-AjD4bsWDQ%40mail.gmail.com.
