fluxbox uses std::unique_ptr<> where it previously used std::auto_ptr<>.
C++0X was approved in 2011. among other things, it deprecates std::auto_ptr.
5 years is long enough for compilers to catch up the standard.
This allows to catch if a grabbed key (combo) is actually w/o effect
(because eg. the OnDesktop condition does not match) and then replay
the event ungrabbed to pass it to the focused client.
Just like mouse grabbing, this BEARS THE POTENTIAL TO LOCK INPUT, thus
needs AS MUCH TESTING AS POSSIBLE
BUG: 1137
NOTICE!!!! THIS IS HIGHLY EXPERIMENTAL!
The patch alters the button grab mode to GrabSync
in order to ReplayPointer the event.
THIS CAN FREEZE ANY INPUT TO FLUXBOX!!!
The toolbar (and other things?) grab buttons in order to
handle MouseN events for the entire bar, INCLUDING all child
windows.
This causes two problems:
1. The bar handles events which are not meant for fluxbox at all
(but the systray icons)
BUG: 940
2. The bar will intercept (and suck) *every* press, even if only
doubleclicks are desired
BUG: 949
The problem with this patch is that an oversight here has the potential
to completely freeze input event processing in fluxbox (ie. the process
needs to be killed from outside), SO IT NEEDS TESTING!
As much as possible.
The evenly distributed space causes a lot of whitespace and otoh. cut
items, so we use the items internal size as indicator IF the item is a
textbutton (the regular usecase in fluxbox)
Also publish the function to be triggered from outside (because the
caller can, in theory, much better compress several text changes)
closing a keyboard driven popup had the sideeffect to return the focus
where the pointer is, regardless of whether that window had the focus
before (due to a NotifyUngrab crossing event), bug #597
This was resolved by simply ignoring NotifyUngrab mode crossings, but
that had the unfortunate sideeffects to break focus passing when the
mouse was actually moved (in a DnD operation, 730) or the focus shall be
passed on for strict mouse focus and a mouse triggered lower action (1012)
So instead we record the window that was last entered by a *real*
crossing and only ignore the NotifyUngrab event if this window didn't
change.
BUG: 1012
BUG: 730
CCBUG: 597
and align calculation on init and reconfigure
As a result, if a menu has no label, the title height is determined
only by menu.titleHeight (and the border sizes), not by the unused font.
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.
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.
Among the first steps to produce better i18n support is to test the created
translations adhoc without running "make install". To achieve this, fluxbox
now honors several environment variables:
- NLSPATH: fluxbox won't create the absolute path to the catalog and thus
catopen() is free to use NLSPATH as described in the manpage. Example
given: "/tmp/%N" will pick "/tmp/fluxbox.cat". %N refers to FLUXBOX_CATFILE.
- FLUXBOX_CATFILE: By setting FLUXBOX_CATFILE the users can make fluxbox to
use a different name for the catalog file. Default: "fluxbox.cat"
- FLUXBOX_CATDIR: Per default fluxbox tries to find FLUXBOX_CATFILE at several
places. Setting this environment variable allows to point fluxbox to a
different search path for the catalog files.
Then, fluxbox tries catopen() first without changing the deduced catalog file
name. After that it applies some heuristics to get a good catalog file name.
This commit implements a tweak to the typeahead feature already existent in
fluxbox: If the user opens up a menu and starts typing, fluxbox tries to
detect matching menu items and makes them available for quick selection.
The typed pattern is now search also in the middle of the text.
I opted to strip down the code quite a bit and remove complexity by throwing
out FbTk::TypeAhead and FbTk::SearchResult because I do not see the need for a
general solution when the only use case for such a feature is in fluxbox'
menus. FbTk::ITypeAheadable shrunk down to 2 functions; the whole file might
be combined with the code that implements FbTk::Menu::TypeSearch.
FbTk::Menu::setIndex() and related code is also gone: the position of each
menu item is defined by it's position in the items container. This reduces the
mount of book keeping fluxbox has to do. Fewer moving parts is a good thing.
It's possible that users start to complaint because they expect their
typed pattern to match only at the beginning of the text OR that some
demand other tweaks. We will see.
This commit also fixes a regression introduced by 8387742c. The bug made
the menu vanish.
'width' might imply something 'aligned horizontally'. The first parameter
of maxTextLength() is given in pixels. To avoid confusion, the name of
the parameter is changed.
The comment before the binary search reflects better why and what we
need to do.
A vertically rotated text should be checked against the height of the
button, not the width of it.
Fixes#1119 ("Toolbar cannot display full text of workspace/clock/window
title.")
Sometimes fluxbox is used as a component of a desktop environment (
e.g., the "Lumina Desktop"). It's easier and more stable for this kind
of "users" to disable the toolbar or the slit alltogether. Why not
configure these features out? Because then they would need 2 installations
of fluxbox: One without the slit and the toolbar (and perhaps other
components) and one with them.
This implements feature request #314, at least partially.
This commit also looks bigger than it actually is: I refactored and cleaned
up classes Fluxbox and BScreen.
There was a subtle flaw in the way fluxbox detects to which BScreen a
given Window belongs: We have to compare the RootWindow of the given
Window against the RootWindow of each BScreen.
That underlying flaw made _NET_REQUEST_FRAME_EXTENTS fail: the code path
needs a valid BScreen for the given window, otherwise we return early.
Closes#1121.
