applyState also requires some updates implied by moveResize, notably the
reconfigure, the setBackground on the window etcetc.
Instead of testing what'd be missing from a moveResize, we just force
the latter to apply even when seeming unrequired.
This has notable impact when switching fullscreen state for a window
with fullscreen dimensions.
BUG: 992
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.
commit 98313bf broke (i'm terribly sorry) this because m_cycling_last stores
the first client in a tabgroup, thus cannot be abused for this purpose.
So we explicitly store a value and btw. do it before sending the focus,
ie. "in time" for sure instead of "for sure™"
Testing one bug, the function seems usually be called with the root
window as parameter, so we can save a pointless lookup for the root of
the root by testing against window before testing against window_root.
Elegantly, this will "fix" the bug where XGetGeometry of the second
heads root will either report the first heads root or some junk (xephyr
case?)
BUG: 1128
the menu focuses which tries to set the current tab, but fails because
the iconified client won't have the input focus (yet), so we pass it a
dedicated "set this client and do not try to set input because we're
going to do next anyway explicitly" call =)
BUG: 997
While usually™ the window is just reset to its original layer, ensuring
to show the active window is certainly a good idea, but it's not
required to lower the fullscreen window to the desktop layer, the other
windows layer + an extra raise is entirely sufficient and it's rather
odd to see conky when activating a utility window to a video player ;-)
CCBUG: 894
Tabs outside the titlebar are not selectable by mouseclicks (ie. the
feature does not work)
The patch clones the enterNotifyEvent code and ignores (for now) the
actual button (no idea whether it makes any sense to restrict it the
left button?)
BUG: 1103
The apps file gets a new key
FocusProtection
supporting a comma separated list.
* None : regular behavior
* Lock : If this window has the focus, no other may claim it
* Deny : This window is not allowed to focus itself
I addition there's preparation for a follow-up patch to incorporate and
substitute the present FocusNewWindow feature:
* Gain : Pass focus to new window
* Refuse : Do not pass focus to new window
rationale:
clients stealing the focus sucks badly and while there's an input driven
timeout, that only protects actual typing flow, but if eg. vlc proceeds on
the playlist, you'll suddenly control vlc instead of your browser
(ie. typing ctrl+w doesn't close the tab, but the playlist ...)
The depth member of FbWindow was abused to store the maximum depth
but that gets overridden with geometry changes of the root window
(screen layout changes) so we store and read the value explicitly while
::depth() maintains the actual depth of the root window
The result of this is that frames for ARGB windows were created with a
wrong depth and failed to reparent the client window.
BUG: 1102
BUG: 1058
Still enough stupid ones around which ask for 0,0
(despite there's a panel ...) or restore a position
on a VGA screen which they stored while being on a 4k
screen.
Otoh, do not forcefully position the window just because
the topleft position is outside any head, this can still
be desired and isn't a problem.
Actually, the corner could be covered by the close button
and if *only* it is onscreen the window can hardly by used
or seen.
Clients which implement a client-side modality might cause
livelocks by reverting the focus to the transient (after the
WM tried to put it on the leader as the transient's modality
is unknown)
So while cycling we revert the focus whenever it moves somewhere
where we don't expect it.
When done, we also focus the window that should have the focus anyway
to allow the client to redistribute the focus (as we prevented it
during cycling)
Hall of Shame: Softmaker Freeoffice uses (only) client side modality.
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.
Under some circumstances a WinButton might be tiny (1x1 pixel). Substracting
values > 1 yields either 0 or something reaaaaly big (UINT_MAX). This will
make fluxbox either crash or make it act weird. We don't want this.
This commit fixes a subtle regression introduced by myself in
f64727ca: WinClient wc = FbMenu::window()->winclient() creates a
copy and this copy gets cleaned up at the end of the scope. What
I really wanted was a reference.
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.
When the windowmenu file is empty in ~/.fluxbox/init the code falls
back to the default. In ab2eef4 I forgot to set the rc_path which
caused this bug to happen.
gcc-4.2.1 on OpenBSD-5.6 hinted that strcpy() is not the safest function on
earth. While seeing the code I wondered why it we first create copies
of the names at all (let alone using memset() and then strcpy() after it).
In f64727ca I removed one 'else' too much. As a result all [maximized] lines
were mapped to MAX_NONE. Fixed.
The rest of the commit is just some cosmetic to reduce indentation and shorten
function names, easier to read.
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.
std::remove_if() removes an item from a container and returns a
past-the-end iterator ... which equals m_icon_list.end(). As a result
the check
if (erase_it != m_icon_list.end()) {
iconList().erase(erase_it);
iconListSig().emit(*this);
}
will never succeed and thus the iconListSig() will never be emitted.
There was a problem deep within how the menus were connected and when and
what gets deleted. It was clearly related to a menu which was kind of
global. In order to better understand the code flow I eliminated the
ExtraMenu code: it was used only to get the Remember-Menu into the
Window-Menu. Instead of having a singleton of the Remember-Menu and fight
against the shaky interconnections we just create a new one on demand
and delete when the menu gets deleted. Looks like this fixes the problem.
The menu code needs more love anyway.
Closes#1118
This reverts 58e09b7190 after having regressions
and bug reports in regards to autorepeated key events are not working anymore.
So, the problem with the lost keypress after the workspace change is still
open but at least the behavior for other folks is as it was. Since 58e09b7190
seems to be corelated to "auto repeat" keys it might indicate the problem
which 58e09b7190 "fixed". We will see.
Fixes#1115.
Note: I expect only modern compilers will hit the source of fluxbox. It
seems futile to guard stdlib headers while demanding <algorithm> etc. This
should trim down the noise in the source quite a bit.
Part of this massive looking but simple rather simple change is a the way we
check for active Xinerama: XineramaIsActive() was used before. The docs for
XineramaQueryScreens() state that
XineramaQueryScreens() returns NULL and sets number to
0 if Xinerama is not active.
Sold.
Every time either the Slit menu or the Toolbar menu were added to the
root menu, the whole root menu was (re)created from scratch. Now we
create and remove only the menus needed.
Side effect: the position of these menus is now at the end of the root
menu and not somewhere in between. If users complaint, I' ll think about
it.
This commit is a preparation step for some menu cleanup ahead. To make it
easier to understand which types of MenuItems are added where and when, I
converted the overloaded FbTk::Menu::insert() functions into explicit ones
(Menu::insertSubmenu(), Menu::insertItem(), etc. ). This makes it possible
to just grep for 'insertSubmenu()'.
Side effect this commit: it trims down the very verbose creation of menu items
in regards to how the labels are created.
Minor: FbTk::Menu::shown and FbTk::Menu::s_focused are moved out of the class.
The font might have an impact to the result of width() and height(). In order
to render the new pixmap correctly fluxbox now first sets the font and the
width of the border and after that it recreates the pixmap.
When fluxbox comes up some of it's drawables span a 1x1 area. Subtracting from
such small numbers bigger ones always lead to massive problems when 'unsigned
int' are involved:
'button_width' is an unsigned int of '1' (this might be caused by another
issue or on purpose, anyway), subtracting -10 or any other number should
result in something < 0 when in reality an integer underflow happen: max_width
is now MAX_INT-something big. This makes fluxbox crash under certain
circumstances.
This fixes bug #1116.
* Correctly build data files when operate outside of the $(srcdir)
* Actually install data files
* Use pkg-config to detect X11, works better on MacOSX. We used pkg-config
already anyway, double checking for X11 does not yield better results.
* Replace EXEEXT in some files while before installing them
xxx_LDFLAGS place the libraries like '-lX11' or '-lXft' at the beginning of
the linker command. Some systems were not able to handle the situation and
this lead to a lot of unresolved symbols. Reading the documentation of
automake:
... you can use LDADD to do so. This variable is used to specify
additional objects or libraries to link with; it is inappropriate for
specifying specific linker flags, you should use AM_LDFLAGS for this
purpose.
In addition we link against -lm in order to satisfy symbols refering to 'cos'
and 'sin'.
POSIX states that 'd_name' in 'struct dirent' is char[], so it cannot be NULL.
This will result in the compiler complainting about an expression which always
evaluates to true ... for this compiler (clang). But in some implementations
'd_name' is a 'char*' that's why it's better to keep the check for possible
NULL.
OSDWindow::resize(const FbTk::BiDiString&) shadowed FbWindow::resize(x, y). To
fix this I renamed the function to OSDWindow::resizeForText() to make the
intention clear.
While running code analysis tools this issue popped up. As it is written it is
clearly a NOP, but the reason for why it is written that way remains unknown.
I suspect that it was a textfragment introduced by some repeat-function of the
used editor (think '.' in VIM). The code was introduced by commit a932a7a801
and looked like this in the original form:
if(!XQueryTree(FbTk::App::instance()->display(), window().window(),
&root_return, &parent_return,
&children_return, &nchildren_return))
parent_return=parent_return;//return;
Look at the outcommented return statement. I decided to return from that
function instead of the NOP.
this commit implements feature-request #317: "Add support for GTK dockapps.":
"Back in 2010, WindowMaker implemented a system where windows with WM_CLASS
res_class = DockApp would be treated as if they had initial_state =
WithdrawnState, since GTK refuses to allow this."
kudos to Arkadiusz Bokowy (this commit is a slightly changed version
of a patch sent to the devel-ml): when retrieving the '.res_name' of
a XClassHint we should check '.res_name' and not '.res_class'.
the other changes only reduce the code.
handing over the dimensions of a WinClient client must not contain properties
of the FbWinFrame, otherwise they get added twice in
FbWinFrame::moveResizeForClient() and thus result in a resizes when no resize
is wanted.
other changes: it's easier for me to detect the nth bit when the value looks
like (1 << 8) instead of 0x0100 (for the 8th bit). that is why i changed
0x0100, 0x0200 etc. in the nearby code.
the -1 in the FbTk::FbTimer::remainingNext() function was pointless in the
first place anyway: reducing the timeout by just 1 microsecond improves
nothing (in this case). if the timer triggers exactly at a full unit (second)
then it's correct to wait for the full next unit.
the lag / skipping of the clock was not caused by faulty timer code
on fluxbox's side but by the behavior and inner workings of time().
since this is fixed now (913244789f) we can now rollback ec7fe513c8
and detect strftime-formats which need intervals of seconds or minutes.
minor: the small change to FbTk::Timer::setTimeout() reduces one
start() / stop() cycle for a running timer.
from time to time (...) time() might be off to gettimeofday() by a
second. the reason for this is that time() is usually implemented
by just returning the field 'second' of the struct that represents
the clock inside the kernel. gettimeofday() on the other hand also
takes the 'fraction' field (mostly 'nanoseconds') into account and
thus is closer to the current time than time().
the result of using time() was a perceived 'lag', sometimes the
clocktool even skipped a second. by using FbTk::FbTime()::system()
instead fixes the issue.
