main.c: In function ‘RelaunchWindow’:
main.c:461:1: warning: control reaches end of non-void function
[-Wreturn-type]
Actually we can't reach the end of the function because the three
possible cases are Exit(-1), return False and return True. Of course if
Exit() were ever changed the above statement might become incorrect.
Some compiler food silences the warning.
Zoltan Balaton points out that Control + Doubleclick on docked app will
launch a new instance. For consistency with that behaviour we now allow
Control + Doubleclick on an undocked appicon to invoke the new
relaunching functionality.
We also now restrict doubleclick handling to the left mouse button in
order to avoid relaunching the application twice when the middle button
is used.
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).
The file "clean", which contains "WindowMaker/Defaults/WMRootMenu"
can be removed, because this file was included to be cleaned in
the commit 01907f9983
The Application/* items are moved to the root menu, removing the
"Applications" submenu. The files from /etc/X11/WindowMaker moved
to /etc/GNUstep/Defaults
(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>
It was removed on 67a8a82670 with the assumption that
nothing was using it. But that was not really the case - FSViewer
used it.
I've just tested it. After a trivial fix regarding the change in
the function definition of WMWritePropListToFile(), FSViewer
compiles and even seems to work (didn't test much though).
So let's not be unfair with FSViewer and put wmlib back. FSViewer
might even be used for educational purposes for people wanting to
write apps using WINGs etc.
The path /etc/X11/WindowMaker is not needed now. The files were
deleted or moved to /usr/share/WindowMaker. Some files were the
same in /etc/X11/WindowMaker and /usr/share/WindowMaker.
The configuration file menu.hook is moved to /etc/GNUstep/Defaults
Duplicated:
- wmmacros
- appearence.menu (copied & generated).
- background.menu
Removed:
- menu.prehook
- menu.posthook
Moved:
- menu.hook (generated).
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.
Make it launch WPrefs instead of displaying GNUstep information.
GNUstep information under a dockbutton is unneeded and it's commonly replaced
by WPrefs. This also is giving one extra space for another dockapp.
WMCreateFont() was calling exit() if it could not create the
font, and was trying too hard not to return NULL.
Just return NULL if the font could not be created instead of exit()ing
and let callers decide what to do upon failure.
Thanks to Christian <chris@computersalat.de> for reporting this.
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>