The problem - when VirtualBox starts virtual machine, window has very
small height (couple of pixels) and it requires some manual fiddling
to resize it to something usable.
See related bugs here:
https://www.virtualbox.org/ticket/14718#comment:19 - small horizontal
line in the middle of the screen is newly opened virtual machine's
window.
https://www.virtualbox.org/ticket/15863
Inspecting with xdebug and xprop reveals that VirtualBox sends wrong hints:
Request(12): ConfigureWindow window=0x0660000a values={x=27 y=559
width=720 height=65512}
Which is interpreted by X server wrongly and shown with xprop as
WM_NORMAL_HINTS(WM_SIZE_HINTS)
:
user specified location: 27, 559
user specified size: 720 by -24
program specified minimum size: 254 by 109
window gravity: Static
Some part of X11 interprets such large value as signed int and wraps
it to negative value.
The solution will be if program requests such big window - detect it,
ignore requested size and resize it to some reasonable defaults.
Disclaimer - I tested it only on Ubuntu 16.04, but should apply to
another systems as well - see bug reports.
This adds an option (IgnoreDecorationChanges in plist) for windows to
ignore any requests from the clients for changing decorations. Since the
default state for any window pre-request is to have all decorations visible
this basically means that applications cannot hide any of the titlebar,
sizing bar, titlebar buttons, etc and any hint that causes these elements
to be hidden will be followed by a restoration if this option is set.
This is useful for broken clients (e.g. Steam) and clients that force
subpar client side decorations. It is basically a per-window setting of the
global advanced option to ignore Gtk hints, except that it also applies to
non-Gtk applications.
Previously, if a window was placed on a workspace other than the current one,
the window placement settings (given by WindowPlacement) were ignored and
the window was drawn in the upper left hand corner. This is Debian
bug #181735, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181735
Part of the bug report by Andrew Gorcester from the link above
is reproduced here:
"When placing a window in a non-active workspace (which usually happens
if the user asks for a program to be started when wmaker is launched,
and defines an initial workspace in the window's attributes dialog),
Windowmaker doesn't follow specified rules on window placement.
All windows of programs that don't manage their own window placement
(Gaim manages placement itself, for instance) are placed in the far
upper-left corner. Usually windows originate from 64, 64, because the
clip occupies the upper-left corner by default."
As reported by Nerijus Baliunas and Paul Jakma, the GNOME application,
which use the GTK toolkit, are asking to have no window decoration. This
can be solved by editing the window's attributes in Window Maker, but this
can be tedious when there are many GNOME application used.
This patch adds a configuration option: Window Maker tries to detect for
GTK-based windows and in this case ignore the decoration hints that were
provided by the application.
Suggested-by: Paul Jakma <paul@jakma.org>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The structure containing the information on windows contains 2 sets of
attributes, client_flags which contains those asked by the application
through Hints (like MWM Hints and others) and user_flags which was defined
to allow the user to override them.
Unfortunately many places of the code was using the wrong structure to save
the attributes to (for example by using the WSETUFLAG macro) which was
merely ok as the user_flags have priority, but when we want to provide a
clean consistent behaviour to users, we need to get things in the right
place.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
There are some risks associated with the way arguments are used in macros,
and using a function also allows check on the type of arguments and leaves
more room to the compiler for making the best optimisation choice; it also
allows writing easier to read code (and thus, to maintain).
As a side effect, this should also help Coverity in avoiding false positive
bug reports (like #109605 and #109607).
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The usual way to define a macro in is to name macro with 'USE_xxx' when
they are used to enable a feature 'xxx'.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Revert patches that moved variables from WMScreen to global level
because this broke X displays with multiple independent screens and
caused dock and clip icons to become mixed up. When managing multiple
screens each screen used to have it's own state/dock and clip. This
commit restores that by reverting mainly the commits listed below (and
those that are invalidated by reverting these) and fixing up later
commits to apply after the revert.
Reverted commits:
f60e65001b Moved 'workspace_name_font' from the Screen to a Workspace object in the global namespace
9e103a46e9 Variable workspace_count moved to the workspace object in the global namespace
e5ae684d02 Variable last_workspace moved to workspace object in global namespace
c610b8d7ce Variable current_workspace moved to workspace object in global namespace
f0c5073600 Array of workspaces moved to the workspace object in the global namespace
9c252988f8 Variable workspace_menu moved to workspace object in global namespace
e86b8dcb2f Clip, Dock and Drawers menu moved to appropriate global namespace
074092f319 Removed WScreen args not used
4a7daf2322 AppIcon list moved out of WScreen
2103fe390b Variable clip_icon moved to clip object in the global namespace
014bc52531 wClipIconPaint appicon argument removed
40e1ea08b8 Varible session_state moved to global namespace
6987d4aa40 Removed WScreen argument
0de3e590ce shortcutWindows moved to w_global
2e64831fb6 Removed unused variable wapp_list
b6423a7b4f wmaker: Moved variable Screen Count into the global namespace
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>
As pointed by Coverity, the caller of the function 'getSavedState' assumes
that if the function returns 0 then the wstate is not initialised. This was
not actually true, so this patch changes 'getSavedState' to behave as
expected.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
While we don't provide compositing ourselves, add-on compositors such as
xcompmgr need us to copy the _NET_WM_WINDOW_OPACITY property from the
client window to the frame window.
We can do this easily enough.
The usual way to define a macro in is to name macro with 'USE_xxx' when
they are used to enable a feature 'xxx'
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Windows which enter fullscreen mode were not automatically given focus.
Usually that didn't matter because they already had focus when they
switched modes. An example of unexpected behaviour is opening a media
file in an already-running vlc from the commandline or via a file manager.
vlc would fullscreen mode but the launching application would retain focus.
Note that if vlc were not already running and it was launched as
described above, it would receive focus when it was opened and thus
retain focus going into fullscreen.
We now track which window had focus before a window enters fullscreen
mode and focus the original window afterwards. In the (usual) case
where the window going fullscreen already had focus, nothing changes.
In the rarer case where the window going fullscreen didn't
have focus, it will gain focus temporarily then yield to the originally
focussed window when it leaves fullscreen mode.
To reproduce:
* Launch vlc and configure it to switch to fullscreen when playing a
movie and to disallow multiple instances.
* Switch to a terminal and type 'vlc /media/funny_cats.mp4' or use a
file manager to open funny_cats.mp4 with vlc.
* Press space to pause the movie. Nothing happens because the
terminal/file manager still has focus.
The toolkit dispatches X events for MouseButton using callback functions,
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 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.
