Hi, all!
i'm quite certain that this is not a Geany bug, but more of a general GTK-on-multi-head problem, but i'm guessing that one or two of you might know a workaround...
On multi-head setups, bringing up the Search dialog (or similar) invariably places it on the wrong monitor (i.e. a monitor other than the one geany's main window is occupying).
Do any of you know of a GTK/Gnome/whoever option which can force dialogs to be shown on the same monitor as their containing application?
The "virtual layout" of the monitors does not seem to affect the behaviour. e.g. it doesn't seem to matter whether my main monitor is laid out to be above/left/right/below of the other monitor.
:-?
On Fri, Jul 8, 2011 at 12:14 PM, Stephan Beal sgbeal@googlemail.com wrote:
Hi, all! i'm quite certain that this is not a Geany bug, but more of a general GTK-on-multi-head problem, but i'm guessing that one or two of you might know a workaround... On multi-head setups, bringing up the Search dialog (or similar) invariably places it on the wrong monitor (i.e. a monitor other than the one geany's main window is occupying). Do any of you know of a GTK/Gnome/whoever option which can force dialogs to be shown on the same monitor as their containing application?
I'm away from my home Linux machine now, but this sounds like maybe Geany doesn't call http://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-transie... for the Search dialog. That's at least the first thing to investigate. This is a function call though, not an option you can tweak without code changes. Perhaps someone developer who actually runs multi-head knows more ...
Regards,
/Emil
On Fri, Jul 8, 2011 at 12:20 PM, Emil Brink emil@obsession.se wrote:
I'm away from my home Linux machine now, but this sounds like maybe Geany doesn't call
http://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-transie... for the Search dialog. That's at least the first thing to investigate. This is a function call though, not an option you can tweak without code changes. Perhaps someone developer who actually runs multi-head knows more ...
Thanks, Emil :).
If someone can point me to where this should go, i can try it out.
On 8 July 2011 20:24, Stephan Beal sgbeal@googlemail.com wrote:
On Fri, Jul 8, 2011 at 12:20 PM, Emil Brink emil@obsession.se wrote:
I'm away from my home Linux machine now, but this sounds like maybe Geany doesn't call
http://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-transie... for the Search dialog. That's at least the first thing to investigate. This is a function call though, not an option you can tweak without code changes. Perhaps someone developer who actually runs multi-head knows more ...
Hi Stephan,
I run Geany on Gnome on multihead without real problems. The dialog is explicitly positioned each time its created and that position is remembered the next startup.
If you move Geany across monitors you get it confused, AFAIK the window manager doesn't inform Geany of the change so it can't compensate. Just move the dialog again and it should stay there.
Again this might be fixed by session management upgrades, but I doubt it.
Note Emil's reference is to GTK3 and Geany is NOT gtk3 compatible (or it might be just that the stupid GTK docs make it too easy to get into GTK3 when you want GTK2).
Cheers Lex
On Fri, Jul 8, 2011 at 12:58 PM, Lex Trotman elextr@gmail.com wrote:
If you move Geany across monitors you get it confused, AFAIK the window manager doesn't inform Geany of the change so it can't compensate. Just move the dialog again and it should stay there.
In both of my cases i run geany always on the same monitor, but it's not the primary monitor (where the desktop lives). In my 2 setups, the desktop lives on the built-in (laptop) monitors and the external monitors (which are much bigger :) are the secondary monitors (but where i do all my work).
So the problem might be that i'm always running geany on the secondary/external monitors.
Again this might be fixed by session management upgrades, but I doubt it.
i recently upgraded from Ubuntu 11.04 to 10.10 (yes, that's an upgrade) because 11.04 was completely useless for me. For one, the session support was apparently removed altogether (i will refrain from calling the 11.04 decision-makers horrible names (in public) for the time being).
Note Emil's reference is to GTK3 and Geany is NOT gtk3 compatible (or it might be just that the stupid GTK docs make it too easy to get into GTK3 when you want GTK2).
i didn't know there was a gtk3 yet.
It sounds to me like i'm stuck with this behaviour for the time being. No big deal - it's only minorly annoying and i would be surprised if this can be fixed in geany without low-level, possibly non-portable hackery.
But thanks for the feedback, guys,
On Fri, Jul 8, 2011 at 1:15 PM, Stephan Beal sgbeal@googlemail.com wrote:
In both of my cases i run geany always on the same monitor, but it's not the primary monitor (where the desktop lives). In my 2 setups, the desktop lives on the built-in (laptop) monitors and the external monitors (which are much bigger :) are the secondary monitors (but where i do all my work).
So the problem might be that i'm always running geany on the secondary/external monitors.
A slight elaboration there, from the config i'm using right this minute:
built-in monitor (#1) sits to my left. #2 (external) sits in front of me. The desktop lives on #1. From #2 i'm ssh'd into a dev server and run geany from there, exporting the display to my machine (via (ssh -X)). When i start Geany, it starts up on the same monitor as the shell i started it from (#2). When i tap Ctrl-F/H/whatever, the search dialog invariably pops up on the built-in monitor.
On my home setup, monitor #2 sits on the left of #1, and the behaviour is the same - i run Geany on #2 but the dialogs pop up on #1. (This time without the extra level of ssh indirection.)
So it would seem (though i haven't fully verified this) that gtk is always showing them on the "main" monitor (==the one where the desktop is configured to show up). But that's really just a guess (and breaks down when we consider what might happen when no WM, or no desktop, is running).
On 8 July 2011 21:23, Stephan Beal sgbeal@googlemail.com wrote:
On Fri, Jul 8, 2011 at 1:15 PM, Stephan Beal sgbeal@googlemail.com wrote:
In both of my cases i run geany always on the same monitor, but it's not the primary monitor (where the desktop lives). In my 2 setups, the desktop lives on the built-in (laptop) monitors and the external monitors (which are much bigger :) are the secondary monitors (but where i do all my work). So the problem might be that i'm always running geany on the secondary/external monitors.
A slight elaboration there, from the config i'm using right this minute: built-in monitor (#1) sits to my left. #2 (external) sits in front of me. The desktop lives on #1. From #2 i'm ssh'd into a dev server and run geany from there, exporting the display to my machine (via (ssh -X)). When i start Geany, it starts up on the same monitor as the shell i started it from (#2). When i tap Ctrl-F/H/whatever, the search dialog invariably pops up on the built-in monitor. On my home setup, monitor #2 sits on the left of #1, and the behaviour is the same - i run Geany on #2 but the dialogs pop up on #1. (This time without the extra level of ssh indirection.) So it would seem (though i haven't fully verified this) that gtk is always showing them on the "main" monitor (==the one where the desktop is configured to show up). But that's really just a guess (and breaks down when we consider what might happen when no WM, or no desktop, is running).
What virtual display are you running on the server via SSH? My guess would be :0, so Geany stores that the dialog is on :0 and then when you run it locally it pops up on :0 which is the main screen.
Either that or its a display (like :2) that doesn't exist on your local machine so the WM just shrugs and puts Geany on the screen its started from and the dialog on :0
Cheers Lex
PS Yes, fixing this sort of thing is not very portable as I know from past heartache.
What virtual display are you running on the server via SSH? My guess would be :0, so Geany stores that the dialog is on :0 and then when you run it locally it pops up on :0 which is the main screen.
Quick check of SSH doc, its the one below.
Either that or its a display (like :2) that doesn't exist on your local machine so the WM just shrugs and puts Geany on the screen its started from and the dialog on :0
Cheers Lex
PS Yes, fixing this sort of thing is not very portable as I know from past heartache.
On Fri, Jul 8, 2011 at 1:45 PM, Lex Trotman elextr@gmail.com wrote:
On 8 July 2011 21:23, Stephan Beal sgbeal@googlemail.com wrote:What virtual display are you running on the server via SSH? My guess would be :0, so Geany stores that the dialog is on :0 and then when you run it locally it pops up on :0 which is the main screen.
It's localhost:10.0 when running over (ssh -X), but the the starting display offset can be configured in ssh, IIRC. But the copy of geany running over ssh is not the same geany binary i run locally - my local copy is only ever active on my external monitor (but it _might_ have, at some point, started up on the internal monitor and i moved it over to the external monitor). On both geany binaries i'm seeing the same behaviour - main window is on screen #2 while dialogs pop up over on #1.
i don't see anything in geany.conf about the display but i do see a socket:
stephan@infomat-dev:~/public_html$ l /home/stephan/.config/geany/ ... lrwxrwxrwx 1 stephan consol 26 Jul 8 13:52 geany_socket_infomat-dev_localhost_10 -> /tmp/geany_socket.d5368770 ...
Either that or its a display (like :2) that doesn't exist on your local machine so the WM just shrugs and puts Geany on the screen its started from and the dialog on :0
Where would i find the persistent display setting? The only mention of ':' i find in geany.conf is:
pref_template_datetime=%d.%m.%Y %H:%M:%S %Z
PS Yes, fixing this sort of thing is not very portable as I know from past heartache.
IMO it's not worth the effort/pain to try to fix this in geany unless it's really just a missing API call (as Emil mentioned), but you already debunked that as being a gtk3 thing. It sounds like it would be a huge, ugly can of worms to me.
On 8 July 2011 22:32, Stephan Beal sgbeal@googlemail.com wrote:
On Fri, Jul 8, 2011 at 1:45 PM, Lex Trotman elextr@gmail.com wrote:
On 8 July 2011 21:23, Stephan Beal sgbeal@googlemail.com wrote:What virtual display are you running on the server via SSH? My guess would be :0, so Geany stores that the dialog is on :0 and then when you run it locally it pops up on :0 which is the main screen.
It's localhost:10.0 when running over (ssh -X), but the the starting display offset can be configured in ssh, IIRC. But the copy of geany running over ssh is not the same geany binary i run locally - my local copy is only ever active on my external monitor (but it _might_ have, at some point, started up on the internal monitor and i moved it over to the external monitor). On both geany binaries i'm seeing the same behaviour - main window is on screen #2 while dialogs pop up over on #1. i don't see anything in geany.conf about the display but i do see a socket: stephan@infomat-dev:~/public_html$ l /home/stephan/.config/geany/ ... lrwxrwxrwx 1 stephan consol 26 Jul 8 13:52 geany_socket_infomat-dev_localhost_10 -> /tmp/geany_socket.d5368770 ...
Either that or its a display (like :2) that doesn't exist on your local machine so the WM just shrugs and puts Geany on the screen its started from and the dialog on :0
Where would i find the persistent display setting? The only mention of ':' i find in geany.conf is: pref_template_datetime=%d.%m.%Y %H:%M:%S %Z
display is an X11 option, not one that Geany controls, its set by --display or the DISPLAY environment variable and xlib reads it not Geany. Note don't play with these on the SSH system or you will probably break it, SSH sets it to something unused on that machine so it has total control for security.
PS Yes, fixing this sort of thing is not very portable as I know from past heartache.
IMO it's not worth the effort/pain to try to fix this in geany unless it's really just a missing API call (as Emil mentioned), but you already debunked that as being a gtk3 thing. It sounds like it would be a huge, ugly can of worms to me.
No it won't be set_transient_for anyway because thats for implicit position and Geany sets the position explicitly.
Just out of interest if you open the search dialog, move it to display #2, close it and re-open it where does it come up? It should be where you left it.
Cheers Lex
On Fri, Jul 8, 2011 at 2:50 PM, Lex Trotman elextr@gmail.com wrote:
Just out of interest if you open the search dialog, move it to display #2, close it and re-open it where does it come up? It should be where you left it.
In fact... that works, but i have to do this separately for each dialog (e.g. Ctrl-F vs. Ctrl-H). Thanks for that tip :).
On 8 July 2011 22:55, Stephan Beal sgbeal@googlemail.com wrote:
On Fri, Jul 8, 2011 at 2:50 PM, Lex Trotman elextr@gmail.com wrote:
Just out of interest if you open the search dialog, move it to display #2, close it and re-open it where does it come up? It should be where you left it.
In fact... that works, but i have to do this separately for each dialog (e.g. Ctrl-F vs. Ctrl-H). Thanks for that tip :).
Yes each dialog is independently positioned.
That should stay that way until you disturb it by opening on some other display. Geany doesn't really handle that situation.
Note that this info is stored in the geany config file so if you use a different config file (-c filename) when running remotely then the two situations should be independent and you won't lose one position setting by overwriting it with another. But of course you also don't share any setting changes or session files.
Cheers Lex
-- ----- stephan beal http://wanderinghorse.net/home/stephan/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, 8 Jul 2011 20:58:23 +1000 Lex Trotman elextr@gmail.com wrote:
Note Emil's reference is to GTK3 and Geany is NOT gtk3 compatible (or it might be just that the stupid GTK docs make it too easy to get into GTK3 when you want GTK2).
But this functions are already inside GTK2, but not sure whether they are working as expected :D
Cheers, Frank
On 17 July 2011 03:08, Frank Lanitz frank@frank.uvena.de wrote:
On Fri, 8 Jul 2011 20:58:23 +1000 Lex Trotman elextr@gmail.com wrote:
Note Emil's reference is to GTK3 and Geany is NOT gtk3 compatible (or it might be just that the stupid GTK docs make it too easy to get into GTK3 when you want GTK2).
But this functions are already inside GTK2, but not sure whether they are working as expected :D
Yes, I didn't have time to check if they were the same. But it won't solve the problem anyway since Geany stores and restores positions itself.
Cheers Lex
Cheers, Frank -- http://frank.uvena.de/en/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sun, 17 Jul 2011 12:24:36 +1000 Lex Trotman elextr@gmail.com wrote:
On 17 July 2011 03:08, Frank Lanitz frank@frank.uvena.de wrote:
On Fri, 8 Jul 2011 20:58:23 +1000 Lex Trotman elextr@gmail.com wrote:
Note Emil's reference is to GTK3 and Geany is NOT gtk3 compatible (or it might be just that the stupid GTK docs make it too easy to get into GTK3 when you want GTK2).
But this functions are already inside GTK2, but not sure whether they are working as expected :D
Yes, I didn't have time to check if they were the same. But it won't solve the problem anyway since Geany stores and restores positions itself.
Yepp. True.
Cheers, Frank
Yes, I didn't have time to check if they were the same. But it won't solve the problem anyway since Geany stores and restores positions itself.
Hi,
I have just realised somewhat belatedly that there is another point here.
I have two monitors but only one screen spread over both of them (xdpyinfo says screen #0 3360 x 1050). So moving Geany from one monitor to another is actually moving it on the one screen.
So there is no reason for Geany to move the dialogs, nothing has happened except the main window has moved a bit. The specification for the dialogs is to stay where they are put, so the user can position them where they are not in the way of what is being editing. It would be somewhat annoying if I tried to move the main window out of the way and the dialogs followed.
The only reason for the dialogs to move is when the window manager says they can't be positioned where they were. This is probably what happens to Stephan as he moves between machines, the saved position on the dual display is illegal on the single one so the window manager just positions the dialog in a legal position and on close Geany saves that position which is reused next time on the dual display, effectively moving the dialog to the other monitor.
As far as Geany is concerned it knows nothing about dual screens since the window system is only telling it about one.
Cheers Lex
On Sun, Jul 24, 2011 at 12:56 PM, Lex Trotman elextr@gmail.com wrote:
The only reason for the dialogs to move is when the window manager says they can't be positioned where they were. This is probably what happens to Stephan as he moves between machines, the saved position on the dual display is illegal on the single one so the window manager just positions the dialog in a legal position and on close Geany saves that position which is reused next time on the dual display, effectively moving the dialog to the other monitor.
Once i learned that geany saves/restores the dialog positions it was easy. Before that i had never tried to move them myself because i assumed they would just revert the next time (as dialogs tend to do in many applications).