Use the WindowRelaunchKey shortcut to examine the WM_COMMAND property of
the active application's main window and launch a new instance of the
application using the retrieved command line.
The function canReceiveFocus should check if the window is no_focusable first.
If the window is not focusable but is miniaturized, the window is shown in the
switchpanel.
How to reproduce the problem:
- Open an application
- Open the window properties, advanced options
- Set that the application can not get the focus and save
- Test the switchpanel (Alt+Tab) the window doesn't appear
- Minimize the window
- Test the switchpanel (Alt+Tab), the window appears
- If the window is selected (restored), and test again the switchpanel, the window doesn't appear!
A new function is created to get the image from the X11 window.
The function updateIconImage is splitted in two blocks, one is moved
to get_wwindow_image_from_x11 with the X11 code, and other is used
to update the Application and Window icons (kept in the same function).
Doug Barton reported that using "Technical drawing-like" for "Size display"
under WPrefs "Miscellaneous Ergonomic Preferences" together with opaque
resize would lead to artifacts left on screen when resizing.
This patch fixes it (and it also fixes some minor coding style issues
in the surroundings).
(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>
I have noticed that in WindowMaker 0.95.2 application icons bounce
when some actions are done, like starting a program, etc.
Disabling Superfluous or Animations also disabled the minimizing
animation which I am used to, so doing that didn't do the job.
Everyone has got his or her own tastes, but I did not like the new
behavior and didn't find any way to disable it without affecting other
things.
So I made a patch to fix just that. It adds a new option in WPrefs.app's
Expert Tab called "Do not make AppIcons bounce" which when enabled,
disables any type of bouncing for Application Icons, restoring the
old behavior.
Bouncing stays the new default behavior.
The only place where this function is called is from a double click
in the first icon of the dock, and only if there's no program already
associated with it.
This is a bit superfluous and most people have defined the first
icon to call WPrefs instead and end up never seeing that panel.
And since the last commit ("Change behaviour of the GNUstep dockapp"),
this is now also the default behaviour of Window Maker.
Furthermore, the panel itself is not accurate. Window Maker is not part
of the GNUstep project.
Icons in the switchpanel are constrained to the value of the IconSize
preference but the grid in which they are arranged is fixed at 64 pixels.
If IconSize is less than 64x64 the panel will show smaller icons with a
wide spacing, which looks pretty stupid.
Fix it by forcing the switchpanel to attempt to load images at the size
it's going to use. The icon it actually gets may of course still be
smaller.
Display a standard Window Maker balloon with the workspace name when the
mouse enters the clip area.
This complements commit 4954d4df23 ("clip: Do not display balloon with
workspace name") because now the balloon which appears on the clip is the
same as in other parts of wmaker.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
When the mouse passes over the clip, wmaker would display a "odd" balloon
text with the workspace name, but the balloon itself was covered by the
clip icon!
So if the workspace name was short enough ("Internet" is, by my testing here)
the user wouldn't see anything, the balloon is completely under the clip icon.
I found this issue because one of my workspaces is called "Beyonder" and I
noticed a small "r" under the clip one day.
Instead of trying to fix this, I just removed the whole thing about displaying
the balloon because it is superfluous and I haven't seen any bug reports about
this yet, so it probably means most people are not even aware of it.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
GRADIENT_CLIP_ARROW was never defined anywhere and having fancier clip
arrows is not something particularly interesting, so let's simply remove
the code.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Replace the ARROWLESS_KBD #define with the ViKeyMenus preference.
When ViKeyMenus is TRUE, users can type h/j/k/l to scroll around menus.
Since ARROWLESS_KBD was previously undefined by default, ViKeyMenus is
FALSE by default.
With the fonts I use here, the memory information line in the "Info panel"
did not fit inside the window. So make that line a bit shorter by displaying
Total memory allocated: 2600 kB (in use: 2182 kB)
instead of
Total allocated memory: 2600 kB. Total memory in use: 2182 kB.
Furthermore, the surrounding code was a bit convoluted to display either
"Additional support for: WMSPEC"
or
"Additional support for: WMSPEC and MW"
As WMSPEC is always present and it doesn't seem we are adding more stuff
to support, one can do the same with a shorter code which reads a little
bit better.
Despite having the inotify mechanism compiled in my WM, everytime I
changed a keyboard shortcut definition in the WMRootMenu via WPrefs
I was required to open the WMRootMenu (eg with the F12 key) for the
change to take effect...annoying.
So explicitly reload the key bindings when a modification inside
~/GNUstep/Defaults/ is detected. As the inotify mechanism calls the
function wDefaultsCheckDomains() when that happens, let's add a call
to rebind_key_grabs() in there.
Now it works fine and changes are automatically in effect once WPrefs
writes the menu.
PS: rebindKeygrabs() renamed to rebind_key_grabs()...
There is code duplication with the cropline() function, so get rid
of it and use WINGs wtrimspace() instead.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
On my PowerPC Debian Squeeze System, the icons are colored
incorrectly. This patch removes the swapping of the data on Big Endian
systems, thus causing the icons to be colored correctly.
The data appears to already be in the native endian format.
After using WINGs wInputDialog() to handle renaming the workspace
upon Ctrl+left click on the workspace menu, all functions in src/text.c
become unused.
As pointed out in the comments in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304480
it's not possible to rename workspaces with non-ascii characters -- more
precisely characters which require deadkeys with your particular keyboard.
According to the investigation made by Rodolfo Peñas:
http://lists.windowmaker.org/dev/msg02529.html
the fundamental issue behind this bug is the fact that XLookupString can't
handle deadkeys.
So either we do something radical or live with the bug.
However -- as Rodolfo also pointed out -- renaming the workspaces via the
Clip works with non-ascii chars. The reason is that the Clip uses a input dialog
function from WINGs to handle the renaming.
So instead of doing the low-level handling of text inside the menu in order
to rename workspaces, just fire up the same WINGs input dialog to handle it.
It works and the old function editEntry() can be removed.
Furthermore, it makes the whole set of functions in src/wtext.c useless, and
they are removed in the next patch.
Overall, 600 lines of code are gone now.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
I use xrandr to decrease the resolution of my display when I connect
it to my TV. When I change the resolution back to my monitor, a few
of the icons at the bottom of my dock are deleted.
This happens because wmaker computes the maximum number of dockapps
which the dock can hold based on the screen resolution:
icon_count = scr->scr_height / wPreferences.icon_size;
and drops the dockapps above that number (in wDockRestoreState()).
But now the resolution can change via xrandr, so the above computation
can lead to dockapps being dropped when the new resolution is smaller
than it used to be.
To fix this it's enough to have a resolution-invariant number of allowed
dockapps.
With the addition of an extra button to the 'Advanced Options' window,
the vertical space of the widget no longer suffices. Increase it from
350 to 360 and adjust other parameters accordingly.
And let's write the button positions as 'PHEIGHT - 40' instead of using
a hardcoded value, avoiding the need to change it everytime PHEIGHT is
changed.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The flag to not let windows be minimized was already defined in
WM (it's called 'no_miniaturizable') and the minimize functions
respect it. However this flag can not currently be set manually.
As can be read in the NEWS file
"NotMiniaturizable option changed to NoMiniaturizeButton"
it seems that the "non miniaturizable" property was a first-class citizen
in ancient times and probably configurable (those changes do not appear in
the old CVS history).
Let's make this property be user-configurable through the "Advanced Options"
panel.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Before this change some lines in the "Advanced Options" window would not
fit into one line and would screw up the others. This depends on the fonts
used, but increasing the width of the panel a bit does not hurt.
There are were a few uses of 'strncpy' that could lead to a missing NUL,
resulting in possible garbage being displayed. As suggested by Tamas,
use 'wstrlcpy' instead
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.
By turning M'bert's d6c134 around a bit and adapting the surroundings,
allow _NET_ACTIVE_WINDOW only if fulfilling it doesn't cause annoying
unwanted changes in the workspace. This is now the default behaviour;
unconditional focus stealing can be enabled on a per-client basis in the
Advanced Options window menu ("Focus across workspaces").
With Xinerama, on heads other than the primary, certain parts (menus,
scrollbars) of certain types of clients (Qt) are incorrectly or not at
all drawn.
The fix follows other window managers in completely ignoring the
_NET_WORKAREA property.
Problem originally poked at by Ambrus Szabo, correct keyword and the
eventually implemented solution suggested by Lucius Windschuh, typed
up by me.
From the original report by Tamas Teves:
"i'm having (and have, for a long time) problems with openoffice and
java-based (perhaps only netbeans-based?) apps.
for openoffice, any menu opens in the far right edge (with xinerama,
on the far right edge of the rightmost display) of the display. it
then can be clicked and operated corretly where it appears.
as for netbeans (and jswat, which also uses netbeans platform as a
base), it's a bit more complicated, but let me try to describe. start
netbeans so that it is not maximized and not in the upper left of the
display. it works fine. move it around, still works fine, resize,
still works fine. now if i maximize it (not by moving to the upper
left corner and resizing, but by the maximize shortcut), then the
menus start acting weird. it seems that the actual position of the
mouse pointer and the hot spot of the mouse pointer get "out of sync"
so to speak, as if the hot spot stayed where the window was before
maximization.
i've made a capture which hopefully better shows what i'm trying to
say. this is a netbeans window maximized, while i'm trying to click
tools->options. the left mouse button must always be held down, or
else it instantly loses any interaction with the menus (in the capture
i released it once when i completely lost track of where i might be).
the capture is available at http://dawn.dev.hu/~ice/tmp/wmjava.avi
i'm not sure whether java stuff other than those based on netbeans
platform exhibit this behaviour. i've seen this with at least one
other nb platform stuff as well."
The fix is to call wWindowSynthConfigureNotify() after wWindowConfigure()
* Remove assigned but not used variables (GCC 4.6)
* Bump _XOPEN_SOURCE to 600, ridding of FreeBSD warnings (this probably need
to be tweaked on a per-implementation basis as problems arise)
Some applications running in my machine are only background
windows, e.g.: screenlets showing CPU usage.
In current wmaker version all these applications pollute my
switchpanel, so I wrote this patch (thanks Carlos for the helping me).
It includes an additional advanced option for windows "Do not
include in switchpanel" which, if set, allows applications to
not appear in the switchpanel.
Signed-off-by: Haroldo Santos <haroldo.santos@gmail.com>
