Based on libexif feature, this patch is adding orientation
detection and provides 2 more shortcuts for live
right/left rotation. Internal version was bumped to 0.7.
cppcheck is reporting the msg below:
[../WINGs/winputmethod.c:215] -> [../WINGs/winputmethod.c:209]:
(style) Found duplicate branches for 'if' and 'else'.
The patch is fixing it by setting a default return call.
With a set of images i was able to detect that
the flip functions was shifting the image by 1px.
The 90 and 270 degrees rotation were not working as
the functions were also mirroring the img.
The patch is also fixing the C style based on checkpatch.
when the rotation angle value passed to RRotateImage is a modulo of 90,
the function is working well but in other cases the rotateImage()
function is called. That last function is half implemented but
the half already implemented part is also segfaulting (use the testrot.c
to replay the crash).
So the patch is moving the 'not implemented' msg to disable the whole
rotateImage() function and comment it out.
moving scr initialization after WApplication existing test
to prevent crashing in case wapp is null
Acked-by: Christophe CURIS <christophe.curis@free.fr>
The library uses internally a cache of tables to convert image to different
depths, there is now an internal function 'r_destroy_conversion_tables' to
free them.
This patch is adding support for google webp image format, if you
don't know it a quick recap is to say that according to their tests
they claim it is better than png and jpeg.
Follow the link below for some more details:
https://developers.google.com/speed/webp/
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
load.c is used to identify the file format, I rebased some checks on
what is defined in the spec of the format.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This is actually taken from patch:
wrlib: Added support for webp image
in which it is out of place as it is unrelated
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
1) according to that checks i was able to see that some netpbm support
type are missing (exactly: ascii graymap (PGM files) and pixmap (PPM)
and ascii/binary bitmap (PBM))
See the link below for more details.
http://en.wikipedia.org/wiki/Netpbm_format
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
This patch is used to add support for syslog messaging implemented in
WINGs lib directly, so available from the lib itself and wmaker too.
I believe it will in a first time help to get some logging info
centralized in one point, and in a second time maybe add some info
level messages like wmaker is starting, stopping, restarting and else.
For now, it's built by default when the syslog support is found, maybe
we could also disable it by default.
This patch is replacing XRandR naming to RandR,
as XRandR is the name of the tool used in X11 and RandR
is the technology WMaker wants to support.
I had to update the info panel too, when many features are
activated not all of them can be displayed properly.
There are a number of window maximization options which are currently
only available to the user via keyboard shortcut:
* maximize vertically/horizontally
* maximize left/right/top/bottom half
* maximize left top/right top/left bottom/right bottom corner
* maximus
In this patch, they become available through the window menu, under
the "Other maximization options" submenu.
I use xrandr to decrease the resolution of my display when I connect
it to my TV. When I change the resolution back to my monitor, a few
of the icons at the bottom of my dock are deleted.
This happens because wmaker computes the maximum number of dockapps
which the dock can hold based on the screen resolution:
icon_count = scr->scr_height / wPreferences.icon_size;
and drops the dockapps above that number (in wDockRestoreState()).
But now the resolution can change via xrandr, so the above computation
can lead to dockapps being dropped when the new resolution is smaller
than it used to be.
To fix this it's enough to have a resolution-invariant number of allowed
dockapps.
A minor bug has been bothering me for a long time. When you maximize a
borderless window in Window Maker, the window ends up too narrow and too short
by two pixels.
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>
David Maciejak