Tab Key in Main Window Displays Wrong Title

[Pendragn]

I'm using the main Calibre window to update metadata for my books. When I hit the Tab key to navigate between fields, the cursor moves to the field, but the book displayed at the bottom of the window shows a different book. I need to click out of that field and then back into it to see the preview of the current book entry. Is there a setting I need to change or is this a new bug?

[JSWolf]

Originally Posted by Pendragn

I'm using the main Calibre window to update metadata for my books. When I hit the Tab key to navigate between fields, the cursor moves to the field, but the book displayed at the bottom of the window shows a different book. I need to click out of that field and then back into it to see the preview of the current book entry. Is there a setting I need to change or is this a new bug?

What version MacOS and what version calibre?

[BetterRed]

Originally Posted by Pendragn

I'm using the main Calibre window to update metadata for my books. When I hit the Tab key to navigate between fields, the cursor moves to the field, but the book displayed at the bottom of the window shows a different book. I need to click out of that field and then back into it to see the preview of the current book entry. Is there a setting I need to change or is this a new bug?

I think you found a bug, are you using version 7.23?

I'm another one of the few who edit metadata in the book list the way you describe. F2 into a cell, edit it, Tab to next cell, edit it, Tab . . ., and Enter to exit cell edit mode.

I haven't used it much of late, but its behaving very weirdly, seems to jump back to book at the top of the list. I'll do some more tests and report back.

Just realised I have to go out, so it'll be a while.

BR

[BetterRed]

Quick test - seems to be OK in 7.15, but awry in 7.21 and 7.23.

There was a related bug fix in 7.18

Fix a regression in the previous release that broke using Tab key to move around the book list while editing cells

BR

[BetterRed]

Looks like that fix applied in 7.18 hasn't worked as intended, or Qt threw yet another spanner in to the works, see https://github.com/kovidgoyal/calibr...ad56d160f9bbcb

Basically if the cells of the Nth book in the list are being edited when Tab is pressed to go into next cell the focus shifts to the first book in the list and it sometimes gives focus to a seemingly random cell for that book… on one occasion it popped the long text edit for my Location column.



And, if the DOCX in that first book is open in Word the "File in use" error handler kicks in.

I tested Windows portable versions 7.15, 7.16, 7.17, 7.18, 7.21.101 and 7.23 - the first two were okay, the rest have the problem.

I'll raise a bug report. Done ==>> https://bugs.launchpad.net/calibre/+bug/2092643

BR

[chaley]

The changes are now in calibre source and will be in the next release/preview.

NB: fixing the problems required behavior changes when using Tab while editing. When editing a cell, pressing Tab will move to the next **editable** cell, skipping over readonly columns such as Size and Formats. This is required to convince Qt to keep editing while tabbing. In addition, columns that require opening a dialog (comments, composites, markdown, etc) will be skipped. This is required to avoid opening dialogs on random columns and convincing Qt to keep editing while tabbing.

I'm sure that someone will complain about these changes. Oh well. Working out Qt's behavior has taken too many hours of my life for something I don't care about (I don't edit on the booklist). I'm done. For those who complain, the choices are:

• the original behavior (book details wrong and random dialogs).
• the current behavior in source, described above.
• someone else does the work.

[JSWolf]

Originally Posted by chaley

The changes are now in calibre source and will be in the next release/preview.

NB: fixing the problems required behavior changes when using Tab while editing. When editing a cell, pressing Tab will move to the next **editable** cell, skipping over readonly columns such as Size and Formats. This is required to convince Qt to keep editing while tabbing. In addition, columns that require opening a dialog (comments, composites, markdown, etc) will be skipped. This is required to avoid opening dialogs on random columns and convincing Qt to keep editing while tabbing.

I'm sure that someone will complain about these changes. Oh well. Working out Qt's behavior has taken too many hours of my life for something I don't care about (I don't edit on the booklist). I'm done. For those who complain, the choices are:

• the original behavior (book details wrong and random dialogs).
• the current behavior in source, described above.
• someone else does the work.

Thank you. I appreciate the changes and I like the way you've decided to do this.

[BetterRed]

Originally Posted by chaley

The changes are now in calibre source and will be in the next release/preview.

NB: fixing the problems required behavior changes when using Tab while editing. When editing a cell, pressing Tab will move to the next **editable** cell, skipping over readonly columns such as Size and Formats. This is required to convince Qt to keep editing while tabbing. In addition, columns that require opening a dialog (comments, composites, markdown, etc) will be skipped. This is required to avoid opening dialogs on random columns and convincing Qt to keep editing while tabbing.

