Improving window-handline commands

[HansBKK]

Not complaining, don't consider these "bugs" except perhaps the first one but it's a trivial one. Just suggestions to take on board when looking at these issues in the future, thought better to solicit discussion rather than posting to the tracker.

- When I've only got two body panes open, and execute delete-editor Leo should simply close the one it can, independent of the current pane focus.

- I've bound F11 to support "fully expand body pane", but haven't found a command to reverse this, IOW get back to the previous state.
  - Ideally F11 could be bound to these two as a toggle, as is the case with every browser I've used in the past few years
  - therefore should be Leo default as a common/sane UI keybinding

- Somewhere I've seen screenshots of "modal" windows in Leo (is that the right term for "detached"?). I'd like to keep the primary node I'm currently working on as "stable" in a separate window, while the normal 3-pane view is used for navigating the outline, browsing secondary nodes.
  - I assume opening another Leo window will result in possible last-saved data loss rather than just being window instances maintaining the same file state?

- Right now can I can cycle between body editors
  - Ctrl-Tab should be a sane default for this
  - but ideally I should be able to bind it to a command that also includes the outline in the cycle

TIA

[Edward K. Ream]

On Tue, Dec 13, 2011 at 11:58 PM, HansBKK <han...@gmail.com> wrote:
> Not complaining, don't consider these "bugs" except perhaps the first one
> but it's a trivial one. Just suggestions to take on board when looking at
> these issues in the future, thought better to solicit discussion rather than
> posting to the tracker.

Thanks for these suggestions. Given my schedule, I am not likely to
get around to these any time soon. So creating wishlist items may be
best, after our discussion finishes.

> - When I've only got two body panes open, and execute delete-editor Leo
> should simply close the one it can, independent of the current pane focus.

I agree, but the present code is wretchedly complex. Iirc, I had an
idea to use Terry Brown's new free_layout code to embed body text
editors, but nothing has come of that at present.

> - I've bound F11 to support "fully expand body pane", but haven't found a
> command to reverse this, IOW get back to the previous state.
>   - Ideally F11 could be bound to these two as a toggle, as is the case with
> every browser I've used in the past few years
>   - therefore should be Leo default as a common/sane UI keybinding

Good idea. Please file a wishlist bug.

> - Somewhere I've seen screenshots of "modal" windows in Leo (is that the
> right term for "detached"?). I'd like to keep the primary node I'm currently
> working on as "stable" in a separate window, while the normal 3-pane view is
> used for navigating the outline, browsing secondary nodes.
>   - I assume opening another Leo window will result in possible last-saved
> data loss rather than just being window instances maintaining the same file
> state?

Yes. A bug has been filed about that issue. I consider it a
high-priority bug, but I'm not sure how to fix it.

> - Right now can I can cycle between body editors
>   - Ctrl-Tab should be a sane default for this
>   - but ideally I should be able to bind it to a command that also includes
> the outline in the cycle

You can do this now with the tab-cycle-next or tab-cycle-previous commands

Edward

[HansBKK]

Thanks for the very helpful clarifications.

On Wednesday, December 14, 2011 7:32:16 PM UTC+7, Edward K. Ream wrote:

> - Somewhere I've seen screenshots of "modal" windows in Leo (is that the
> right term for "detached"?). I'd like to keep the primary node I'm currently
> working on as "stable" in a separate window, while the normal 3-pane view is
> used for navigating the outline, browsing secondary nodes.

I don't know if the above is a separate issue or closely related to the below - rather more relevant for me, if it's already been logged to the tracker I'll never mind. . .
 

>   - I assume opening another Leo window will result in possible last-saved
> data loss rather than just being window instances maintaining the same file
> state?

Yes.  A bug has been filed about that issue.  I consider it a
high-priority bug, but I'm not sure how to fix it.

Is it as difficult to have Leo prevent opening the second instance, or at least throw up a warning to the user?

[Edward K. Ream]

On Wed, Dec 14, 2011 at 9:24 AM, HansBKK <han...@gmail.com> wrote:

> Is it as difficult to have Leo prevent opening the second instance, or at
> least throw up a warning to the user?

Most other editors can detect when another copy is running. So it's
possible. I just don't know how to do it yet. That's the only
problem.

EKR

[Terry Brown]

On Tue, 13 Dec 2011 20:58:33 -0800 (PST)
HansBKK <han...@gmail.com> wrote:

> - Somewhere I've seen screenshots of "modal" windows in Leo (is that the
> right term for "detached"?). I'd like to keep the primary node I'm
> currently working on as "stable" in a separate window, while the normal
> 3-pane view is used for navigating the outline, browsing secondary nodes.

Modal refers to windows which block input to all other windows while
they're open.

Leo body pane windows can be detached with the Alt-X stickynote
command, if the stickynotes plugin is enabled. Detached windows are
simple plain text editors, no syntax highlighting. I was going to say
no Leo key bindings either, but I'm not sure if that's still the case
after recent key handling changes.

> - I assume opening another Leo window will result in possible last-saved
> data loss rather than just being window instances maintaining the same file
> state?

Right, if you have more than on Leo open they will attack each other :-)

Cheers -Terry

[HansBKK]

On Wednesday, December 14, 2011 10:21:13 PM UTC+7, Terry wrote:
> Modal refers to windows which block input to all other windows while they're open.

Thanks for the clarification.

Leo body pane windows can be detached with the Alt-X stickynote
command, if the stickynotes plugin is enabled.

