After three or four failed attempts, I have finally hit upon a, safe,
methodical strategy that should be guaranteed to work. You can call this an
Engineering Notebook post. Only those directly involved in the
viewrendered plugins need take note.
*A methodical approach*
1. viewrendered.py contains both the VR code base (since it works) and the
VR2 code base as a reference. Initially, all VR2 code was disabled with:
if 0:
# pylint: disable=function-redefined
@others
This makes it possible to use pylint at every step.
2. I carefully merged both ViewRenderedProvider classes into a single
ViewRenderedProvider3 class. I removed the ctor and instantiated it this
way:
provider = ViewRenderedProvider3(c)
free_layout.register_provider(c, provider)
Perhaps more important, there were many copies of two strings,
'_leo_viewrendered3' and 'viewrendered_pane' that *must match* everywhere.
They have now become global vr3_ns_id and vr3_pane_name constants.
3. Now the real work began. For every top-level vr function, I copied the
corresponding vr2 function into the vr node, and carefully compared the
code. The only difference was a slight change in show_scrolled_message.
I've made a note of the change, but for now it has no effect.
4. Similarly, I compared all the top-level commands in the two versions.
Here, there was *no difference at all* between the two sets of functions.
5. Moving on, I compared all the methods of the two ViewRenderedController
classes. The only differences (and this is where *all* the real work will
take place) is in the update methods and the ctors.
So after steps 3, 4 and 5, *almost all* of the code duplication has
disappeared, but nothing has in fact changed.
To handle the two *very different* versions of update, I created a new
update method:
def update(self, tag, keywords):
if VR3:
self.update3(tag, keywords)
else:
self.update1(tag, keywords)
VR3 is the master switch (now off) that will switch between the two sets of
code. update3 is the VR2 version of update, update1 is the VR version.
6. This step is much like steps 3, 4, 5. update1 and update3 have their
own set of helpers. So I moved the update1 and update3 helpers to be a
siblings of update, but I *disabled *the update3 helpers. Since the VR3
switch is off, everything *still* is as in VR.
This is where we are now.
7. The next step will be to merge the update3 helpers into the update1
helpers, using the VR3 switch if necessary. The process will be much like
steps 3, 4 and 5, but we expect real differences. After the grand merge
(there may be complications) the VR3 switches will show *exactly* where
the differences between the VR and VR3 code bases are.
8. Finally, I'll merge the ctors of the two ViewRenderedController classes.
Again, the VR3 switch will highlight the differences.
*Summary*
In a complicated merge like this, the only way forward is to make haste
slowly. The method described depends only on comparing the contents of one
node with another. The best way to do this is to paste the VR2 code into
the VR node, and then compare the two versions line-by-line.
It will soon, at long last, become apparent exactly how VR differs from VR3.
In the process, I saw that there is *no way*, using the present code base,
to allow multiple VR panes in an outline. I'll discuss how to make this
work in another thread.
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 [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.
