bug description: after menu is displayed I get a segfault when trying to hover over the last menu
entry. it looks like under some circumstances menu->entries[] gets accessed past the last valid
value (off by one).
how to reproduce:
right-click desktop to show menu and keep right mouse button pressed
sweep mouse up-down the menu a few times - it crashes all the time between 1-5 sweeps
this commit fixes the unwanted behaviour, in active use since december 2021.
Setting a clip as autoattracting will disable an autoattracting drawer,
and reciprocally. Although not immediately obvious, it should be fairly
easy to figure out, and is totally reversible. So we'll probably never
opt to show that confirmation dialog box.
toggleAutoAttractCallback needs to check whether there are clips before iterating
through them (or it crashes WM!). The extra test is needed because now drawers can
auto-attract as well. Before drawers, only clips could auto-attract, so testing
wPreferences.flags.noclip was pointless.
The dock will have the up-right and down-left arrows to change workspaces and
the clip will be disabled. That is, if option ClipMergedInDock is set to yes in
GNUstep/Defaults/WindowMaker.
[not thoroughly tested]
No more ghost dock when switching sides: the real swap happens
immediately, you can still adjust vertically afterwards. Removed two
functions in superfluous that are no longer used
Drawers are horizontal docks, and they can themselves only live in the dock
To use them, right click on the dock or a docked appicon and select "Add
a drawer". Then move appicons into the drawer (drag them with the
mouse). You may change the icon of the drawer. By default, drawers
auto-expand and -collapse, and auto-raise/lower. This can be customized
in the same way as for the clip.
Set DisableDrawers to YES in G/D/WindowMaker if you do not want to see
the menu entry to add a drawer.
Just discovered this bug: the auto-attract icon functionality will not
work (to be precise, it crashes WM!) if the clip is disabled
(NoClip=YES). Will fix shortly, of course.
Behaves essentially the same, only a bit more consistently.
Known differences:
1. An AppIcon will now always end up undocked if moved while Mod1 is pressed.
2. Moving a docked AppIcon with Mod1 pressed (undocking it) used to auto-expand the clip,
as clip expansion happened first, while looking for a snapping position,
and the test on Mod1 being pressed happened only later
The options are ClipAutoraiseDelay, ClipAutolowerDelay, ClipAutoexpandDelay, ClipAutocollapseDelay
The default values are weird but merely represent the previously
hard-coded ones. They are repeated in Defaults/WindowMaker to avoid a
WPrefs crash (but it's a good idea to make them "visible", too)
WPrefs change coming up
When changing workspace, mapped windows are unmapped from top to bottom
(referring to their stacking order), causing mapped but obscured windows
to briefly appear when the obscuring window is unmapped and until they
are themselves unmapped. [This might not be visible on recent hardware].
The fix is to unmap windows in reverse stacking order when changing
workspace.
In handleIconMove, when moving an appicon near the clip, all clips were
systematically shown each time the mouse moved, causing some flickering
(perhaps only perceptible on a low-end machine?). This patch introduces
a showed_all_clips boolean to expand clips only once.
If btn->omnipresent, then btn->dock is precisely
scr->workspaces[scr->current_workspace]->clip (cf.
wWorkspaceForceChange() calling wClipUpdateForWorkspaceChange())
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.
There is no point in checking
if (dock_state)
if the function would have already returned with
the check if(!dock_state) right above.
Retrived from http://yo.dan.free.fr/wmaker.phtml.en
[crmafra: wrote the commit message]
Bug overview:
New windows are sometimes mis-placed when the "smart" algorithm is used.
How to reproduce it:
be sure (with WPrefs.app, for instance) to use the so-called "smart"
window placement algorithm. In an empty workspace, open a first window
(for instance, an xterm). The window should appear at the upper left corner.
Shade it (hide its contents below its title bar by double-clicking on it)
and select another empty workspace. Open another window. Instead of placing
it at the exact same place as the first window, wmaker places the new
window a little bit lower, or frankly to the right.
Explanation and correction:
when placing a new window, wmaker avoided all shaded windows, instead of
only avoiding the shaded windows on the active workspace.
1. Setup two windows in a workspace, one at the center and the
other at a corner. Move the mouse to the center of the screen, so
that the focus goes to the center window. Now, with the help of the
keyboard (with Alt-tab, typically), try and switch the focus to the
other window. In doing so, the switch panel shows up, gives the
focus to the other window and then disappears. However, its
disappearance make it seem to wmaker that the mouse has just
entered the center window, so wmaker gives the focus to that
window again.
2. It is a lit bit more involved. "Raise window when switching
focus with keyboard" needs to be set. In a given workspace, maximize
a first window A, then setup "above" window A two windows B and C
(one in the upper left corner and the other one in the lower right
corner, for example). Move the mouse so as to give the focus to
window B. Press the Alt key, hit the key tab once (window A moves
up to the "top"), then another time (window C is then selected).
Eventually relase the Alt key: window B is given the focus again.
Correction: it is a matter of ignoring some (EnterNotify) events
when the switch panel is active or has just been used.
This also fixed an endless loop that could be entered by the previous code
in certain situations, after the patch to fix navigation/selection in a
textfiled with UTF8 chars was applied.
fix the 2 problems mentioend below:
- Fixed buggy handling of UTF8 characters in textfields in WINGs.
- Fixed segfault in WPrefs when some font description is missing from the
configuration file.
WINGs based applications should now work with both KDE and GNOME
applications (Sylvain Reynal <sreynal@nerim.net>)
- better check for the XDND protocol version when interoperating with other
applications. As it seems xdnd version 3 (which WINGs supports) and newer
are not backward compatible with xdnd version 1 and 2. This is why WINGs
applications cannot interoperate with GNUstep applications (which uses
xdnd version 2). Xdnd version 4 and 5 are backwards compatible with
version 3 though. (Sylvain Reynal <sreynal@nerim.net>)
small integer and causing unexpected color releases that can crash
Window Maker (Martin Frydl <martin.frydl@systinet.com>)
- fixed a small memory leak in WINGs/wview.c caused by not releasing the
background color of a view (Martin Frydl <martin.frydl@systinet.com>)
on 64bit platforms (Max Loparyev <max@city.veganet.ru>)
- fixed issue with icon colors on big endian platforms
(Max Loparyev <max@city.veganet.ru>)
patch based on a previous patch by Vladimir Nadvornik <nadvornik@suse.cz>
belong to, that works without auto-arranging the icons, while still avoiding
multiple icons in the same spot by moving the miniwindows to a new slot if
their old slot was occupied in the meantime.
- double clicking an appicon will also raise the miniwindows that belong to
that application to the front (along with the normal windows).
- Fixed WPrefs path in the installed WMState (changed after recent WPrefs
installation path changes)
- Fixed wmaker.inst (apparently some very noisy individual was unable to get
right his 10 line patch to rename a path)
the old .AppInfo/... to the new Library/WindowMaker/... on the fly when
Window Maker starts.
This should allow a transparent transition without any need for users to do
anything.
in the first place in his trivial 10 line patch which only attempted to
replace one path with another.
He must be a big time user of his own patch, to not have noticed where the
paths pointed after his change.
than 10 parameters in inline asm, else disable asm code.
This should enable it to work on any x86 platform (not just linux as before)
given that a recent enough gcc is available (no more need to guess by looking
at $host)
This should also fix the issues of compiling wrlib with gcc-2.95
- Keep menu and title text at 12px since there is not constrained by width
- Removed some obsoleted options from wconfig.h
- Added a lighter image for the switch panel
Petre Rodan