Maurice posted on Fri, 05 Jul 2013 11:27:55 +0000 as excerpted: > On Fri, 05 Jul 2013 01:51:05 +0000, Duncan wrote: > >> Unless I'm missing something, that would be a window-manager setting, >> not a pan or firefox setting. Probably something to do with >> focus-stealing- prevention. >> >> What window-manager are you using? > > KWin. And in System Setings/Window Behaviour the 'focus-stealing > prevention level is set at 'none'. > > Perhaps it's a KDE v. Gnome thing, as with KDE app's (e.g. Kmail, > Kwrite) Firefox does come up on top (i.e. steals focus), but it did not > happen with 'old' Pan.
FWIW, with focus-stealing-prevention set to medium, here... I just checked here and firefox (sometimes, see below) comes up behind pan when I click a link in pan, too. However, it has never been a big issue here, because I use kwin's window rules to force pan to a just-slightly-shorter- than-maximized size and position on my lower monitor, while firefox is normally vertically maximized and horizontally half-screen, so the firefox titlebar remains visible/clickable. Alternatively, since I have kwin set to "smart-position" new windows on the "active" desktop (the one the mouse is on), I can click the pan link and quickly point to the middle monitor instead of the lower (primary working) monitor, to have firefox open on the middle (secondary working) monitor instead. Here's the same screenshot I posted the other day as an illustration, tho in it it's claws-mail in feed-reader mode on the bottom monitor, with pan in the middle, but they're both in the "just-shorter-than-maximized" state I described, with a half-monitor firefox window visible below the claws-feeds window, the firefox titlebar accessible just above the feeds window (which is set to no titlebar). (Again, moderate NSFW warning due to swimsuit model firefox skin.) http://wstaw.org/m/2013/05/11/duncan-fullscreen.png **BUT**, the coming-up-behind behavior didn't match what I remembered from claws-mail in feeds mode, where I tend to click a LOT of links and often end up with a dozen or more firefox windows open (firefox is set to open a new window when I click a link in some other app). I (usually) have to click the (almost maximized) claws window to bring it back to the top, after clicking a link in claws, since firefox then (normally) opens above claws. And claws and pan are both gtk apps (gtk2 here, as I don't have gtk3 installed). So I began to think about it, and here's what seems to happen here. Consider: firefox has always been considered a somewhat large app, taking a bit to initialize, particularly for people running quite a few extensions. I've never had too much of a problem with it, partly because I run a reasonably fast machine, and partly because I've simply gotten used to it, but I know that firefox is infamous in some circles due to that launch delay, which apparently drives some (either more sensitive to it or with slower systems) crazy. So, what I found out after a bit of experimenting, is that when a firefox window is ALREADY running (perhaps minimized, or on another desktop), so the click (in either claws or pan) to open a new firefox window doesn't have to start a new firefox, just a new window of an existing firefox, firefox opens that new window fast enough that it appears ON TOP of what I was doing. But if firefox is NOT already running, so opening the new firefox window has to launch firefox as well, not just open a new window of an existing firefox, THEN the firefox launch process apparently takes just enough additional time that kwin doesn't associate it with the click that opened the window, and considers it a random window popping up instead, in which case it opens UNDER/BEHIND pan or claws-mail/feeds. So the distinction appears to be whether firefox is already running in another window or not, and thus whether it has to do all the extra work of initializing (opens behind), or whether it's simply opening a new window in an existing instance (opens in front). Try it there and see. If you don't have the screen-space to comfortably do it on the same desktop, open firefox on a different desktop, then switch to the one you're running pan on, and click a link. If I don't miss my guess, firefox will then open on top, since it doesn't have to do full initialization since it's already running, and thus will open fast enough that kwin associates it with opening in response to the click and acts accordingly, putting it on top. But without firefox already running, it'll open too slowly, and that association is lost, so kwin opens it behind. At least that's the behavior I see here, with medium focus-stealing prevention, on a reasonably fast machine. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
