On Sat, Mar 14, 2020 at 9:12 AM vitalije <vitali...@gmail.com> wrote:
The way to achieve this is straightforward but it requires some effort. The > coupled modules should be decoupled as much as possible. From the current > state it is not obvious how decoupling can be achieved, but the decoupling > process must start somewhere. It can't be started unless you as Leo's > creator and main developer do not wish to consider decoupling as a worthy > goal. > Imo, improving Leo's code base is a worthy goal. However, I am not inclined to do it merely to add or improve unit tests. Let me give an example of the unnecessary couplings I have in mind. > > About a year ago, when I was experimenting with the history_tracer plugin, > I wished to create a small window with the scale and a text widget. > Changing the scale widget should show in the text widget the version of the > selected node. I wished to have syntax highlighting in the text widget. > Now, Leo has several classes related to highlighting the source code, but I > could not use any of them. They are all coupled to the commander, so it is > not possible to use them for highlighting anything other but the body > widget. > Yes, this is a problem. At present, the commander is needed to gain access to settings. The idea behind object oriented programing is code reuse. But with the > current implementation of syntax highlighters in Leo the code reuse is not > possible. I had to implement another highlighter if I wanted to make a qt > display widget. > Another idea would be to create a *shim commander* that only provided the necessary "features" of the real commander. The g.TracingNullObject class helps create shim objects. Instead of a valid commander c, use something like: c = g.TracingNullObject(tag='coloring.c') This will show you how the colorizer uses c. It's not guaranteed to work without crashing, but it will provide hints about what is needed in, say, a ShimColorizerCommander class. I really believe that doing decoupling piece by piece, module by module, > can make Leo's code much easier to test and more importantly easier to > (re)use. > I am inclined to agree with you. However, I am not convinced this is the main line of Leo's development. 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/CAMF8tS2CHrV6qpnxd4kUN4axrewV10jGzYLYGcmJOs2wjMZbyg%40mail.gmail.com.
