Tomas-M / xlunch

Graphical app launcher for X with minimal dependencies
http://xlunch.org
GNU General Public License v3.0
219 stars 37 forks source link

When using --dontquit, application is not showing on-top of xlunch #88

Closed fredx181 closed 6 years ago

fredx181 commented 6 years ago

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:

xlunchdemo

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

PMunch commented 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.

fredx181 commented 6 years ago

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

PMunch commented 6 years ago

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.

fredx181 commented 6 years ago

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)

PMunch commented 6 years ago

Yeah I think it's a WM thing. Might help if xlunch set some more WM hints, something to look at.

fredx181 commented 6 years ago

Any news about this maybe ? Would be a good improvement if this can be fixed for windowed mode, IMHO.

Fred

PMunch commented 6 years ago

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.

fredx181 commented 6 years ago

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)

Tomas-M commented 6 years ago

@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?

Tomas-M commented 6 years ago

@fredx181 try to locate line 1048:

restack();

and put this there instead:

if (!windowed) restack();
fredx181 commented 6 years ago

@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 :)

PMunch commented 6 years ago

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..

fredx181 commented 6 years ago

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?

fredx181 commented 6 years ago

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

PMunch commented 6 years ago

@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?

Tomas-M commented 6 years ago

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 :)

fredx181 commented 6 years ago

So... isn't commenting out line 380 a good improvement then ? As I said earlier, works fine for me (and without any bad consequences).

Tomas-M commented 6 years ago

What about this? f64953ac128d2b5a4681184e9715f2c1e7aa46bc Is it what you want?

fredx181 commented 6 years ago

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 ?

Tomas-M commented 6 years ago

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

fredx181 commented 6 years ago

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.

fredx181 commented 6 years ago

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 :)