right mouse click VS Shift+F10, MenuKey

[BetterRed]

The context menu shown for right click on a field in Book Details is not the same as the context menu shown when Shift/F10 or the Menu key is used on the same Book Details field, viz:



Qt permitting, could the Shift/F10 context menu be made the same as mouse right click context menu.

For me, right click with a mouse is hard enough, on a laptop's trackpad its diabolical… the only gestures I do are two fingered ones

BR

And no, I don't know why I have the book editor configured for DOCX files.

[chaley]

Kovid will know, but I suspect it is hard if not impossible to do. The mouse knows what field it is over so can adapt the menu. The keyboard doesn't (seem to) use the mouse position.

[kovidgoyal]

yeah context menu event is position dependent (aka the menu depends on what you click on). With the keyboard that position is zero IIRC.

[kovidgoyal]

well charles points out that one can avoid the click and allow pressing the context key instead, provided you are willing to move the mouse to the desired location first.

[BetterRed]

Originally Posted by chaley

Kovid will know, but I suspect it is hard if not impossible to do. The mouse knows what field it is over so can adapt the menu. The keyboard doesn't (seem to) use the mouse position.

In my second screen shot, the dots (ants) around DOCX indicate that that's where the keyboard focus lies.

I would have thought the keyboard handler should process Shift/F10 or Menukey down/up interrupts in the same way as the mouse handler handles the right button down/up interrupts… without reference to the mouse location.

Originally Posted by kovidgoyal

well charles points out that one can avoid the click and allow pressing the context key instead, provided you are willing to move the mouse to the desired location first.

Nope - if I hover the mouse over the DOCX and press Shift/F10 I get the same 3 item context menu - Copy, Search, Re-index menu.

BR

[chaley]

Originally Posted by BetterRed

Nope - if I hover the mouse over the DOCX and press Shift/F10 I get the same 3 item context menu - Copy, Search, Re-index menu.

BR

The question:
We can change calibre so that in book details the keyboard context menu request uses the item under the mouse pointer instead of the semi-random position Qt uses. Keyboard focus does not provide this information.

Are you willing/able to move the mouse pointer before you press the context menu key? Do note that you must click somewhere (anywhere) in the book details panel before this will work.

[BetterRed]

Late breaking discovery:

If I backtab into the field e.g. the DOCX, and press Shift+F10 or Menu key I get the full menu. I can live with that workaround, but it suggests it should be fixable for forward tab into a field.

@chaley - using a mouse on a lap mounted Surface Go whilst sitting on the Manly ferry and then the 199 bus to Newport is best avoided… and if not, it would have to be on a leash

BR

[chaley]

Originally Posted by BetterRed

Late breaking discovery:

If I backtab into the field e.g. the DOCX, and press Shift+F10 or Menu key I get the full menu. I can live with that workaround, but it suggests it should be fixable for forward tab into a field.

BR

That doesn't work for me. I see no difference in behavior no matter whether I forward tab or backtab to a field. Glad it works for you. I hope it continues to do so.

[BetterRed]

Originally Posted by chaley

That doesn't work for me. I see no difference in behavior no matter whether I forward tab or backtab to a field. Glad it works for you. I hope it continues to do so.

Works for me on all fields in both detached Book details windows.

• Open one of the detached book details windows
• Tap Tab until I get to the field I want - DOCX has ants
• Tap Tab again - EPUB has ants
• Tap Shift/Tab - DOCX has ants
• Press Shift+F10 or Menukey - et voila the full context menu

Works in calibre 4.3, on my Win10 Dell desktop, and on my Win11 Surface Go.

BR

[chaley]

Originally Posted by BetterRed

Works for me on all fields in both detached Book details windows.

• Open one of the detached book details windows
• Tap Tab until I get to the field I want - DOCX has ants
• Tap Tab again - EPUB has ants
• Tap Shift/Tab - DOCX has ants
• Press Shift+F10 or Menukey - et voila the full context menu

Works in calibre 4.3, on my Win10 Dell desktop, and on my Win11 Surface Go.

BR

As far as I can see the behavior you see is accidental and doesn't always work. Reason: the Qt focus rectangle you see isn't the same size as the underlying hyperlink's click rectangle, but is instead a pixel or 2 larger. However, sometimes the focus point of the rectangle provided by Qt (one corner) is correct in that it is within the hyperlink's click rectangle. I haven't determined how Qt chooses which corner to provide.

If it is working for you when you need it, good.

[BetterRed]

Leaving aside the Tab/Backtab issue, it always works for me, the entire content of the field is always selectable - as visualised by the dotted rectangle surrounding the field.

If I Backtab into a long text field that contains <a ref…> links I can Shift+F10 on the links and open the links. If I Backtab into a Link or Note icon I can do the same, see attached screen shots.

As I wrote in my opening post:

"Qt permitting, could the Shift/F10 context menu be made the same as mouse right click context menu."

I'm at a loss to understand why Qt would do something different if a field is selected via a Backtab as opposed to what it does when the same field was selected a moment earlier via a Tab.

I've given Qt a nickname -- 'Thatcher'!

Curious - did you try the sequence of steps I provided in my last post.

BR

[chaley]

Originally Posted by BetterRed

Curious - did you try the sequence of steps I provided in my last post.

BR

Yes, and several other variants on several fields including formats. The response appeared to be related to whether there is more than one item in the category (2 formats or a link, backtab usually worked) and whether the time of day in seconds is an even number. Sometimes it works with a forward tab, sometimes with a back tab, and sometimes not at all. Publisher seemed to always work.

I worked out what I think Qt is doing and submitted a work-around that Kovid accepted and is now in source. Qt gives a different point in the focus rectangle based on which direction was used to enter the field. It now always works for me. We will see whether or not it works for you or I killed whatever daemon you have in your computer that was working on your behalf.

[BetterRed]

Shift/F10 and Menukey behaves just same in Windows 10 Safe Mode with no plugins, arrive on a Tab no good, arrive on a Backtab all good.

Windows advanced visualisation settings may play a role - mine are:



BR

[chaley]

Originally Posted by BetterRed

Shift/F10 and Menukey behaves just same in Windows 10 Safe Mode with no plugins, arrive on a Tab no good, arrive on a Backtab all good.

Windows advanced visualisation settings may play a role - mine are:

Attachment 205767

BR

I confess to confusion. Are you saying I should take out the changes I made to compensate for Qt behavior verified using changes to calibre code because all is good?

[BetterRed]

My Test library has 89 columns, 14 standard and 75 custom

I just Tabbed and Backtabbed into each one of them, and into various embedded <a ref> links (html, calibre, onenote, mailto, file), Category links and Notes and saw the same phenomena on all of them - select on a Tab: no good - select on Backtab: all good.

BR