The new workspace struct includes the global information
for the workspaces. All information related with the workspaces
should be included here.
The first variable moved is workspace_name_font, included in this
patch. This variable was included in the screen info, but the
screen and the font used in the workspace name don't have any
relationship.
This patch changes the keybinding check in cycling keyrelease.
Now, the variable binding contains the keypressed, so we can
check if the key pressed is the same than the keybinding. If
the keybinding is different (user press other key) then finish.
Without the loop, the code is faster.
Then, the keybinding variable is not used anymore, and can be removed.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
The function StartWindozeCycle() uses now the variable WShortKey
to store the shortcut key.
The code is the same, but now the hasModifier variable is calculated
in only one place.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
We were using wwin as the temporary variable in WM_ITERATE_ARRAY() but
wwin was already set to the result of WMGetFromArray() and was due to be
returned from the function. As a result of this oversight, wwin was
always set to NULL.
The bug could cause a problem in the - admittedly rare - case where all
windows were minimised at startup, causing the first invocation of the
switchpanel to highlight the first minimised window but then fail to
raise it.
Reported by Yury Tarasievich.
This patch removes the error variable, because is not changed
after their initialization.
This patch also removes the if check to wfree the path variable,
because this variable never is NULL.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch swaps the if and the else blocks for the
image value. Now, if the image doesn't exist, and because
error is always "0" (is not changed after the definition),
we can exist from the wIconChangeImageFile function.
Before this patch, if the image was NULL, the error variable
was set to "1", so we must return !error, then return "0".
Because the "path" variable is not NULL, we must wfree it.
Now, the "Set the new image" block is moved out the if block.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch swaps the "if (path)" block to "if (!path)"
therefore, the true block is now "error = 1" and the
false block is the call to get_rimage_from_file function.
The second change is that the "error = 1" statement is
changed to "return 0", because if "error" is "1", then
only the "return !error" statement is used, then we can
change it for "return !1" that is "return 0".
Then, we can move the get_rimage_from_file call out of the
if block.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
A default cursor would make sense if we were talking about an API,
where we would propose a 'I-don't-know' choice to devs, but here
we're talking about WindowMaker's internal, where we're supposed
to provide a consistent interface to the user, so picking a
cursor is not an option (and 'Normal' is actually a decent
looking choice anyway).
Suggested-by: Rodolfo García Peñas <kix@kix.es>
As the cursor choice for each action is actually a user choice,
it is logical to put this into the structure, instead of a poorly
defined 'extern' in every file.
Having all the global variables at the same place will provide
better visibility on the code; grouping them in a structure
reduces the risk for name clash; it also offer the possibility
to organise them.
Another BIG benefit is that, when reading the code, an access to
a global variable will now be clearly visible, and distinguished
from a local variable use.
The name will be a problem with next change because it uses a too
common word which will be useful at a better place.
Took the opportunity to rewitre the check in the human logical
thinking order to make it easier to read.
This patch includes the function "NumLockMask", that checks if the
Alt Modifier key is "NumLock". Then we can use this function in the
calls to Capture the key sequence and don't use this modifier.
This patch includes the changes for the new debian package 0.95.5-1:
Changes are:
- New libwutil library, new version 3:
- Updated debian/control file, replacing libwutil2 with libwutil3.
- Files moved in debian folder:
- libwutil2.changelog-upstream -> libwutil3.changelog-upstream
- libwutil2.install -> libwutil3.install
- Removed file libwutil2.symbols
- New file libwutil3.symbols
- libtiff migrated from version 4 to version 5:
* "Build-Depends: libtiff5-dev" in packages wmaker and libwraster3-dev,
since libtiff-dev introduces dependency to libtiff4 which is in oldlibs.
- Small changes:
* Included the word "WindowMaker" in the wmaker package description,
to found it easily.
* When compiled on DragonFly+gcc 4.7.3, this out of bounds array element
initialization causes an important variable to be overwritten and a
subsequent WindowMaker crash
* It was sheer luck other compilers/environments didn't exhibit any obvious
issue so far
The flag "supports_tiff" doesn't belong to the wScreen, because all
screens has (or not) the same value. If wmaker supports (or not) tiff
files is global to all wmaker, not to the screens.
The optimize_for_speed was used to set the Alpha channel for jpeg.
The alpha channel for jpeg should be used always. The current CPUs/GPUs can do
it without problems and this is an old behaviour.
This patch removes some extra curly brackets, some empty lines,
extra spaces,...
This patch is not removing the goto calls. I am not sure if the code
is better without gotos.
This patch removes some extra curly brackets, some empty lines,
extra spaces,...
This source file had some empty if blocks. Now are removed.
This patch also changes some preprocessor macros for C code.
When an application steals focus and switches workspaces autonomously,
"ignore workspace change" does not get reset. Since I didn't want to
track down the exact case I thought it best to reset the flag in all
cases, as it probably should be.
> How did you discover this? What was the behavior you saw?
After saving files in avidemux, the "Done" dialog pops up, and with it the
entire application is moved to the current workspace. After this, using the
mousewheel on the root window or using the appropriate key combination does
not change the workspace anymore, only using the arrows on the clip works.
And, as mentioned on the mailing list, just starting emacs (22.3.1) also
provokes this bug. Using a Debian/Sid system btw.
modified: WPrefs.app/po/Makefile.am
Ommited .pot messages in Docks.c were recovered.
modified: WPrefs.app/po/ko.po
Update Korean Localization of WPrefs.app to 0.95.4
modified: po/ko.po
Update Korean Localization of WindowMaker to 0.95.4
The original type was not as safe as it looked like to be, and led
to more memory usage than necessary.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
It is bad practice to define the prototype of an external function
inside a source file that wants to use it.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
It is dangerous to define an extern variable locally because the
compiler is not able to ensure proper type definition, but including
the header that defines it allows a safer situation.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The whole changeImage() function in switchpanel.c is a no-op if
wPreferences.swtileImage is set to None because the panel isn't actually
drawn in that case. As a consequence there are no images to change.
As well as being logically incorrect the existing code causes a segfault
if the user has the SwitchPanelImages preference set to None because
changeImage() would attempt to access the icons and images arrays which
are only initialised in wInitSwitchPanel() when swtileImage has a value.
Bug report and diagnosis by Juan Giordana, Gabriel Vlasiu and Christophe
Curis.
There is a dedicaded floating point modulo operator that does a
better job (faster, no precision loss), so we use it instead of the
complicated formula that uses type conversions.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
For this case we happen to already have the same variable as integer
type, so it is better to use them directly for computation.
Please note that the floating point variables do not contain more
precision in this use case, otherwise the change would not be
transparent.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
