On Sat, Apr 26, 2014 at 8:14 AM, 'Terry Brown <[email protected]>' via leo-editor <[email protected]> wrote: > On Fri, 25 Apr 2014 08:13:29 -0700 (PDT) > "Edward K. Ream" <[email protected]> wrote: > >> - This scheme is only useful when multiple Leonine programmers work >> in a non-Leonine project. Solo Leonine programmers in a non-Leonine >> project may as well use @shadow or @auto. > > First off welcome back and good luck with the hips. It was kind of > weired how quiet the forum got after reaching a new high of activity - > I'm way overloaded work-wise at the moment, still using Leo all the > time for doing the work, of course :)
I attribute much of the quiet to your absence ;-) > I was confused by your post until the above statement - so it's > basically about sharing the content of ~/.leo/shadow? But you're > thinking of adding some things, sha1 hash of public files for > example, although what that buys you over existing @shadow I'm not > following. sha1 hashes are merely a way to reliably associate sentinel files with the corresponding public (sans sentinels) files. The details don't much matter. There are subtle differences between this scheme and @shadow. @shadow was only ever intended to be useful for a single Leonine users in a non-Leonine environment. True, multiple Leo users could share their supposedly private (with sentinels) files, but Leo provides no support for such sharing. Sentinels files could be considered a (weak) form of support for sharing for "stealth" Leo users. > Although it would be cool to share other people's views of files, to me > it's not a priority - I could see each of the 3 Leo users in a 7 person > team having their *own* view of the public files all 7 are sharing. > I use the hierarchical bookmark system to have my own view of LeoPyRef > and LeoPluginsRef, for example. In that case, @shadow will do. However, this is not without complications. In particular, Leo users can much more easily rearrange outline structure. The diff-based algorithm that underlies @shadow can't really handle structural rearrangements. So in practice there will be problems (inconveniences at the least) unless all the Leo users use pretty much the same outline structure. This would be more likely if sharing sentinels files were easier. > On the directions for Leo front, supporting Python 3.x / Qt *5*.x > should probably get addressed at some point, even though it's kind of > annoying if we want to keep supporting Qt 4.x simultaneously. > It appears that Riverbank is not making a Python 2.7 Qt 5 combo, so > we'll have to keep 4.x compatibility to go with 2.7. Thanks for reminder. I've just added "add support for Qt 5" to the to-do list. A smallish wrapper class/module should make it possible to use either Qt 4 or 5 without much fuss. Yes, all the Qt-related imports will have to be modified, but it shouldn't be a big deal. 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
