This may apply to other versions as well, but I'm using Sierra.
The tabbed dialog boxes don't read the cursor position correctly. It's basically "move until the thing you want to click acts like you're hovering". Pulling the tab out as a separate window resolves the issue. The main editor doesn't have this issue.
@jrittenh Could you describe in more detail what happens (e.g. steps to reproduce the issue)? I'm not sure I understand completely what happens from your current description. I haven't noticed any issues myself.
@techee there is a ML post thats probably this as well.
@elextr Yeah, the ML post is mine.
@techee I tried to screenshot the issue, but I'm not satisfied with the built-in screenshot tools, as they either capture the cursor but not the error (the Grab utility), or they show the cursor's current "position" but not the cursor (the CMD+SHIFT+4, SPACE command to capture the current window).
I'll attempt to display an ASCII version of what the issue is:
<- (cursor) (blank space) [] (checkbox) [] (another checkbox) [[]] (active/hovered checkbox)
What you would normally see:
[] (checkbox) [] (another checkbox) [[]]<- (active/hovered checkbox with cursor)
Effectively, the cursor's position as interpreted by the dialog box is offset from the actual cursor position, typically by some upward vertical and possibly some leftward horizontal amount. If it's a checkbox, it won't highlight the checkbox directly under the cursor, but possibly one below it somewhere, or if you move the cursor to the right position, you'll see it highlight the one you're intending to click, but see the cursor somewhere not over the box. The same happens with text boxes and the text cursor. It doesn't change to the text cursor until you're somewhere above the text box, not over the text box.
This is really strange, I don't see anything like that myself macOS Sierra too - lines witch checkboxes are highlighted correctly for the cursor position for me.
A few questions: 1. Are you using multi-monitor setup? If so, does it happen with a single monitor setup too? 2. From the mailing list it seems you have the preferences window maximized - does the same problem appear when it's normal size? 3. In the mailing list you mention "Is it possible to disable the new dialog-boxes-are-tabs functionality?". The thing is there's nothing new like that (I actually don't understand what dialog-boxes-are-tabs means - yes, there are tabs used in the preferences dialog but it has always been like that). Is there some regression compared to previous releases (see http://download.geany.org if you want to test)? 4. "Pulling the tab out as a separate window resolves the issue." Hmm, how do you do that? Tabs cannot be dragged out from the preferences window as far as I know.
It almost looks like the contents of the Preferences window are opening as a document tab. I have no idea how that could happen unless a plugin or something was intentionally doing it intentionally.
@jrittenh can you try to run Geany directly from the console using a clean config dir. I'm not exactly sure but somewhere in the bundle directory there should be the actual geany binary (or an equivalent runner script?), and pass it an option like `geany -c /tmp/just_testing` to have it use a clean config dir for testing. Alternatively, you could move `~/.config/geany` directory out of the way (ex. `mv ~/.config/geany{,.backup}`) and then running Geany normally.
For the record, here's the screen shot posted to the ML: 
Why is the pref dialog tabbed like this? Is this a recent GTK thing? @techee do you have seen this before?
This is an OSX thing, not something we do, see "merged windows" [here](https://support.apple.com/kb/PH25079?locale=en_GB&viewlocale=en_US).
Its likely that GTK is not compatible with this OSX feature.
Ah, wow, I didn't notice the preferences dialog was part of the editor in your screenshot - I see nothing like that on my machine, all dialogs are separate windows. I have no idea how this could have happened - I'd suggest what Matthew says to e.g. rename the Geany configuration directory so Geany recreates it with a clean configuration (please keep the old configuration files and if the above helps, send us the geany.conf file so we can check what got wrong).
Looks like @elextr nailed it. Window isn't "full screen" in the OS X sense, but it is "maximized" in the Windows sense (ALT/OPTION+green button), which is apparently close enough to full screen to default to tabs. Setting the "merged windows" OS X setting to manual has resolved the issue. This was a fresh install on a new machine, previous machine hadn't updated to 1.30, so I just assumed it was a 1.30 thing. I'll close this out, as it's not a Geany issue. I may see about pushing a bug upstream at some point (GTK?).
Closed #1428.
OK, I was completely unaware of this merged window settings (@elextr, are you secretly using OS X :-) ? Just for information, where is this "merged windows" settings in OS X? I removed the "Window" menu from Geany because basically nothing works from there for Geany so I'm wondering how you got this activated.
You can report this bug against GTK but I'm afraid there are so little developers working on the Quartz backend for GTK (the number of OS X developers fluctuates between 0 and 1) so I don't expect it to be fixed soon. Also I use GTK 2 for Geany because GTK 3 is way more buggy in other areas so it's possible this might be fixed in GTK 3 already.
ok this seems related, when using OSX Catelina, open GTK 1.36 and mouse responds as if the based of the pointer arrow is the active part. If I open to full window all works ok, then if reduce window to smaller size all works ok!
github-comments@lists.geany.org