Thanks Vitalije, Edward and Terry for this discussion, I can go into code details and so, maybe at that level your points are valid. From the user experience, I would say that using trees to setup themes is cumbersome (and preferences and to enable/disable plugins). Maybe there is and important principle there, but exposing Leo potential users to all this complexity (particularly the non-programmers) could result in a lot of incidental complexity. Something with check boxes and scrolling menus and options (like atom and tools alike) could help with settings and plugins use and discovery and may simplify underlying code.
This thread reminds me of the 20K lines of code principle for human understandability of software systems [1] and the Smalltalk culture of fighting actively against incidental complexity (see [3], for example). Of course this is not easy, but any discussion and action in this line should be visible and supported. [1] https://news.ycombinator.com/item?id=3291085 [2] http://www.vpri.org/pdf/tr2011004_steps11.pdf [3] http://cuis-smalltalk.org/ Cheers, Offray On 27/04/18 13:53, vitalije wrote: > > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 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.
