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.
As reported by Amadeusz Sławiński, there were a number of debug-only
information printed by the menu parser, which had no reason to be
in a user package.
This patch removes all the hard-coded DEBUG definitions pointed
by Amadeusz and adds a new (standard-like) option '--enable-debug'
to the configure script, which activates debug stuff for the devs.
The default behaviour is now to not have them.
As a side effect, the option also disable optimisation, which are
generally annoying when trying to run a debugger.
Managed to squeeze two more options from the expert page to the
corresponding pages and also reorganised some widgets to avoid large
now unused spaces in one place and clipped text in the other.
As found by Rodolfo, it looks like there could be memory leak in the
function 'RSmoothScaleImage' because it reserveda given number of
memory blocs but used another count to free them after use.
This patch uses the same count for release as it seems this variable
is not modified in between. Took the opportunity as Rodolfo proposed
to convert a global variable to a local variable - this global
definition seems incorrect.
As reported by Amadeusz Sławiński, the support for (d)quoted string
in the menu file was not exactly the same as in previous versions
of WindowMaker, so we had a regression which is not acceptable.
This patch propose a consistent handling for (d)quoted text instead
of the previous on-the-title-only code; now all (d)quoted strings
are still kept as-is (as expected) but the (d)quotes are always
removed.
As a side note, it also improve the support for \escaped character
to work correctly as mentioned in the example of the default menu.
Note: This reverts b2e7620868 which
was an incomplete solution to the problem.
The function wIconValidateIconSize checks if the width size and height size are
less than the preference size (and left space for the border). If the width
size or height size is greater than the preference, then checks what is the
bigger size of them. Then resize it using the bigger value and holding the
aspect ratio.
Before this patch, wIconValidateIconSize didn't check if height was bigger
than width and always suppose that width was greater than height.
The function get_wwindow_image_from_wmhints returns a image from WM Hints,
but the image could be larger than the desired.
Then, the image can be resized using wIconValidateIconSize(). The resize
should be done in get_rimage_icon_from_wm_hints(), not in the function
get_wwindow_image_from_wmhints(). This is because the function
get_wwindow_image_from_wmhints() is used in wIconStore() too. If we resize
the image before save it to disk, then if we change the icon/dock size, then
the image saved will have a different size than the curren icon size. Is
better resize the image when is painted in the screen, not the image saved.
As reported by Rodolfo, there are some cases when working with icons
where a crash can occur, which is related to trying to re-release
some memory that have been already freed previously.
This patch adds a reset-to-NULL of the corresponding pointers so that
on next usage wmaker will know there's no more memory associated with
these pointers.
On 12.11.2012 Paul Seelig reported:
- open an application positioning an app icon on the bottom
- right click this app icon to show the context menu
- wonder yourself why there are two lines saying "Hide"
- first Hide entry does not do anything, second does
The reason for this curious behavior is the following.
The "Launch" entry was added in 8352c9ef60 ("Allow relaunch with shortcut key")
as the first one in the appicon menu, but this first position was hard-coded
in another part of wmaker's code in order to decide the menu entry text based
on the application's 'hidden' state in openApplicationMenu():
if (wapp->flags.hidden)
menu->entries[1]->text = _("Unhide");
else
menu->entries[1]->text = _("Hide");
But the "Launch" entry is before these "Hide/Unhide" entries and now the assumption
about entries[1] containing the relevant string for this hide/unhide decision is
no longer valid.
The simpler "fix" is to move the "Launch" entry below these "Hide/Unhide" games.
Move bounce options from expert prefs to its own box on ergonomic
prefs to have them at one place which makes them somewhat more clear.
The options previously occupying this place have been moved to other
pages where they better belong.
This patch only add some tabs the window.h (only window struct area).
The main change is that moves this block to switchpanel.c, because
is only used there:
((w)->wm_gnustep_attr->flags & GSWindowLevelAttr) && \
((w)->wm_gnustep_attr->window_level == WMMainMenuWindowLevel || \
(w)->wm_gnustep_attr->window_level == WMSubmenuWindowLevel))
The patch also include two comments in the window's image:
- WIcon icon is only used when the window is minimized, else is NULL
- RImage has the window image, used in switchpanel,...
The WIcon variable force_paint can be removed, because now is possible
update the icon directly in the function wAppIconPaint.
Now wAppIconPaint creates the RImage file if needed, and then paint it.
The function get_default_image_path has the WScreen argument that
is not used, so can be removed.
The function could be static, but perhaps is interesting leave it
as public.
The function get_default_icon_filename(), now get_icon_filename(),
was working in a bad way. Before this patch, the function always
searched the default icon in the second search:
- file_name = wDefaultGetIconFile(winstance, wclass, True);
+ file_name = wDefaultGetIconFile(winstance, wclass, False);
For this reason, the argument default_icon didn't work.
This patch change it. Now, if the default_icon is false, the function
can return NULL, then other functions can do the correct work. For
example, now wDefaultGetImage() doesn't need do nothing, because the
default_icon is set to True. get_icon_filename() checks if the
icon exists in the disk before returning it (except for default icon
in get_default_image_path(scr).
The line "icon_editing = 0" is the first line in the "if" sentence
and the first (and only) sentence in the "else" block, so can be
moved outside the if-else (and the empty else block can be removed).
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
The function wIconSetHighlited() is now faster because it doesn't
re-create the icon before setting the Highlited status. Now it only
draws the icon pixmap.
The new function update_icon_pixmap() updates the pixmap for a icon task.
Now, wIconCreate() creates the image and sets the icon->file and
icon->file_image variables and update_icon_pixmap() updates the icon->pixmap.
This is interesting because we can update the pixmaps without creating the
image again.
The function wIconUpdate now create the rimage for the icon, using
different functions. When the icon is created, then the pixmap is
generated using this rimage.
The function get_pixmap_icon_from_icon_win(), before this patch,
creates the pixmap icon for dockapps (docks with a mini application
inside). The function did three steps:
1. Create the (r)image
2. Create the pixmap using the image
3. Put the application inside the image
Now these three steps are three functions:
step 1: static void get_rimage_icon_from_icon_win(WIcon *icon);
step 2: static void get_pixmap_icon_from_icon_win(WIcon *icon);
step 3: static void set_dockapp_in_icon(WIcon *icon);
These functions contains the same code, that before the changes.
The original function get_pixmap_icon_from_icon_win() includes the
calls to the new functions get_rimage_icon_from_icon_win() and
set_dockapp_in_icon()
There is a bug in wmaker with icon files set in config files, but
that doesn't exist in the disk. For example, if the config files have:
etc/WindowMaker/WMWindowAttributes:
xcalc = {AlwaysUserIcon = Yes;Icon = "HP-16C-48.xpm";};
share/WindowMaker/IconSets/Default.iconset:
xcalc = {AlwaysUserIcon = Yes;Icon = "HP-16C-48.xpm";};
But the icon "HP-16C-48.xpm" doesn't exist in the disk, wmaker does:
1. Load the config file in memory, in a database
2. When the application is launched, wmaker tries to find their icon in
the database (using wDefaultGetIconFile), the icon is found: HP-16C-48.xpm
3. When WindowMaker try to find the full path for the icon, using FindImage(),
WindowMaker cannot find the icon, and returns NULL.
Even, if the user set the default_icon boolean variable to True, wmaker
finds in the database the wrong icon.
This patch checks that the icon exists both in the database AND in the disk. If the
icon doesn't exist in the disk and the default_icon variable is set to True,
then windowmaker loads the default icon using the function get_default_image()
because this function searches the default icon directly.
The function get_default_image() is moved from icon.c to wdefaults.c because
it is now used in both places. This function is now splitted, to find the file
(get_default_image_path) path and the file image (get_default_image)
The function get_pixmap_icon_from_icon_win() is now rewritten.
This function now creates the icon using the function get_window_image_from_x11(),
using itself as Window and updates the icon using icon_update_pixmap().
At this point the Pixmap is only the icon background. Now we must put inside the
dockapp, in the correct position. Then the funcion get the dock application size,
(the max size is wPreferences.icon_size, because get_window_image_from_x11() checks
the valid size), checks if the icon has title and then reparents the dockapp to put
it inside the icon.
This patch includes a lot of comments to better understand the code.
The function get_wwindow_image_from_x11() is renamed to get_window_image_from_x11()
and does the same work, but now its argument is a Window struct instead of a
WWindow.
This change is better because it allows objects with Windows (but without
WWindows) to call this function.
The function now is not static to allow its use in other parts of the code.
A new functions get_pixmap_icon_from_x11 and get_rimage_icon_from_x11
are included in icon.h
1. get_pixmap_icon_from_x11, set the rimage at icon->file_image
The code sets net_icon_image in icon->file_image
2. The get_rimage_icon_from_x11 function, only converts
the icon->file_image in icon->pixmap
The function get_pixmap_icon_from_wm_hints() is splitted in two
functions now:
1. get_rimage_icon_from_wm_hints, set the rimage at icon->image
The code comes from the function get_pixmap_icon_from_default_icon()
2. The get_pixmap_icon_from_wm_hints() function, but now only converts
the icon->file_image in icon->pixmap
The function get_pixmap_icon_from_user_icon() is splitted in two
functions now:
1. get_rimage_icon_from_user_icon, set the rimage at icon->image
The code comes from the function get_pixmap_icon_from_default_icon()
2. The get_pixmap_icon_from_user_icon() function, but now only converts
the icon->file_image in icon->pixmap
The function get_pixmap_icon_from_default_icon() is splitted in two
functions now:
1. get_rimage_icon_from_default_icon, set the rimage at icon->image
The code comes from the function get_pixmap_icon_from_default_icon()
2. The get_pixmap_icon_from_default_icon(), but now only converts
the icon->file_image in icon->pixmap
The function get_pixmap_icon_from_wm_hints() is now rewritten using
the functions get_wwindow_image_from_wmhints() and icon_update_pixmap().
Now, the function creates a new RImage using get_wwindow_image_from_wmhints()
and then updates the Pixmap using the function icon_update_pixmap().
The CachedPixmap folder is added to the icon list. This is because
if one icon is created, but the user change it and set other icon, the first
icon cannot be selected anymore using the settings window. The user
needs modify the configuration files by hand.
Some extra paths are added to the debian default config file.
This patch changes the behavior of wIconChangeImageFile.
Before apply this patch the behavior was:
The image (file_image) is set to NULL, then the function tried to find
a new image. If the new image was not found, the variable file_image contains
NULL when the function returns, and the return code was 1.
With this patch the image is changed only if a new image is found.
The function wIconChangeImageFile mustn't update the icon if
no file is set.
This is a bug. To reproduce it:
1. Right click on dock icon. Select "Settings"
2. Erase the Icon Image contents (set empty)
3. Click "OK" -> Exit, no changes... no?
4. Right click on the same dock icon. Select "Settings"
5. Erase the Icon Image contents (set empty)
6. Click "OK" -> Crash
If wmaker don't crash, watch the file ~/GNUstep/Defaults/WMWindowAttributes,
the default icon ("*" has trash in the name). Probably something is not fine
at wIconUpdate.
