WindowMaker have a Maximus feature expanded by ability to resize windows
to half screen (horizontally and vertically). Although, there was no way
to move windows between different heads (while screen is spanned between
different monitors - heads - if there was no xinerama used). This patch
enables possibility for moving windows between states. Assuming we have
a window on first head, maximize left would make the window occupy left
half of the screen. Assuming we have another head right of the first
head, following scenario will be possible:
- maximize right will make window occupy entire free space (just like
ordinary maximizing will do)
- another maximize right will make window be maximized half right of the
first screen
- another maximize right will make window be maximized half left on
second screen
- another maximize right will make window be maximized on second screen
- another maximize right will make window be maximized half right on
second screen
- another maximize right will make no effect
So it will cycle between half screen/fullscreen making window to travel
from left to right. Same goes for opposite direction.
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.
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.
