is g.app.commanders filled up with commander(s) that are opened with leoBridge?

[Félix]

Perhaps I should have made more research before asking about those things but i'll ask anyways - sorry in advance if this is basic stuff...  (multiple opened file support is  the last major feature of leointeg to be done, the rest is trivial... So i'm tempted to ask questions instead of studying the problem for a longer time because i'm eager to finish! )

I've made sure to comment out my override of g.app.commanders in the __init__ of LeoBridgeIntegController.

and then, I start my 'openFile' method in leobridgeserver.py as usual, but I added a printout of the g.app.commanders this way: 

def openFile(self, p_file):

'''Open a leo file via leoBridge controller, or create a new document if empty string'''

self.commander = self.bridge.openLeoFile(p_file) # create self.commander

# did this add ato existing array of g.app.commanders() ?

print(str(self.g.app.commanders())) # test

but the print outputs an empty array : [ ]...  !

I'm still trying to untangle the concepts of window, frame, commander ... they're all somewhat synonyms in my mind : "an opened Leo document" so its taking me a long time hehe.. also trying to get a good grip of what are 'containing/pointing to' those things.

I'm also trying to figure out if files opened via leoBridge would still fill up this array, and also i'm trying to figure out if when starting a bridge like this: 

self.bridge = leoBridge.controller( blabla.... )

does this open up all the 'current / recent) leo files that opening normal leo would and place the controllers of all those leo files visible in g.app.commanders() ? 

[Félix]

i'm in the middle of a heat wave here in montreal and there's noisy construction work in my street today. So my concentration and productivity levels are quite low !! :(

[Edward K. Ream]

​

On Mon, Jun 22, 2020 at 12:54 PM Félix <felix...@gmail.com> wrote:

 (multiple opened file support is  the last major feature of leointeg to be done, the rest is trivial...

Really? What about syntax coloring?

So i'm tempted to ask questions instead of studying the problem for a longer time because i'm eager to finish! )

...I start my 'openFile' method in leobridgeserver.py as usual, but I added a printout of the g.app.commanders this way...but the print outputs an empty array : [ ]...  !

Hmm. g.app.windowList was not populated when using the bridge. But now it is. See below.

Here is my test file, in c:\test\bridgeTest.py:

import leo.core.leoBridge as leoBridge
import leo.core.leoGlobals as g

path = r'c:\leo.repo\leo-editor\leo\core\LeoPyRef.leo'
assert g.os_path_exists(path)

controller = leoBridge.controller(gui='nullGui',
    loadPlugins=False,  # True: attempt to load plugins.
    readSettings=True, # True: read standard settings files.
    silent=False,      # True: don't print signon messages.
    verbose=False)     # True: print informational messages.

g = controller.globals()
c = controller.openLeoFile(path)
g.printObj(g.app.windowList, tag='g.app.windowList')
g.printObj(g.app.commanders(), tag='g.app.commanders()')

You can run this directly from python, or from this Leo script:

path = r'c:\test\bridgeTest.py'
assert g.os_path_exists(path)
g.executeFile(path)

A cff shows that only qtFrame.finishCreate appends 'self' to g.app.windowList. Let's have nullFrame do the same. In NullFrame.ctor I added these lines:

# Leo 6.3: support for leoInteg.
g.app.windowList.append(self)

Well, that failed (details omitted). Boo hoo.

Let's try setting g.app.windowList in leoBridge.openLeoFile:

c = self.createFrame(fileName) # existing code
# Leo 6.3: support leoInteg.
g.app.windowList.append(c.frame)

Success! Now the test program prints:

g.app.windowList:
[
    <leo.core.leoFrame.NullFrame object at 0x0000022C4166E608>
]
g.app.commanders():
[
    Commander 2389099200456: 'c:/leo.repo/leo-editor/leo/core/LeoPyRef.leo'
]

The new code is at rev 3f19711 in devel.

I'm still trying to untangle the concepts of window, frame, commander ... they're all somewhat synonyms in my mind

They are not synonyms, but they are interconnected.

Commanders always exist. A commander represents all the data of an outline (.leo file).

c.frame is the (gui) frame associated with the commander/outline/.leo file. Window is a gui-only concept. You can forget about it.

Summary

leoBridge.openLeoFile now supports leoInteg by setting g.app.windowList, thereby also causing c.commanders() to return the list commanders opened by the bridge.

Note 1: Closing a commander will not update g.app.windowList. Indeed, the bridge has no closeLeoFile method. That may not actually be a problem. I don't see any reason ever to close a .leo file in the bridge.

Note2: leoBridge.openLeoFile will return an already-open commander if it has been opened previously. Closing the commander would interfere with this.

HTH.

Edward

[Félix]

Holy sh*t, you're a machine!!

[Félix]

Tested: it works ! 

THANKS! I don't need all that stuff at around line 430 of the server anymore: 

self.g.app.commanders = self._commanders

def _commanders(self):

''' Return list of currently active controllers '''

# TODO : REVISE/REPLACE WITH OWN SYSTEM

# return [f.c for f in g.app.windowList]

return [self.commander]

Everything makes sense now! I knew there was something not right between the way I though things were suppose to work, how they really were supposed to work, and the way they actually work. 

Those three things are now one. 

...So I guess I'm going back to the workbench to finish some of the basic multi file support for real this time! :)

Félix

[Félix]

Note 1: Closing a commander will not update g.app.windowList. Indeed, the bridge has no closeLeoFile method. That may not actually be a problem. I don't see any reason ever to close a .leo file in the bridge.

(Not tested yet: ) Would that perhaps 'trip'  the derived file detection for closed files that would still be listed by commanders() when the efc does his cycles... or maybe efc checks a 'closed' flag that is set on a commander that were .close() considered 'closed'? Just thinking out loud here...

[Félix]

just checked the code of idle_check_commander and it does not care, i guess this will trip the efc checks... -but its a simple problem to solve: I'll just add/set a 'closed' flag myself to commanders upon opening them. this will be simple, easy to implement, and enough to prevent tripping the derived files changed popup for 'closed' leo files. 

so its all good :)

Félix

[Edward K. Ream]

On Mon, Jun 22, 2020 at 5:56 PM Félix <felix...@gmail.com> wrote:

Tested: it works ! 

THANKS! I don't need all that stuff at around line 430 of the server anymore: 

You're welcome. Glad to hear the change was useful.

Edward

[Edward K. Ream]

On Mon, Jun 22, 2020 at 8:26 PM Félix <felix...@gmail.com> wrote:

Note 1: Closing a commander will not update g.app.windowList. Indeed, the bridge has no closeLeoFile method. That may not actually be a problem. I don't see any reason ever to close a .leo file in the bridge.

(Not tested yet: ) Would that perhaps 'trip'  the derived file detection for closed files that would still be listed by commanders() when the efc does his cycles... or maybe efc checks a 'closed' flag that is set on a commander that were .close() considered 'closed'? Just thinking out loud here...

Good questions. I don't know the answers.

Edward

[Edward K. Ream]

On Mon, Jun 22, 2020 at 8:39 PM Félix <felix...@gmail.com> wrote:

just checked the code of idle_check_commander and it does not care, i guess this will trip the efc checks... -but its a simple problem to solve: I'll just add/set a 'closed' flag myself to commanders upon opening them. this will be simple, easy to implement, and enough to prevent tripping the derived files changed popup for 'closed' leo files. 

so its all good :)

Good job.

Edward