Hello, I have a small problem with arrow button for switching between tab document. When I click too fast on the arrow button, geany create new tab document and take me to the end. I also sometimes saw tabs overlapping too. Are there an issue with this bug ? I use geany 1.32 on Ubuntu 18.04 with gnome shell
Can you provide a screenshot of what button you're referring to?
@codebrainz I guess the button on the very right and/or left of the tabs, part of the notebook. I don't see this issue, but I guess it's a bad interaction with a specific version and our *double click on empty notebook area creates a new tab* feature.
@julien5762 could you give us version information on the supporting libraries via the *Help → Debug Messages* (the first few lines)?
I Will give you a screenshot and the debug message when I'm back to home. The keyboard shortcuts corresponding at this button (ctrl + PgUp and ctrl + PgDown) haven't this problem and work perfectly
As promised the screenshot :
http://imagizer.imageshack.us/a/img923/7310/3qeL5e.jpg
and the debug message :
20:43:53: Geany INFO : unknown : None (UTF-8) 20:43:53: Geany INFO : unknown : None (UTF-8) 20:43:54: Geany INFO : unknown : None (UTF-8)
Huh. This bug really sucks as I am also too fast for Geany 1.32 running in xfce. When a new empty tab is created, only those messages are added to debug log: 15:34:31: Geany INFO : unknown : None (UTF-8) 15:34:31: Geany INFO : unknown : None (UTF-8) etc.
No matter how quicky I double click on the arrows, Geany does not create a new document.
@marisn your desktop should allow you to configure how fast clicks are interpreted as double click, maybe you can change that setting.
To my endless frustration, this happens to me constantly, to the point that I've learned that the arrows are too buggy to rely on and that I need to avoid having too many documents open as much as possible. Until I read this post it never occurred to me that it was interpreting my clicks as a double-click, as opposed to just bugging out randomly. They can be spaced quite far apart in time and this still happens.
Might I suggest--nay, beg, desperately on my knees--that this feature be removed entirely? There is already a toolbar button that creates a new document with a single click, as well as an option in the File Menu requiring two clicks, as well as the CTRL+N keyboard shortcut. It doesn't make logical sense for the scroll arrows to create a new document rather than scrolling when clicked too quickly; those functions are unrelated, the buttons aren't even present unless you have enough documents open, and it destroys the intended functionality of those buttons.
I use Geany for hours every day for programming and basically any time I open a text file graphically. Many times I snarl in fury and hopelessness, battling with this issue, and every time I do an update I open it with trepidation and excitement, holding my breath in the hope that this is the day the bug finally goes away. Finally in desperation I came here to report it, thinking that somehow it must have gone unnoticed (perhaps only I routinely open dozens of files and use the GUI to move between them?)--and now I see that it's actually an unintended consequence of an attempted feature, which explains everything.
Oh great devs, I beg you from the bottom of my heart! I wail and I scream in desperation! I will sacrifice five strong bulls and ten spotted goats to your glory! Only please, please free me from this curse. My only wish is the ability to move between open documents at will without unwanted blank new documents jumping into existence and undoing all of the scrolling I'd already completed by dragging me back all the way to the end of the list to stare at them, grind my teeth in fury, and start the long process again. Please, please, please let the scroll buttons be peaceful and simple and honest and usable.
SOME DATA: After playing with it... I have no idea what's going on. It's definitely bug-related and not just a double-click issue. (1) It requires at least 3 clicks. (2) It doesn't always happen. (3) Once one untitled document has been created, it seems that it DOES always happen. (4) Sometimes it creates the document where you are in the list, sometimes it creates it at the end of the list. (5) Once it's happened, the arrows occasionally behave in a strange manner, e.g. getting all the way to the left and clicking the right arrow jumps several documents to the right or to the end. (6) Double-clicks seem like maybe they can be spread between the two buttons, where once you've gotten to the first document and click the right arrow once, a new document appears? I'm thinking that possibly the new untitled documents are in a different order in some internal array than they are in the displayed document list? And that... well, I don't know. Beyond that vague partial guess I really can't venture to say what's going on.
TO TEST: Open a bunch of files, say 30, go to the end, and rapidly click the left arrow until you get to the beginning. Then rapidly click the right arrow until you get to the end again (might only take one click???). Then rapidly click the left arrow again and watch hell spew forth. Here is a video cropped from my gnome 3 desktop of this happening, with mouse presses visible. Please forgive the horrifying artifacts where pieces of the background appear in the window.
This is not a jpg, this is an mp4 with a .jpg extension because GitHub screamed at me when I tried to upload an mp4. I'll see if I can find a quick upload service somewhere and replace this with that.
![cropped_screencap](https://user-images.githubusercontent.com/5234097/47271144-a30f1580-d543-11e...)
@b4n and other gtk spurts
The code to detect being on the tab bar background uses styles "scroll-arrow-hlength" and "scroll-arrow-vlength" as part of the calculation of position.
But those appear to be scrollbar arrows, not notebook tabs arrows [here](https://developer.gnome.org/gtk3/stable/GtkWidget.html) and are not mentioned in [notebook styles](https://developer.gnome.org/gtk3/stable/GtkNotebook.html). Its theme dependent how big scrollbar arrows and tabbar arrows are, so maybe where scrollbar arrows are small and tabbar arrows are large [this](https://github.com/geany/geany/blob/97547edb52e34b8f78f44a13548a0fb55baf1a44...) code is finding parts of the tabbar arrow are outside the arrow and ripe for double clicking?
IMHO that code and the widget layout dependent checks [here](ttps://github.com/geany/geany/blob/97547edb52e34b8f78f44a13548a0fb55baf1a44/src/notebook.c#L517) are wrong, they depend on implementation dependent things and now some implementations have changed.
Since the feature is implemented wrongly and is undiscoverable it should indeed be removed (by commenting if you want) until "somebody" PRs a correct implementation that doesn't depend on styles and GTK widget layouts.
github-comments@lists.geany.org