Closed fredx181 closed 6 years ago
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 --dontquit
, the application goes on top of xlunch.
I see now, as you say, that it's not normal behaviour with full-screen, but it's also not the case if I use --dontquit --windowed
together.
Can't bring the application (that I just ran from xlunch) up (from the taskbar icon), need to minimize xlunch (click twice on xlunch-window taskbar icon) to see the application I just ran.
Can you confirm that ?
(also, btw, the applications that I have already opened before launching xlunch in windowed mode, I can't bring them up either, need to minimize xlunch to see them again)
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 --dontquit --windowed
and start an application it appears above xlunch. But this is with using i3 which isn't really made for floating windows, so it might be ignoring a lot of the hints around those. It seems like i3 is somehow given priority over the other windows, but I'm not quite sure what would cause that.
For info: Just tested on JWM, and behaviour is slightly different. Same that running an application get underneath xlunch, but I can bring it up by clicking on it's taskbar icon. (not needed to minimize xlunch as it's the case on Openbox)
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 ? Would be a good improvement if this can be fixed for windowed mode, IMHO.
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 xprop
in a terminal and click that window it might give us some more insight.
If you find a program where this doesn't happen
It happens with all programs I run from xlunch with windowed mode, no exception, all go underneath xlunch window. (for clarity: when using --dontquit --windowed
together)
@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:
restack();
and put this there instead:
if (!windowed) restack();
@Tomas-M, thanks for the suggestion, but... Tried that and makes no difference, still programs go under xlunch on Openbox. Anything else I could try maybe?, I'd be happy to test, as I said I'm a big fan of your program :)
Well it calls restack
before it forks, so it makes sense that that doesn't do a whole lot. It does however do a restack
when it get's focus events. So try to comment out line 380, that should stop it from going above other windows, but might make it behave strangely in other scenarios..
So try to comment out line 380, that should stop it from going above other windows, but might make it behave strangely in other scenarios
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. Behavior of windowed mode works as it should be IMO now. Thanks again @PMunch !!
Fred
@Tomas-M, I think the restack
thing was something you added before I came to the project. Do you remember why it moves up the stack if it's not quitting?
I implemented it this way:
void restack()
{
if (focusmode==LOWEST) XLowerWindow(disp,win);
if (focusmode==TOPMOST) XRaiseWindow(disp,win);
}
So xlunch raised or lowered its window only for given focus mode. I do not remember that at all, but I found it in github "Blame" mode :)
So... isn't commenting out line 380 a good improvement then ? As I said earlier, works fine for me (and without any bad consequences).
What about this? f64953ac128d2b5a4681184e9715f2c1e7aa46bc Is it what you want?
Thanks, that works if using --windowed
but not with full screen.
Commenting out line 380 works with both, but I guess you have reason for making it only work for --windowed
, I'm curious, why ?
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.
I need to digest (it's a bit overwhelming info for me at the moment).
Probably you are right about that's it better only for --windowed
I'll be back later after more testing and thinking about it.
I thought your concern is only for windowed mode.
Yes, that's right, I wasn't thinking clearly.
I personally would use --dontquit
only in combination with --windowed
So your fix is fine, thanks again :)
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