[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Firefox starts *behind* Pan window
From: |
Duncan |
Subject: |
Re: [Pan-users] Firefox starts *behind* Pan window |
Date: |
Sat, 6 Jul 2013 16:23:19 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 368aae4 /usr/src/portage/src/egit-src/pan2) |
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
- [Pan-users] Firefox starts *behind* Pan window, Maurice, 2013/07/04
- Re: [Pan-users] Firefox starts *behind* Pan window, Duncan, 2013/07/04
- Re: [Pan-users] Firefox starts *behind* Pan window, Maurice, 2013/07/05
- Re: [Pan-users] Firefox starts *behind* Pan window, Duncan, 2013/07/05
- Re: [Pan-users] Firefox starts *behind* Pan window, Maurice, 2013/07/05
- Re: [Pan-users] Firefox starts *behind* Pan window, Duncan, 2013/07/05
- Re: [Pan-users] Firefox starts *behind* Pan window, Maurice, 2013/07/06
- Re: [Pan-users] Firefox starts *behind* Pan window,
Duncan <=
- Re: [Pan-users] Firefox starts *behind* Pan window, Maurice, 2013/07/06