[patch] Forward scroll and unused button events to the window manager

[Brian J. Tarricone]

On 09/24/04 13:21, Nils Rennebarth wrote:
> Brian J. Tarricone wrote:
> >the problem with this is that, if a user is using another WM with xfce, the
> >scrolling stops working.  that's not acceptable to me.
> Sounds suprisingly similar to what Oliver said: Don't take away the 
> scrolling feature from xfwm4, people use it as a WM independently from 
> xfce. Both of you have a valid point though, so doubling the 
> functionality in both places seems inevitable.

unfortunately =p

> >i haven't been
> >following the xfwm4 patch, but if there's a hidden pref in there for
> >disabling the root windows scrolling, i'd rather see xfdesktop use that as 
> >a
> >basis for whether or not to foward the events.  or just disable/drop them.
> These are fwm4 settings, and successfully reading them does not 
> guarantee that fwm4 is running.

good point, though i suppose it doesn't matter that much.  we can use xfwm4's
config value, and continue to implement the scrolling in xfdesktop.  the
problem comes if xfwm4 isn't even installed: having the user create a
config file for a nonexistant app to affect the behavior of another app is
just weird.  i haven't decided if i care or not.

> The real problem appears to be that for mouse wheel events there is no 
> commonly accepted program to be responsible: Desktop/Pager or the Window 
> manager. For keypresses that is decided: the Desktop ignores them.

no... the real problem is that for just about any DE-wide behavior, there
is no commonly accepted responsible program or default behavior.
freedesktop.org hopes to remedy this; meanwhile i have three different
things to set to ensure that different terminals will pick up the backdrop
image when they're in 'transparent' mode.  that's just stupid.

> There is another problem here: What should happen on the first resp. 
> last window: just stop there, or cycle? People voice different opinions, 
> so it appears to be a user preference. Now interestingly xfdesktop and 
> xfwm4 implement different views: xfdesktop cycles, xfwm4 just stops.
> This will get even more interesting when the desktops are laid out in a 
> two dimensional grid (see the "Xfwm: support for 2d pagers" thread)

personally, i like the current xfdesktop behavior (which is what xfwm4
used to do as well).  i believe there's a wrap_something hidden pref for
xfwm4 that reenables this, but i haven't bothered to look it up since
xfdesktop handles it (though since i kill and restart xfdesktop a lot, it
_is_ noticeably annoying).

> If your concern for dropping the scrolling feature from xfdesktop is 
> only backward compatibility, I'd suggest introducing hidden options to 
> xfdesktop in the same way as for xfwm4, create a single option called
> 'scroll_events' which is true by default. If false, scroll events are 
> just forwarded to the window manager, who does what he is configured for.

*sigh* i hate hidden options, i really do.  in this case, it's a little
harder, because xfdesktop doesn't have a config file that's not managed by
MCS.  this makes changing the setting non-trivial: you have to kill the MCS
manager to have it reload the settings from disk.  doing this causes gtk to
revert to the default theme and font settings, which, if you have a lot
of windows open, can take up to several minutes.

> >on a side note, xfdesktop _should_ be forwarding any unused clicks to the 
> >WM, so i'd like to incorporate some version of your code.
> 
> 
> >also, would gdk_event_put() (or gdk_display_put_event()) work?  i'd much
> >rather use GDK rather than xlib if the same functionality is available.  if
> >it's not, that's fine.
> Reading the gdk source superficially, I suspect that 
> gdk_display_put_event will not work: It will end up in the same place 
> again, probably creating an endless loop, because nothing else changed 
> in between. What we want is to pretend that our virtual root window 
> isn't there for this particular event, which apparently is not possible 
> with gdk alone.

yeah, that's what i was thinking as well, but i wanted to hear your opinion.
it _seems_ like those functions just inject events into the glib/gdk event
loop, but what would happen if you set the window parameter of the event to
the root window?  probably the event just will get lost, since xfdesktop
doesn't watch the root window.  as you suggest, it's doubtful that it actually
acts as XSendEvent() does.

at this point, i'm very very close to just saying screw it all, and applying
your patch as-is.  i'm coming to the conclusion that your patch does the
Right Thing[tm], and if users want to mix and match WMs in xfce, they'll have
to deal with some reduced functionality.  that's the price you pay when you
break our integration, and trying to cater to these partial-xfce users in
every way doesn't seem to be worth the effort or in my best interests.

so i'll mull it over and probably make a decision later tonight (it's half
past noon here right now).

	-brian