| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Reordered the "Options" section and made it more clear that for setting solid,
gradient, or pattern textures, one should also refer to fbsetroot(1).
|
|
|
|
|
|
|
|
These were leftovers from a marginally-botched rebase of my docs branch before
pushing to the main tree.
|
|
This hides the odd cornercase of users with no lastwallpaper file and no
background set in their style or overlay.
Adapted from the patch at
http://sourceforge.net/tracker/?func=detail&aid=2389567&group_id=35398&atid=413962
|
|
When a user sets 'background: none' it really means "Do not let themes touch the
background I have already set with fbsetbg" -> It does still actually call
fbsetbeg to re-assert the proper background.
This new value 'unset' is for users who will use an alternate method to set
their background (root-tail, xscreensaver, or whatever). It instructs fluxbox
to *never* run fbsetbg.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This separates the menu-syntax portions of fluxbox.txt out into its own man
page, and includes a rather large rewrite of much of fluxbox.txt, as well as
small improvements in other pages.
|
|
This makes things a bit simpler and more generic.
|
|
|
|
Added :man source:, :man revision:, and :man manual: attributes to all remaining
asciidoc manpages, and regenerated them with asciidoc-8.2.7
|
|
This is now in its own man page, fluxbox-apps(5).
|
|
This now shares the CLIENT PATTERNS section in common with fluxbox-keys(5), so I
split this out into a client-patterns.txt which is included by both
fluxbox-apps.txt and fluxbox-keys.txt.
|
|
|
|
|
|
|
|
This is needed until we support full ARGB colors everywhere. Until then, since
the outer-most "frame" window in FbWinFrame is the only 32-bit window we create,
and the only part seen is the border, we only need to worry about forcing this
one color to be opaque.
|
|
Of course I need to use the real screen number when getting the Default
values, or it will fail on screen != 0.
|
|
Apparently InputOnly windows must actually 'CopyFromParent' and cannot use the
"Default" settings of the root window.
|
|
We accomplish this by creating the outer-most parent window of FbWinFrame with a
32-bit visual.
Everything else fluxbox does (decor, menus, colors, fonts, etc) is still at most
24-bit (no alpha chanel), for now, by falling back to the screen's default
visual and not inheriting directly from the parent FbWinFrame window.
|
|
Changing workspaces also reveals other windows, which causes unexpected focus
changes.
|
|
No functional change.
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
of self-written code.
No functional change.
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
No functional change.
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
Also sort file.
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
Signed-off-by: Slava Semushin <php-coder@altlinux.ru>
|
|
|
|
|
|
|
|
|
|
Moving and Resizing windows can reveal other windows, which of course can change
unexpected focus changes in focus-follows-mouse.
|
|
Lower is one of the actions which may reveal a window under the current mouse
pointer which would unexpectedly change focus under focus-folows-mouse.
|
|
This is the basic condition that was first noticed because of the effect of the
ClientMenu window unmapping and the resulting EnterNotify event stealing focus
from the window selected in that menu. But to be complete, any window unmapping
should cause focus to move to the next in the last-recently-focused window list,
not the one that happens to be beneath the mouse cursor.
|
|
This will be used to avoid some situations where an EnterNotify event should not
focus the window beneath the mouse cursor. For example, when a menu (or any
window for that matter) is unmapped, focus should not pass to whatever window is
beneath the current location of the mouse cursor, but to the previous window in
the focus list.
This was first noticed when using the ClientMenu feature with
focus-follows-mouse on -> The focus would always end up on the window beneath
the mouse pointer, not the window selected in the menu.
|
|
|
|
|
|
|
