Dana Jansens [Wed, 6 Jan 2010 22:30:42 +0000 (17:30 -0500)]
Improved menu behaviour
Make 'left' key in a menu close it's visible child menu and move to the parent
properly.
Make clicking on a menu item in a menu close any of its grandchildren and
remove focus from its children, effectively focusing the menu item you
clicked on.
Dana Jansens [Mon, 4 Jan 2010 20:07:10 +0000 (15:07 -0500)]
Some fixes for the submenu hide delay code
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
Dana Jansens [Mon, 4 Jan 2010 21:25:13 +0000 (16:25 -0500)]
Make the Focus action stop all interactive actions (Fixes bug #4436)
Old < 3.4.8 Openbox versions would stop focus cycling when focus moved. Now that is not the case, but you should be able to stop it by Choosing a window explicitly still.
Dana Jansens [Mon, 21 Dec 2009 14:51:11 +0000 (09:51 -0500)]
A fix for delayed hiding of submenus.
It fixes this:
(Mikachu) dana: i think his issue was if you have a menu with two
submenus s1 and s2, open the s1 submenu, then point to s2 and
go into s1, then after the delay, s1 is hidden despite you
being inside it still, because s2 was never unselected
Dana Jansens [Mon, 14 Dec 2009 20:40:09 +0000 (15:40 -0500)]
Allow the user to bind more than one keycode to a keysym for Ob Menus/Move/Resize
If the user has escape bound to more than one keycode then they can use any of
them to close a menu. This change applies to the hardcoded keys in openbox,
which are used for the menus and for move/resize, and maybe other places.
Dana Jansens [Thu, 10 Dec 2009 15:27:54 +0000 (10:27 -0500)]
Add an openbox.desktop file for the applications/ directory
This is for gnome-session to start Openbox correctly as the window manager
See the commit log for http://cvs.fedoraproject.org/viewvc/devel/openbox/openbox.desktop?revision=1.3&view=markup
Dana Jansens [Wed, 9 Dec 2009 21:00:32 +0000 (16:00 -0500)]
Make the edge detection fully include monitor edges.
This fixes the move-to-edge behaviour, when moving past the edge of a monitor,
the window will stop with its tail edge against the inside of the monitor's
edge.
Dana Jansens [Wed, 9 Dec 2009 19:59:18 +0000 (14:59 -0500)]
Find a valid image to use in the image cache. Fixes bug #1149
The larger of the width and height has to match. If the smaller matches, then
it would have to be resized down to fit inside the area, so that does not
count.
Dana Jansens [Wed, 9 Dec 2009 15:32:36 +0000 (10:32 -0500)]
Set a minimum value for the screenEdgeWarpTime for 25ms.
When this is very small it just gives X/Openbox a heart attack and ends up going forever. Even 25 is quite too fast to be usuable so it should be a good minimum.
Dana Jansens [Tue, 8 Dec 2009 16:11:41 +0000 (11:11 -0500)]
Change _net_active_window behaviour.
Move focus on _net_active_window "app" requests if focus stealing would be
allowed. If focus is not given to the target window and it is hilited (or
any other situation where it is hilited) and the window is on another desktop,
then also raise it and make it the LRU window, so when you switch desktops
you go right to it.
Bump glib req to 2.14 to get GRegex, now we only replace ~ with your
homedir in an action if it is (at the start of the string or preceded
by whitespace) and (at the end of the string or followed by (whitespace
or a slash)). (?:^|(?<=[ \t]))~(?=[/ \t$])
Fix interpretation of struts with multiple screens
According to the WM Specification, the left, top, right, and bottom
fields are to be declared relative to the overall X screen dimensions,
not the monitor dimensions.
The example given in the spec (v1.3 or 1.4draft2) is: "Another example
is a panel on a screen using the Xinerama extension. Assume that the
set up uses two monitors, one running at 1280x1024 and the other to the
right running at 1024x768, with the top edge of the two physical displays
aligned. If the panel wants to fill the entire bottom edge of the smaller
display with a panel 50 pixels tall, it should set a bottom strut of 306,
with bottom_start_x of 1280, and bottom_end_x of 2303. Note that the strut
is relative to the screen edge, and not the edge of the xinerama monitor."
In my case, I have a 1680x1050 monitor to the left of a 1920x1200 monitor
aligned at the top. I then have a gnome-panel along the bottom edge of
the 1680x1050 monitor with a height of 24 pixels.
xprop reports the following partial strut: _NET_WM_STRUT_PARTIAL(CARDINAL)
= 0, 0, 0, 175, 0, 0, 0, 0, 0, 0, 0, 1679 which is correct according to
the spec. Gnome-panel is reserving the 150 pixels along the bottom that
aren't visible on the screen plus the 25 it requests for itself.
However, maximizing a window on this monitor leaves a gap of exactly 150
pixels between the bottom edge of the maximized window and the top edge
of the panel.
Also, when the 1680x1050 monitor is the primary monitor (id=1) then the
_NET_WORKAREA property on the root window is also off by 150px for the
same reason.
This patch fixes the two issues I mentioned for exterior monitor edges.
It doesn't attempt to account for "interior" monitor edges (i.e. a 'left'
strut on monitor A when monitor B is directly to the left of monitor A)
because it's not possible to do so with the current strut specification
(see http://mail.gnome.org/archives/wm-spec-list/2004-March/msg00004.html
for a discussion on this limitation)
This could be avoided by having the partial strut atom contain a xinerama
screen ID that the strut applies to, but unfortunately the discussion
all those years ago never got anywhere.
Add "prev" and "next" as possible targets for moveto/resizeto actions.
One of the Debian users asked if it's possible to send a window to other
monitor when using xinerama, especially useful of you have 2 monitors and want
to toggle a window to the other one. I wrote a patch that implements next and
prev to also make that work for 3 or more workspaces.
As suggested in #3622, we don't need to open the default font for every
place that wasn't specified in the theme. Solved a bit differently than
the patch given there.