Build 2635 - more navigation options

[mike]

Hi folks!

The first preview build of v1.2.4:
http://magnumbytes.com/downloads/previe ... (2635).zip

There're a few improvements:

• Now NC can restore recently closed panels.
  The "+" (Plus) button in a tabs row now supports a long press, which show a menu with recently closed panels.
  There's also a new Go->Recently Closed navigation menu and "Shift+Cmd+R" hotkey to reopen the last closed panel.
  (viewtopic.php?f=5&t=313 viewtopic.php?f=6&t=337)
• Temporary panels are now 1st class citizens in panels' history.
  (viewtopic.php?f=6&t=84)
• Startup panels restoration was improved - there should be no more "empty" panels after startup.
• Fixed the issue with APFS performance on large files.
  (viewtopic.php?f=5&t=353)
• Fixed the issue with directories overwriting.
  (viewtopic.php?f=5&t=355)
• Fixed the issue with navigation in textfields.
  (viewtopic.php?f=5&t=357)
• SFTP VFS now supports falling back to "rm+mv", when a remote SSH refuses to accept an overwriting rename command.
• Fixed an issue with a residual memory of the QL panel.
  (viewtopic.php?f=5&t=345)
• Fixed an issue of reporting an invalid size in a temporary panel under specific conditions.
• Create Directory dialog now uses a focused file name as a default value too.
  (viewtopic.php?f=6&t=289).

[warpkanal]

Hmm, how could I best describe, can't fully reproduce it...
Tried to close two tabs and then restore both (by hitting the shortcut twice), it worked, but somehow afterwards the restore works erratically, doesn't want to restore a particular folder, then later it restored a folder in a tab although I just closed a tab with another folder
Will see whether I can get this more reproducible...

[warpkanal]

Think I found one reproducible issue: restore-closed-tab is broken (looks like its internal last entry in stack is removed) immediately after invoking sync panels.

[mike]

Ok, my bad, I should have written some clarification on how this "history" works.
Several major points:
- This history is being gathered across all NC's windows.
- When composing a list of candidates for restoration for a window, NC removes any duplication of already existing tabs in the window. So it's possible to see a difference between such lists produced for different windows.
The reasoning here is that you probably don't want to restore something, that you already have in current window.
- After restoring a panel, the according record is removed from the history.
I think this behavior is logical.

[warpkanal]

Understood.
For me it's honestly a bit confusing: closing a tab for folder /a and then doing a tab restoration might then either
a) restore that tab with folder /a (if I have no other tab with /a somewhere open) or
b) do nothing (when I have some tab at /a and have nothing else in the history) or
c) restore a different folder than /a (when I have some tab with /a still open and there are more entries in the history)

I would have expected to behave just like the software where I use tab restoration: a browser (where there is no history manipulation). Pressing Cmd+Shift+T (the standard shortcut in browser for tab restoration) just goes along the history and opens whatever was put on tab close into this history.

For me the current behaviour requires too much thinking to know in advance what will happen when I press the restore shortcut

[mike]

For me it's honestly a bit confusing: closing a tab for folder /a and then doing a tab restoration might then either
a) restore that tab with folder /a (if I have no other tab with /a somewhere open) or
b) do nothing (when I have some tab at /a and have nothing else in the history) or
c) restore a different folder than /a (when I have some tab with /a still open and there are more entries in the history)

Maybe I'm missing something, but isn't it the same logic, with an exception of definition of "somewhere", i.e. current window or all windows?

[warpkanal]

Yes it is the same
I just wanted to show how different the outcomes of tab restoration could be with that algorithm of removing entries from the history.
While in a browser it's pretty straight forward and I immediately know what will happen

Not a big deal for me as I rarely have the same location opened twice, still I personally find this too intelligent, but maybe other users will appreciate it.

[mike]

Ok, I see. So, your suggestion is not to filter history entries regarding of what's currently open, right?

This behavior is an open question, I don't know if there is the "right" way to do it, so it's good to have different opinions.
Probably I was indeed overthinking the problem.

[warpkanal]

So, your suggestion is not to filter history entries regarding of what's currently open, right?

Yes exactly

[warpkanal]

Btw. is there some doc/hints on these "temporary panels"? Never realised such thing exists