IgnorantGuru / spacefm

SpaceFM File Manager
http://ignorantguru.github.com/spacefm/
GNU General Public License v3.0
487 stars 73 forks source link

pop-unders from right-click dialogs #424

Open dolphinoracle opened 10 years ago

dolphinoracle commented 10 years ago

When right-clicking and using the spacefm desktop menu, the dialogs that open tend to open beneath any other open windows. This behavior is observed in fluxbox and jwm as configured in antix. The default antix icewm doesn't exhibit this behavior.

VastOne commented 10 years ago

Just throwing this to the wind, but it sounds like fluxbox layering issues... Does jwm use an apps file also that controls layering like fluxbox does?

fluxbox layers - Each layer has a number. The named ones are: 2-AboveDock, 4-Dock, 6-Top, 8-Normal, 10-Bottom, 12-Desktop.

You will want layer 2, 4, or 6 - maybe 8 - in ~/.fluxbox/apps file to keep the dialogues above the windows.

I had to do this with lxpanel in fluxbox to keep it above/below windows

IgnorantGuru commented 10 years ago

Dialogs opened from the desktop are probably parented by the root window, which is set below other windows. This may cause their dialogs to be too, although this seems like a window manager mishandling.

I might be able to force them to the top by leaving them unparented (NULL) and/or attempting to pop them to the top (although if they're set below other windows then they may not obey).

I don't have this problem in openbox.

dolphinoracle commented 10 years ago

I'm going to agree with IgnorantGuru, this seems to be a wm quirk. neither flux nor jwm were really designed with a desktop folder in mind.

I tried VastOne's suggestion to use the layer control in fluxbox to raise the dialog windows. What happened is that the whole desktop got raised, rather than just the dialog window, so that other open apps were covered by the desktop.

On Fri, Feb 14, 2014 at 8:10 PM, IgnorantGuru notifications@github.comwrote:

Dialogs opened from the desktop are probably parented by the root window, which is set below other windows. This may cause their dialogs to be too, although this seems like a window manager mishandling.

I might be able to force them to the top by leaving them unparented (NULL) and/or attempting to pop them to the top (although if they're set below other windows then they may not obey).

I don't have this problem in openbox.

Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/424#issuecomment-35143188 .

IgnorantGuru commented 10 years ago

I've made a change in ccfdf2d so the app chooser dialog opened from the desktop has a null parent (no parent window). If someone can test to see if this corrects the problem of the dialog not being on top in some WMs, I will look over the other similar dialogs. You can follow the BUILD NEXT instructions in README to test. Be sure to 'killall spacefm' after upgrading so you're sure you're running the new version on the desktop. Thanks.

EDIT: By app chooser dialog I mean right-click on desktop and New|Desktop Application.

dolphinoracle commented 10 years ago

built and tested spacefm-next as requested. In fluxbox and jwm, the desktop application item launches on top of other windows. This is also still true in icewm. In fluxbox and jwm, the other dialogs still open underneath open windows. In icewm all dialogs open on top as intended.

On Sat, Feb 22, 2014 at 9:26 AM, IgnorantGuru notifications@github.comwrote:

I've made a change in ccfdf2dhttps://github.com/IgnorantGuru/spacefm/commit/ccfdf2dso the app chooser dialog opened from the desktop has a null parent (no parent window). If someone can test to see if this corrects the problem of the dialog not being on top in some WMs, I will look over the other similar dialogs. You can follow the BUILD NEXT instructions in READMEhttps://github.com/IgnorantGuru/spacefm/blob/master/READMEto test. Be sure to 'killall spacefm' after upgrading so you're sure you're running the new version on the desktop. Thanks.

Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/424#issuecomment-35803759 .

IgnorantGuru commented 10 years ago

So I'm reading that the change fixed the problem in all WMs tested, for the app chooser dialog (the only one that has been changed thus far). Thanks for testing.

I'll look over the other dialog opened from the desktop and make similar changes.

IgnorantGuru commented 10 years ago

All desktop dialogs should now be on top - you can test using the next branch (see instructions above), due in 0.9.4 release.

This required extensive changes to pointers, so testing is appreciated - eg ensure all dialogs open, no segmentation faults, custom commands from desktop working, etc. Thanks.

IgnorantGuru commented 10 years ago

The problem with this change is that in 0.9.4, desktop dialogs are appearing on the wrong desktop when multiple desktops (workspaces) are used, at least in openbox. So it may not work to not parent them. This change may need to be reverted and the fix may need to be requested in the window managers that aren't handling root window parented dialogs correctly.

IgnorantGuru commented 10 years ago

869ec1c5f reverts the previous changes so desktop dialogs are again parented by the root window (due in 0.9.5). WMs that handle this poorly probably need to be fixed.