> > If, as you assert, the "user will notice nothing", then how can the new > behavior possibly solve such problems? > > I meant to say: users are supposed to notice that Leo works better but they won't have to do anything to have this improvement.
> > So I have chosen the BreezeDarkTheme for my preference and now I can't > edit myLeoSettings without loosing my preferred look and feel. > > I don't have this problem. My copy of myLeoSettings.leo contains: > > @string theme-name = EKRWindowsDark > > Am I correct in assuming your myLeoSettings.leo contains: > > @string theme-name = BreezeDarkTheme? > > Yes you are correct. But I probably have some remaining settings from the previous ways of configuring the look and feel. I know what I have to do. I have to re-create myLeoSettings from the empty outline copying one by one setting and reloading Leo to see which settings are causing this issue, but as I said I am a bit reluctant to take such an effort because of many painful experiences I had with the changing myLeoSettings. My point was that those additional required steps that I have to do to fix my Leo are introduced just by updating Leo. I guess there are other users like me who just can't find enough will power to enter the settings battle again. But I am afraid that there might be even more users who just gave up Leo after encountering these kind of problems. > Another example quite recent is introducing new dock layout. As you can >> see from the previous screenshots my preference is to have outline in the >> top left and log underneath, and body on the right. Recently when I updated >> Leo, docks were introduced and I couldn't find the way to layout the docks >> to look like the screenshot above. So, I had to change all my Leo launchers >> to add --no-dock argument. >> > > You probably have to make the body pane the central widget: > > @string central-dock-widget = body > > Probably, but it would again require more of my time to tweak myLeoSettings.leo having to reload it all the time. I might do this, but I prefer to wait until it is stabilized. My point is, you have many times introduced changes that required users to >> change their settings or to give up updating Leo. >> > > Adding docks to Leo was a major change. --no-docks makes it possible to > use Leo exactly as before. We spent weeks fixing bugs in the new code. You > could have asked for help at any time during this process. > > > I'm not sure why you have such problems with your settings. It should be > possible to fix them with Leo as it is. > > I am not saying it is impossible. It just takes time and effort which I am not so eager to put into the tweaking my settings now. If it was possible for me to change setting central-dock-widget with a menu or even through executing minibuffer command I would have tried this. If it was possible for me to change theme setting in the menu or executing minibuffer command I would have tried this. Maybe it takes just to add two headlines to my settings file, but I am not sure. In my experience it might just turn into an hours long session of fixing some visual issues. That is the reason I rather choose not to follow this path. The real issue here is not my configuration problems. I am more concerned with the other users especially new ones. You have argued that introducing a cache potentially can cause some >> confusion. Well I can agree that it is a possibility. But Leo already uses >> cache. >> > > Yes, Leo does use a cache. --trace=cache will show you what it contains. > I've been looking at that a lot recently while I worked on the gui (global > docks) branch. At present, his cache is relatively benign because: > > I was not talking about that cache. My point here is that c.config and g.app.config are caches in a nutshell. Leo doesn't read and scan outlines each time it needs particular setting value. Instead it retrieves this value from the g.app.config and c.config. So your point that my idea is to introduce cache is not relevant. Leo already uses cache for configuration, although I would say not very efficient one. > > When it needs a value of some setting it doesn't read all those outlines >> again and doesn't parse them again to retrieve the value, but instead it >> retrieves the value from the cache that was built during the startup. The >> difference is when this cache is built. >> > > I am not convinced that this is an improvement. See below. > > In my idea it is built (and updated too) whenever user changes any >> setting, and not during the startup. >> > > At present, the user "changes" a setting only when saving an outline > (including leoSettings.leo and myLeoSettings.leo). As you imply, this does > not immediately update Leo's internal settings data. > > But it could if the settings are handled differently. > That is why if implemented my idea will help to make things easier for >> users and allow them to see the effect of their changes immediately and not >> after the next reload. It would remove a lot of confusions that Leo at the >> moment imposes on users. >> > > The reload-settings and reload-all-settings do (supposedly;-) update all > settings data. > > I have just tested that reloading all settings won't change theme. You can say that is how it is supposed to work. But for me this is a bug. If we just put aside question how Leo should handle settings for a moment. Telling user that it is impossible to change theme on the fly because it is technically impossible to achieve this is a bit awkward and false. The sizes, colors, and fonts can be easily changed and immediately visible in PyQt widgets. The fact that we, Leo developers, can't deliver that feature to the Leo users is something we should be ashamed of. The reason why we can't deliver it lays in an inadequate way how Leo handles its own configuration. > If settings were the *only* thing that mattered, then these commands > should (in theory), suffice. Yes, in practice, there could be bugs. > > As I said there are bugs. > However, settings are *NOT* the only things that matter. Settings, > especially theme-related settings, and plugin-related settings, have side > effects throughout Leo. Imo, your proposal has *no chance* of mitigating > these side effects. > > Maybe not directly, but through simplifying startup code, chances of fixing those problems are increased. > >> Imo, putting all of Leo's settings into the cache accomplishes virtually > nothing. It will add code that must be debugged. Any discrepancy between > the cache and settings in the various Leo file will lead to unbounded > confusion. > > On the contrary in the present scheme there are constant discrepancy between the cached c.config and g.app.config settings and the values user sets. That is why Leo requires restart to pick up the changes. > The fundamental problem with this proposal is that* no caching scheme can > undo side effects arising Leo's myriad settings:* > > *- *If reload settings doesn't work, neither will updating cached setting. > You are right just updating cached settings is not the full solution, but it is necessary precondition to make reload settings mightier. It would require some more refactoring in other parts of Leo to use config cache more efficiently. Anyway reload-settings should change the theme at the minimum. I have rejected them for the reasons stated. To summarize: > > - Caching settings creates the potential for serious confusion. > You haven't shown any evidence to support this claim. And I say that serious confusion already exists in the way Leo handles settings. - I particularly want to minimize the size of the cache. > Interesting. What is the point of this particular wish? Have you encounter any cache-size related issues? Has anybody complained about large cache? - *Caching settings can not undo side effects.* > Leo's reload-settings command shows what is, and isn't, possible. > The *only* way to be sure of the effects of changing a settings is to > reload Leo fully. > > Yes at the moment, but I wouldn't call it a feature, but rather a bug. Side effects should be minimized. But I must say again. There is no valid reason that changing widget sizes, fonts and colors requires restart. 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/8e781b7f-4761-4b58-99d8-4d6debe81a13%40googlegroups.com.
