On Feb 15, 9:19 am, "Edward K. Ream" <[email protected]> wrote:
Again: this post will be of interest only to those with a deep interest in Leo's implementation. Feel free to ignore. > Rev 4985 completes the first draft of the new_config code. > Init code will never be easy, but this new code is about as easy as > straightforward as it is possible to imagine. I spent all day yesterday attempting to integrate the new code into Leo. The code itself is straightforward, but that is of little help: then environment into which the new code must be fitted is truly difficult. As a preliminary measure, I added an important new tool: the g.trace_startup switch. This switch enables traces in all significant parts of Leo's startup code. So now I can compare the code that works (g.new_config = False) with the code that doesn't (g.new_config = True) and see exactly what the differences are. Aside: defining global switches in leoGlobals.py rather than leoApp.py is one of those "small" improvements that has had an immediate impact. I toggle these switches *directly* simply by altering the source code. It turns out this is the simplest way. The recent "developmental unit test for the new_config code sets and restores the g.new_config switch, which was very handy. There are two possible approaches to initing Leo properly: 1. The old (and future?) way: read each local .leo file twice, first using a null gui, and then with the qt gui to create the actual commander used throughout Leo. The easy way to do this is in a separate pass, so that the "pre-load" code is relatively disentangle with g.openWithFileName and g.app.newLeoCommanderAndFrame. The problem then becomes associating preloaded settings with the commanders that will be loaded later. Problems doing this are behind but 568452: "file local @settings ignored if file opened from command line with absolute path." This can be done in a foolproof manner as follows. The early startup code will create a FileInfo object for each local .leo file on the command line. Leo will use the list of FileInfo objects to pre-load files *and* to call g.openWithFileName. Pre-loading a file will set an ivar in the FileInfo object to the created settings dicts, so there is no possibility of mis-associating configuration settings with loaded commanders. End of bug. 2. The ambitious way. You would think it would be possible to load a .leo file in a single pass, and that is still my goal. However, there are severe practical difficulties with this approach. It implies altering what might be the most fragile part of Leo, namely the exact sequence in which Leo's most basic classes get initialized. Adding additional complexity to this part of the startup code merely for the sake of avoiding reloads (which after all are mostly cached) may be too ambitious. Still, I am going to continue experimenting with this approach. It may be that I can discover an organizing principle that simplifies this part of the load process. Alas, the "no calls to g.config.getX until finishCreate time" isn't enough. The problem is that the labyrinth of init code make it difficult to implement *any* strategy. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
