As pointed by Coverity, there was a memory leak when updating the shortcuts
in the menu for windows which occured when a shortcut was associated with
the window and this shortcut did not change.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The idea is that an array is easier to work with, when it's about to add,
remove or change entries, because all data end up stored in one place
instead of dispatched around the code.
It also makes code smaller as it avoids repetitions.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The code to update the "Other maximization" menu's labels was moved from
makeMaximizeMenu() to updateMaximizeMenu(), making the WMenuEntry
pointer in the former function redundant.
Ensure that keyboard shortcut labels for other entries in the window
menu are updated if the user changes the shortcut. Previously they were
only set when the menu was created and could get out of sync.
The shortcut labels for items in the "Other maximization" menu were set
at startup and not updated if the user changed the shortcut key. Thus
the labels shown could be wrong. They might even be missing if no
shortcut was assigned at startup but was subsequently set during the
session.
We now ensure that the shortcut labels are updated with the menu
whenever preferences are reloaded.
The window menu Unmaximize entry had the Maximize shortcut key as its
label. That's because the Maximize and Unmaximize menu options are in
fact the same single entry with different text depending on the window's
state.
It can, however, cause confusion if a window is maximized using one
of the "Other maximization" options such as Maximus. Selecting the
Unmaximize entry from the window menu would indeed unmaximize the window
but pressing the listed shortcut key would not.
We now dynamically update the shortcut label so that it shows a key
which will actually unmaximize the window. Thus the menu description
and shortcut action are now consistent.
There are a number of window maximization options which are currently
only available to the user via keyboard shortcut:
* maximize vertically/horizontally
* maximize left/right/top/bottom half
* maximize left top/right top/left bottom/right bottom corner
* maximus
In this patch, they become available through the window menu, under
the "Other maximization options" submenu.
When an entry of a menu is selected, the appropriate action is triggered
using a callback, which means having a fixed argument list for that
function.
It is then correct to not use all the arguments, so this patch adds the
appropriate stuff to avoid a false report from compiler.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The WScreen arguments in the functions wWorkspaceMenuUpdate() and
makeMakeShortcutMenu() is not used now, so can be removed.
Signed-off-by: Rodolfo GarcÃa Peñas (kix) <kix@kix.es>
The clip, dock, workspaces and drawers menus are common for all
workspaces, so they should be included in the global namespace
instead of the screen struct.
The variable workspaces, that contains the list of workspaces
is moved to the global workspace properties.
Now the screen is not needed to know the workspaces.
The function getWindowState() doesn't need the WScreen argument.
The variable current_workspace, that contains the current workspace
is moved to the global workspace properties.
Now the screen is not needed to know the workspace_count.
The variable workspace_count, that contains the number of workspaces
is moved to the global workspace properties.
Now the screen is not needed to know the workspace_count.
The file winmenu.h includes the function prototypes for winmenu.c.
The prototypes included were moved from funcs.h.
Signed-off-by: Rodolfo GarcÃa Peñas (kix) <kix@kix.es>
Added new keyboard shortcuts for moving windows between workspaces.
MoveToWorkspace1Key moves the active window directly to workspace 1.
Similarly for MoveToWorkspace2Key through MoveToWorkspace10Key.
MoveToNextWorkspaceKey moves the window to the next workspace,
MoveToPrevWorkspaceKey moves the window to the previous workspace.
Both keys respect the ws_advance and ws_cycle preferences.
MoveToNextWorkspaceLayerKey moves the window ten workspaces "forward" if
possible.
MoveToPrevWorkspaceLayerKey moves the window ten workspaces "back" if
possible.
The function getShortcutString() was defined statically in winmenu.c.
Replace it with the new function GetShortcutKey() which calls the
existing function GetShortcutString() so it can be used elsewhere and
cut down on code duplication.
A result of this change is that shortcuts are now labelled consistently.
Previously the format was different in generated menus, which used, for
example, M1 to refer to Mod1 whereas window menus used the full string
Mod1. Now both use the shorter form.
One could argue that the new function name is more consistent, as now
GetShortcutString() takes a char * argument and GetShortcutKey() takes a
WShortcutKey argument. That argument assumes that the original
intention behind the name of GetShortcutString() was not to hint that it
returns a String...
Other toggle menu items such as Maximize and Shade change their text
labels according to the action which will be performed. A shaded window
has its Shade menu item text changed to Unshade, for instance.
As well as maintaining consistency with other menu items, changing the
Select menu entry's text to Deselect for current selected windows
provides another (the only) way of reporting that a window is selected
when its border has been disabled. Currently the only indication that a
window is selected is that its border colour will change.
The functions of main.c should be included in main.h, not in funcs.h.
This patch adds the main.h file and moves the function prototypes to
this file.
The not needed "include funcs.h" are removed.
There are some code duplication in winmenu.c. Two new functions,
- open_window_menu_core
- prepare_menu_position
Join the common code and then the duplicated code can be removed.
The window menu displays the shortcut key for operations with a
shortcut, but does not display the modifiers. This reduces the utility
of the display as it's hard to know whether "h" means "Mod4+h" or
"Ctrl+Mod4+h" or something else.
This patch prefixes those shortcut displays with the modifier names,
e.g. Ctrl+Mod4+h, and adds a preference ModifierKeyLabels to allow
overriding this, e.g. to "⌃◇h". It doesn't add this preference to
WPrefs, if someone else wants to do that feel free.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
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>
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()?
If menu is NULL we would have a null pointer dereference when initializing scr.
> Ie, why not move the assignment of 'src' to after the test?
I thought about this, but I checked the 3 different calls to
updateWorkspaceMenu (all in winmenu.c). They must all call
updateWorkspaceMenu with non-NULL pointers, so if we have a NULL
'menu' pointer then we obviously have a major problem and it is
probably better to crash here than to silently return and fail a
little latter.
[crmafra: edit changelog]
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
- Fixed bug in icon chooser dialog that could cause a segmentation fault
in some cases (Pascal Hofstee <caelian@gmail.com>)
- Fixed crash in asm code in wrlib, with new versions of gcc.
- Fixed bug in the x86_PseudoColor_32_to_8() function which incorrectly
used the r, g, b fields in the conversion.
- Fixed x86 ASM code in wrlib to work on 64 bit architectures.
- Fixed the focus flicker seen with some apps (notably gtk2)
(Alexey Spiridonov <snarkmaster@gmail.com>)
- Fixed all crashing bugs that were generated by wmaker starting with the
WMState file missing.
- Added NetWM support (a modified version of the patch originaly written
by Peter Zijlstra <a.p.zijlstra@chello.nl>)
- Applied patch to enhance the Virtual Desktop behaviour, and to integrate
it with the NetWM code (Peter Zijlstra <a.p.zijlstra@chello.nl>)
- Applied a few xinerama and placement fixes (Peter Zijlstra
<a.p.zijlstra@chello.nl>)
- Fixed memory leak in dock code.
- Fixed and enhanced the text wrapping in WINGs.
- Fixed the layout of some elements in WPrefs.app
- Added workaround for aplications that don't set the required hints on the
client leader window, but they set them on normal windows (observer with
KDE 3.3.0 mainly). This will allow these apps to get an appicon again.
(they should be fixed still)
- Added workaround for applications that do not set a command with
XSetCommand(), but instead they set the _NET_WM_PID property. This works
with operating systems that offer a /proc interface similar to what linux
has. (This also is to fix problems with KDE 3.3.0 apps, but not only them).
- Fixed bug with autostart and exit scripts not being executed if user
GNUstep path was different from ~/GNUstep (when setting GNUSTEP_USER_ROOT)
- Added utf8 support in WINGs (removed old X core font code)
- Added utility to convert old font names to new font names in style files
- Separated the font caches for normal fonts and fontsets in WINGs (they can
have the same names and collide in the cache giving unwanted results)
- Updated the years in the copyright notices
internal code clean-up with notifications for window state change and other
stuff, also cleaned kde and gnome support in preparation for wm-spec support..
first element in the array that is matched by match(item, cdata)==True.
- added WMArrayFirst(), WMArrayLast(), WMArrayNext() and WMArrayPrevious()
functions and also WM_ITERATE_ARRAY() and WM_ETARETI_ARRAY() macros, to make
interfaces to WMBag and WMArray similar and to make life a little simpler
when iterating through all elements of an array.
- replaced bags with arrays wherever appropriate. This will improve
performance a bit.
- replaced some recursive code with iterative code in WINGs/selection.c
- some code cleanup is src/
