This patch adds update-changelog.pl, a script which adds the subject line and
author of every commit since ChangeLog was last touched by git, in a style
consistent with the entries up to version 0.92.0.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Previously, the whitespace in WindowMaker was inconsistent, with some
indentation using spaces and some using tabs, and a mixture of tabs and spaces
used to align comments at the ends of lines. As a result, patches that touched
this file would often result in warnings from checkpatch.pl.
This patch fixes this so that indentation uses tabs and all other alignment uses
spaces.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch adds the ability to "snap" a window to the top, bottom, or any of the
four corners of the screen. It uses three new helper functions, drawSnapFrame,
getSnapDirection, and doSnap, to reduce code duplication and increase
readability.
It also updates NEWS to indicate the additional directions.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
You can now set the behavior when dragging a maximized window, i.e., the
"DragMaximizedWindow" option from ~/GNUstep/Defaults/WindowMaker, from the
"Window Handling" tab of WPrefs.app.
Note that to make room for the pop-up button required to set this option, the
switch button to set the "OpenTransientOnOwnerWorkspace" option has been moved
to the "Expert User Preferences" tab and the "Edge Resistance" frame has been
made slightly smaller.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
You can now configure the behavior when dragging a maximized window by setting
DragMaximizedWindow in ~/GNUstep/Defaults/WindowMaker. The options are:
- Move: Move the window and retain its maximized status and geometry (the
current behavior and the default).
- RestoreGeometry: Move the window and unmaximize it, restoring its original
geometry.
- Unmaximize: Move the window and unmaximize it, retaining its maximized
geometry.
- NoMove: Don't move the window.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Window Maker was not correctly maximizing windows in some cases
"... do not cover dock" enabled with "Dock postion":
Normal - maximizes ok
Auto raise & lower - maximizes ok
Keep on Top - maximizes ok
"... do not cover dock" disabled with "Dock postion":
Normal - maximizes ok
Auto raise & lower - maximizes ok
Keep on Top - maximizes not covering dock
Reported-by: Johann Haarhoff <johann@haarhoff.org.za>
Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch adds the ability to completely unmaximize, i.e., clear the maximized
flag and return to the original geometry, a maximized window that is moved.
This behavior mirrors that of other common desktop enviroments, e.g., GNOME,
Unity, and Windows.
To enable this feature, set "UnmaximizeOnMove = YES" in
~/GNUstep/Defaults/WindowMaker.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
If a user moves a window which is currently maximized, the current behavior is
to keep the window geometry and maximized status unchanged. This can lead to
peculiar behavior. For example, suppose a user maximizes a window to the
right half of the screen (either through the window menu, keyboard shortcut, or
new snapping feature), then moves it, and then attempts maximize it to the
right half of the screen again. Instead of the expected result, the window is
unmaximized and returned to its original geometry.
This patch changes the behavior by clearing the maximization flag when a
maximized window is moved. Then, when a window is maximized and then moved, it
can be maximized again without issues.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch adds the ability to "snap" a window to one side of the screen by
dragging it to that side. It is enabled by setting WindowSnapping = "YES" in
~/GNUstep/Defaults/WindowMaker.
Note that window snapping is automatically disabled if DontLinkWorkspaces =
"NO", as this feature also involves dragging a window to one side of the
screen.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is creating the missing custom GNUSTEP dir.
Patch found on vinelinux.org as WindowMaker-0.95.6-GSDIR.patch.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding mouse wheel action on clip to switch from
one workspace to another. It's a modified version of the vinelinux.org
(WindowMaker-0.95.6-wheel.diff) which was setting the action on the entire dock.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is updating makeWindowListArray function,
as it crosses the whole window focused list each time
we don't have to bother on checking previous and then next
focused windows, so saving some cycles here.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding GUI configuration for new mouse actions:
-Previous Workspace
-Next Workspace
-Previous Window
-Next Window
-Switch Windows
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding atomic mouse actions to mouse buttons to:
-focus on previous or next window
-move to previous or next workspace
and adding wheel action to
-switch between windows
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding a wWindowFocusPrev() and wWindowFocusNext() functions.
And copying switchmenu.c focusWindow() as wWindowSingleFocus().
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is updating the gradient texture user experience
by auto selecting the first color in the list when possible
and fixing the autoselection after a delete action.
In fact what that is called gradient colors is just a list of colors
with hue/saturation/brightness value.
That patch is loading the first one from the list (color, hue,
saturation, brightness) and setting the 3 sliders according to that
value instead of using some default hardcoded values.
The default color value on the top-right is never modified.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Recently added msgid's were translated, and some existing translations
improved. As development is done in git 'next', strings from wmaker-0.95.6
will be remained at the end of the files, so they are backward compatible.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding a readMenu function to be called from
readMenuPipe and readMenuFile, saving about 20 lines of code.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is improving the key shortcut labelling in the root menu.
It modifies the GetShortcutString function to save some cycles
as wXModifierFromKey is already doing all the string comparisons.
This patch introduces a new function called wXModifierToShortcutLabel
that is checking the return value from wXModifierFromKey.
Not sure why Control was set as a special key, as keyboards could
have 2 controls but also 2 shift keys.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is adding the _NET_WORKAREA property
which according to EWMH spec MUST be implemented.
Some application like rdesktop or nautilus are using
it, that's maybe why you encountered some errors like these:
** (nautilus:6457): WARNING **: Can not get _NET_WORKAREA
** (nautilus:6457): WARNING **: Can not determine workarea, guessing at layout
For now, the property is only updated when a workarea is created or destroyed.
This patch is updating the coding style based on checkpatch output
and as suggested by Rodolfo it also inverts the condition test
in getAnimationGeometry fct to return earlier when possible.
This patch is fixing the shortcut label used in window menu.
As now when a 'control' shortcut was used, the label displayed
was 'bug' cause GetShortcutString fct which is calling wXModifierFromKey
fct was waiting for a 'Control' static string not the default one
set to 'Ctrl' string.
This patch is fixing the RenderBadPicture X errors on deiconifying
window using double-click.
Background:
I also experienced this issue these days, after checking it was not
introduce with latest apercu feature I decided to dig into it.
As far as I saw in the archive it was first reported by Rodolfo in June 2012.
Each time a window is deiconify using double-click, the error below
is reported in the session error log:
wmaker(catchXError(startup.c:177)): warning: internal X error:
RenderBadPicture (invalid Picture parameter)
Request code: 152
Request minor code: 7
Resource ID: 0x6000a4
Error serial: 9269
So I decided to track when the issue is happening,
from src/action.c wDeiconifyWindow then in src/icon.c wIconDestroy
then in src/wcore.c wCoreDestroy.
At that stage, all the structures I checked are cleaned up properly
during the icon destroy process.
So I also checked when the issue is generated, I ended in
wrlib/xutil.c RCreateXImage (in the share memory extension code)
XSync(context->dpy, False);
oldErrorHandler = XSetErrorHandler(errorHandler);
XShmAttach(context->dpy, &rximg->info);
XSync(context->dpy, False);
XSetErrorHandler(oldErrorHandler);
At this point I was quite lost, cause it means the error could
have been in the server error queue already.
Facts, seems the issue is appearing only on double-clicking the miniwindow,
but not when "Deminiaturize" is clicked from the right-click contextual menu.
I also checked the code from winmenu.c when the action MC_MINIATURIZE
is selected from execMenuCommand fct, but it was just calling
wDeiconifyWindow function. Hum.
So, after one full day of thought I tested to just change the focus before
double-clicking the miniwindow, and bingo it works.
That means when the icon is destroyed the X server still has a reference
on it that's generating the issue.
This patch is used to fix the Debian bug #140181
It updates the NumLockMask function to report the mask and
call XFreeModifiermap when needed.
It also modifies capture_shortcut function to be able to use Super keys
and report numeric keypad when pressed (aka now detects correctly
if the numlock is enabled or not).
This patch is changing the default application icon to
a one that reminds the NeXTcube but also a blackbox of
something we don't know about.
It's from LuBu OpenMagic 1.0 for Sparc project at
www.alge.no/index.php/OpenMagic_1.0
According to the license,
"LuBu OpenMagic 1.0 is put into the public domain"
Since the resolution of the Retina display tends to make everything small,
the default apercu preview size (twice the icon size) couldn't be used to
distinguish the window contents without tiring too much my eyes.
Therefore, let's make the apercu size a configurable option. You can set
it through the ApercuSize variable with
$ wdwrite WindowMaker ApercuSize 4
in multiples of the icon size (in this case the apercu size will be four
times the icon size).
The default size remains 2 (twice the icon size).
This patch is adding miniwindow apercu when the mouse
is over the miniwindows.
To enable it you have to run WPref, in Miscellaneous Ergonomic
Preferences, check miniwindow apercus.
Then, you will be able to see a screenshot of the app when the mouse
is over the miniwindow.