I'm avoiding using plugins while I'm still such a **total noob** (aargh) at figuring such basics as to why I'm losing hours' worth of work (OT - later)

 

Right, if you have more than on Leo open they will attack each other :-)

If this is difficult to do within Python - I assume because it requires poking into underlying OS-platform-specific stuff - then what about letting OS-specific "launch wrappers" handle it? Hang on a minute. . .

OK, I've just written an AutoHotKey script to launch Leo that looks for the string ".leo" in window titles and if found, pops up "are you sure?" with a list of the window titles currently open. Obviously platform-specific, but works-around for me for now, and only took 5 minutes, including looking up code samples at the AHK web-site. . .

I reckon the Linux people would take less time than that to put together a sample script to do the same thing.

I can see where one wouldn't want to pollute the Python-purity with this sort of platform-specific kludge, (plug-out's?) but if they're made available outside of the main program and are easily adaptable by the end-user. . .

[Edward K. Ream]

On Wed, Dec 14, 2011 at 8:08 PM, HansBKK <han...@gmail.com> wrote:

> I'm avoiding using plugins while I'm still such a **total noob** (aargh) at
> figuring such basics as to why I'm losing hours' worth of work (OT - later)

That's why Bug "711158: Warn if same .leo file open in another Leo
instance" has high priority.

> If this is difficult to do within Python - I assume because it requires
> poking into underlying OS-platform-specific stuff - then what about letting
> OS-specific "launch wrappers" handle it?

It is easy to do in pure python: just maintain a "lock" file, say
~/.leo/open_leo_files, and warn if the to-be-opened file is mentioned
in the lock file. A common file should be safe enough because
concurrent access can't happen.

However, before doing even this much work I would like to be sure that
no simpler way exists.

Edward

[Terry Brown]

On Wed, 14 Dec 2011 17:08:35 -0800 (PST)
HansBKK <han...@gmail.com> wrote:

> > Right, if you have more than on Leo open they will attack each other :-)
> >
> If this is difficult to do within Python - I assume because it requires
> poking into underlying OS-platform-specific stuff - then what about letting
> OS-specific "launch wrappers" handle it? Hang on a minute. . .
>
> OK, I've just written an AutoHotKey script to launch Leo that looks for the
> string ".leo" in window titles and if found, pops up "are you sure?" with a
> list of the window titles currently open.

Cool. I don't think it's that hard to make a cross platform solution,
one approach is to have Leo write its pid (process ID) to a file in
the .leo directory, and erase it when it exits. And check for it being
there already when it starts, of course. VNC, GoogleEarth, Chrome,
OpenOffice, all seem to take this approach.

The added nicety would be bringing the pre-existing Leo to the front.
The approach used in the leoserver plugin is a general solution for
remote control of a running Leo, but for this particular case a
lightweight use of http://docs.python.org/library/signal.html might be
ok - it doesn't say anything about not being available in Windows.

Cheers -Terry

[Edward K. Ream]

On Thu, Dec 15, 2011 at 9:55 AM, Terry Brown <terry_...@yahoo.com> wrote:

> one approach is to have Leo write its pid (process ID) to a file in
> the .leo directory, and erase it when it exits.  And check for it being
> there already when it starts, of course.  VNC, GoogleEarth, Chrome,
> OpenOffice, all seem to take this approach.

Good. That's what Leo will do.

> The added nicety would be bringing the pre-existing Leo to the front.
> The approach used in the leoserver plugin is a general solution for

> remote control of a running Leo.

Do you mean leoremote.py?

Edward

[Terry Brown]

On Thu, 15 Dec 2011 10:48:44 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> > The added nicety would be bringing the pre-existing Leo to the front.
> > The approach used in the leoserver plugin is a general solution for
> > remote control of a running Leo.
>
> Do you mean leoremote.py?

Indeed I do - everyone please revise their recollections of my posts
for the last few weeks to replace 'leoserver' with 'leoremote' :-}

Cheers -Terry

[Edward K. Ream]

On Thu, Dec 15, 2011 at 11:10 AM, Terry Brown <terry_...@yahoo.com> wrote:

>> Do you mean leoremote.py?
>
> Indeed I do - everyone please revise their recollections of my posts
> for the last few weeks to replace 'leoserver' with 'leoremote' :-}

I am going to study leoremove first. It seems like a more general
solution than low-level signals, however wrapped by Python.

EKR

[Edward K. Ream]

On Thu, Dec 15, 2011 at 11:24 AM, Edward K. Ream <edre...@gmail.com> wrote:

> I am going to study leoremove first.  It seems like a more general
> solution than low-level signals, however wrapped by Python.

And everybody please change leoremove to leoremote.

EKR

[Terry Brown]

On Thu, 15 Dec 2011 11:24:43 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> I am going to study leoremove first. It seems like a more general
> solution than low-level signals, however wrapped by Python.

I think that's true - but if it's going to be the mechanism for
tracking running Leo's it would need to be enabled by default, which is
ok.

Currently starting Leo again with leoremote enabled in both instances
tends to mess up the leoremote functions, you seem to end up with
neither Leo responding. But of course this new code would address that.

leoremote is the basis for my scripts `led`, `lo`, and `sn`, which,
from the command line, load a file into the running Leo, load an
outline into the running Leo, and create a stickynote in the running
Leo. They're either on the wiki or in the contrib branch.

Cheers -Terry