On the one hand, libWINGs wasn't linking against -lX11 when it should
have been. And on the other, only libWINGs needs Xft, only wmaker needs
Xrandr, only wmaker and wmsetbg need Xinerama, only libwraster needs
Xmu, and -lpng may not need -lz.
Cleaning this up can help distributions get their dependencies correct,
and might even avoid loading the unused libraries at runtime, so we may
as well do it.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
Turns unhelpful
wmaker: warning: wrong option value for key "NewStyle". Should be one of new, old, next
into helpful
wmaker: warning: wrong option value for key "NewStyle". Got "YES", should be one of "new", "old", "next"
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
If we Restart() directly, the windows with titlebars come back N pixels
below their original positions before the xrandr-induced restart, where
N is the titlebar height.
To avoid this issue, let's do the proper restart preparation before
actually calling Restart().
Let's also grab ConfigureNotify in the event loop as in the patch
here: http://lists.kde.org/?l=kwin&m=116429907520188&w=2
(thanks to Tamas for pointing it out).
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
If you link against a library A that itself links against a library B,
it may or may not work to use symbols from library B in your executable;
this is known as "indirect linking". GNU ld does indirect linking by
default (but it can be disabled using --no-add-needed), but the new
experimental GNU gold linker does not do this. It's an easy fix for us,
as the tests are all already done in ./configure, we just need to tell
the Makefile.ams to use the results.
This should fix Debian bug #556677, if they ever start using this
branch.
[crmafra: Folded Andreas Metzler patch to update debian/changelog]
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
If the appicon is not in the dock/clip, or the dock/clip is not set to
"Keep on Top", there's a good chance you won't actually see the bouncing
because some other window is covering the appicon.
Besides adding the option to raise bouncing windows, this patch adds a
utility method to move a window back into its correct stacking position
after it has been messed with using XRaiseWindow.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
Since bouncing respects DisableAnimations option, there's no need
in #ifdef's.
Acked-by: Carlos R. Mafra <crmafra@gmail.com>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
I have my dock on the right edge of the screen, and my clip right next
to it. So the first icon underneath the clip is 64 pixels from the top
and 64 from the right. It seems silly for it to bounce downwards instead
of sideways like every other icon under the clip.
So make the choice of vertical or horizontal for docked icons be
relative to the dock or clip rather than absolute screen position.
Left/right or up/down is still chosen by screen position, as are
situations where the icon is a chess bishop's move from the clip.
I just spent an hour trying to find out why the latest wmaker-crm was
ignoring a number of the preferences in my configuration file. It turns
out the problem was that commit f41db5 added a value into the middle of
the enum in src/keybind.h, and the setting of
AUTOMAKE_OPTIONS = no-dependencies in all the Makefile.ams meant that
make wasn't smart enough to rebuild the files depending on it.
Would anyone mind if we just remove no-dependencies from
AUTOMAKE_OPTIONS? People can still run ./configure with
--disable-dependency-tracking to disable it at configure time.
On Wed, Sep 15, 2010 at 04:40:52PM +0200, Gilbert wrote:
>
> "." = {NoAppIcon = Yes;};
> "*" = {NoAppIcon = Yes;};
Oh, I see. It lets you override NoAppIcon generically instead of for
each app.
> Exactly, having 'DockApp' as the class name makes them behave more
> consistently internally. This might be fixed in some other way
> internally, but I couldn't figure it out...
Except it doesn't, the only thing it changes inside wmaker is that it
avoids displaying the name as "DockApp" on the settings window.
A "dockapp" is just an application that sets icon_window in WM_HINTS
(which causes a window to be displayed as the app icon) and
initial_state to WithdrawnState (which causes the main window to not
actually appear when the window is mapped). The class has nothing to do
with it.
The problems I mentioned stem from gtk+ not allowing you to set
initial_state to WithdrawnState. Openbox and fluxbox (and maybe others)
don't take the icon_window into their "slit" unless initial_state is
WithdrawnState, so the whole thing completely fails. Wmaker always uses
the icon_window for the app icon, so that part works fine, but the
"main" app window still flashes onscreen for a split second before the
app can call gdk_window_withdraw(), and wmaker applies SharedAppIcon to
it which winds up screwing up the "Kill" menu option.
That said, I've attached a patch to have wmaker treat any window with
class DockApp as if it had initial_state = WithdrawnState, and hopefully
openbox, fluxbox, and the like will pick up the idea too so gtk+
hacks[1] will no longer be needed. If this patch is accpeted, I'll poke
fluxbox and openbox to suggest the idea to them.
[1] E.g. http://wmudmount.svn.sourceforge.net/viewvc/wmudmount/dock.c?r1=8&r2=7
Subject: [PATCH] Improve dockapp recognition
Dockapps are traditionally recognized by having initial_state =
WithdrawnState in WM_HINTS. But some toolkits (e.g. gtk+) will not allow
setting initial_state in this way. So we offer an alternative: any
window with the res_class portion of WM_CLASS set as "DockApp" will be
treated as if it had initial_state = WithdrawnState.
This patch highlites appicon of a currently focused window.
Original-patch-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
When starting application (or opening transient dialog) bounce
its appicon.
Original-patch-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
When doing right-click in a window list menu open window menu.
Can be useful for sending here window from another workspace.
Original-patch-by: Pavel S. Khmelinsky <hmepas@yauza.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
MinimizeAllKey - minimize all windows on current workspace.
Original-patch-by: Pavel S. Khmelinsky <hmepas@yauza.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
[crmafra: AllMinimizeKey --> MinimizeAllKey]
When generating menus, lookup translations for menu entries in
specified textdomain. Often used by linux distributions.
Original-patch-by: Alexey Voinov <voins@altlinux.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
When unhiding window by clicking its appicon, unconditionaly
raise its frame.
Original-patch-by: Artem Delendik <u2u@nm.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
Instead of using the --disable-verbose-compile hack, let's
use the standard option --enable-silent-rules (or 'make V=0' directly)
available with autoconf 1.11 and higher.
This is enabled in autoconf by using 'silent-rules' in AM_INIT_AUTOMAKE.
The verbosity of compilation is reduced in a similar manner as using
the --disable-verbose-compile option, so we can remove all that ugly
hackery.
WUtil.h:212: warning: function declaration isn’t a prototype
WUtil.h:259: warning: function declaration isn’t a prototype
WUtil.h:300: warning: function declaration isn’t a prototype
WINGsP.h:593: warning: function declaration isn’t a prototype
WINGsP.h:599: warning: function declaration isn’t a prototype
WINGs.h:616: warning: function declaration isn’t a prototype
raster.c:295: warning: no previous prototype for ‘calculateCombineArea’
This patch makes wmaker automatically Restart() to take into account
resolution changes done by xrandr.
The motivation to write this patch is that when I start my laptop connected
to an external monitor (VGA1), the resolution in the monitor is initially
wrong (perhaps this is a bug in XOrg or OpenSuse, but anyway), so I always
do this after starting wmaker:
xrandr --output VGA1 --preferred
The resolution in the external monitor gets fixed, but wmaker does not
recognize the change automatically and I have to manually restart it.
So this patch avoids the last step by making wmaker be XRandR-aware.
Wmaker now restarts automatically when it receives a RRChangeScreenNotify
event and I don't have to do the last part of the silly procedure described
above.
I am not sure if restarting wmaker is the most elegant solution, but
it at least solves part of my issue with wmaker + xrandr.
In C, dividing two integers automatically rounds towards zero, so ceil(a
/ b) is useless as the result is truncated before ceil ever sees it. The
correct result for positive integers is obtained by (a + b - 1) / b.
I personally cannot stand stealing Ctrl+Wheel for resizing windows, so I
turned it off. But wmaker is still preventing Ctrl+Wheel from reaching
apps, which is certainly not the behavior I desire.
We grab Mod+Button events for our own purposes, and swallow them using
XAllowEvents(AsyncPointer) to prevent the client window from seeing
them. But if events are coming in fast enough (e.g. via fast wheel
scrolling) so that multiple grabbed events are in the queue, the second
queued event would be allowed to leak through to the client by the
unconditional XAllowEvents(ReplayPointer) a few lines later.
One misuse of CARD32 was missed back when someone fixed the 64-bit
issues (background: X has 8-bit, 16-bit, and "32-bit stored in a long"
data formats; on a 64-bit system, long is 64 bits). This was causing
minimized windows to be restored as shaded, and possibly occasional
crashes, when wmaker was restarted.
Also, throw in a safety check that 10 items really were returned before
trying to access them.
The "make dist" command can be used to generate the release tarball, but
only if the Makefile.am correctly specifies EXTRA_DIST, specifies
headers in foo_SOURCES, and so on.
Initialized variables that are conditionally set. In particular, this
construct is dangerous:
void *p;
if (something) p = couldReturnNull();
if (!p) p = fallbackFunction();
C99 defines new strict aliasing rules to allow compilers to make certain
optimizations. These rules prohibit converting an XEvent to an event
struct (e.g. XShapeEvent) that is not already in the XEvent union using
pointer type punning (e.g. "(XShapeEvent *)&ev"), and vice versa. The
canonical fix seems to be to create a union between XEvent and the
extension event struct to make the aliasing explicit, so do that.
A few internationalized format strings have only one %s in the default
while two strings are being passed. Change those defaults to have two
%s's, which means we also have to update the .po files to match. May as
well throw in the extra %s in the translated version while we're at it.
If a window has the skip_window_list flag set wmaker currently not only skips
this window from the window list (F11) but also from the switchpanel (TAB).
This patch makes skip_window_list-windows appear in the switchpanel and be
skipped only in the window list, strictly honoring what the name of the flag
is supposed to mean.
The motivation for this is that I have lots of workspaces and almost all of
them has a xterm, so that I set the skip_window_list for the xterms not to
overcrowd the window list. But I still want to alt+TAB to xterms on the current
workspace.
In addition to that, now the "internal window" flag is not checked before
appearing in the switchpanel.
- Kill unused vars in wrlib
- Add missing initializers to defaults.c:staticOptionList
- Re-format it slightly
- Kill some dead code
- Kill stupid "if (const op var)"
I noticed a bug today in menu workspace positioning (in the next tree):
if I right-click and hold the button down at the left edge of the
screen, the menu appears (correctly) half off the edge but will *not*
slide back onto the screen. Compare the behavior to right-clicking at
the right edge of the screen: the menu appears half off the edge, but
sliding the mouse to the edge causes the menu to slide until it is fully
visible.
Also, opening a submenu in this state positions the submenu as if the
menu were fully on the screen, leaving a gap between the menu and the
submenu.
If the menu happens to also go off the bottom of the screen, moving the
mouse to the bottom edge causes the issue to be magically fixed as soon
as the sliding upwards begins.
I also note inconsistent behavior when simply right-clicking (without
holding) to bring up the menu: at the right or bottom edge the menu
appears in the correct partially off the edge position, but at the left
edge it immediately jumps to be fully on-screen, almost as if
WrapMenus = YES were set for the left edge only.
I bisected it to d316260395. As far as I
can tell the "fix" there was to position the menu at the correct
negative X position but then lie to wmaker so it thought the menu was at
X=0. Presumably the "WrapMenus" behavior was the intended result.
Since (AFAIK) the window menu is the only one with this problem, why
don't we just check if x is too negative in OpenWindowMenu()?
When using Xinerama, make it possible only to cycle between those
windows that are on the currently active head - AFAICT this means
windows that have the majority of their area on the same head as
the pointer.
Patch complete with WPrefs integration, alas this being quite
unusable - for a lack of a better idea, I tucked the option on the
expert panel, making the item list too tall - making it scrollable
would be a nice addition.
The default for the new option (CycleActiveHeadOnly) should be NO,
that is, no change in default behaviour.
