Allow setting relative value for x and y or width and height separately in
the apps configuration file. This makes these settings compatible with ones
available in the keys file.
Previous buggy behavior:
If someone has specified, e.g. "[Dimensions] {50% 100}" it was parsed as
"{50% 100%}" not as "{50% 100px}" which was inconsistent with the "keys"
configuration file.
From now on it is possible to write something like this:
[app]
[Position] (RIGHT) {50% 0}
[Dimensions] {300 100%}
[end]
Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
A bug sneaked into my implementation of Boyer-Moore-Horspool. This lead
to not finding certain patterns. Given the text 'abcdde' and the pattern
'dd', the faulty implementation would not find 'dd':
1. 'ab' does not match, skip 2 (length of pattern)
2. 'cd' does not match, skip 2 (length of pattern) <- the bug.
3. 'de' does not match, end of string
The bug in step 2 is to not use 'd' to detect how far to skip but to
use 'c' (which is not in the skip-table) and thus 2 bytes are skipped).
Different styles makes the menu width different.
When the original menu width is bigger than the newly selected style's
width, the rendering produces pretty strange effects:
The old style's frame not cleared, so it was rendered and visible next
to the new style edge.
With this change, the menu width will be as wide as the widest menu
item.
Style switching still not perfect, because the height of a menu item is
from the "first" selected menu, also font color are not updated.
We define the value ICONV_NULL = -1, but when we attempt to set the
s_iconv_convs array to all NULL values, we zero the array instead of setting
its entries to -1.
This patch properly initializes and wipes s_iconv_convs.
Instead of creating the titlebar buttons with a size of 10x10 pixels
and rely on resizing later on we now pick the correct dimensions
right on.
This fixes also bug #1125 ("Detaching a window from a tab-group renders
app-icon to 1/2"); the problem also occurred on restart.
I took the chance to refactor a little bit.
Fluxbox now supports three MenuSearch modes:
* NoWhere - essentially "disabling" the menu search.
* Somewhere - the search string matches somewhere.
* ItemStart - the search string matches at the start of a menu item.
The default value is "ItemStart", just in the good old times. As long as
this feature is not configurable via the menu it would irritate users
with distinct muscle memory who type without thinking OR checking the
visual feedback: they would trigger items they did not intent to trigger
after years of the old behavior.
Once this feature get's an entry in the config menu the default value
might change.
