Open ralf3u opened 2 years ago
Maybe the solution of this issue has a connection with #5.
The main problem of #5 is the detection of a signal whether sidebar is in focus or not in focus when clicking in the sidebar. This signal apparently does not exist in Geany.
But the problem of #15 is different: When clicking on the tab-title of the sidebar, the tab-title of the sidebar becomes green. I don't know how to program software, but does not something exist like:
IF there is a CSS-color change of the tab-title, THEN execute something like geany.keycmd("FOCUS_SIDEBAR")
.
(For more information to geany.keycmd("FOCUS_SIDEBAR")
, see https://github.com/xiota/geanylua-scripts/issues/7#issuecomment-1455335094).
I don't know how to program software, but does not something exist like:
IF there is a CSS-color change of the tab-title, THEN execute something like geany.keycmd("FOCUS_SIDEBAR").
Is this possible or not possible?
Setting focus has been an ongoing issue that may not be resolvable any time soon.
In September 2022 I opened at Geany the issue number 3289. In that issue there are two links about GTK3 that could help to solve the focus issue:
https://docs.gtk.org/gtk3/signal.Notebook.focus-tab.html https://docs.gtk.org/gtk3/signal.Widget.grab-focus.html
Did you try both?
I tried every signal a couple years ago. None of them worked at the time. The problem is focus goes where you don't want it. You want the browser contents to be in focus. But usually some other part of the notebook is given focus, like the tabbar. Even when I think focus has gone where you want it, when you start navigating with the keyboard, focus can be moved to a different component. (Then you open an issue saying press some keys in some order and the tab changes instead of scrolling the view.)
OK, but what about the idea to report at GTK that some things don't work as they should?
I think that there are two issues that should be reported at GTK because they don't work correctly:
I will not report the issues because I have too less knowledge about programing software.
I will not report the issues because I have too less knowledge about programing software.
I don't know enough to be sure there is a problem with GTK or whether it's working the way they want it to. They may not want programmers to be able to move focus around in certain circumstances because it's a potential security risk (eg, to intercept user input).
I don't know enough to be sure there is a problem with GTK or whether it's working the way they want it to.
I would say: Just report it and then you will know with the answer they offer.
Just report it and then you will know with the answer they offer.
I don't really want to write code to reproducibly replicate the problem, try fixes, etc. Plus, GTK development has moved on to GTK4. I don't even know if Geany and plugins build with GTK4.
I don't even know if Geany and plugins build with GTK4.
Maybe this information helps: https://github.com/xiota/geany-preview/issues/5#issuecomment-1261747888.
I doubt the devs will proactively update that issue. When they do decide to support GTK4, the devs (not users) will probably have to open a lot of new issues to remove outdated GTK3 stuff.
So, that means for me that you wait till Geany und the plugins will support GTK4, and then, if the issue is still there, you would report it to GTK. The problem could be then that GTK5 will be already available. So, it could be that the issue will never be reported.
When they do decide to support GTK4, the devs (not users) will probably have to open a lot of new issues to remove outdated GTK3 stuff.
That's your point of view. I have another point of view: If you report the issues now, then I can imagine that they will not fix it for GTK3 but maybe think about a solution that will be supported only by GTK4 and future versions.
I am not going to open bug reports to GTK about this. The entire process will take a lot of time and effort. Most likely nothing would come of it.
Why don't you figure out how to access and search their bug reports to see whether it's already been reported. Then you can track it's process. https://gitlab.gnome.org/GNOME/gtk/-/issues/
Well, I can try to report at GTK. Let's try first with the title. I would describe it like this: issue 1: GTK3: no possibility to put focus on the content-area of a tab of the sidebar in the editor Geany issue 2: GTK3: no possibility to detect if content-area of a tab of the sidebar is in focus in the editor Geany
Is it OK like this?
Do a search first to see if you find anything relevant. I don't really want to be involved in an upstream bug report.
OK
I just recognized that in Lubuntu 23.10 with Geany 1.38 if I click in the sidebar on the tab-title Files
(plugin File Browser
), then the content of the tab is also not in focus. I will report it the next days at geany-plugins.
Before reporting the issue at geany-plugins, I wanted to ask if the information could help to solve the issue: https://docs.gtk.org/gtk3/method.Widget.child_focus.html
I don't see how this is related to geany-plugins.
I just opened at geany-plugins an issue with the issue number 1320. The title of the issue is: "A release of a click on the tab-title of a plugin-tab in the sidebar should put the content of the tab in focus".
The plugin Preview is not responsible for this issue. The issue has to be fixed upstream. That is the reason why I close this issue.
Could you please join the conversation at geany-plugins 1320, because the maintainer claims that the issue does not belong to the Geany project.
Now the maintainer added some more information:
Therefore plugins are entirely responsible for the behaviour of their UI. Plugins should connect to the relevant signal eg "switch-page" or "focus-tab" or "clicked" on the tab or whatever and then implement the behaviour they require.
So, the sentences for me mean that Preview is the problem. The sentences mean also for me that the issue can be solved in the plugin Preview.
[...] I said elsewhere the tab and the contents are different things, and in standard GTK the tab can be focussed instead of the content by clicking it when the page is current.
When I observed the behavior of the plugin File Browser
, I thought that it was the same for the plugin Preview, namely that the toolbar is in focus. But now I think that it is not the toolbar that is in focus after a release of a click on the Preview-tab, it is the tab, and that is the reason why I have first to press 1x the arrow-down-key on the keyboard to put the content of the tab in focus.
When the tab is clicked, the tab itself is in focus. Probably not a good idea to change focus to the contents because that would interfere with changing tabs with left/right. You would then have to use ctrl+pgdn / ctrl+pgup.
Figuring out the exact component of interest and the right signals to use is difficult and unreliable. Focus may not go where you want or expect with every sidebar plugin. I already tried unsuccessfully to change focus to the gtkwebkit widget in the past.
When the tab is clicked, the tab itself is in focus. Probably not a good idea to change focus to the contents because that would interfere with changing tabs with left/right.
I don't know what you mean.
You would then have to use ctrl+pgdn / ctrl+pgup.
I use ctrl+pgdn / ctrl+pgup now anyway for tab-browsing in the sidebar. It works when I click on the tab-title of the Preview-tab and it works also when the content of the Preview-tab is in focus.
Since xitweaks has tab switching detection basically working, I'll take a look at whether the contents can be focused. However, I'm expecting it will not work for the gtkwebkit widget (used by preview plugin), since it didn't work in the past.
[...], I'll take a look at whether the contents can be focused.
This would be great, because it is the last existing important artifact in the plugin Preview.
The xitweaks plugin already has code that moves focus to the contents of the notebooks when sidebar_focus or notebook_focus features are enabled. It is working on my computer. Please check whether it is working on yours.
I also found a few minor bugs. Will try to fix them.
Please check whether it is working on yours.
This issue still exists on my computer after sudo apt update
and sudo apt dist-ugrade
. If I click on the tab-title on the Preview-tab, the content of the tab is not in focus because I have to press 2x the arrow-down-key of the keyboard, so that a very long webpage starts to scroll downwards.
It is working on my computer.
Maybe this issue is fixed in Geany 2.0. I use Lubuntu 23.10 and Geany 1.38.
Could also be something in gtk3 library. I remember the signals didn't work a few years ago when you opened these issues.
So, let's wait till Lubuntu 24.04.
But it is good to know that it is working on your computer!
In https://github.com/xiota/geany-preview/issues/15#issuecomment-2021850774 you write:
The xitweaks plugin already has code that moves focus to the contents of the notebooks when sidebar_focus or notebook_focus features are enabled. It is working on my computer. Please check whether it is working on yours.
In Geany in Lubuntu 23.10 the issue is still not fixed. If I click on the Preview-tab-title, the content of the tab is still not in focus.
actual behavior If I click on a tab-title of the sidebar: The tab-title is in focus, even if the mouse-key is not pressed any more. Evidence: There is no sign for it, but both tests below are negative.
control tests with a very long html-document, and with at least two tabs in the sidebar: TEST 1: Open Geany, click on the Preview-tab-title, then press the arrow-left-key only once: the content of the Preview-tab should still be in focus. TEST 2: Open Geany, click on the Preview-tab-title, then press the arrow-down-key only once: the html-document should move downwards.
expectation
remark The tabs in the sidebar should work exactly like the tabs in the editor: Open Geany, click on a tab-title of the editor and hold the mouse-key for about 10 seconds: tab-title is in focus, but in the moment where the mouse-key is not pressed any more, the content of the tab is in focus, and not the tab-title of the editor, what is visible with the highlighted line.