Use the following in your per-app rules:
<size>
<width>A</width>
<height>B</height>
</size>
A and B can be integer values to specify a size in pixels. They can also be
percentages or fractions to be relative to the size of the monitor the window
is placed on.
In Openbox 3.4 we used the group leader's WM_CLASS value when it was available.
This prevents windows in the group from overriding with a specific value,
however which is bad. More rationale can be found in
http://icculus.org/pipermail/openbox/2010-September/006790.html
Some applications (eg. Firefox) use command line flags to set the WM_CLASS
property on the group leader but do not change the property on the mapped
windows themselves. This makes matching these windows not possible in Openbox
3.5.
We resolve this by exposing the group's WM_CLASS values alongside the individual
window's values. We add _OB_APP_GROUP_NAME and _OB_APP_GROUP_CLASS properties
along with "groupname" and "classname" attributes for the rc.xml application
tag.
Bug #5152 - "mouse double-click time is too low by default - 200ms"
We only use the doubleclick in one place in the default configuration,
for doubleclicking titlebars to maximize windows, so any negative impact
of increasing the timeout should be minimal, especially with the
addition of requiring the two clicks to be in the same place.
Doubleclicks are hardcoded to occur within 8 pixels for now, it doesn't
seem worth it to add a config until someone complains. A possibility is
using the drag threshold, but some people have that set very low so it
could be hard to doubleclick then.
Add a Primary option for which monitor to place new windows on. Make "Active" the default instead of "Any", which is just totally crazy.
When a window is being placed in the FOREGROUND, use a monitor chosen in
the following order:
1. same monitor as parent
2. primary monitor if placement=PRIMARY
active monitor if placement=ACTIVE
pointer monitor if placement=MOUSE
3. primary monitor
4. other monitors where the window has group members on the same desktop
5. other monitors where the window has group members on other desktops
6. other monitors
When a window is being placed in the BACKGROUND, use a monitor chosen in the
following order:
1. same monitor as parent
2. other monitors where the window has group members on the same desktop
2a. primary monitor in this set
2b. other monitors in this set
3. other monitors where the window has group members on other desktops
3a. primary monitor in this set
3b. other monitors in this set
4. other monitors
4a. primary monitor in this set
4b. other monitors in this set
Decide to focus the new window before placing it, so we know if it will be
placed in the foreground or background.
Always choose a single monitor, then place on it, rather than possibly moving
to a "backup" monitor. Unpredictable monitor placement is horrible.
Add _OB_VERSION property on the root window.
Change _OB_ROLE/CLASS/NAME to _OB_APP_*.
Add _OB_APP_TYPE which has a string for the type chosen for the window on
mapping by Openbox.
Adjust the rc.xml to match these changes.
When nothing in a menu is selected, go back to selecting the open submenu.
Adjust the LeaveNotify event handling to only respond when there is not a
EnterNotify coming for the same menu frame.
Change the default submenu show/hide delays.
Have the default values for submenu show/hide match the default rc.xml
A couple of things were wrong, the parser added 1 to the value despite
expecting the user to give values in the range of 1 to
screen_num_monitors, rc.xml documented the values to start from 0 and
finally the monitor value wasn't copied over at all when matching the
client.
Diffing against the old work branch where most of the changes
in backport were cherry-picked from indicates this should be
alright. (0de9097017d4d1991388a35e380a57dc1135b431)
