| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Note to myself: less gitting at late hours.
|
|
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.
|
|
|
|
The lookup for the skip value needs to be based upon the lowercase version of
the current byte.
|
|
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.
|
|
Also: try to avoid unsigned/signed problems in drawing code.
|
|
|
|
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 earlier _GNU_SOURCE definitions possibly did not take effect
everywhere where it was intended.
|
|
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.
|
|
gettimeofday() is subject to be changed on daylight-saving or to ntp-related
(think leap-seconds). even worse, it is subject to be changed BACK in time. this
is hard to fix correctly (see commit 45726d3016e and bug #3560509). it is
irrelevant for timers to know the nano-seconds since the epoch anyways.
|
|
Found with cppcheck.
|
|
Found with cppcheck:
"Prefix ++/-- operators should be preferred for non-primitive
types. Pre-increment/decrement can be more efficient than
post-increment/decrement. Post-increment/decrement usually
involves keeping a copy of the previous value around and adds
a little extra code."
|
|
|
|
I removed the const versions of reconfigSig() in the process since FbTk::Signal has no const
methods anyway.
|
|
|
|
use the FbTk::Timer API correctly, bug(s) introduced by
1f0adef4daa2da5b08ed7f41e7a0ce1e3f71e46f
e68511794130388ab9668fdef0dcf48dbbf002fd
|
|
nxserver-3.x creates a XExposeEvent for the unmapped FbTk::Menu(), which is
not configured completely yet (hence unmapped). this causes a call to
FbTk::Menu::clearItem() which then uses a value of 0 for m_rows_per_column
to divide the current index which triggers a SIGFPE.
it is still unclear, why nxserver-3.x creates the XExposeEvent for the
unmapped (menu) window. doing nothing if the menu is unmapped 'fixes'
the problem for now.
many thanks to Lars Engels (bsd-geek.de) to assist me in debugging this
issue.
|
|
'typeinfo' was needed for RTTI in isItemSelectable() (see last commit)
'algorithm' is already included some lines above
|
|
|
|
MenuSeparator is never enabled since it returns always 'false' in its
implementation of isEnabled(). no need to use RTTI imho.
|
|
* removed useless struct _menu
* code deduplication via renderMenuPixmap()
* improved documentation:
- 'sublevel' actually means 'column'
- 'persub' means 'row_per_column'
|
|
on startup a lot of 'Fluxbox: X Error: BadDrawable (invalid Pixmap ...)' occured.
this was caused by using an empty 'Window' to create the shape.
|
|
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).
|
|
'openeing' such an empty submenu lead to an already hidden menu referenced by
the 'shown' pointer
|
|
|
|
|
|
|
|
|
|
menu.hilite.selected.pixmap and menu.selected.pixmap was not
deleted while switching between non-pixmap styles and pixmap styles.
|
|
separators to focus model menu
|
|
|
|
|
|
|
|
|
|
|
|
ObjectRegistry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
