-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When using --dontquit, application is not showing on-top of xlunch #88
Comments
--dontquit
, application is not showing on-top of xlunch
--dontquit
, application is not showing on-top of xlunch
Yeah that's expected. Not quite sure what behaviour you want, but by default xlunch is launched in full-screen mode. So when you launch a window it will appear below it (can't have full-screen windows below windowed ones in most WMs). Obviously when using desktop xlunch is redirected to the background so it's not an issue, and when using windowed it behaves just like any other window and is at the discretion of your WM. The fact that the panel appears when you open an application is the only thing that could really be considered a bug here, but that's probably either you WM or the bar itself which is doing something to show you that you've opened a window. |
The behaviour I'd like is that when using Fred |
Hmm, that is very strange. Probably something to do either with your WM or the attributes xlunch sets on the window. When I use |
For info: Just tested on JWM, and behaviour is slightly different. |
Yeah I think it's a WM thing. Might help if xlunch set some more WM hints, something to look at. |
Any news about this maybe ? Fred |
Well it's hard to fix something we don't know the cause of. If you find a program where this doesn't happen and run |
It happens with all programs I run from xlunch with windowed mode, no exception, all go underneath xlunch window. (for clarity: when using |
@PMunch, isn't there a problem with restack() ? Each time it is called (when desktop mode is disabled), it puts the xlunch window to front. And restack() is called in run_command(). Maybe we could call restack() only if --windowed is off? |
@fredx181 try to locate line 1048:
and put this there instead:
|
@Tomas-M, thanks for the suggestion, but... |
Well it calls |
That works ! I'll test further tomorrow, any scenarios to try specially to look for possibly strange behaviour side-effects? |
Tested more various ways (with line 380 commented out) on Openbox and JWM and could not find any negative side-effects. Fred |
@Tomas-M, I think the |
I implemented it this way:
So xlunch raised or lowered its window only for given focus mode. |
So... isn't commenting out line 380 a good improvement then ? |
What about this? f64953a |
Thanks, that works if using |
I thought your concern is only for windowed mode. The problem is that restack() is called in different situations. Once it is called during startup, to put xlunch either at background or to front. This should be IMHO preserved. Then, restack is called on focus in/out, to make sure that for example if it should be at background, then it always gets sent back even if your window manager thinks that focus should put it to front (eg when you click on xlunch somewhere while in desktop mode). Similarly, it should be forcibly sent to front even if your window manager thinks that focus out should send it to back, but as far as I can see right now it does not work that way on FluxBox. Finally, restack is called before clicked icon is executed, and here I do not understand your window manager, because even if xlunch puts itself to front, and THEN it executes the app, your window manager should put the app in front of xlunch. It is probably because it restacks on focusOut and it actually works properly on your window manager while it does not on my FluxBox as I mentioned before). Basically, what is your use case? Lets say you have your desktop with some windows open. Then you run xlunch, what you want to happen? You want to put xlunch to front on startup? So only xlunch is visible and other open windows are not visible? Then, when you click icon, what you want to see? Your application opens above the xlunch? So finally, you have old windows, covered by xlunch, and xlunch covered by newly opened applications? This stacking is not currently possible with xlunch unless you use --windowed |
Thanks Tomas for your explanation. |
Yes, that's right, I wasn't thinking clearly. |
Title says it already, but I noticed some other (strange?) things
This when using only
--dontquit
(not combined with--desktop
or--windowed
)As it's rather difficult to explain exactly, see also below animated .gif
What I did and resulting in:
Click Xterm, it flashes and gets underneath xlunch window
Panel has appeared, trying to bring Xterm up by clicking on taskbar icon, panel disappears. (and as I noticed afterwards, Xterm became minimized by clicking on the icon, which is expected behaviour).
Same as above by clicking on Gnome-mplayer
Same as above by clicking on Leafpad, but trying to minimize xlunch by clicking on it's taskbar icon, then again panel disappears.
When using
--dontquit
together with--desktop
, all is fine.Together with
--windowed
, also the application is not showing on-top of xlunch (then need to minimize xlunch to show the application).EDIT: Additional info: This is with Openbox WM, no Desktop provided by any program, just tint2 bottom panel and wallpaper set by nitrogen.
Did a similar test with xfce4-panel as bottom panel (replacing tint2), same result.
Fred
The text was updated successfully, but these errors were encountered: