| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
openbox/config.c
openbox/event.c
openbox/prop.c
openbox/prop.h
openbox/screen.c
openbox/screen.h
|
|
users.
The hints are _OB_ROLE, _OB_NAME, and _OB_CLASS.
|
|
See http://live.gnome.org/SessionManagement/GnomeSession#A1._Launch
Gnome-session sets the DESKTOP_AUTOSTART_ID env variable with the SM client id
instead of passing it on the command line.
|
|
|
|
This matches the behaviour of the focus cycle and key chain popups.
|
|
This reverts commit 2e1adce628ee3234accc5d88cafb57672800cae0.
|
|
popup while it is going to be shown later by a delay."
This reverts commit 33328583a143677d27eb3d081ce66532c3aaca1c.
|
|
popups will appear
|
|
|
|
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.
|
|
Previously it would only react if the height of the strut changed, not if its
start/end changed (that was a long-standing bug).
|
|
|
|
window which is no longer visible is still focused.
|
|
|
|
|
|
Also, maximized windows were having their client padding reduced by the size of
the outer border from this same bug, which is now fixed.
|
|
rc.xml. Fixes bug #4350
|
|
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.
|
|
This allows transient windows to be above helper windows. And generally keeps
helper windows below transients, unless they are raised directly.
|
|
Conflicts:
openbox/actions/all.h
openbox/actions/session.c
openbox/client.c
openbox/event.c
openbox/grab.c
|
|
|
|
client_activate() is a helpful way to focus a window on another desktop,
but only Openbox is allowed to do such things, user messages cannot.
|
|
Applications should be better behaved by now, and GTK based apps seem to be
at least. We can file bug reports with them if we need to still.
|
|
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.
|
|
|
|
Just "do the right thing" based on if you are connected to a session manager
or not.
|
|
Conflicts:
openbox/popup.c
|
|
them "undecorated" with the keepborder config option on.
This fixes what commit 85f39cd27e7ea0eec8bc78f6139092b44fda2dad fixed for the
fullscreen window case, but also fixes bug #4344.
|
|
struts with multiple monitors.
|
|
while it is going to be shown later by a delay.
|
|
|
|
|
|
|
|
Just kidding. This doesn't revert d81d54c7a977a034199f24fc8fa7433e634aaf91 but
it redoes the work that patch reverted in a better, less intrusive, way.
|
|
This reverts commit fd2f617be7ff57fcb187daa737f66d243544c8cd.
This reverts commit a47d0a53652a96ca1df96fc9268757df1431ae55.
This reverts commit a1908e076736e1a618bd305c5963dbfecaa30497.
This reverts commit dc2e6f6bf7143a56de360a393b33906735e63625.
This reverts commit 985e7dadf9a3ebf4bd265d955c3198e96405e5d2.
This reverts commit db781556d63d1a50bd1b1b4b6b5423ef703bf2c7.
This reverts commit feec8f663f0a11546c2da87575fecc8a88d97ca1.
|
|
Add asserts to default: in switch statements
Store pointed to variables locally so it knows they don't change
Remove some dead assignments
Mark ob_exit_with_error as noreturn
Use "%s", msg instead of just msg to printf style functions
Use the c_pfocus variable
|
|
|
|
|
|
|
|
Google's chrome does this when you toggle window decorations.
Based on patch in #4250 by Daniel Erat.
|
|
|
|
Conflicts:
openbox/actions/desktop.c
openbox/client.c
openbox/event.c
openbox/extensions.c
openbox/popup.c
openbox/screen.c
parser/parse.c
|
|
It doesn't look good in some places, e.g. WnckTasklist (gnome-panel)
[ Also update translations -- Mikael ]
|
|
|
|
Currently you can't mark anything that comes after the __ with _ to make
that a shortcut.
|
|
We check that xinerama is active already, but someone got a NULL here.
|
|
|
|
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.
[ quoted from bug #3792 ]
|
|
|
|
This should be a satisfactory fix for #3694 I hope.
|
