password prompt always appears on the left-most monitor

[mathstuf]

So this is fun. The window always pops on the left monitor, but my right monitor is the primary. The window size is determined by the screen where the pointer currently is, but my right monitor is 1080p versus 1440x900 for the left one, so the size gets proportioned and the buttons and input overlap. I think just popping up on the screen with the mouse (or keyboard focus; not sure which) would be better.

[coldfix]

indeed, this sounds fun:)

First, I don't have any experience with multiple screens (I just use one at a time), so all of the following may be wrong:

I thought the responsibility for moving new windows to the correct screen should be kept within the window manager rather than the applications themselves. At least in awesome you can configure on which screen a window will appear I believe. Can you check whether there is such configuration options in your window manager?

Further, if your window manager (or some other component?) does any size rescalings depending on which screen the window is located on, it should IMO also be smart enough to use the correct screen for this computation. If it can't do this, it looks like a bug to me that should be reported over there. (B.t.w. I didn't even know that you can change the proportion on different screens, but maybe I misunderstand the whole issue.)

There is currently no special code in udiskie to make the dialog appear on any particular screen. From a quick glance at the GTK APIs, the implementation should look something like this:

display = Gdk.Display.get_default()
screen = display.get_pointer()[0]
dialog.set_screen(screen)

is this what you had in mind?

[mathstuf]

On Fri, Sep 25, 2015 at 19:04:59 -0700, Thomas G. wrote:

I thought the responsibility for moving new windows to the correct screen should be kept within the window manager rather than the applications themselves. At least in awesome you can configure on which screen a window will appear I believe. Can you check whether there is such configuration options in your window manager?

There is, but it'd be a hack (I need this for no other app so far). Anyways, this seems to be a bug in XMonad itself.

Further, if your window manager (or some other component?) does any size rescalings depending on which screen the window is located on, it should IMO also be smart enough to use the correct screen for this computation. If it can't do this, it looks like a bug to me that should be reported over there.

Like I said, it seems that it wants to show up there, but it gets moved for some reason. After some more careful debugging, it seems that the problem arises only when focus is on one montior, but the cursor is on the other. It gets sized on the cursor-screen, but moved to the focus-screen causing the ratio resize. This also happens with a stripped down manage hook. I'll file a bug against XMonad.

Thinking about it, I never really had any apps which have popped up, so I guess this is just bugs in my configuration (well, here, WM itself) that I've never hit before :) .

(B.t.w. I didn't even know that you can change the proportion on different screens, but maybe I misunderstand the whole issue.)

This XMonad's doing. It stores window geometry using ratios with 0 being top/left and 1 being bottom/right (negative and greater than 1 being off-screen). I can see this if I tell XMonad to move the window from one monitor to the other, but if I drag it across, it doesn't change size.

There is currently no special code in udiskie to make the dialog appear on any particular screen. From a quick glance at the GTK APIs, the implementation should look something like this:

This may be related to not having a transient parent?

[mathstuf]

By the way, this would probably be helped by having size hints or something on the dialog layout if they're not already there.

[coldfix]

I'll file a bug against XMonad.

Sounds good.

This XMonad's doing. It stores window geometry using ratios with 0 being top/left and 1 being bottom/right (negative and greater than 1 being off-screen). I can see this if I tell XMonad to move the window from one monitor to the other, but if I drag it across, it doesn't change size.

Ah, I see.

This may be related to not having a transient parent?

Possibly, this was also my first thought, but I'm still not entirely sure, what exactly transient window does for you. Did you try using the patch from #76?

By the way, this would probably be helped by having size hints or something on the dialog layout if they're not already there.

I don't think so. The window should be automatically layouted according to the sizes of the different buttons and controls - which depends on theme settings such as text height, borders, etc. To me the issue you described sounds like XMonad layouts the dialog on one screen, then moves it to another screen while keeping the relative window size the same and thereby effectively decreasing the absolute window size forcefully below the minimum size requirements.

[mathstuf]

Yeah, it doesn't look like XMonad respects WM_SIZE_HINTS. Boy, I can't wait for Wayland :) .

[coldfix]

Closing this for now, since I believe this is an XMonad/configuration specific issue. Notify me, if you discover an easy fix from within udiskie.