When changing workspaces, after focusing new window, wmaker handles all
pending events. If it receives another change-workspace combination,
you may end up with a workspace without any focused window.
Ctrf-F1 and Ctrl-F2 used to switch to 1st and 2nd workspaces.
Hold Ctrl and press F1 and F2 almost at the same time.
This patch ignores all change-workspace commands while workspace
change is in progress.
See also https://bugzilla.altlinux.org/show_bug.cgi?id=7230
[crmafra: Thanks to Alexey I. Froloff for the above explanation]
The man page of XChangeProperty() says:
"If the specified format is 32, the property data must be a
long array."
And as we call it with format 32, the type of 'data' must
be 'long'. It happens to work nowadays in 32-bit architectures
because sizeof(CARD32) = sizeof(long), but that is no longer
true in 64-bit mode.
This patch was downloaded from
www.openbsd.org/cgi-bin/cvsweb/ports/x11/windowmaker/patches/patch-WINGs_wwindow_c
and I thank Alexey I. Frolov and Vladimir Nadvornik for helping me
to understand it on a wmaker-dev thread.
For those not familiar with the way Macs cycle windows, the Command-Tab
sequence (Alt-Tab elsewhere) switches between DIFFERENT application windows
and Command-Grave (key above tab) switches between windows owned by the
SAME application as is currently focused. So if you had three Safari and
two Finder windows open, and Safari had focus, Command-Tab would switch to
Finder; Command-Tab would switch back to Safari; Command-Grave would switch
to a different Safari window etc.
This patch implements "something like" the above by only populating the
switchpanel with windows matching the currently-focused WWindow's wm_class
when the new cycling mode is activated. In practice this means you can
switch to The Next XTerm or The Next Firefox Window using this method.
The configuration names for these new shortcuts are GroupNext and
GroupPrev. The patch tells WPrefs.app about them. Of course switching to
The Next Window is still possible with the (unchanged) FocusNext and
FocusPrev keys.
Allow wmsetbg to revert to pre-0.90.0 behaviour when choosing a
background image that is large enough to span several heads in a
Xinerama setup. If the -X flag is passed to wmsetbg, the background
image will be stretched to fill the logical screen (as it would be by
default in older versions of wmsetbg) instead of being tiled across
screens.
Shift the workspace name, shown when switching workspaces, by 32
pixels. This is purely for aesthetic reasons. It just looks better
(IMO) than having the name flush against the screen edge.
When switching workspaces, force the name to be shown entirely within
one head of a Xinerama display. Previously the name would span heads if
set to TOP, CENTER or BOTTOM alignment, and was hence hard to read when
the display comprised an even number of heads.
This patch combines two small patches which fix issues with x86_64 and mmx in
the configure script.
Submitted by: Gilbert Ashley
Author: unknown?
Origin: ALT/Sisyphus Linux, Alexey Voinov <voins@altlinux.ru>
If the old_geometry coordinates were saved while the window
was in another xinerama head, use current coordinates as
the old ones to avoid making the window jump heads when
un-maximizing it.
This patch removes bits and pieces of xmu that for some reason
have been bundled with wmaker. I can very well imagine that at the time
they were bundled, xmu was not, was not available everywhere, or
whatever.
I couldn't come across a system that doesn't have these things in its
system-supplied x libs, though i've been carrying this since january,
and my memory is quite flakey at times.
certainly nothing xorg is at danger, nor xfree86 dating back to at
least 3.3. i believe this stuff should be everywhere that calls itself
to be on par with x11r6.3 at the very least.
it would be incredibly useful if people having access to commercial
unixes could check this on things released in the past, say, 15 years.
i believe back then i had solaris 8+and sco openserver 5+ covered.
When a maximized window is resized (either using wmaker or because the
application changed the window size), and you want to maximize it again,
you first have to unmaximize it (because wmaker thinks the window is still
maximized), and only then you can maximize it. The following patch
corrects this behaviour.
The patch "Clean up maximization and un-maximization logic" introduced
a regression wrt to the left/half maximization feature, due to a C
operator order precedence issue.
With this patch, minimized windows do not reshuffle anymore.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361241
where Martin Hinsch reported:
"The behaviour of icons (minimized applications) is severely broken when
automatic placement is switched on.
* When switching the workspace icons often stick thereby covering (and
hiding) icons on the workspace one is switching to.
* After minimizing an application, clicking (singly or doubly) on one of
the icons causes all of them to reshuffle, usually in a way that the
icon in question changes its place (which is extremely annoying).
* Icon placement ignores the dock so that icons disappear behind
it/cover it.
All of these suddenly appeared about a year ago (I think with 91.0). The
problems are not architecture-specific since they occur in exactly the
same way on my pentium machine. Wiping the complete configuration (rm -r
~/GNUstep) did not make a change either."
This fixes a compilation failure with gcc-4.3.4, where it complains
nxpm.c: In function RGetImageFromXPMData:
nxpm.c:99: error: expected expression before ] token
...
There is no point in having a buffer capable of 512 simultaneous events,
as it will typically be only 1. But increase the value for the length
of the path + filename to 64 (which is a reasonable size for a
typical /home/something/GNUstep/Defaults/WMRootmenu filename).
This patch adds history to some dialog boxes. To use it replace %a with
%A in menu file (like in "Run..." menu item). You can specify third
parameter to %A to use different histories for differen dialogs.
All history files is kept in ~/GNUstep/.AppInfo/WindowMaker/ and the number of
history lines controlled by DialogHistoryLines parameter (one for
all dialogs) defaults to 500 lines.
It also adds Tab completion.
Origin: ALT/Sisyphus Linux, Alexey Voinov <voins@altlinux.ru>
This patch is from the contrib directory. It adds an option to allow starting
DockApps with a single click. It's a handy option that adds only a few lines to
the code.
It is a good feature patch example because it includes modifications
to the WPrefs application so that the feature can be easily enabled or
disabled. The one-click ability allows wmaker to integrate more seemlessly with
programs like ROX-Filer which can be configured to use single or double click
actions.
The README in the contrib/ directory says,
author:
Sebastien Bauer <seb_bauer@bigfoot.com>
John Morrissey <jwm@horde.net>
updated for Window Maker 0.65.0 by:
Daniel Richard G. <skunk@graphics.lcs.mit.edu>
updated for Window Maker 0.80.2 by:
Martial Daumas <martial@nasgaia.org>
update for 0.80.2+ by:
steve lion <steve.lion@verizon.net> and vlaad
We should not try to un-maximize the windows from inside
the function wMaximizeWindow(), as that makes no sense.
If the window is already maximized then we don't call
wMaximizeWindow() anymore and call wUnmaximizeWindow()
instead, which will use the old geometry regardless
of which maximization is active (horizontal, vertical,
maximus, etc). And the old geometry now is also saved
when we enter wMaximizeWindow().
So when we call wMaximizeWindow() or wUnmaximizeWindow()
we really mean "maximize to the specified state" or
"go back to whatever old geometry coordinates we had before".
This patch introduces the "tiled maximization" feature, a.k.a. Maximus.
By pressing the keyboard shortcut associated with Maximus, the focused
window will be maximized to the greatest area satisfying the constraint
of not overlapping existing windows.
Bug overview: right after start up, omnipresent AppIcons (living in the Clip)
are displayed but non-functionnal.
How to reproduce it: place two AppIcons in the Clip, make the first one (A)
omnipresent and leave the second one (B) as is. Make the Clip "autocollapse".
Switch to the second workspace and restart wmaker. Wmaker starts in the first
workspace; the Clip is closed (its text color corresponds to the closed state,
AppIcon B is not shown). However, AppIcon A is displayed. Moreover, A does
not react when the Clip expands or collapses. Finally, a click on A makes it
disappear. Fortunately, changing to another workspace fixes the problem
definitively.
Explanation and correction: internally, wmaker maintains as many clips as
workspaces. When the user switches to another workspace, the omnipresent
AppIcons are moved to the new "current" clip. In the situation above (trying
to reproduce the bug), when wmaker restarts, the omnipresent AppIcons are
restored in the second workspace, whereas the first workspace is active. In
the previous code, a "hack" (calling XMapWindow()) unconditionally displayed
the omnipresent AppIcons. The proposed patch makes sure the omnipresent
AppIcons are moved to the first workspace on wmaker startup.
This is a bug fix. Bug overview: if an AppIcon is moved rapidly over a Clip
set to auto-expand, the latter may erroneously auto-expand afterwards.
How to reproduce it: set a Clip to auto-collapse, and make sure it contains a
(random) AppIcon, so as to easily visualise its open/close state. Now move
rapidly an AppIcon over the Clip. Try to move it so fast that the cursor
sometimes is out of the AppIcon's tile. Then, replace the AppIcon out of the
Clip.
Explanation and correction: if, while the AppIcon was being moved, the mouse
cursor entered at least once in the Clip's tile, the latter is going to
receive an EnterNotify event (after the AppIcon is replaced) and thus expand
automatically after the relevant delay. The solution is to simply "gobble"
(i.e., ignore) all EnterNotify events when moving an AppIcon.
Moved the half_scr_width calculation to after the
usableArea = wGetUsableAreaForHead(scr, head, &totalArea, True);
call. This fixes the problem where windows that get "half screen
maximized" cover the dock or clip.
Instead of open coding the animation routines in the function bodies,
put them in a helper function called shade_animate(wwin, what), whose
second argument can be SHADE or UNSHADE.
This adds Left Half / Right Half Maximize capability to WindowMaker.
It allows you to maximize a window to only the left or right half
of your screen.
It is useful on widescreen displays where one might to bring up
two different windows side-by-side.
This patch cleans up an obvious code duplication case in the
different "placement" algorithms.
Avoid this needless repetition by using a helper function,
which in turn lets those functions a bit easier to read and
also makes wmaker 0.11% smaller :-)
[mafra@Pilar:wmaker.git]$ size src/.libs/wmaker.*
text data bss dec hex filename
619824 19160 8544 647528 9e168 src/.libs/wmaker.new
620552 19160 8544 648256 9e440 src/.libs/wmaker.old
The "Kill Application" dialog window doesn't always show the
application name when killing DockApps. It shows its wm_class
instead, which is not always the same as the app name.
This patch allows the Kill Application dialog window to show
the application name in the window -- as expressed by using the
basename of the path to the application.
[crmafra: Added wtokensplit() to get only the app name]
These are some of the fixes sent to the wmaker-dev list by
Vladimir Nadvornik, with minor modifications to address Dan
Pascu's concerns.
Original-post: http://lists.windowmaker.info/dev/msg00293.html
In commit d6c134f420 ("Do not switch
workspace to follow new windows in others") the default behavior
was changed, and workspace switching to follow focus requests was
strictly forbidden.
Although that seems to be a sane thing to do by default, that raises
concerns about whether Window Maker could be more flexible in that
respect -- allowing the user to choose which applications are or
are not allowed to do that.
This patch adds such configuration, located in the "Advanced Options"
submenu of the top-level "Attributes" menu.
New windows should only be focused if they are in the current workspace.
Not performing this check can lead to WM switching workspaces if a
window is opened which:
(a) is configured to appear in a particular workspace
and
(b) sends a _NET_ACTIVE_WINDOW message to give focus to
something, e.g. a sub window.
This behaviour was observed with firefox if a session with more
than one tab open was restored at startup because:
"If a Client wants to activate another window, it MUST send a
_NET_ACTIVE_WINDOW client message to the root window:"
Original-post: http://lists.windowmaker.info/dev/msg00442.html
[crmafra: Added comment]
