This commit fixes issues #72 (brought up + different solution by Mattias
Guns; I received a similar patch by 'Nable 80' via ML and discussed the
issue in #fluxbox with 'Nable 80'), patch #73 (Mattias Guns) and finally
patch #162 (Ulrich Eckhardt; this commit is heavily based upon Ulrich's
work).
The original code was overly complex. It tried to avoid writing
bytes to the disk at the expense of comprehensibility and as a result it
was buggy. I looked at both patches from Mattias and 'Nable 80' which address
the bug with skipping entries in the history-file (my fault: incorrect use
of outfile.ignore(1, '\n')): They provided a proper fix for the problem
but I decided to use Ulrich's code since it improves the whole code by making
it a lot simpler.
So, kudos to all of you.
usually $HOME is set when fluxbox runs. in some rare scenarios (eg., fuzzying
binaries to detect bugs) one could launch fluxbox by using 'env -i' and thus
eliminating $HOME from the environment. to prevent crashes fluxbox uses now
'getpwuid()' when $HOME is not set to detect the home folder.
This commit alters XRANDR (X Resize And Rotate) extension dependency,
which is expected to have at least version 1.4. Earlier old versions of
xrandr were supported, at least to some extent.
Do not try to be too smart which compilations need config.h, as most of
them will simply because of the config.h has information about system
capabilities.
ClientPatterns might be tricky to get right. Instead of fiddling around in
either the keys-file or the apps-file and restarting fluxbox to see if the
changes had any effect / matched the right windows, 'ClientPatternTest' and
the fluxbox-remote should make this easier:
$> fluxbox-remote "clientpatterntest (title=.*vim*)"
This causes fluxbox to store the list of matched windows in the
_FLUXBOX_ACTION_RESULT property onto the rootwindow. This property might
then be read by:
$> xprop -root _FLUXBOX_ACTION_RESULT
or
$> fluxbox-remote result
The format of the list is:
win_id \t title_of_window \n
win_id is '-1' when fluxbox wasn't able to parse the given ClientPattern.
win_id is '0' when there are no windows matching the given ClientPattern.
fbsetbg: The random number generation used 'time' shell internal, which
does not exist in all shells. Allowing 'ps' output to be part of cksum
input will increase entropy and enhance quality of the randomness.
fbsetbg: The second fix is more important. In posix shell there is no
'==' comparision operator.
fluxbox-generate_menu: There are no quarantees about echo accepting
options, so use 'printf' for more advanced outputing.
The previous check relied upon the (undocumented) return value of
XChangeProperty to determine the exit status; at least, on my gentoo system,
the function seems to return 1 even when it fails to change the property
due to contrived, and invalid, parameters. However, setting an error
handler allows proper detection of this case. So, now the return status
properly indicates whether or not the property was changed (but not
whether fluxbox liked the command!).
Add a few lines of code to prevent a few spaces in some menu output.
'{$app $options}' would expand to '{app }' if no options were set.
Also, while scattered throughout, in this particular spot the
unnecessary braces around some of the variables (and not around some
others) and inside flux's braces could be very visually confusing and
lead to editing errors, so removed those.
Transpose one function from main to the rest of the functions and one
block from the top of the script to the top of main. Add an 'End
functions' comment.
before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.
the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).
bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.
our users should migrate seamlessly to our new windows-cycling behaviour
without losing their current way of doing things. so, 'fluxbox-update_configs'
tries its best to add '(workspace=[current])' wherever it looks like a valid
place for it. such changed lines are marked by '!! FBCV13' at the end and can
be easily spotted in case the updater got it wrong.
addtional changes:
* added '-check' to 'fluxbox-update_configs' to check the version number in
'~/.fluxbox/init' vs. the version number of 'fluxbox-update_configs'
* moved the update-code for each version into its own function, easier
housekeeping
a 'BidiString' holds both the logical content and the visual reordered
version of the content of a string. this helps to reduce the number of
calls to reorder the string before drawing it (as introduced in the patch
from Ken Bloom) and to be more consistent in menus and textboxes (drawing
cursors and underlining text).
