Re: [Pan-users] Firefox starts *behind* Pan window

[Duncan]

Maurice posted on Sat, 06 Jul 2013 12:53:36 +0000 as excerpted:

> On Sat, 06 Jul 2013 00:34:42 +0000, Duncan wrote:
> 
>> Do you have any window rules that could affect either pan or firefox?
>> Here, I have window rules for both,
> 
>   Where/what is your window rule for Pan, Duncan?

There's two ways to reach it.

1) In any window menu (the menu reached by clicking the app-icon in the 
titlebar), more actions, window manager settings (there's a couple 
options to set/modify the rules for that specific app or window also, but 
window manager settings is the general location with the list of all 
window rules).

2) The same window rules list dialog can be found in kde settings (I 
refuse to call them system settings since most of them are user specific 
kde specific settings! the kde3 name, kcontrol, was more accurate!), in 
workspace appearance and behavior, window behavior, window rules.

Once in that dialog, window rules should be the bottom entry, or at least 
it is here.  FWIW, I have a whole list of custom window rules here, since 
once I discovered this feature, I kept finding windows that didn't 
behave /quite/ the way I wanted, but that could quickly be solved with a 
window rule. =:^)

If you click on new, or if there's existing rules, select one and click 
on modify or double-click the rule itself, a second-level tabbed dialog 
opens, with window matching, size and position, arrangement and access, 
and appearance and fixes tabs.

The window matching tab contains the rule name/description (I use app 
name and if necessary window name/role, for instance pan main or pan 
prefs), along with all the conditions that determine which windows match, 
and a detect-window-properties button that gives you a cross-hairs 
selector to click on the window you want, which will then popup a third 
level dialog with some of the window information, and a selector to 
choose which elements you want to match, in ordered to pre-fill some of 
the match conditions (as well as the position element on the appropriate 
tab).

(It's worth noting that the tabs have evolved somewhat over time.  The 
window match elements used to be spread over two different tabs.  I like 
the single window-match tab far better as shows all the match conditions 
at once.)

The rest of the tabs let you set various aspects of behavior that you 
want.  Most elements have an activate checkbox on the left, the name of 
the element, whether it should remain unaffected (the default), applied 
initially (each time the window opens, but you can change the setting of 
the open window if you want, due to the way the detection works, 
sometimes this won't work if for instance you're matching on name, and 
the app opens a window /then/ sets its name), remembered (I've never 
actually used this one), forced (every time the window opens, you can't 
change it without changing the rule, but sometimes force is necessary if 
apply initially won't work), apply now (one-shot), or forced temporarily 
(only until the app is shutdown), and then the setting as appropriate, 
yes/no for toggles, xxx,yyy for size/position, etc.

I mentioned that I auto-set my pan main window (using my pan main rule) 
to "almost-maximized".  Window rules is how I do it, setting the position 
and size both (size and position tab, of course), using "apply 
initially".  FWIW, the match conditions are window class: substring 
match: pan pan (match whole window class checked), window role: exact 
match: pan-main-window, window types: normal window, window title: 
substring match: Pan.  (Machine hostname is "unimportant" for all my 
rules as I don't use that condition.)

I also have a pan prefs rule, that matches class pan pan (whole class 
exact), role pan-preferences-dialog (exact), type dialog window, title 
Pan: Preferences (exact).  This one has only one action element enabled, 
size, forced, to work around some strange presumably gtk bug that had the 
dialog waaayyyyyyy long (several times even my double-monitor screen 
height, IIRC).

As for firefox, I have a single rule, matching on class navigator 
(substring, whole class), role browser (exact), type normal, title 
unimportant.  This rule has several action elements enabled.  On the 
position tab, maximized vertically (force, yes), minimum size (force, 
958,1050, basically half-monitor-width, that's minimum size however so I 
can make it wider if desired), obey geometry restrictions (force, no).  
On the appearance and fixes tab, I have active opacity (force, 100%), 
inactive opacity (force, 100%, both of these are because I normally use 
window translucency, but find it doesn't work well for me with the 
browser), focus stealing prevention (force, none).

It's this last one, firefox rule, focus stealing prevention, that if set 
to high or extreme, will cause firefox to /always/ open in the background.

As mentioned, forcing keep-above (arrangement and access tab) will force 
firefox always to the front, but that's likely to be problematic as then 
you wouldn't be able to put anything else in front (unless it too was 
keep-above).  keep-above, apply initially, might work some better, as at 
least then you could turn off the keep above on the open window if 
desired, but it's still likely to be a hassle.

The other alternative, which might work better depending on how you use 
pan, would be to set pan's main window to keep-below, probably with apply 
initially so you can turn it off on the open window, if desired.

(Just in case you don't know where to set the titlebar buttons, that's in 
kde settings also, also in workspace appearance and behavior, but under 
workspace appearance, window decorations, hit the configure buttons 
button.  If you don't already have them on your titlebar, you can add the 
keep above and keep below buttons there, as well as customize button 
location and order, if desired.  Having those buttons on the titlebar 
will make toggling the keep-above/below state on an open window far 
easier. =:^)

>> if you've tried both pans on the same system (thus with the same kwin)
> 
>    I can't, because old Pan will not install on Mageia-3, which is why
> I've changed to new Pan!

That's what I thought.  But I wasn't sure, and the point remains valid 
whether you could actually try it or not, so...

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