... after selecting a color from a floating picker, similar
to what we do for the font name/size toolbar controls.

But moving the focus didn't work properly under gtk2, as it
was cycling the focus between the floater and the main
window with each click. The cause for this was the
GrabFocus call made by ValueSet/PushButton upon clicking,
which resulted in a XSetInputFocus in GtkSalFrame::ToTop.
But removing this XSetInputFocus would break keyboard
handling inside floating windows (as in tdf#104368),
given that GtkSalFrame::Init sets the input hint to false.
Setting the input hint to false is a hack needed for some
WMs to not steal the focus from the main window, when
showing floating toolbars. This mostly affects Compiz and
Metacity (and its forks Marco and Muffin, but fixed in
recent Mutter - see gnome#773210). Other WMs nowadays seems
to deduce the desired no-focus initial state, from the
toolbar window type hint.

According to wm-spec, one way to make a newly mapped window
not steal the focus is to set 0 to _NET_WM_USER_TIME (and
this method is indeed used by gtk). This helps for Compiz
(w/o messing with the input hint), but not for Metacity,
which will anyway unfocus the parent window.

The only solution that seems to work so far, is to start
with the input hint as false, and change it to true after
the window is mapped. And do this craziness only for
Metacity and its forks, just in case... (although I didn't
actually notice any problems with this in place, under
other WMs.)

(I also considered fixing tdf#114935 by making ValueSet/
PushButton not grab the focus on click, by setting
WB_NOPOINTERFOCUS on them. But that will be just a partial
solution, as e.g. if a user selects a different palette
from the palettes list, the focus will stuck in that list.)

Change-Id: Id8241bc809c445ff4e46f1a747b9af5ed57e5a1c
Reviewed-on: https://gerrit.libreoffice.org/47690Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>