On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
>
> > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > file (from the URL) *except* either:
> > >
> > > Mouse 1 A MS Iconify
> > > or
> > > Mouse 1 A
> On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> >
> > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > file (from the URL) *except* either:
> > > >
> > > > Mouse 1 A MS Iconify
> > > > or
> > > > M
> > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > > in xev
>
> Forget about these; that's just how X works.
I dusted off old memories about the patches that I'm carrying in my
home fvwm binary and not my work one, and I think that this has come
up before and ha
On Mon, Feb 27, 2017 at 04:35:31AM +0200, Alexander Gromnitsky wrote:
> So I have
>
> Key F4 A M Close
>
> in .fvwm2rc for closing any window on Alt-F4. But I want the xterm app
> to be exempt from such a treatment.
>
> W/ fvwm-2.6.5, this configuration has been working flawlessly for me:
>
On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote:
> > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> > >
> > > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > > file (from the URL) *except* either:
> > > > >
> > > > > Mouse
On Wed, Mar 01, 2017 at 07:02:55PM +0100, Dominik Vogt wrote:
> On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote:
> > > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> > > >
> > > > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > > >
> The only other reason fvwm grabs a button is for focus handling in
> focus.c:__focus_grab_one_button(). The only possible reason I
> could think of is that the application does not accept focus so
> that grab never gets removed. Have you tried
>
> Style * Lenience
>
> as Dan suggested?
>
>
> > Unless I have a simple test application and a configuration
> > that exhibits that behaviour I cannot do much about it.
> > Would you be able to fvwm in Xnest and debug through
> > events.c:__handle_bpress_on_managed() to see what actually happens?
>
> By the way, have you tried to get the appl
On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote:
> (Let me know if you want more detail somewhere here and I can rerun
> my gdb tracing and/or add printfs appropriately.)
>
> Fortunately there is a simple reproduction program mentioned in the
> Debian bug, https://bugs.debian.org
On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote:
> On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote:
> > (Let me know if you want more detail somewhere here and I can rerun
> > my gdb tracing and/or add printfs appropriately.)
> >
> > Fortunately there is a simple rep
On Wed, Mar 01, 2017 at 08:45:36PM +0100, Dominik Vogt wrote:
> On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote:
> > On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote:
> > > (Let me know if you want more detail somewhere here and I can rerun
> > > my gdb tracing and/or a
> > If you click on the link, it's supposed to print something like:
> >
> > link
> > http://gtk.org
> > In a configuration with a Mouse 1 binding that includes the Window
> > context (so W or A), the link can't be activated by clicking mouse-1
> > and link.py prints nothing. You can howeve
On Wed, Mar 01, 2017 at 03:10:48PM -0500, Chris Siebenmann wrote:
> > > If you click on the link, it's supposed to print something like:
> > >
> > > link
> > > http://gtk.org
> > > In a configuration with a Mouse 1 binding that includes the Window
> > > context (so W or A), the link can't be
Here is a fvwm puzzle that I suspect is solvable but I don't know how
to solve. When a window is iconified or starts out iconified, I'd like
its icon location to go as follows:
1) if it's not being iconified for the first time, its icon goes wherever
it did last time (whether I moved it from t
On Wed, Mar 01, 2017 at 06:08:57PM +0100, Dominik Vogt wrote:
> A bug in a patch from 2013: By accident the variable that
> indicated a "--" action was evaluated before being set. I've
> pushed a fix to the branch "dv/devel". Can you please try that
> and see if it solves your problem? It does
15 matches
Mail list logo
