This can be a long post that may or may not be of interest to readers. Please skip it if you find it uninteresting.
In another thread Edward wrote something that I would like to quote here just as an example of something that I notice throughout the Leo source code. It can be described as a design principle that IMO introduces unnecessary complexity everywhere. We will also need a paste-as-xml command, so that people can paste the > xml-version of an outline into an external editor. Personally I don't have anything against the xml format being used in clipboard. I have made a prototype that uses json, but it's not important at all. I could have made a prototype that uses xml. Something other bothers me in the above sentence. Why is it important to allow user to paste outline in another editor? I have never done this and can't imagine for what purpose any user would want to do that. If someone needs to copy part of the outline and make out of it new Leo document, it would be just as easy to open new Leo file and paste outline there. To repeat again, this is just an example of something that I notice throughout the Leo code. It would make no harm if it were the only exception, but it is present everywhere. To make the discussion easier I will name this design principle "flexibility no matter what" (FNMW). Do I consider having flexibility to be good or not? I would certainly consider lack of flexibility when you need it, to be a misfortune. It is good to have flexibility when you need it. But what about the case when you have some extra flexibility that you don't use at all. If it doesn't cost you much it would be nice to have it just for the case you might need it one day. But what if it costs you dearly and you don't have a real need for it in the foreseeable future? It would be like you own thousand houses world-wide and you live in just one of them. But you pay taxes and bills for all other houses that you never use or use very rarely. You would in this case do much better for yourself if you throw away all those houses which bring you just costs and no benefits. If you don't make a good use of those houses they become just a burden. The same logic should be applied to code design. If you need to achieve some flexibility in a certain part of code, then no effort should be spared to implement it. But if there is no evidence that the flexibility would be used, usually it will make code shorter, cleaner, easier to understand and maintain, and often faster to execute if you forget about that flexibility and make smallest viable product. Keep the energy for more important things. I can point out to many examples of this FNMW design principle throughout the Leo code. Many modules, classes, methods and functions are designed as if they were public libraries used by many users for different use cases. But most of those modules are used only by Leo developers and in a very specific way. Those modules could be made much more readable, smaller, more efficient if they were tailored to a more specific task they need to perform and not as a general purpose tool that can be used for many other tasks. Without any intention to diminish any effort that recently went into making very flexible theme handling code, I still wander whether it was good thing to do. Let me explain a bit. I haven't looked at that code yet, and I have only skimmed through the theme related discussion. So, I may be very wrong about this. I just can't imagine that lots of users will see or use this flexibility. I guess that only one or two qt stylesheet experts will ever make small set of Leo themes that most of the other users will use just as they are without any customization. Basically qt stylesheets are just plain text files and Leo had already large number of tools for writing text files. Was it really the case that those stylesheets couldn't have been written using only standard Leo features for dealing with external files? If the theme customization in Leo were made to be extremely user-friendly comparing to other editors, I would consider all those efforts worthy. But let's be honest, customization of Leo appearance is not strongest Leo feature. There are tons of user complains about it. I can agree that Leo has a flexible system for writing style sheets, so it may be the tool of choice for some stylesheet designers out there. But I am not sure that even they needed all this flexibility. It seems to me very likely that the qt stylesheet designers would make those stylesheets just as easy using standard Leo features for external files. In the end there is a slight possibility that a few designers will use all the flexibility of Leo's theme related code, to produce ten different stylesheet files. But the rest of users will be afraid to touch any part of the themes and will just choose one of them to use as it is. I know that I am the one of the users afraid to touch the theme content. Last time I tried to customize Leo's appearance it took me several hours. Another example: unknownAttributes. In other thread we were seriously discussing possibilities that some user may have some exotic data in uA and what should we do to make this feature most flexible. But where is the evidence that any user would actually use that flexibility? I don't recall that I have ever used uA for any purpose. I can't imagine what would I put in uA and why? As I understand some plugins use this feature. Which plugins? How many of Leo's official plugins do use this feature? What do those plugins put in uA? Do we have ready answers to these questions? Have we ever made a list of this plugins and its uA needs? What if the list had just a few entries and all of them put just strings and numbers in uA? And let me remind you, we had an issue reported when someone used both python 2 and python 3 verisons on the same document that was caused by pickle version protocol. So, some users suffered because we used pickle module for handling uA. It may happen that nobody has ever gained any benefit from such flexibility and yet some of our users had suffered from it. I am not claiming that this is the case. I don't know who uses uA and in what way so I can't be certain about this. But until proven otherwise I doubt this flexibility is required. Given that supporting this feature makes code complex and ugly, I would vote for restricting it. If I am allowed to put a string in uA, then I can encode arbitrary data structure into a string. So I don't think that any user should feel uncomfortable regarding this restriction. Those few who really need some special data to be kept in uA, can encode/decode their own data as they want. But the rest of code should not be further complicated to support some feature that those who need can easy enough achieve even under such restrictions. I remember the discussion about the book "Made to stick" in this forum several years ago. There is an example described in the book about one project manager who made a wooden block as a model of a handheld PIM device the project was about. Whenever a member of a team had some idea what to add to the device, this manager would take the wooden block in his hand and reply something like: "Great idea, but look there is no space for another button". There is also a rule that most artists honor: "The perfection is achieved not when there is nothing more to be added, but when there is nothing to be removed." To summarize, I don't think that we should panic. Leo's code has been around for a long time and there is no immediate danger. Leo mostly works as expected. However, if we let FNMW principle to prevail we risk that one day Leo would support so many features that no-one would be able to remember or use just one tenth of them and Leo code complexity would exceed the ability of mightiest human mind to understand. It is already very hard to understand some parts of Leo even with the help of Leo's outlining capabilities. It may be a good strategy to examine each Leo feature in terms of how often it is used and if the same effect can be achieved through some other features. The questioning should start with those features that introduce most complexity, and give minor value to the Leo. Each feature that complicates much and is used rarely or not at all, should be discarded and code simplified until someone shows up who really needs such feature. When the code is simple, clean, easy to read and reason about, it is not hard to achieve any missing feature. But when the code is complex it may happen that a feature otherwise achievable, because the complexity of present code base, is labeled as an impossible idea. Vitalije -- 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.
