Cmd+T doesn't toggle TOC back off when in window mode

Bug #1503910 reported by Michael on 2015-10-07
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Undecided
Unassigned

Bug Description

Cmd+T toggles the TOC on and off when in panel mode. Cmd+T opens the TOC when in window mode but pressing it again does nothing instead of toggling it back off like it does in panel mode. Have to switch from keyboard to mouse to get it closed again. Cmd+T should toggle it back off.

Not sure what you mean by panel mode and window mode? For me, that
keyboard shortcut toggles the ToC pnael on/off in both full screen mode
and windowed mode.

 status incomplete

Changed in calibre:
status: New → Incomplete
Michael (mikefm) wrote :

Windowed mode meaning when you click the little button with 2 squares to make the panel float over the main book window in its own window. Here is a screenshot of windowed mode: http://i.imgur.com/56LAO1z.png

Cmd+T no longer works when you open it in windowed mode because the main Viewer window loses focus. I can get Cmd+T to work if I click back on the main Viewer window to put focus back but having to click defeats the purpose of the keyboard shortcut.

Kovid Goyal (kovid) wrote :

I dont see the problem here. No keyboard shortcuts will work when a
different window is focused. And since you just clicked in order to make
the panel float, clicking once more to switch focus back to the main
window is not that big of a burden.

 status wontfix

Changed in calibre:
status: Incomplete → Won't Fix
Michael (mikefm) wrote :

This is no different than how any program with pop-up panels like Photoshop and most graphics programs work or any program with an "inspector" popup window, most would think something was broken if a shortcut only opened the panels but didn't close them without an extra click. The user probably isn't switching between panel and pop-up mode, so that button is only being clicked once. It just seems like it would make sense for the pop-up TOC to close when it receives a cmd+T. The Viewer window never needs to receive the shortcut, it just acts like it did, the user doesn't need to know how it's happening it should just be consistent. .

Michael (mikefm) wrote :

A better way to put it is that it's the box is the same TOC object whether it is anchored or floating. A same window shouldn't have its shortcuts changed simply because it's not anchored any more. It'd be like if ctrl+q for the main Viewer stopped working if you had focus on the panel. That wouldn't make sense and vice versa, they're both part of the same app so the shortcut should work wherever.

Kovid Goyal (kovid) wrote :

On the contrary, having shortcuts from one window operate in another
window is chaos. No one would expect shortcuts from window 1 to work in
window 2, that you would never know what shortcut did what. Showing and
hiding the ToC panel is a function of the main window.

One can certainly argue that it would be nice to have it hide the
floating toc window as well, but, as I said, I dont see what the big
burden is there, since if the floating toc window has focus, it means
you must have cliked on it recently, so another click to close it is not
a big deal.

Michael (mikefm) wrote :

The floating state of the panel is persistent. It only needs to be set to floating once. From then on it can be opened with cmd+t only for the rest of time, the float button never needs to be clicked again.

I fail to see how cmd+t closing the panel whether it is anchored or floating would "create chaos". But if you are concerned about cross contamination and want to treat it as an independent window instead of a detached child of the main window then the user should be able to close it with the standard cmd+W just like any other window at least. To not have any keyboard-only way to close a window is bad from an accessibility standpoint alone. I don't think it's as intuitive as cmd+T for open and close but it does need some way to close via the keyboard.

Kovid Goyal (kovid) wrote :

If you dont open it via a click, it will not have keyboard focus and
therefore the keyboard shortcut will still work, since the main window
will have keyboard focus.

And there is obviosuly no problem of cross contamination when
implementing one shortcut. That comment was simply addressing yours
about the desirability of having keyboard shortcuts work across all
windows.

Finally, at least for me, the standard close window keyboard shortcut
works for all floating windows, including the ToC window.

So, to sumamrize, I have no objection to implementing that particular
shortcut, I just dont see much need for it, since it is only needed if
you give the toc keyboard focus, which can only be done via the mouse,
anyway. Or in other words, the effort for implementing this is not worth
the gain.

However, as I write this, I realize that the effort for implementing it
is probably less than that of arguing with you, so...

Fixed in branch master. The fix will be in the next release. calibre is usually released every Friday.

 status fixreleased

Changed in calibre:
status: Won't Fix → Fix Released
Michael (mikefm) wrote :

>If you dont open it via a click, it will not have keyboard focus and
therefore the keyboard shortcut will still work, since the main window
will have keyboard focus.

The behavior you are describing is not happening on my mac. Even when I don't open with a click the pop up window doesn't respond to any shortcuts, the TOC gets focus whether it is opened with click or keyboard, so that is probably a second part of the bug and why we're seeing different things.

>Finally, at least for me, the standard close window keyboard shortcut
works for all floating windows, including the ToC window.

Again, this might be different on mac, the pop up window responds to nothing, cmd+t nor cmd+w, for me.

Michael (mikefm) wrote :

Great, thank you.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers