| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Only the chroot popup uses delayed mapping so this is just a latent bug.
|
|
data is incremented one too many times when y2sz is zero, leading to
memory corruption.
[ also changed % 2 to & 1 -- Mikael ]
|
|
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.
|
|
the window to become unmanaged
|
|
|
|
This caused problems for placing windows with decor turned off, the
placement code thought they had it on.
|
|
|
|
More things need to be case insensitive and whatnot.
|
|
|
|
|
|
Some compilers, like sun studio and clang don't support them.
|
|
|
|
|
|
Conflicts:
openbox/config.c
|
|
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.
|
|
Conflicts:
openbox/event.c
openbox/frame.c
|
|
|
|
Many composite apps use this to pass through clicks where they are transparent.
|
|
|
|
Apparently on solaris, you can't invoke -x scripts via "sh install-sh".
|
|
|
|
avoid overriding bar=no
|
|
Using format specifiers without arguments in printf is still bad.
openbox/debug.c:105:18: warning: format string is not a string literal (potentially insecure)
fprintf(out, log_domain);
^~~~~~~~~~
openbox/debug.c:107:18: warning: format string is not a string literal (potentially insecure)
fprintf(out, level);
^~~~~
openbox/debug.c:109:18: warning: format string is not a string literal (potentially insecure)
fprintf(out, message);
^~~~~~~
|
|
Conflicts:
openbox/event.c
|
|
This poses a small problem. We currently let translators reorder this
string, but ngettext only takes one numeric argument. This means that you
can either get correct pluralization or the order you want, but not both.
I fixed up the languages I understand at a very basic level, but the
rest will need translator assistance.
|
|
openbox/client.c:269:10: warning: incompatible pointer types passing 'gint *', expected 'guint32 *'
if (!OBT_PROP_GET32(self->window, NET_WM_USER_TIME, CARDINAL, &user_time))
^~~~~~~~~~~~~~
|
|
didn't come from the user.
Instead, just activate the flashy thinger.
|
|
|
|
|
|
|
|
|
|
Conflicts:
openbox/client.c
openbox/prop.c
openbox/prop.h
|
|
|
|
It failed to increment a variable after finding a $ but no pid or wid,
which led to a fun infinite loop. Also don't check if c[1] is w if we
already established it was p.
|
|
|
|
This reverts commit 73adc6480d59fc5dccf9fe19ed5234c9582b328c.
I know I had a good reason for reverting this commit, I don't know what
that reason was though.
|
|
The code assumed the timestamps had the same domain as the type Xlib
uses for them, which is almost never the case with Xlib. Change all
involved variables to guint32.
|
|
optimize the gradient code better with all the pointers going on
|
|
Without this, urxvt won't use motif hints for borderless mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
error message.
|
