| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Otherwise implicit focus changes by the workspace change would be
perceived as focus stealing and the focus restored to the last window on
the original desktop
|
|
The fixes a permanent (sync) button grab.
Well, oversaw global buttonpresses.
Let's wait for more to come ;-)
|
|
|
|
We have a nifty counter-based grab, so use it
|
|
REQUEST: 185
also PATCH 92
|
|
The user needs to enter his chain within 5 seconds
Otherwise the chain is reset.
REQUEST: 291
|
|
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
|
|
Should reduce exposure events, notably since the
windows are not in stack order.
|
|
Command is "RelabelButton button.foo $LABEL"
This is useful to eg. hint the amount of unread mails in a
button to start your MUA, reflect the $USER in a session menu button
etc.
|
|
Allows to maintain access to desktop fractions etc. against
maximized windows. Also permits to OnToolbar clicks in this case, eg. to
raise it.
REQUEST: 150
|
|
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
|
|
|
|
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.
|
|
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 58e09b719077605efadac9b712acb8f5e752f732 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.
|
|
Another patch to trim down the code that needs to be part of BScreen
|
|
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.
|
|
Again, it's easier to read the code when the whole menu-generation is out of
the way.
|
|
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.
|
|
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.
|
|
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."
|
|
|
|
Do not Ungrab the keyboard for a KeyPress event, this causes us to lose the
KeyRelease event which is needed to ungrab the keyboard after the event
happened.
|
|
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.
|
|
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.
|
|
|
|
placement based on apps file
* if you have e.g a 1920x1200 monitor and a small 800x600 monitor to the
right of the bigger one and a small window at the right side of the
big monitor (but still the whole window area at the big monitor) then
the original head detection would claim the window is on the small
monitor because (800/2+windowWidth/2 < 1920/2+windowWidth/2) is true
for small windows; but that is obviously wrong, the window is entirely
on the big monitor
* these incorrect head detections did lead to incorrect window
placements as they were required in the apps file
|
|
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.
|
|
Added the option to remove the SystemTray tool completely from
fluxbox.
|
|
The changes made in b178bed60b5bd8b2c9ed0cbc67fd729ff3820589 used the wrong
variable to set the default state of '--enable-randr' in configure.in, that is fixed now. I
also removed '--enable-randr12': If support for the Xrandr-extension is
available at compile time we set HAVE_RANDR; if there is also support for
Xrandr-1.2 (or higher), we also set HAVE_RANDR1_2 automatically.
Other changes:
* cleaned out public interface of 'class Fluxbox'
* added 'RANDR' to output of 'fluxbox -info'
|
|
* reduced duplicated auto-code
* renamed '--enable-newwmspec' to '--enable-ewmh'
* don't compile 'Slit'-code when '--disable-slit'
* use AS_IF() in configure.in
* use AS_HELP_STRING() instead of obsolete AC_HELP_STRING in configure.in
* removed redundant calls to 'imlib2-config' to fill in $IMLIB2_CFLAGS
and $IMLIB2_LIBS, AC_PATH_GENERIC() does that out of the box already
|
|
|
|
|
|
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."
|
|
Found using cppcheck.
|
|
ps: it was already commented out, I'm just deleting it
|
|
it was testing for FbWindow.property() == Success, where it should've tested for == true.
|
|
|
|
I removed the const versions of reconfigSig() in the process since FbTk::Signal has no const
methods anyway.
|
|
Introduces a new member function, FbWindow::cardinalProperty()
This change also changes other code that previously used
FbWindow::property() to do the same thing as the new function; this
reduces code duplication.
There are still some bits of code (Ewmh.cc, extractNetWmIcon()) that use
FbWindow::property() to retrieve XA_CARDINAL values, but as the new
method is designed for getting a _single_ property, and that code uses
FbWindow::property() to retrieve the number of values present, and then
grab all of them; it's a different use case. I opted to not try to make
cardinalProperty() into some monolithic all-purpose cardinal method;
FbWindow::property() works just fine for that.
This change also adds an optional (default=NULL) boolean to
FbWindow::textProperty and friends that allows the caller to determine
whether or not a value was actually retrieved. This was necessary for
integrating FbWindow::cardinalProperty with the codebase, and it seemed
to fit with FbWindow::textProperty as well. Prior to this change, if
you got a return value of "", you wouldn't know if you successfully
retrieved the value which happened to be blank, or if you failed to
retrieve the value. Now, you can pass the address of a boolean if you
so choose in order to differentiate these situations; the same applies
to the new FbWindow::cardinalProperty().
|
|
old code crashed on sparc64, pid_t seems to be 32bit on that platform.
|
|
Sun CC++ 5.11 complaint on linking about missing symbols 'nextWorkspace()',
'prevWorkspace()' etc.
|
