**Conditions** - enable the sidebar - in the sidebar: enable the tab with the title `Symbols` and the tab with the title `Documents` - turn off all plugins, to be sure that the issue has not something to do with plugins - open some documents in Geany
**Steps to reproduce** 1. click in the editor 2. click in the sidebar on the tab-title `Documents` 3. with the mouse: mark the first item from the top (result: the first item is marked) 4. click in the editor 5. click in the sidebar on the tab-title `Symbols` 6. click in the sidebar on the tab-title `Documents` 7. press 1x the arrow-down key on the keyboard (result: the next item is marked; so, that means that the release of a click on the tab-title after 6 made the content-area of the tab in focus) 8. click in the editor 9. click in the sidebar on the tab-title `Documents` 10. press 1x the arrow-down key on the keyboard
**Expectation** the next item should be marked
**Result** nothing visible happens; that means that the release of a click on the tab-title in 9 didn't make the content-area of the tab in focus; so, the behavior after 6 is not the same behavior like after 9; but there is something that happens even if it is not visible: after having pressed 1x the arrow-down key on the keyboard in 10, the focus moves from the tab-border to the content-area because if one press again 1x the arrow-down key on the keyboard, then the next item is marked; see also "Remark I" down below
**Remark I** in 3: instead of the first entry, mark the last entry; then do 4 to 6; then in 7 press 1x the arrow-up key instead of the arrow-down key on the keyboard to mark the item before the last item; then do 8 and 9; then in 10 press 1x or several times the arrow-up key instead of the arrow-down key on the keyboard; there will be no change; one have to press first 1x the arrow-down key (!!) on the keyboard to move the focus from the tab-border to the content-area; then press 1x the arrow-up key on the keyboard to mark the second last item
**Remark II** one can do "Steps to reproduce", but without 8
**Remark III** in "Steps to reproduce" one need first to click in the editor, then on the tab-tile "Symbols" and then on the tab-title "Documents", so that the release of the click on the tab-title will put the content-area of the tab in focus; but there is also a second possibility to put the content-area of the tab in focus: if the tab-title "Symbols" is active while the editor has focus, and then if one click on the tab-title "Documents"
**History** I reported the issue already in the year 2021 on the website of the plugin `Preview` (https://github.com/xiota/geany-preview/issues/15) because to that time I thought that the plugin `Preview` was the problem. But today I could reproduce the issue while all plugins were deactivated. That means that not the plugin `Preview` is the problem, but Geany.
**System** Lubuntu 24.04 Geany 2.0
Result nothing visible happens; that means that the release of a click on the tab-title in 9 didn't make the content-area of the tab in focus; so, the behavior after 6 is not the same behavior like after 9; but there is something that happens even if it is not visible:
Correct. Its subtle but its normal GTK behaviour.
If the tab is not displayed, clicking on the tab switches the tab contents, so the content widget is displayed and selected and so up and down arrow moves the selection _in_ the content.
But if the tab is already displayed then clicking it will _select the tab title_ not the tab content. This may be visible depending on your desktop theme, mine shows a fine dotted line around the tab title. So the first down arrow moves the selection _to_ the content widget, but if you don't notice the selection it will appear that nothing happened. Now the content widget is selected a second and subsequent arrow will move the selection _in_ the content widget.
It is probably easier to see with symbols, when the symbols tab is first made the current tab the filter entry at the top will be selected and have a flashing cursor in it. Press up arrow and the tab title gets the selection and filter entry will lose selection and the cursor, press down arrow and selection comes back to the filter entry.
But if the tab is already displayed then clicking it will select the tab title not the tab content.
I don't see a sense in this behavior. Why the tab-titles of the sidebar have not the same behavior like the tab-titles of the editor?
If the tab is not displayed, clicking on the tab switches the tab contents, so the content widget is displayed and selected and so up and down arrow moves the selection in the content.
That is not true. Example: If the tab-title Documents is in focus: Click 2x on the tab-title Symbols, then click on the tab-title Documents.
I don't see a sense in this behavior. Why the tab-titles of the sidebar have not the same behavior like the tab-titles of the editor?
As I said, the sidebar has __default__ GTK behaviour, the editor tabs have __non-standard__ behaviour that had to be "implemented" in Geany when the editor is focussed deliberately when a document is shown (except when it doesn't, see the infamous #3531) which moves the selection from the tab title to the editor (but I can see the dotted outline on the tab title flash). So the behaviour of the editor notebook is non-standard and an accidental side effect of other code.
If the content-area of the tab-title Documents is in focus: Click 2x on the tab-title Symbols, then click on the tab-title Documents.
I said click once, clicking twice is back to the "select the tab title" behaviour. Once the tab title is selected and the tab changed the tab title of the selection stays on the tab title instead of the content.
You can confirm this is GTK default behaviour with the message window notebook tabs which also do the default thing.
As GTK default behaviour its a bit messy, but default knows nothing about any application specifics and for a11y reasons the default behaviour has to allow for navigation by keyboard arrow keys if there is no mouse, so the fact that the tab title is selected shows that the arrow navigation is going to move between tabs not move within tab contents if its not selected. If its moving between tabs it stays in that mode to allow multiple tabs to be navigated. But it may make it a bit confusing if navigation is mixed mouse and arrows.
Default GTK behaviour.
Closed #3961 as not planned.
[...] the default behaviour has to allow for navigation by keyboard arrow keys if there is no mouse [...]
The keyboard navigation of the tabs in the editor is possible with Ctlr+Page-up/down and nobody is complaining or asking the default GTK behavior. And also in the sidebar one can tab-browse with Ctlr+Page-up/down, so without the mouse, without any problems, no matter if the tab-title or the content-area is in focus.
[...] the sidebar has default GTK behaviour, the editor tabs have non-standard behaviour [...]
Because tab-browsing is possible in the sidebar by keyboard (Ctlr+Page-up/down), so without mouse, what about the idea to change sidebar tabs to a non-standard behavior like the editor?
Up to you to raise a separate feature request to change the behaviour and see what others think (of course an attached PR will usually be considered positively ;-), all I have done here is explain why this issue is not a bug.
Certainly nobody is asking for the GTK default. But its what you get when nobody considers it worth the effort coding something else.
Up to you to raise a separate feature request to change the behaviour and see what others think [...]
What about the idea that I ask the gtk community (https://gitlab.gnome.org/GNOME/gtk/-/issues) to change the GTK default behavior?
What about the idea that I ask the gtk community to change the GTK default behavior?
Well, you can always try, but given we are talking about GTK3 which is pretty much in maintenance only I would have expected that they won't make such changes.
Also don't know what the GTK4 behaviour is, maybe find a simple GTK4 app and see if its the same?
[...] maybe find a simple GTK4 app and see if its the same.
Even if a simple GTK4 app would exist and even if in the simple GTK4 app the issue would not exist any more, it does not mean that the simple GTK4 app is using the GTK4 default behavior. As with Geany, there may be a non-standard behaviour implemented.
@elextr Because all necessary information are here in this issue – my report and your explication –, could you please reopen this issue and remove the invalid-label. Then I will change the title of the issue to this title: `A release of a click on a tab-title of the sidebar should put always the content-area of the tab in focus`
No, this is a Geany issue, not a GTK issue. Geany is not raising the GTK feature request, you are.
Some advice (mine only, it does not represent Geany opinion).
If you are proposing a change to GTK that will often apply by default to all GTK applications, you need to explain it to GTK relative to current documented and actual GTK behaviour, justify it to GTK, discuss it with GTK, and don't expect all those involved in the discussions to read through a foreign issue on a single application as justification. And I would suggest your hurdle to clear will be even higher with a feature request to GTK3 behaviour, when GTK3 is supposed to be stable. So you need to make an issue with the description, reasoning and support of the highest quality and referring to a Geany issue is not the way to do it.
In comment https://github.com/geany/geany/issues/3961#issuecomment-2373617833 you wrote:
Up to you to raise a separate feature request to change the behaviour and see what others think (of course an attached PR will usually be considered positively ;-)
Why should I request a separate feature request if everything necessary is said in this issue. As I mentioned in my last comment, if you reopen the issue and remove the label, I will change the title of the issue. The title will then be `A release of a click on a tab-title of the sidebar should put always the content-area of the tab in focus` instead of `BUG: A release of a click on a tab-title of the sidebar does not put always the content-area of the tab in focus`. Because I'm not a software developer but a software user, I can't offer a PR.
Regardless of this feature request I have the intention to contact GTK to ask if they can change the GTK default behavior.
Are you trying to say you want to convert this to a feature request, you never actually said that clearly? As I said above (added emphasis):
Up to you to raise a __separate__ feature request
The history of this issue and having been closed as invalid in the past is not appropriate for a feature request.
But _within_ Geany you can certainly have your feature request refer to this for background.
You should add to the FR how you suggest it should be addressed, especially how the selected tab title and arrows stuff is to be handled, etc. And as I said, adding a PR would be worthwhile, since so far nobody has cared enough to make the changes to the default GTK notebook behaviour for both sidebar and message window notebooks.
On your GTK request, I would also add, check the documentation, and check if there has been a previous similar issue before and what the answer was.
@elextr
You can confirm this is GTK default behaviour with the message window notebook tabs which also do the default thing.
The behavior of the sidebar and the message window are different: 1. Sidebar: If the tab has focus, so not the content-area of the tab, then tab-browsing with the arrow-left-key or the arrow-right-key is possible. Message-window: If the tab has focus, so not the content-area of the tab, then tab-browsing with an arrow-key is not possible. 2. Sidebar: If the tab has focus, so not the content-area of the tab, I can put the content-area of the tab in focus by pressing 1x the arrow-down-key. Message-window: If the tab has focus, so not the content-area of the tab, I can not put the content-area of the tab in focus by pressing 1x an arrow-key.
The common behavior of sidebar and message window is: When clicking on a tab-title, it can be – under certain conditions –, that the content-area of the tab is in focus.
Thats nicely and clearly described thank you ... except are you aware that the message pane can be positioned to the right where the tabs are at the top like the sidebar, or the message pane can be positioned to the bottom (and is default) and the tabs are to the left and stacked vertically. You didn't mention which position it is in but it changes which arrow keys are used.
1. Sidebar: the same as you Message-window: if the message-window is at the right side and the tab has focus it works exactly the same as sidebar, if message-window is at the bottom and the tab has focus then tab browsing works, but with up/down arrows to switch to the next/previous tab which sort of makes sense since the tabs are stacked vertically so up/down is the direction between tabs. 2. Sidebar: the same as you Message-window: if the window is at the right the down arrow moves from the selected tab to the content, if the window is at the bottom the right arrow moves from the selected tab to the content, and again that makes sense since the tabs are to the left of the content it is right from the tab to the content.
This is on a different machine (LMDE6) to my previous experiments, but the results are the same again. Except for confusion about left/right vs up/down arrows the only reason I can think of why it works/does not work is that CSS might be able to affect it, but I don't know if it can or how.
You didn't mention which position it is in but it changes which arrow keys are used.
It doesn't matter which position the message window is because I wrote those words:
[...] then tab-browsing with an arrow-key is not possible. [...], I can not put the content-area of the tab in focus by pressing 1x an arrow-key.
On the machine that I use, I can't tab-browse with any of the arrow-keys in the message window, no matter if the message window is on top or at the bottom, no matter if the tabs are ordered vertically or horizontally. And on the message window I can't put the focus on the content-area of a tab with any of the arrow-keys, no matter if the message window is on top or at the bottom, no matter if the tabs are ordered vertically or horizontally.
@elextr Sorry for that what I wrote my in last two comments. You are right: Sidebar and message window have exactly the same behavior. I recognized that after I deactivated all plugins.
Ahh, the olde plugin piracy :pirate_flag:
I just opened a new issue: https://github.com/xiota/geany-preview/issues/58
github-comments@lists.geany.org