As found by Rodolfo, a crash could happen when changing an icon to
a non-existent file. From his report:
Steps To Reproduce
1. Open the Settings box, for example for WMDock. (Right click on WMDock, Settings).
2. In the "Icon Image" field, write some characters. For example "asdfasdfasd".
3. Click in "OK". You get "Could not open specified icon file: GNUstep.tiffasdfasdfasd"
4. Hit in "OK"
5. Repeat 2,3,4 some times (sometimes 1, sometimes 2, sometimes 10).
The problem came from freeing the previous icon but not updating
the pointer, so if the new file did not exist it ended up with a
fake-looking icon being used, hence possible crash.
BTS: http://www.kix.es/mantis/view.php?id=1
This patch avoids the icon creation in winspector.c and adds the
ability of creating + paiting and unpainting instead of destroying the icon.
Now the icon is always created by wApplicationCreate and the icon
exists while the application is runnning. If the user doesn't want
an appicon the winspector.c will not remove the icon, it will only
not paint it on the screen. But the icon is still created.
Probably the most difficult part in this code is how to handle the
icons in the iconlist. We must include the icon in the iconlist when
it is painted, not when it is created. And it must be removed when it
is unpainted.
We can check if the icon is in the iconlist if icon->next AND icon->prev
are null, else it is on the applist. If it is included we must not
paint it again because the function PlaceIcon() will calculate a new
icon place in the screen including the icon!, then a hole is painted.
This patch set the vmask in one line.
- vmask = CWBorderPixel | CWCursor | CWEventMask | CWOverrideRedirect;
- vmask |= CWColormap;
Is similar to:
+ vmask = CWBorderPixel | CWCursor | CWEventMask | CWOverrideRedirect | CWColormap;
And vmask is not used between the two original lines, therefore we can do the
initialization in only one line.
The contents for searching the icon in wAppIconCreateForDock()
are moved to icon_create_for_dock().
Now wAppIconCreateForDock() and wAppIconCreate() do the same work and
icon_create_for_dock() and icon_create_for_wwindow() do the same work too.
The procedure to create the icon is similar in both functions.
Now wAppIconCreateForDock, needs more arguments (command, instance and class).
These functiosn were renamed:
wIconCreateCore to icon_create_core
wIconCreateWithIconFile to icon_create_for_dock
wIconCreate to icon_create_for_wwindow
The variable "dicon" is now named "aicon", the same name that
the WAppIcon variable used in wAppIconCreate.
Some clean code more, like spaces in function arguments.
Remove the call to wIconUpdate() in wAppIconCreate() and place it in
makeAppIconFor() since wAppIconCreate() is only used in that function
and icon update or icon painting is not icon creation.
Now the function wAppIconCreate() only creates the app_icon.
The function wIconCreate search the icon image calling wDefaultGetIconFile.
wDefaultGetIconFile search first the icon file name and then search the
image using the icon file name. wDefaultGetIconFile returns the icon image
to wIconCreate, then wIconCreate search the file name (again).
Is better that wIconCreate search first the file name, and then get
the image using the file name.
Code in the function wIconCreateWithIconFile does the same task as
get_default_icon_rimage(), therefore replace it with a call to that
function.
It is the code to get the image file (rimage) using the file name.
This patch reviews the code style in dock.c, removing some
curly brackets not needed and adding other where needed.
This patch removes some lines commented and some extra lines for
better understanding.
After we exit there are no window decorations therefore frame extents
are meaningless.
We could be left with parts of the window being the wrong opacity if the
property is left intact and a compositing manager configured to draw
decorations with a different opacity to the rest of the window is still
running.
Remove the _NET_FRAME_EXTENTS property from all windows when we shut
down to prevent windows from being drawn incorrectly after we're gone.
Using window-supplied depth, visual and colormap information has the
side effect of causing window borders to be draw using inconsistent
colormap entries. Allocate entries from each window's colormap when
drawing its border.
Force setting the border when the window is first created so it's
guaranteed to be drawn in a consistent state.
Recalculate frame extents when the titlebar, resize bar or border are
enabled/disabled.
Account for border when calculating top and bottom frame extents.
Quoth I,
> I've just seen that _NET_FRAME_EXTENTS isn't updated when
> disabling or enabling the titlebar, resizebar and border of a window,
> so that needs to be fixed.
The attached patch fixes _NET_FRAME_EXTENTS not updating when using
the inspector to disable or enable the titlebar, resizebar or border.
It also fixes not taking the border width into account when
calculating the top and bottom extents.
With the patch the window's border is drawn for 32bpp urxvt windows
with compton. The border still isn't black, however. That's because
the border is taken from the screen's colormap rather than the
window's. I'll have a fix for that soon.
Accept windows' depth, visual and colormap instead of always using those
of the root window. Internal windows such as menus behave as before.
In conjunction with a compositing manager on a display supporting the
RENDER extension windows can now manage their own opacity.
I wrote the patch after reading the FAQ for urxvt, which says,
regarding transparency support:
"3. Use an ARGB visual:
urxvt -depth 32 -fg grey90 -bg rgba:0000/0000/4444/cccc
This requires XFT support, and the support of your X-server. If that
doesn't work for you, blame Xorg and Keith Packard. ARGB visuals
aren't there yet, no matter what they claim. Rxvt-Unicode contains the
necessary bugfixes and workarounds for Xft and Xlib to make it work,
but that doesn't mean that your WM has the required kludges in place."
In conjunction with a compositing manager (I tested compton) it does
work and urxvt draws a semi-transparent background with fully opaque
foreground text and scrollbars; much prettier than applying a blanket
transparency value over the whole window with the compositing manager.
Other application windows I tested were, as expected, drawn the same
as before.
I verified that urxvt is drawn in the same way when using xfwm4
(with builtin compositing). Since Window Maker doesn't (at time of
writing) have its own compositing manager I should clarify that one is
required to see any benefit from this patch.
Whether or not this feature is useful for any application other than
urxvt I don't know, though I assume that an application which chose an
ARGB visual in the same way would be able to draw itself prettily.
On a display without RENDER things work just as they do without the
patch. I have, however, only been able to test on a fairly standard
TrueColor display supporting multiple colour depths with 24bpp being
the default. Testing with more ... exotic ... display types would
probably be advisable.
The functions wDefaultGetIconFile(), get_default_icon_filename() and
get_generic_value() use the argument noDefault in order to avoid searching the
default icon. This double negation is difficult to read though. This patch
changes it to be True if the default icon should be included or false if not.
This patch changes the noDefault argument to default_icon, then the
True is now False and False is True.
The main change is at get_generic_value():
- /* Search the default icon name - See noDefault argument! */
- if (!value && !noDefault) {
+ /* Search the default icon name - See default_icon argument! */
+ if (!value && default_icon) {
Because the functions wDefaultGetIconFile() and get_default_icon_filename()
mainly forwards the noDefault argument to get_generic_value().
The icon size should be set when the icon is created. Therefore the icon size
for net_icon_image should be set at get_wwindow_image_from_x11(), function that
creates the image.
The function scaleDownIfNeeded's code is duplicated with the code of
wIconValidateIconSize(), then this function can be removed. The icon
size in the switchpanel should be ~48 pixels, to allow the frame around
the icon. Then, we always should resize the icon to this size. The standard
icon size is specified in WPreferences.icon_size (usually 64 pixels).
The icons should be scaled if their size is "max_size - ~3 pixels".
Tipically, max_size is 64 pixels. With the current wIconValidateIconSize
the max size for an icon is "64 pixels", then the icon don't have border
and is ugly. This problem is in the dock icons and in the switchpanel.
The new wIconValidateIconSize function don't use the fixel value of 64
pixels, uses the argument max_size to get the final icon size. The icon
is scaled holding the aspect ratio and reserve ~2 or ~3 pixels to hold
left space to the icon border. Now the icon is inside the icon space,
with border.
This patch removes the preprocessor option of DONT_SCALE_ICONS, because
all the icons should be scaled if needed, to hold a beatiful interface.
The default icon (defIcon) is never used because the function wDefaultGetImage
always returns a icon (it searches the default icon). So we can remove the
defIcon variable, its creation and remove code.
The function create_default_icon sets the panel's default icon. This
is interesting to have a "cache" icon and don't search the default
icon more than one time if the icons don't have icon associated.
The code of create_default_icon was included in the addIconForWindow()
function, this patch only moves it to get a better (clear) code.
Now that the built-in parser has support for all the feature of CPP
being used by WindowMaker's default menu, we can remove the stuff
related to calling CPP:
- code for preparing and running CPP;
- compile-time option to de-activate the call to CPP;
- command-line option
A number of macros are pre-defined by WindowMaker for CPP in the
function 'MakeCPPArgs', they are now available in the internal
parser too. CPP also had some predefined macros, a subset of them
have been added.
The definition have been split in two parts:
- the macro that are dependant on WindowMaker parameters are
defined by WindowMaker (src/rootmenu.c)
- those that are independant, which can be defined by the parser
itself (WINGs/menuparser_macros.c)
The parser is prepared to handle '#' directives, starting with file
inclusion. The search path for the file are taken from what was
actually given to CPP. There is an arbitrary limit to the inclusion
nesting, which is actually not a design limitation but a security
to avoid infinite include loops.
The default function used so far provides informations not so useful
to user, like wmaker's source file, line number and function; it
also cannot provide the line number from the parsed file because cpp
messes this information.
With this dedicated function we try to provide useful things which
are being tracked by the parser internally, like valid line number
and the name of the file being read (which can be convenient in the
case of #include, for which we may also be able to provide the
inclusion tree!)
From caller point of view, the two function have been merged into a
single function in the API. This will be needed by the advanced
parser that will have to not separate the concept of a 'line' and
the concept of 'content' (due to empty/comment lines, multi-line
comments, long lines split with '\')
All the information related to the file being parsed are stored in
a single place. The content of this structure is not visible to
caller to avoid messing the content; the parsing will be handled as
methods to this object.
Please note that all functions visible as part of the parser's API
are using the CamelCaseNotation to be consistent with the rest of
the API; however all internal functions use the non_camel_case_syntax
to follow the coding style set by Carlos for the project.
Due to the tasks to take in charge, the internal parser will grow in
size to support basic CPP feature, so it is a good idea to start by
moving the current functions into a dedicated file.
The code to find the icon in the function getWindowMakerIconImage()
is duplicated, because it is the same code as in get_default_icon_filename()
This patch includes the prototypes of get_default_icon_filename()
and get_default_icon_rimage() in defaults.h, so these functions
can be used in other files.
The function wDefaultGetImage() is splitted in two:
1. get_default_icon_filename(): This function returns the full
path of an icon. The function searches the icon in the database
using instance and class.
2. get_default_icon_rimage(): This function returns the RImage for
a given image path (full path). This function validates the icon
size, so the icon is fully usable.
The function get_default_icon_filename() now adds the .app icons in the
search (using wApplicationExtractDirPackIcon()). To do it, the command
should be included, because this function searches '"command".app' icons.
Setting the command to NULL, this case is not used.
To do it we need the function wApplicationExtractDirPackIcon() defined
at appicon.c, so we need set the function as non-static and provide their
prototype in appicon.h.
This patch also includes an extra pointer check at wDefaultGetStartWorkspace
to make sure that WDWindowAttributes exists.
This patch adds support for the _NET_FRAME_EXTENTS property as
described in the EWMH spec. With it I was able to use the compton
compositing manager to draw fully opaque windows with semi-transparent
titlebars and resizebars.
Set the _NET_FRAME_EXTENTS property based on border widths and
titlebar/resizebar heights.
The EWMH spec says:
"_NET_FRAME_EXTENTS, left, right, top, bottom, CARDINAL[4]/32
The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the
window's frame. left, right, top and bottom are widths of the
respective borders added by the Window Manager."
Update the saved X co-ordinate of a window which was moved when
maximized (only) vertically so that unmaximizing the window restores
its dimensions without warping it back to its previous X position.
Similarly update the saved Y co-ordinate of a window which was
moved when maximized (only) horizontally.
Handle Maximus as a special case. We remember the Maximusized X and Y
co-ordinates then adjust the restored co-ordinates relative to the
delta between the window's position just after Maximusizing and its
position just before restoring. So for example if a window is
Maximusized, moved 100 pixels to the left and restored, it will end
up 100 pixels left of its original geometry.
Also fix "jumping window" bug reported by Christian Wittmer:
This "jumping window" happens only when you
1) open new xterm (STRG +n)
2) current position is (+64, +0)
3) maximize window vertically
4) undo maximizing
5) move window to the right or left (up or down as you like)
I moved right to (+450, +0)
6) maximize vertically again
7) and undo maximizing
8) window jumps back to (+64, ..) position
If you move a new opened window to a new position (e.g. +200, +200)
and then start with "3)". window is jumping back "+200, +200"
The variables waiting_save_ack, dragged_while_fmaximized,
buttons_dont_fit, rebuild_texture and needs_full_repaint are not used,
so they can be removed.
Even though net_state_from_client was never being set, it was
being tested inside a
if (!wwin->flags.net_state_from_client)
which according to testing was always being true (probably because gcc
initializes it to zero). But this situation is confusing, so it's
better to remove the if() test altogether as that is the intention
if net_state_from_client is not explicitly set (which it isn't in
the current wmaker source).
This situation is analogous to:
[mafra@Pilar:c]$ cat init.c
int main(void)
{
int a;
if (!a)
printf("No a = %d\n", a);
return 0;
}
[mafra@Pilar:c]$ ./init
No a = 0
The functions related to colormap are moved from funcs.h to the new
file colormap.h. These files are included where needed.
The functions wColormapInstallRoot and wColormapUninstallRoot are
removed, because they are not used.
