This patch contains several improvements in order to make the help
output more readable (reduce length of first column):
- move default value into description
- use ... instead of too long format strings
- use [] for optional arguments
This patch contains several improvements:
- add missing colons before format strings
- always print format string after argument
- do not duplicate format string before description
- use <replaceable> only for variables in format string
- use +/- for boolean arguments
- print also default value for all kinds of arguments
This patch contains several improvements for arguments list:
- use capitals consistently
- remove full stop sign at the end
- use "experimental" constiently for unstable and hacky features
- use <> for variables consistenly
- use [] for optional parts consistently.
- shorten some format strings to make /help more readable
- replace whitespace in variables for better readability (especialy man page)
- fix wrong argument tyes
- add missing formats
When unlinking the file before binding, a new entry is created
in the file system after binding. This is not desireable, so
unlink it after binding to remove the temporary file after the process
closes.
If the size parameter is used with a percentages like /size:50% now
an additional 'w' or 'h' can be appended (like /size:50%w) to specify
where the percentage should be applied. If both or none are set the
behavior is like it was before and the percentage is applied to width
and height.
SDK 10.13 (and possibly olders as well) need HAVE_UNISTD_H to be set to
a value if available otherwise the following error is thrown:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/dispatch/dispatch.h:38:45:
error: expected value in expression #if !defined(HAVE_UNISTD_H) || HAVE_UNISTD_H
* client/x11: Fix colors on big endian
The bitmaps are recieved in little endian byte order (LSBFirst in terms
of X11). This is a problem on systems, where bitmaps are expected in big
endian byte order (MSBFirst). X11 client tries to handle this situation
by different color formats (e.g. RGBX vs. BGRX), but this doesn't work.
BGRX is not MSBFirst variant of RGBX, it should be XRGB. But this would
work only for 32/24 depths, where color channels matches bytes. Let's
say to the XServer that all the bitmaps are in LSBFirst encoding instead
of changing the color formats on big endian systems.
https://github.com/FreeRDP/FreeRDP/issues/2520
* client/x11: Fix cursor color on big endian
The cursor color is wrong on big endian systems. It is not probably
possible to force bitmap_order for XcursorImage as it is possible for
XImage. Fortunately, cursors are always 32 bit so we can use ABGR
instead of BGRA to deal with.
https://github.com/FreeRDP/FreeRDP/issues/2520
* client/x11: Fix comment indentation
The comment has wrong indentation for some reason, let's fix it.
* client/x11: Fix BGR vs. RGB detection
The BGR vs. RGB detection code is leftover from history and I am conviced
that it is wrong with the current color handling, where invert flag is TRUE
by default. However, I suppose that the detection still makes sense and
XServer may use the inverted formats in some cases. Maybe we can force XServer
to use our masks somehow, but let's just fix the value to FALSE now.
* client/x11: Remove unused color shifts
The color shifts are lefover from history and are not used in current
code. Let's remove them.
