> > Really? What modules, classes, methods and functions trouble you? > > The actual design principle that I consciously follow *all the time* is > that modules and classes should hide all details about an easily understood > *idea.* In other words, Leo's design is about making modules and classes > completely independent from each other. That's what makes Leo stable. To > the first approximation, nothing else matters, and certainly not details > about kwargs. >
It's not about kwargs, but yes they have made me think and try to describe and define what is it that make things worse than they need to be. If you really did follow the principle of hiding details and making classes and modules as much independent of each other many classes would look differently. For example one of the most basic element of Leo's data is certainly VNode. And yet one can not instantiate VNode class without acquiring full blown commander, which in VNode is known as context. In the comment of context attribute is explicitly declared that it is called context to indicate its limited usage. However this field is used not only as a holder of hiddenRootNode but there is a method on VNode that knows about c.frame.body.wrapper and knows that c.frame.body.wrapper has setInsertPoint, setYScrollPosition... It also knows indirectly about c.fileCommands.gnxDict. Now, whichever module needs to access VNode class, can't just import leo.core.leoNodes and use it. It needs to acquire commander instance before. Recently, we discussed the copying and pasting outline. It delegates its task to fileCommands. FileCommands OTOH knows about c.frame.resizePaneToRatio, c.selectPosition, c.frame.initialRatios, c.atFileCommands.readAll, c.frame.body.onBodyChanged... It seems to me that copying and pasting outlines should belong just to VNode. I would expect that v instance knows best how to encode itself into a string, and to decode itself from string. There is no real need for v instance to know anything about c.fileCommands, c.atFileCommands, c.frame.body.wrapper ... You could say that fileCommands is designed to encode/decode vnodes. But why then it selects position, sets frame ratios ... If we want to extract encode/decode functionality from v in its own module, that's o.k. But extracted module in that case should be even lower level then vnode. It shouldn't know about any other functionality than VNode class. If fileCommands need to provide reading and saving Leo documents, then it would probably use the same low level helper module as Vnodes for encoding/decoding them from/to string. Additionally it may provide some gui related values like aspect ratios and selection. But it should not apply those values directly to c.frame.body.wrapper ... It should return those values to the commander and let the commander to apply those values (if it finds necessary to do so). I could write many more examples but these few would suffice to make my point clear. Leo is a programming environment. In principle, we don't know how people > have *already used* uA's. > > Exactly we don't know but we act as if we are certain that there are users who put in uA's some exotic data. IMO there was no need to introduce such level of flexibility before. Once upon a time there was no support for uA's at all. And then it was created based not on real user needs, but on the FNMW principle as flexible as possible no matter how expensive it may become. Do not misunderstand me. I really don't mind using pickle as a format. My point is just that we need to be aware of costs it incurs, and at least to think about whether we have to pay the full price or we can live with the less flexible one. Not a single thing that I have complained about is much important taken in isolation. I can live with any one of them. Only when I think about all of them together I see that they are real threat. I wrote this mostly because I feel sad about the fact that Leo has few brilliant ideas that every developer, designer, writer world wide would greatly benefit from if they learned about those brilliant ideas. Based on these few ideas Leo could become best and most wanted editor in the world. However, it is not likely to happen ever, because of all other features that we stick to so firmly and which make Leo not so user friendly. I may be wrong but that's how I feel. I hope that one day you may reconsider some of the design decisions. Vitalije PS: here are quotes from your last message that repeatedly demonstrate this subconscious principle > In particular, it must coexist with Leo's configuration code. > We have to support more complicated ways indefinitely. No way am I going to change uA's without an exceedingly strong reason for > doing so. > They are a fundamental part of Leo and they aren't going away. > Some, like @root, are hidden, but they *must* remain indefinitely > because people still use them. All of Leo's features are the result of specific user requests. This last one is debatable. For example the way that Leo handles settings was not what user wanted. In fact on more than one occasion users asked for something simpler and more familiar. The decision that Leo should handle the settings the way it does can't possibly be motivated by user needs because no other tool handles settings this way. It was motivated only by the (IMO questionable) idea that we can use the same code for reading settings and for reading Leo documents. How many complications this single decision brought is hard to number. It is a complication for the end-users. It also significantly complicates the code. But, we (the users who have learned about at-others and clones), have to live with it. We can't give up on this few brilliant Leo ideas, so we have to live and find our ways to deal with all other obstacles that Leo imposes. -- 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.
