Allright, good point, I've just took 30 seconds to make sure of how much does the 'inBridge' is checked in all of leo, seems to be relevant to LeoInteg only in getScript. (Doh! Why didnt I check that before?!?)
So i guess your suggestion totally makes sense : I'm going to override getScript in leoGlobals on top of overriding the wrapper (I re-use the WrapperApi class as-is and replace some of its members in the most easy and lazy way possible : the standard programmer's way ) Thanks for those helpful tips ! -- Félix On Sunday, September 27, 2020 at 4:54:05 PM UTC-4, Edward K. Ream wrote: > > On Sun, Sep 27, 2020 at 3:15 PM Félix <[email protected] <javascript:>> > wrote: > > [The problem is] that methods in Leo (such as getScript in leoGlobals.py) >> consider important to check if they're in leoBridge (!), even if they also >> check if the wrapper is available on the frame.body ! (see line 14 of >> getScript in leoGlobals.py) >> > > It's possible that g.getScript has this weird check because of the console > gui. > > wadaya think? >> > > Perhaps I misunderstood you. The general idea was to leave Leo's core > unchanged, but call it with g.app.inBridge = False. That's all the wrapper > does. > > How general is the problem? If it's only a few methods/functions, the > patching technique I discussed could be used to patch g.getScript (and any > other pesky methods/functions) to your liking. > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/72925957-5e92-4917-93b8-ad895f549ef1o%40googlegroups.com.
