Fullscreen windows should only be on top when they are in focus. Change
the stacking level temporarily back to WMNormalLevel if the fullscreen
window loses focus due to an alt+tab operation.
Change the stacking level back to WMFullscreenLevel if the fullscreen
window receives the focus again.
Cc: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
This reverts the commits:
311ab6b08c ("Raise fullscreened window")
a504370f3b ("Remove WMFullscreenLevel")
Removing WMFullscreenLevel had the side effect that a dock or panel
having the _NET_WM_WINDOW_TYPE_DOCK type would stack on top of
fullscreen windows, obscuring part of them. This is unwanted. No
other window should cover a focused fullscreen window:.
https://specifications.freedesktop.org/wm-spec/latest/ar01s09.html#STACKINGORDER
Simply raising the fullscreen window to the top of the stack of normal
windows is not sufficient if there are windows with higher stacking
levels present. The separate WMFullscreenLevel is needed.
Cc: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Menus may now be shaded like other windows by double clicking on their title
bars. Note that, even if animations are enabled, the shade animation seen
with other windows does not work for menus.
This fixes Debian bug #72038 [1]:
From: Chris Pimlott <pimlottc@null.net>
Subject: wmaker: Persistant menus should be shade-able
Date: Tue, 19 Sep 2000 14:04:41 -0400
One of the many little things that makes me appreciate Window
Maker is that by clicking on the title bar of a menu, it can be made
"persistant" so it stays on screen and doesn't dissappear after click or
mouseout like normal. I find it useful if I need to run a number of
commands in a submenu, or for keeping a list of open windows on
screen.
The usefulness of this feature could be extended by allowing menus
to be shaded (by double-clicking the title) like normal windows, thus
collapsing them to take up less space when not needed but still be
persistant. Perhaps other commands of windows (like maximizing/
minimizing, resizing) might be considered as well, although
personally only shading stands out as particularly useful for menus.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=72038
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."
This patch includes some changes to avoid compiler warnings and
some code style.
Compiler warnings are:
- notifyClient, do not uses the menu argument. Including (void) menu.
- WUserMenuData, keyover: label is not used.
- configureUserMenu, params is not initialized.
- configureUserMenu, mentry is not initialized.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This pach removes the icon from the icon cache when the icon is
detached from the dock/clip.
That helps to hold tidy the icon cache folder.
-------8<-------
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your WMWindowAttributes
now it is full of entries referring to the cache that should not be there and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to it.
-------8<-------
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch saves the icon filename in the database and in the disk. wmaker
can find the icon in the different folders, including the cache folder.
This patch is based in the comments of Zoltan:
-------8<-------
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your WMWindowAttributes
now it is full of entries referring to the cache that should not be there and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to it.
-------8<-------
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch avoids to create again the cache icon for a docked application.
If the application is docked, then the icon was previosly created.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch avoids to create again the icon in the Cache if the icon
was in other Dock/Clip/Drawer, becasue the icon was previously created
and exits.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch avoids to create Cached Icons for all applications. Only
the applications docked should create it, as Zoltan said:
-------8<-------
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your WMWindowAttributes
now it is full of entries referring to the cache that should not be there and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to it.
-------8<-------
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
As Josip Deanovic reported:
-------8<-------
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016 is the first bad commit
commit bc0700e016
Author: Rodolfo GarcÃa Peñas (kix) <kix@kix.es>
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:040000 040000 7c58877ad533d52affb3 M src
-------8<-------
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Because the connection between the icon and the window is broken
(icon->owner is null) we need check if the icon->owner exists
when we try to re-create the icon in the Window Attributes window.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch introduces two new configuration values, SnapEdgeDetect and
SnapCornerDetect, which users can set to change the distance from an edge
or corner at which window snapping will begin. The defaults are 1 and 10,
respectively.
Suggested-by: Josip Deanovic <djosip+news@linuxpages.net>
As reported by Josip, the code in Window Maker to detect the use of the
legacy keyword "MiniwindowApercuBalloons" and "ApercuSize" was broken,
which means they were always seen as used even when not present.
This patch fixes the detection to only use them if they were effectively
used.
Reported-by: Josip Deanovic <djosip+news@linuxpages.net>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
In the crash handling dialog there was a reference to an old email address.
This patch replaces it with the official one, taken from the 'configure.ac'
definition so it will not need manual update anymore.
The mail address is inserted in the string with a '%s' in order to not have
it in the translation files (po) to ease the maintainer's task in case of
future change.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Since C99 we have floating point functions available for single precision,
so as it is what we need we detect them (configure) and use them when
appropriate. The goal is to avoid unnecessary float->double + double->float
conversion.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
To preserve the accuracy of the operation, the C standard request that the
mathematical operation is performed using double precision, but in many
case this is not necessary so this patch fixes a few constants to avoid
that conversion.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The standard specify that the pseudo-selection which is used to
cooperatively replace window managers should actually contain the version
of the ICCCM standard which is supported. As this could be handy for
compatibility checks in the future, let Window Maker comply.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As it is really unlikely that in normal use case someone would need this
feature, it is now conditional code, which is not enabled by default; the
configure scripts now propose a '--enable-wmreplace' option to enable the
corresponding code, as people making package for distributions may want to
enable the feature to provide users the ability to give a try of all the
window managers.
Suggested-by: Carlos R. Mafra <crmafra@gmail.com>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Use the same logic used by xfwm4, metacity et al to replace an existing
window manager on the screen and allow other window managers to replace
us, as defined by the ICCCM 2.0:
http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
Communication with the Window Manager by Means of Selections
By convention those window managers try to become the selection owner of
the WM_Sn atom where n is the screen number. If the atom is owned by
another window manager and the --replace argument was not given to wmaker
we fail to start. If the argument was given we try to become the new
owner and wait for the existing window manger to exit.
After a successful startup we watch for SelectionClear events on the
atom and initiate a shutdown if one arrives, as that implies that
another window manager was started with --replace.
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>
As reported by Nerijus Baliunas, there was a problem when unchecking an
attribute in the Window Inspector and saving it. The original code was
meant to save an attribute that is being checked by user, but not one that
is explicitly unchecked, which means than although it looked ok when using
the "Apply" button, it was not remembered when restarting the application.
In continuation to the clean-up started in the previous patches, this one
is updating the Window Inspector to display 2 check-boxes, one read-only on
the left, displaying the state requested by the application, and a second
one which makes use of the new Tri-State button in WINGs to let the user
specify if he wants to force-on, force-off, or leave as-is the attribute.
The saving to the property list is then updated to take into account this
new 3-state when saving to the file, so relaunching the application will
remember correctly the user choice.
Reported-by: Nerijus Baliunas <nerijus@users.sourceforge.net>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As there is already an attribute to allow changing this behaviour, and this
is being using for the Net WM hints, there is no reason to not support it
for MWM Hints also; contrary to the initial guess suggested by the comment
it costs actually nothing to properly support that.
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>
The Window Inspector is used to let user change a list of advanced options
for all the windows of an application. This list was defined through many
hard-coded things; by defining an array with everything at the beginning of
the file it is easier to maintain (the code is simpler because it is more
generic) and to make it evolve.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The Window Inspector is used to let user change a list of advanced options
for a window. This list was defined through many hard-coded things; by
defining an array with everything at the beginning of the file it is easier
to maintain (the code is simpler because it is more generic) and to make it
evolve in the future.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The Window Inspector is used to let user change the list of attributes for
a window. This list of attributes was defined through many hard-coded
things; by defining an array with everything at the beginning of the file
it is easier to maintain (the code is simpler because it is more generic)
and to make it evolve.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As pointed by the "checkpatch.pl" script, one line was too long in respect
of the coding style.
This line contains the calculation of an offset when storing a value in an
array, as this offset is a constant during all the loop, this patch is
calculating the offset only once before the loop and then uses this result,
which should make the code faster (although gcc may already optimise this
kind of things), makes it compliant with coding style, and takes the
opportunity to explain the reasons behind this offset.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
By defining the const array with everything at the beginning of the file,
it is easier to maintain and to make evolve.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
By defining the const array with everything at the beginning of the file,
it is easier to maintain and to make evolve (all stuff at the same place).
Merged the function makeMakeShortcutMenu into makeOptionsMenu because it
allows to use a simple callback in the structure like for the other
submenus and because its complexity did not justify a dedicated function.
Took opportunity to give a more appropriate name to the index
MC_DUMMY_MOVETO which did not mean what the entry is about.
As a side effect, this should close Coverity #50251 which was about saving
the return value of function into a variable but not using it, which is not
really good for maintainability.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
There was the possibility to include a global sub-menu to the root menu
using a dedicated file, but this does not look like it is really useful as
this root menu is already defined by a user file, and the root menu is
already specific enough that it does not need anything more 'global'.
Furthermore, the variable enabling this feature (GLOBAL_SUBMENU_FILE) is
not defined anywhere (neither from "configure", nor in "wconfig.h", ...) and
is also not documented at all.
Considering it was introduced a very long time ago (1999!) and was not
touched anymore, this patch removes the dead code associated with it.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
It is not really efficient to call it twice because the strings will not
change, and by using the appropriate trick it can make the code smaller,
with less redundancy, so less prone to bugs and easier to maintain.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
