shaded icons behaved badly on restart, they went into a real stupid state:
somehow shaded, but at the same time iconic, so you werent able to unshade,
resize them properly.
i fixed that by applying NormalState on shutdowntime (see
FluxboxWindow::restore(), unshading a shaded frame to get good
window dimensions and on init() i mark the window initialized and connect it
to Fluxbox::attachSignals() a bit later.
MoveTo <int|*> <int|*> <Reference Corner>
- * means "use current value"
- Reference Corner is one of:
- UpperLeft, Upper, UpperRight
- Left, Right
- LowerLeft, Lower, Right
examples:
MoveTo 0 * Left -> snap to left workspace edge
MoveTo * 0 Lower -> snap to lower workspace edge
MoveTo 0 0 UpperRight -> snap to upper right workspace corner
TODO: perhaps add some "aliases" to make it more userfriendly
- Removed "antialias"-option completly, to enable/disable "antialias"
use either <fontname>:antialias=<bool> in the style or use
Xft.antialias: <bool> in your .Xdefaults
- Added new styleresources:
*.font.effect: <halo|shadow>
*.font.shadow.x : <int> - shadow x offset
*.font.shadow.y : <int> - shadow y offset
*.font.shadow.color : <color> - color of shadow
*.font.halo.color : <color> - color of halo
- Removed 'shadow' and 'halo' options from fontdefinitions:
!! Style authors have to update their styles !!
- Simplified XmbFontImp to not try all possible fonts to match locale
- Style authors may specify multiple fonts:
<font1>|<font2>|<font3>
if loading of font1 fails, fluxbox probes <font2>, etc. The last font is
"fixed". Hints for style authors:
- if xft tries to load a font it will _ALWAYS_ return a valid font,
it doesnt have to look like the one you want to have, read more
about it: http://fontconfig.org/fontconfig-user.html
- export XFT_DEBUG=1 before running fluxbox helps to see
which fonts are picked.
eg:
*.font: Verdana,Arial-12:antialias=true|-artwiz-snap-*-
if fluxbox is compiled with xft this will NEVER try to
load "-artwiz-snap-*-" since xft gives for sure a font,
most likely Verdana or Arial but noone knows. So, if
fluxbox has no xft support the first fontpattern fails
and fluxbox tries the next one, which might be successful.
if everything fails, it will use "fixed"
- Added caching of fonts, fonts are only loaded once.
- Fixed#1090902 (slow utf8 start)
fluxbox in utf8-locales:
if no fontset is found up to this point its because of
a) no such font
b) not supported locale
if we try our best and enhance the basename-list and add some
more generic patterns the xserver will give us a valid
fontset .. which is good coz we have something to work with
but which is BAD coz we return a valid fontset as if we
have found the font the user wants .. so, every fallback
in higher level code will fail coz we find a valid fontset by any
meaning here. if no fontset can be found, the "fixed"-fontset should
be there already.
state is set... what about moving it outside of the visible area? we need to
think about this.
* mixing _NET_WM_STATE_HIDDEN and _NET_WM_STATE_SKIP_TASKBAR is solved, we
dont do this anymore
* we dont use _NET_WM_STATE_SKIP_PAGER .. so we shouldnt delete it, thats
handled now correctly -> look at the *State() - functions
when sending _BLACKBOX_NOTIFY_WINDOW_DEL
_NET_WM_DESKTOP and _WIN_WORKSPACE had wrong initial values (-1), which lead to probems
with (eg) fbpager (unaware of newly created windows and such things)
- Shade - just like the "Stick"-button
Styleresources:
window.shade.pixmap, window.shade.unfocus.pixmap, window.shade.pressed.pixmap
window.unshade.pixmap, window.unshade.unfocus.pixmap, window.unshade.pressed.pixmap
etc.
- MenuIcon - click on it provides the windowmenu, if the app
contains a pixmap (gvim, konqueror etc etc) the pixmap is displayed, a
little menu otherwise.
Styleresources:
windowmenu.pixmap, windowmenu.unfocus.pixmap windowmenu.pressed.pixmap
etc.
Example ~/.fluxbox/init - entry:
session.titlebar.left: MenuIcon Stick
session.titlebar.right: Shade Minimize Maximize Close
hint: if the app HAS a pixmap i use window.title.focus.pixmap (look
WinButtonTheme for reference)in pixmap-based-styles. this looks excellent and dont need
much extra-code to pipe that info into WinButtons.
if the xkb-extension is enabled and the user switches between his/her
keyboardlayouts fluxbox's keybhandling doesn't work well anymore because
xkeyevent.state contains also xkb-related flags and thus we have to handle
that with caution.
KeyUtils now contain 'isolateModifierMask()' to really work only on the
modifiers. why not as part of cleanMods() ? because the XLookupString return
false results, eg TextBox's would only print chars from the first
keyboardlayout.
we now place shaded Windows above the normal windows. ArrangeWindows
touches only windows on the current (xinerama)-head.
there are still some open issues with this, look at my notes at the function
itself.
NoIcons - display all noniconified windows
WorkspaceNoIcons - display all noniconified windows on the current
workspace
modified the nls-files accordingly
"carrier" (maybe a temporarly name?) ... carriers dont need background-updates
.. ever.
this leads to a big performance"boost" over the last commits. before we
updated also the windows which are the hosts for the apps (m_window and
m_clientarea in FbWinFrame) -> bad idea.
if someone changed the session.screen0.workspaces:<int> value and fired a
"reload config"/reconfigure-Command fluxbox crashed.
changes:
- cleaner way of reading in the workspacenames
- cleaner way of initialize the workspaces in BScreen()
- on BScreen::reconfigure we add/delete Workspaces to the
current screen until init-file and fluxbox are in sync
-> the user changed the initfile and pressed reload, so
imho he wants to have the changes in the init-file realized.
fluxbox should handle the windows. default behavior is to handle
each available screen. closes#1159809. usage:
-screen <"all"|int[,int]>
eg:
$> fluxbox -screen 0,2 will run fluxbox on 0.0 and 0.2 so
one can run any other wm on 0.1.
$> fluxbox -screen all default, fluxbox manages all screens
called too often:
m_root_menu is locked for the current screen when loading the
style for the current screen, but not for the screens already
initialized and thus its executed when called thru Theme::reconfigure();
now only the themes on the same screen are affected by the load-routine.
notempty (eg :NextWorkspace or :PrevWorkspace want to have the 'argument'
really empty).
now the first thing we do is to remove whitespaces from begin and end of the
line.
SIGHUP: restartfluxbox
SIGUSR1: load configuration
SIGUSR2: reload configuration
TODO:
whats the essential difference between "loading" and "reloading"?
maybe we can drop one of that functions
an XWithdrawWindow unmaps a window and sends a synthetic UnmapEvent after
that. when the second UnmapEvent arrives we have to set either the WM_STATE to
WithdrawnState or delete it. i decided for deletion so its absolutly clear
its not any longer under our control
<Workspace> in apps-file. Reason is, that an unmanaged window is not yet
assigned to an workspace and thus the returned workspacenumber is -1 ... which
leads in combination with getWorkspace(nr) to an invalid workspace (0x0) ...
This also fixes the problem with several deiconify-modes of the iconbar, when
the iconbar is in icons-only mode (same reason)
The other changes in the files are just cosmetic, i throw out the comments
about the changes Simon did coz they make sense and are correct imho.
only when using "imlib_load_image_with_error_return" as the loading
function imlib2 seems to avoid trouble when an image with <filename>
doesnt exist. all other loadroutines lead to heavy problems when
fluxbox shuts down and tries to restart (memleak(?), distorted xressources
etc)
i ll analyze this further. another open issue with imlib2 is that it
doesnt work when xserver/fluxbox is running in dualscreen-mode (not
xinerama), no valid pixmaps are visible on the second head. dunno why
(yet).
besides xpm. to get imlib2 support in fluxbox one has to
./configure --enable-imblib2
default is disabled. a fluxbox-binary that supports imlib2 will have
IMLIB2 in "fluxbox -info"-output
explanation to the changed files:
* xft.m4 -> acinclude.m4 + added ac_path_generic.m4
(from http://ac-archive.sourceforge.net/Miscellaneous/ac_path_generic.html)
* configure.in, Makefile.am, src/FbTk/Makefile.am changed to handle
imlib2-support
* Font.cc/hh Image.cc/hh App.cc fluxbox.cc consistent way of init for global
stuff for fonts and imagehandlers.
* rest of changes just add the imlib2-code, pretty straightforward
* synchronize _NET_WM_STATE in Ewmh.cc
* added FluxboxWindow::setFullscreen(bool) to Window.cc
furthermore, if a window is in fullscreenmode any existing shape is
disabled (looks pretty annoying in mplayer for example)
file and directory - helproutines.
* created the FileUtil-namespace which contains file-related functions, moved
those functions out of Directory - code
* changes to the rest of the files to follow those changes
FbTk::Menu::update(Subject*) and FbTk::Menu::update(int index)
to avoid this, we rename FbTk::Menu::update(int index)
-> FbTk::Menu::updateMenu(int index)
this is mostly cosmetic, but if it makes the life of a compiler happy, well ..
be happy icc :)
causes a reconfigure .. which causes a loop over all toolbaritems and call
updateSizing() .. where we should check, if a new timeformat makes the clock
bigger or smaller...
closes#1026096
and all related bugreports elsewhere. "fixes" because i think the real problem
is in xft somewhere somehow, but i dont have any prove (yet).
thanx to Rob Stevens for informing us about that problem.
furthermore, and this is really interesting, this seems to fix also the bug
widely known as g.o.d - the grab of death. the g.o.d seems to freeze fluxbox
but let the mouse still be moving and no high-cpuload can be seen. the
(un)lucky can force the g.o.d by clicking like a weirdo and pressing keys like
crazy and then maybe it will happen. we are not quite sure WHY exactly this
happens but as it seems: XSync(true) caused the trouble.
we still keep watching this issue but hopefully noone experiences bad
"freezes" anymore. (/me crosses fingers)
