Subject: Re: FVWM: Transient Flicker

From: Dominik Vogt <[email-masked]>
Date: Thu, 17 Oct 2002 13:02:39 +0200

(I have moved this thread to fvwm-workers)

On Wed, Oct 16, 2002 at 11:43:07AM -0700, Tim Freedom wrote:
> --- Dominik Vogt wrote:
> > On Tue, Oct 15, 2002 at 01:50:24PM -0700, Tim Freedom wrote:
> > > With both snap-20021010 and snap-20021015 I've noticed that transients
> > > (well netscape's "Open Page" -- CTRL-O specifically) seems to flicker
> > > badly (twice I think) upon bring-up.  There were no changes to the
> > > .fvwm2rc file, the only mention of anything related to transients is,
> > > 
> > >   Style "*" MouseFocus, GrabFocusTransient
> > >   Style "*" MWMFunctions, MWMDecor
> > >   Style "*" Color White/DimGray, WindowListSkip, NoHandles,
> > >             DecorateTransient, BorderWidth 3
> > > 
> > > Where there any changes in that realm or am I doing something wrong ?
> > 
> > Yes, there were changes.  I can't say much about that without
> > 
> >  * Knowing the exact netscape release.
> >  * A more precise description of "flickering".
> 
> I'm using Netscape-4.75 (I know its archaic) on a,
> 
>   uname -a: SunOS pez 5.7 Generic_106541-08 sun4u
> 
> In terms of this flickering (and it happens on all transient windows,
> ALT-F (netscape's find) does it as well); the window pops-up and gets
> raised and focused, then it seems as though it attempts to raise itself
> one more time which end-up looking as though its a flicker.  In essence,
> it redraws itself twice before becoming available.

There are two different problems here.  As you said, with certain
styles set, transients are raised twice when they are created.
The second time should have no visual effect at all, though.
Please post all your "Style" commands so I can see if something is
wrong in the new transient handling.  I am aware that under some
obscure (well, not obscure to me) situation, transients are
lowered and then immediately raised.  But that should only play a
role if you have at least one transient and a transient of that
transient.

The second problem is that new windows are always drawn unfocused
at first, even if they have the GrabFocus or GrabFocusTransient
style.  I have committed a patch to remove this effect (except for
sticky windows).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Freedom <[email-masked]>
Date: Thu, 17 Oct 2002 12:47:14 -0700 (PDT)

> role if you have at least one transient and a transient of that

OK, I did a grep of "style" and here it is,

MenuStyle	Black Moccasin Blue *-helvetica-bold-r-normal--18-* fvwm
Style		* Font		*-helvetica-bold-r-normal--18-*
Style		* IconFont	-adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*
Style "*"	IconBox 5 -80 -140 -5
Style "*"	MouseFocus, GrabFocusTransient
Style "*"	MWMFunctions, MWMDecor
Style "*"	ManualPlacement
Style "*"		Color White/DimGray, WindowListSkip, NoHandles, DecorateTransient,
BorderWidth 3
Style "Fvwm*"		Color Blue/Green, NoTitle, NoHandles, Sticky, WindowListSkip,
BorderWidth 0
Style "FvwmForm"	Title
Style "FvwmConsole"	Title
Style "FvwmPager"	StaysOnTop
Style "FvwmBanner"	StaysOnTop
Style "xbiff++"		Color Blue/Green,NoTitle,NoHandles,Sticky,WindowListSkip
Style "xbiff"		Color Blue/Green,NoTitle,NoHandles,Sticky,WindowListSkip
Style "FvwmButtons"	NoTitle,NoHandles, Sticky, WindowListSkip, BorderWidth 0
Style "FvwmWinList"	Color Black/Yellow
Style "*clock"		Color Blue/Green,NoTitle,NoHandles,Sticky,WindowListSkip
Style "xterm"		Color white/gray64, NoIcon, WindowListHit
Style "rxvt"		Color white/gray64, NoIcon, WindowListHit
Style "Datebook"	StartsOnDesk 0, Icon datebook.xpm, WindowListSkip
Style "emacs"		NoIcon, WindowListHit
Style "xman"		Icon xman.xpm
Style "xmh"		Icon mail1.xpm, StartsOnDesk 2
Style "rxvt"		Icon term.xpm
Style "xvgr"		Icon graphs.xpm
Style "matlab"		Icon math4.xpm
Style "xmag"		Icon mag_glass.xpm
Style "xgraph"		Icon graphs.xpm
Style "FvwmButtons"	Icon toolbox.xpm
Style "xmeter"		Title, NoHandles, WindowListSkip
Style "Debug*"		Icon question.xpm, WindowListSkip
Style "DDD*"		WindowListSkip
Style "*/*"		Icon word_processor.xpm, WindowListSkip
Style "*Untitled*"	MinOverlapPlacement
Style "*Exit*"		GrabFocus
Style "Netscape"	NoDecorHint
Style "Netscape"	NoFuncHint
Style "FvwmIconMan"  NoTitle, Sticky, WindowListSkip, BorderWidth 0
Style "FvwmIconMan"  HandleWidth 0

> style.  I have committed a patch to remove this effect (except for

OK, I'll get tomorrow's snapshot to see if there were any effects on
my current issue.

Another thing to note, why is it that transients are always above
other windows beyond their initial bring-up state.  In other words,
I have this "Open Page" Window which when comes up flickers :-) and
then gets focus and I can type into it no matter where my cursor
was -- which is cool.  But assume I want to paste-in something that
was on its parent window, if I move the mouse (and I use MouseFocus)
to purposely lose the focus on the transient, the transient resists
being lowered.  If I force a "lower yourself" command on it, the
parent gets lowered as well - is this intended behavior ?  Does anyone
else see it a bit too forceful and harsh ? I would have thought that
the 'GrabFocusTransient' just grabs the focus and raises itself
upon bring-up.  Ideally, the transient should be at least "forcible"
to be lowered if one opted to do it via a 'lower' command, no ?

Last suggestion :-)  it would really be cool to have an automatic
mechanism to get all the necessary data that you as developers need
to see to report a bug (or an oddity).  Something akin to emacs'
"report-emacs-bug" or emacs VM's "vm-submit-bug-report" which pretty
much dumps the configuration options, and various internal important
state values/settings.  A builtin command (or an external script via
perl or something) could be invoked via a menu entry which would result
in a window (similar to FvwmIdent's output) which one can cut-n-paste.
Map that "fvwm-report-bug" in the source (like Alt-Tab is done today)
to say Alt-F12 and its available to all fvwm users.

Thanks (please CC replies)

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 17 Oct 2002 20:52:34 +0000

> to be lowered if one opted to do it via a 'lower' command, no ?

If you search for "Transient" in the man page you may find some insights.
The default is:

  Style * RaiseTransient, LowerTransient, StackTransientParent

I use:

  Style * DontRaiseTransient, DontLowerTransient, DontStackTransientParent

> to say Alt-F12 and its available to all fvwm users.

We already have fvwm-bug (should be in your $PATH).

Copying from FvwmIdent would be nice, but it does not contain much more
information than xwininfo -all (that may be copied).

FvwmCommand(1) provide more like an information you speak about, but it is
inconvenient to use and I will remove this functionality sometimes anyway
as Dominik requested. I will think about something more convenient for
dumping style and other information about a window, but this will be of
limited use and really not something to be added to fvwm-bug by default.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Oct 2002 09:38:14 +0200

On Thu, Oct 17, 2002 at 08:52:34PM +0000, Mikhael Goikhman wrote:

[snip]
 
>   Style * DontRaiseTransient, DontLowerTransient, DontStackTransientParent

And with current snapshots (and probably the only valid syntax in
3.0):

  Style * !RaiseTransient, !LowerTransient, !StackTransientParent

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Oct 2002 11:28:09 +0200

[snip]

I can reproduce the problem now.  Raising a transient that is
already on top raises its parent first and then the transient.  I
will take care of this later.

Bye

Dominik ^_^  ^_^