Category Ranges in Tag Browser

[BetterRed]

Is there a way to NOT have the first letter groupings in the Tag Browser, e.g. F-H, P-S etc Ψ³

<snark deleted>

BR

[theducks]

You want to Disable it? No letter level That is a lot of scrolling
(I tried tapping a letter to see if it would jump to the first (Ln) use. )

Preferences: Look & Feel: Partitioning method: disable

[chaley]

Originally Posted by BetterRed

Is there a way to NOT have the first letter groupings in the Tag Browser, e.g. F-H, P-S etc Ψ³

Seems like an unnecessary adornment to me, especially for something that lacks the basic functionality of being accessible via the <expletive deleted> keyboard.

BR

Set Preferences / Look and feel / Tag browser / "Combine letters when fewer items than" to zero

[BetterRed]

Originally Posted by chaley

Set Preferences / Look and feel / Tag browser / "Combine letters when fewer items than" to zero

Thanks - can I suggest you put something like "Set to 0 if you don't want letters combined." in the tool tip.

I normally avoid using Tag Browser, but there are occasions when its the only viable choice.

I think all I want is a way to give the tree focus (mouse click would be okay), navigate with 'up', 'down', 'right, 'left', 'home', and 'end'; expand/collapse branches with '+' and '-'; and the context menu key on branch and leaf nodes.

BR

[ownedbycats]

The letter grouping was my idea Sorry

[chaley]

Originally Posted by BetterRed

I think all I want is a way to give the tree focus (mouse click would be okay), navigate with 'up', 'down', 'right, 'left', 'home', and 'end'; expand/collapse branches with '+' and '-'; and the context menu key on branch and leaf nodes.

BR

I think I can do this. Kovid is OK with it as long as the tag browser doesn't steal the focus at odd times such as when a dialog completes. My problem is a) testing that it is sufficiently complete to be useable, and b) that Kovid's condition isn't accidentally violated.

The goal: allow the tag browser to have keyboard focus. It would get it by clicking on something, or by using a keyboard shortcut I am adding. SHIFT-ESC returns the focus to the library view (an existing modifiable shortcut). Once there the arrow keys move up, down, in, and out of categories. The return key would "toggle" (search) the current item. The space key would open the context menu, which would also get the keyboard focus.

Do/can you run from source? That would make testing much easier and more complete, and avoid releasing something that is suboptimal.

*Expanded question*: does anyone who would use this run from source?

[BetterRed]

Originally Posted by chaley

I think I can do this. Kovid is OK with it as long as the tag browser doesn't steal the focus at odd times such as when a dialog completes. My problem is a) testing that it is sufficiently complete to be useable, and b) that Kovid's condition isn't accidentally violated.

The goal: allow the tag browser to have keyboard focus. It would get it by clicking on something, or by using a keyboard shortcut I am adding. SHIFT-ESC returns the focus to the library view (an existing modifiable shortcut). Once there the arrow keys move up, down, in, and out of categories. The return key would "toggle" (search) the current item. The space key would open the context menu, which would also get the keyboard focus.

Do/can you run from source? That would make testing much easier and more complete, and avoid releasing something that is suboptimal.

*Expanded question*: does anyone who would use this run from source?

Thanks a lot for looking into this.

I don't run from source - but I guess I could for this. Be good if someone who normally does run from source could also test. Being of the 'near enough is good enough' school, I don't regard myself as a 'good' tester.

To help allay Kovid's concerns: How about an additional setting in Look & Feel->Enable tag browser keyboard interaction which defaults to unchecked, and/or only enable keyboard interaction if the new Focus the tag browser shortcut is used.

"The space key would open the context menu…" - I would much prefer to use the 'normal' context menu keys, i.e. the one that's normally next to the right Ctrl key, or Shift+F10. Also in other trees the space bar does nothing or does what a left mouse button click does - e.g. file managers show folder contents in main panel.


Aside: something I noticed a long time ago - Ctrl+Esc and Alt+Esc are the default shortcuts for Clear the virtual library and Clear the additional restriction, but Windows uses them to pop the Start Menu and switch between active tasks, and they takes precedence. There maybe other clashes I've not noticed.

BR

[chaley]

Originally Posted by BetterRed

I don't run from source - but I guess I could for this. Be good if someone who normally does run from source could also test. Being of the 'near enough is good enough' school, I don't regard myself as a 'good' tester.

On the other hand, you would use it and you care.

To help allay Kovid's concerns: How about an additional setting in Look & Feel->Enable tag browser keyboard interaction which defaults to unchecked, and/or only enable keyboard interaction if the new Focus the tag browser shortcut is used.

I haven't found a way to enable/disable keyboard interaction on the fly reliably.

As for the setting: yes, one is necessary. I had been leaning toward a tweak because it is certainly set-and-forget, but am coming around to an option for discoverability.

"The space key would open the context menu…" - I would much prefer to use the 'normal' context menu keys, i.e. the one that's normally next to the right Ctrl key, or Shift+F10. Also in other trees the space bar does nothing or does what a left mouse button click does - e.g. file managers show folder contents in main panel.

This is exactly why I need someone who cares. I don't think I have ever pushed that "Menu" key in my life, and I didn't know about Shift+F10. Fortunately, Qt knows and they already work. I will take out the repurposing of the space key.

Aside: something I noticed a long time ago - Ctrl+Esc and Alt+Esc are the default shortcuts for Clear the virtual library and Clear the additional restriction, but Windows uses them to pop the Start Menu and switch between active tasks, and they takes precedence. There maybe other clashes I've not noticed.

This kind of thing happens all the time with other characters. Some programs, for example the Intel Graphics Manager, allow hijacking keys. I don't think it is possible to make default assignments that won't conflict somewhere.

I don't intend to provide a default binding for "Give TB the focus". I am using ALT-B for testing.