For a icon, the icon image is stored in icon->file_image. If we repaint
the image, we we don't need search the icon again. We can continue using
icon->file_image.
Indeed, if launch the "window inspector" window (winspector), using a
saved icon and "ignore client icon" set, then the database holds the
name of the icon to draw on the screen. If we remove the icon info in
the winspector (removing the file name or un-setting the "ignore client
icon" flag, then the database losts the icon name and then the function
wDefaultUpdateIcons() cannot find the icon to draw for the icon.
In winspector, with this patch, the previous image set by "ApplySettings"
and stored at icon->file_image is used.
This patch avoids to save the icon name in the configuration file
if the flag "Ignore client supplied icon" is not selected.
First, when winspector tries to show the icon to the user, it must not search
the default icon. It should use the specific icon or the icon provided
by the client.
When we click in "save Settings", the function saveSettings reads the icon
specified by the user in the text box. If the checkbox "Ignore client supplied
icon" is not selected, then saves the icon too.
Using this behaviour we never recover the initial position (no icon selected,
no ignore client supplied icon flag set). This patch recovers the initial
state of the icon options.
When the user unsets the ignore client the filename provided is not saved in
the configuration file. Now, the configuration is like the initial status.
If the user checks the flag and set the file to use as icon, the file is used.
This patch sets a correct style on winspector.c. It removes some
empty lines, moves variable definitions to the function heads,
moves preprocessor definitions to the top of the file and removes
some extra curly brackets.
The function to create the winspector panel is so big, and is hard
to understand it. This patch split the function createInspectorForWindow
in some extra functions:
create_tab_window_attributes
create_tab_window_advanced
create_tab_icon_workspace
create_tab_app_specific
This functions don't do nothing extra, only the code is moved to them.
This patch avoid a crash when moving an icon without command.
To reproduce the problem:
1. Launch an application, for example xeyes, with appicon.
2. Move the appicon to the clip.
3. Close the application.
4. Edit the appicon in the clip, and empty the commands fields.
5. Move the appicon from the clip to the dock. -> Crash.
The crash happends because icon->icon->owner is NULL and then
wwin will be NULL. Then the call of wwin->client_win will crash.
This patch checks if icon->icon->owner is not null (application is
running) and then assign it to wwin. Then get the command from the
running application.
Added CycleIgnoreMinimized configuration option settable on Expert page in WPrefs.
When option is set, switch panel cycling ignores minimized (grayed) windows. They
are still visible and can be selected using left/right arrows or mouse click.
Please find attached a diff to add the missing .h files from src/Makefile.am
One way to find these:
$ git checkout next
$ ./autogen.sh
$ ./configure
$ make dist-gzip
$ tar xzf WindowMaker-0.95.3.tar.gz
$ cd WindowMaker-0.95.3
$ ./configure
$ make
The function applySettings() set now the icons. Updated icons are:
- Appicon: Always, with or without always_user_icon
- Window: If the window is minimized, with or without always_user_icon.
Window must be minimized to see the icon change, else, wwin->icon
doesn't exist and therefore you won't see this change (no icon).
There is a problem if the window is not minimized and is minimezed,
because it will show the icon in the database, not the assigned icon.
This problem must be updated not here, in the wIconifyWindow()
function, at actions.c
The function wIconChangeImageFile set the file_image variable directly,
now the code is faster and the assigned image is used.
Before this patch, the assigned file couldn't be used, because wIconUpdate
serached the icon using different methods.
The variable wwin is only used in one block of the if, so should be moved
inside this block. OTOH, is better check if the variabl exists before
assign it. The code now is more stable and avoid crashes.
The dock applications has their icon image set in icon->file_image
to draw the icon if the application is not running. But if the
application is running, the icon mustn't be show. This patch don't
paint the icon for docks.
The function wIconUpdate can receive a image to setup as icon image.
If image is NULL, then use the original method, using different procedures
to get the image.
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.
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.
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)