I'm sure that someone will complain about these changes. Oh well. Working out Qt's behavior has taken too many hours of my life for something I don't care about (I don't edit on the booklist). I'm done. For those who complain, the choices are:

• the original behavior (book details wrong and random dialogs).
• the current behavior in source, described above.
• someone else does the work.

sounds good to me.

Will cells that require a dialogue box open them when F2 is pressed directly on the cell? Similarly for multi-value cells such as Tags, will they respond to Shift+F2 as they do now?

For me at least, because non editable cells will be skipped by a Tab, rather than behaving like ejector seats, the new behaviour will be better… much better in fact.

Added: I'd be surprised if that isn't true for everyone who uses the book list editing feature more-or-less exclusively as I do.

BR

[chaley]

Originally Posted by BetterRed

Will cells that require a dialogue box, open them when F2 is pressed directly on the cell? Similarly for multi-value cells such as Tags, will they respond to Shift+F2 as they do now?

On cells that aren't open for editing, F2 and keyboard-modifiers+F2 work as before.

When not editing the current cell, Tab goes to the next cell as it did before. If the destination cell is read only then F2 does nothing, as it did before. This means you can avoid skipping over cells while editing by pressing Return to close the editor, pressing Tab to get to the desired cell, then F2. This is a straight-forward way to get to cells that require a dialog without using a mouse.

I considered disabling Tab-to-edit, instead having Tab close the current editor as if Return had been pressed then doing a normal Tab-specified move. In the end I thought it might be a bridge too far, especially given that a user can press Return if that is the behavior they want. It also wasn't obvious how to make it work in all cases.

FWIW: I apologize for my crankiness. My annoyance is mostly with Qt and the difficulty of tracing what seems to be random behavior. It was more fun when I was younger.

[BetterRed]

Portable Version 7.23.101

Tab editing seems to be working fine, I really like the way Read Only cells are skipped rather than terminating the edits, and as predicted I also much prefer skipping Dialogue Edit cells.

I think we've discussed this before and agreed to leave as-is:

If I Backtab (shift+tab) into a multi-value cell… e.g. Tags… the Manage items dialogue pops, i.e. the one that a Shift+F2 pops.

This prompted a thought: If I Backtab into a Dialogue Edit cell (e.g a long text or composite) could it pop the relevant dialogue box. So when I Tab over Location (a sparsely used long text column) and I actually want to enter a Location then I could hit Backtab and the dialogue would pop.

Only if very easily done of course

BR

[chaley]

Originally Posted by BetterRed

This prompted a thought: If I Backtab into a Dialogue Edit cell (e.g a long text or composite) could it pop the relevant dialogue box. So when I Tab over Location (a sparsely used long text column) and I actually want to enter a Location then I could hit Backtab and the dialogue would pop.

I don't agree that this would be good behavior. It is very context dependent and to my mind unexpected. Shift-Tab should backtab in this context, not do anything else.

When doing the work I considered disabling the edit dialogs when the cell was opened with Shift-Tab. The dialog opening always surprised me when testing. There is no way to recover short of Esc then F2. What I wanted was for the inline editor to open so Shift Tab would continue to work. If I wanted the dialog I could hit escape then Shift-F2. The same is true if I want Ctrl-F2. I didn't make these changes to avoid surprising users, but I think I should have.

To get what you want, either:

• Hit Esc then Tab to move into the multi-value cell, then Ctrl-F2.
• Tab to the "cell to far", hit Esc, Shift-Tab to back up as needed, then Shift F2 to open the editor.

This is consistent, predictable behavior.

[BetterRed]

@chaley - I think we're after exactly same thing… consistency.

My recollection is that the popping of the Manage item dialogue when shift-tab is used in edit mode was hard to suppress because of the way QT handles modifier keys. It was never something I wanted.

It annoys me every time I run into it after realising I just made a mistake and try to backtab to the cell in question. And when I checked it today it was in the hope that wouldn't be there, not to make sure it was still there :lol:

I find it hard to believe anyone takes advantage of the 'feature'… we may be the only people who know it even exists.

BR

[chaley]

Because of my changes and Kovid's changes to work around the Qt bug (opening then closing editors) it is now easy to ignore keyboard modifier keys when tabbing during editing. I'll do it.

[chaley]

Originally Posted by chaley

Because of my changes and Kovid's changes to work around the Qt bug (opening then closing editors) it is now easy to ignore keyboard modifier keys when tabbing during editing. I'll do it.

The changes are in calibre source.

[Pendragn]

Sorry, just found time to get back in here after the holidays. I'm using Calibre version 7.23 on macOS Sequoia (15.2).

Chaley, thank you for your hard work! I look forward to seeing the changes in the next update.