xfwm4 changes

[Olivier Fourdan]

Hi Thomas,

> I thought I'd try switching to xfwm4 for a bit. I'm planning to make a few
> changes for a ROX version, possibly using a configure argument
> (--with-rox-ui?) or a fork, if that's inconvenient for you.

I would really prefer a configure argument, using #ifdef/#endif to
protect that part of the code that are ROX specific.

> My first patch (attached) is not ROX-specific; it stops xfwm4 from
> deadlocking in a server grab on startup (the first Gtk application to use
> pango causes a font cache window to be created, but xfwm4 aleady holds an
> X server grab when it tries to do this).

That makes sense although I did not run into that deadlock yet.

> - Change the behaviour of button-3 on the window frame. Click-release will
>   pop up the menu as now, but click-drag will work like using button-1 but
>   without raising the window. Allows windows to be moved and resized
>   without raising them.

That should be fairly easy, possibly using the XfwmButtonClickType()
function defined in events.c

It returns an enum telling what kind of click occured (ie drag, click,
click and drag and double click) The double click time is the one
defined by xsettings, thus it's very standard.

> - Get rid of the raising behaviour in some other places (eg, raise on
>   click in the main area). Should this be an option?

Definitely yes. And I would add disabled by default, at least not when
using --with-rox-ui ;-)

> - Allow options to be changed at run-time. Is this currently possible?
>   Eg, changing the theme without restarting. I haven't looked into it yet,
>   but it should be possible to have a configure option to either compile
>   a ROX-Filer style in-process options box or an XSettings-client system
>   for changing the prefs.

Changing the options at run time is already possible. Right now, you can
force an update by sending a HUP signal to the xfwm4 process, or by
changing the font/gtk theme xsettings.

There are plans in this area regarding the way things will be
implemented in a near future. I don't think using xsettings would be a
good thing for apps specific settings, such as WM theme (gtk already
does that and IMHO it's not a very good idea since I think xsettings is
for settings shared accross apps, all apps and not just gtk apps)

I described the plan somewhere in a mail on the list but it seems I just
cannot find it anymore in the archives.

Anyway, the plan is to use something very similar to xsettings
technically, but with "channels". An application can register to a
channel and receive changes only for that given channel. An application
can register to more than one channel.

There will be no common channel as xsettings should be used for that
purpose. 

> Quite impressed with it already, though :-)

Thnaks ;-) It still needs work, but all major features are mostly there.

Cheers,
-- 
Olivier               <fourdan at xfce.org>            http://www.xfce.org
-----------------------------------------------------------------------
XFce is a lightweight  desktop  environment  for  various *NIX systems.
Designed for productivity,  it loads  and  executes  applications fast,
while conserving  system resources. XFce is all free software, released
under GNU General Public License.    Available from http://www.xfce.org