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 funcs.h is removed. A new file osdep.h is created to hold
the definition for all osdep_*c files.
The files .c has been adjusted to include the right header files,
removing funcs.h, including osdep.h.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
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>
The file startup.h includes the function prototypes for startup.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.
Use the new preferences FrameBorderColor and FrameSelectedBorderColor to
set the border colour of frame windows and selected frame windows
respectively.
From the BALATON Zoltan comment:
If the P in WINGsP.h stands for Private then no files outside of WINGs
should include it. If WINGsConfiguration is an internal structure of
WINGs then only accessor methods should be used outside of WINGs.
This patch uses the new functions to read the WINGs configuration, not
using the internal library data.
Windows were drifting by FRAME_BORDER_WIDTH pixels when their
borders were toggled on or off.
Windows which had a border before we managed them were drifting
on shutdown and again at startup. It happened because the absolute
upper-left co-ordinates of a bordered window would in fact be the
upper-left co-ordinates of the border itself, whereas we consider
the client window to have no border and co-ordinates offset by the
titlebar and frame border.
The initial fix for the bug reported by Paul Seelig whereby windows
would drift on restart introduced two regressions.
New windows would place higher on the screen than intended, possibly
obscuring the bottoms of other windows with their titlebars, and all
windows would jump vertically at shutdown because we weren't restoring
them to where they were before they had a titlebar and border.
Bug report from Paul Seelig:
"Yet another rather strange glitch:
- open three terminal windows
- repeatedly restart wmaker
- all windows slowly drift to the left and up by just a few pixels
If i remember correctly, this is also a longstanding issue and nothing
new. It is no showstopper either, as one rarely restarts wmaker."
The slight drifting left and up seems to have been due to
wWindowConfigure() accounting for the window border when placing, which
was fixed in an earlier commit.
Windows could still shuffle down, however, because wWindowConfigure()
was moving the window down to make room for its window frame.
We now move it up by the titlebar height to cancel out that movement.
Bug report from nikty:
"Window Maker does remember the size of windows, but for maximized windows it does not keep the position.
When a maximized window appears it is shifted to the right for a few pixels (firefox, thunar) or both to the right and to the bottom (openoffice, vlc, virtualbox)."
We weren't accounting for the window border when calculating whether the window would position correctly.
To reproduce:
* Launch some application which remembers its position. I used
Thunar as suggested in the bug report.
* Maximize!
* Kill the application.
* Launch it again.
* Maximize! The expected behaviour is that nothing would happen
because the window should have started right where it was before.
Observed behaviour is that it moves a few pixels.
After the patch we can verify that the maximize operation is
idempotent with regards to geometry.
Tested with and without Xinerama, with and without a panel strutting
one edge.
Bug report: http://www.kix.es/mantis/view.php?id=4
Brief comment on what wAppIconFor() and wWindowFor() do, as it
may not be immediately obvious.
Given a raw X11 Window they will find the AppIcon (or WWindow,
respectively) associated with that window. Thus they can map an
X11 object to a Window Maker internal object.
The function remove_wwindowstate is now remove_wwindowstate. This was
proposed by Christophe and Carlos:
- - -
On 2012-10-09 01:09, Carlos R. Mafra wrote:
> On Tue, 9 Oct 2012 at 0:58:19 +0200, Christophe wrote:
> you name the function "remove_*", which makes think that it would
> remove the entry from the list, but the function does not do that, it
> just frees the memory, so it may have been better called "free_" (or
> maybe "release_")?
>
Good point, release_ makes more sense to me.
- - -
The variable "check" is always False, so the if (!False) is always
True and the function wNETWMCheckClientHints is always called.
The variable check is not used anymore, so the variable check
can be removed.
After we exit there are no window decorations therefore frame extents
are meaningless.
We could be left with parts of the window being the wrong opacity if the
property is left intact and a compositing manager configured to draw
decorations with a different opacity to the rest of the window is still
running.
Remove the _NET_FRAME_EXTENTS property from all windows when we shut
down to prevent windows from being drawn incorrectly after we're gone.
Accept windows' depth, visual and colormap instead of always using those
of the root window. Internal windows such as menus behave as before.
In conjunction with a compositing manager on a display supporting the
RENDER extension windows can now manage their own opacity.
I wrote the patch after reading the FAQ for urxvt, which says,
regarding transparency support:
"3. Use an ARGB visual:
urxvt -depth 32 -fg grey90 -bg rgba:0000/0000/4444/cccc
This requires XFT support, and the support of your X-server. If that
doesn't work for you, blame Xorg and Keith Packard. ARGB visuals
aren't there yet, no matter what they claim. Rxvt-Unicode contains the
necessary bugfixes and workarounds for Xft and Xlib to make it work,
but that doesn't mean that your WM has the required kludges in place."
In conjunction with a compositing manager (I tested compton) it does
work and urxvt draws a semi-transparent background with fully opaque
foreground text and scrollbars; much prettier than applying a blanket
transparency value over the whole window with the compositing manager.
Other application windows I tested were, as expected, drawn the same
as before.
I verified that urxvt is drawn in the same way when using xfwm4
(with builtin compositing). Since Window Maker doesn't (at time of
writing) have its own compositing manager I should clarify that one is
required to see any benefit from this patch.
Whether or not this feature is useful for any application other than
urxvt I don't know, though I assume that an application which chose an
ARGB visual in the same way would be able to draw itself prettily.
On a display without RENDER things work just as they do without the
patch. I have, however, only been able to test on a fairly standard
TrueColor display supporting multiple colour depths with 24bpp being
the default. Testing with more ... exotic ... display types would
probably be advisable.
This patch adds support for the _NET_FRAME_EXTENTS property as
described in the EWMH spec. With it I was able to use the compton
compositing manager to draw fully opaque windows with semi-transparent
titlebars and resizebars.
Set the _NET_FRAME_EXTENTS property based on border widths and
titlebar/resizebar heights.
The EWMH spec says:
"_NET_FRAME_EXTENTS, left, right, top, bottom, CARDINAL[4]/32
The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the
window's frame. left, right, top and bottom are widths of the
respective borders added by the Window Manager."
The functions related to colormap are moved from funcs.h to the new
file colormap.h. These files are included where needed.
The functions wColormapInstallRoot and wColormapUninstallRoot are
removed, because they are not used.
The contents of the rootmenu.h file are not used and can be removed,
but the prototypes of rootmenu.c are in funcs.h and should be moved
to the correct (rootmenu.h) file.
The superfluous.[ch] files have a few minor issues, this patch addresses some of them:
- Move the defines to the top of the superfluous.c file
- Include the ifdef NORMAL_ICON_KABOOM inside the DoKaboom() function
because the DoKaboom is used without the NORMAL_ICON_KABOOM ifdef in
other files.
- Include the ifdef WINDOW_BIRTH_ZOOM inside the DoWindowBirth() function,
therefore the function don't needs to be defined twice (with and whitout
WINDOW_BIRTH_ZOOM define.
- Now the functions are defined in superfluous.h and the externs are not
needed.
- We need include the dock.h in the superflous.h because is used by the
definition of MakeGhostDock().
- We need include the superfluous.h in window.c (removing the extern)
memset is the last function call in wmalloc, just before it returns the
newly allocated memory. Therefore it is not needed to call it again
after wmalloc call. Although I would prefer to switch wmalloc to a
calloc-based wcalloc function, the compatibility of WINGs for old apps
should be kept.
This patch removes the unneeded curly brackets in multiple files.
It also add some comments in the code. In usermenu.c removes some
variables not used.
(Window|Menu)Title(Min|Max)Height defaults options allow to set
minimum and maximum titlebar height.
For example, to force all titlebars to 24 pixels execute
following commands:
$ wdwrite WindowMaker WindowTitleMinHeight 24
$ wdwrite WindowMaker WindowTitleMaxHeight 24
$ wdwrite WindowMaker MenuTitleMinHeight 24
$ wdwrite WindowMaker MenuTitleMaxHeight 24
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
PropGetWMClass()
- XAllocClassHint()s a struct for class hint data
- This is filled by XGetClassHint(), which in turn uses Xlib to allocate
some more space for XClassHint members
- Upon XGetClassHint() failure, "default" is libc malloc'd (via strdup),
and is returned to the caller
- Upon XGetClassHint() success, XClassHint members are returned raw --
these members must be freed with XFree() (see XAllocClassHint(3))
- Thus it's up to PropGetWMClass() callers to decide (based upon the return
value) which method (libc free() or XFree()) to use to free res_name
and res_class. This was done nowhere, thus leaking some memory
on every failed PropGetWMClass() call.
- So just strdup the successful res_name/res_class members, XFree() them
while still in PropGetWMClass(), and allow callers to unconditionally
libc free() whatever PropGetWMClass() returns.
