Subject: re: FVWM: Re: 5.0 stability

From: Elliot Sowadsky <[email-masked]>
Date: Mon, 11 Mar 2002 13:09:18 -0800 (PST)

ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/fvwm-snap-20020301.tar.gz

> I tried it....and icons started in the top-left corner instead of the
> iconbox. I had to open them to get them to use the iconbox.

< I am not sure, but your icon box problem may be caused if you restarted
< from 2.4.3 to 2.5.0. This may be a one time restart problem, it was fixed.

Still bad.

> [FVWM][convert_charsets]: <<WARNING>> conversion from `' to `UTF8' fail (init)

No longer get this msg.

Get this instead...

[FVWM][FInitCharset]: WARN -- Illegal charset (nl_langinfo and CHARSET env): 

These 2 functions do a resize of non-maximized window.
This no longer resizes correctly. Either maximizes to wrong size, or tiny
size.

AddToFunc Max2Size
+	I Maximize
+	I ResizeMove $0p $1p $2p $3p
+	I Resize br w-10p w-27p  # account for borders and title

AddToFunc Tile
+	I Resize 0 0
+	I Maximize grow grow
+	I Max2Size $[w.width] $[w.height] $[w.x] $[w.y]

My mailtool now beeps on every opening of view window.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Mon, 11 Mar 2002 16:22:54 -0500

> < from 2.4.3 to 2.5.0. This may be a one time restart problem, it was fixed.

Hmm, I restart so seldomly.

I see it too.
I'm using fairly recent CVS.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 12 Mar 2002 08:41:45 +0100

> [FVWM][FInitCharset]: WARN -- Illegal charset (nl_langinfo and CHARSET env): 

This message is a warning and should not cause big problems.
2.5.x has support for the EWMH specification and this spec
forces fvwm to convert strings encoded in your locale charset
into UTF-8 encoding (and conversely). Some small visible problem
may appear if you use KDE >= 2 and GNOME2 applications
(e.g., the window name that fvwm displays may be different than
the name that the KDE2 panel displays).

The message says that fvwm found that your locale charset is "".
You may try to set and export the CHARSET env variable to a
good value (before staring fvwm). But this may leads to others
warning messages. Unfortunately, this good value is system
dependent: it depends on your C library iconv implementation.
The good value is ISO-8859-1 with a gnu system (or if you use
gnu libiconv), I think that it is ISO8859-1 with aix, osf,
solaris and irix and I think it is iso88591 or iso81 with hpux!
Any way I hope that in the future fvwm will be able to always find
the good charset by itself without this CHARSET env variable (at
least if libiconv is installed). But maybe, if you have time you
can help me: 
- what is your system?
- type "man iconv" and try to determine what is the good
iconv command line to convert from ISO8859-1 to UTF-8.

Finally, 2.5.0 is stable but some part of the EWMH support is
work in progress.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 12 Mar 2002 23:48:27 +0100

> I'm using fairly recent CVS.

If you can see this, could you take a look at the problem please?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Tue, 12 Mar 2002 21:41:18 -0500

Dominik Vogt <[email-masked]> writes:
> > > < from 2.4.3 to 2.5.0. This may be a one time restart problem, it was fix
> > > 
> > > Still bad.
> > 

Since you said please, how can I resist?

There are so many things going on during restart, its hard to
tell what the plan is.  I guess it doesn't want to AutoPlace
the icons, but rather put them where they just were.

On a restart,  it places the  icons using  the  logic at  line 1130 in
events.c.  Since I may be using CVS from a week or so ago, this is the
routine:

    case IconicState:
      if (isIconifiedByParent ||
	  ((tmp = get_transientfor_fvwmwindow(Tmp_win)) && IS_ICONIFIED(tmp)))
      {
	isIconifiedByParent = False;
	SET_ICONIFIED_BY_PARENT(Tmp_win, 1);
      }
      if (USE_ICON_POSITION_HINT(Tmp_win) && Tmp_win->wmhints &&
	  (Tmp_win->wmhints->flags & IconPositionHint))
      {
	Iconify(Tmp_win, Tmp_win->wmhints->icon_x,
		Tmp_win->wmhints->icon_y);
      }
      else
      {
	Iconify(Tmp_win, 0, 0);
      }

The last iconify is the one it goes to.
The reason it goes there is
(Tmp_win->wmhints->flags & IconPositionHint)
is zero.

I do have one icon that gets placed correctly, that has X resources
that set its icon position.

Back in 2.2.5, that logic would position the icon using wmhints
on just the condition "Tmp_win->wmhints".  Ie. the logic looked
like this:

	case IconicState:
	  if (Tmp_win->wmhints)
	    {
	      Iconify(Tmp_win,
		      Tmp_win->wmhints->icon_x, Tmp_win->wmhints->icon_y);
	    }
	  else
	    {
	      Iconify(Tmp_win, 0, 0);
	    }

So, I don't think it should be using the position hint flag,
and I'm not sure why it should be testing the USE_ICON_POSITION_HINT.

I didn't verify this, but I'm guessing this is the change:

2001-03-02  Dominik Vogt  <[email-masked]>

	* fvwm/events.c (HandleMapRequestKeepRaised):
	icon position hint was sometimes used although it was not set

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 23 Mar 2002 13:08:30 +0100

> 	icon position hint was sometimes used although it was not set

Um, I can't remember.  Did we resolve this or not?  If not, I'd
appreciate if someone made a patch.  I'm swamped with work and
will probably forget to do this.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 23 Mar 2002 08:14:23 -0500

> will probably forget to do this.

OK.  if you can't remember why you changed it, I'll bring it
back closer to where is was originally.

---

From: Dan Espen <[email-masked]>
Date: Sat, 23 Mar 2002 08:50:31 -0500

Dominik Vogt <[email-masked]> writes:
> > > > > > I tried it....and icons started in the top-left corner instead of t
> > > > > < I am not sure, but your icon box problem may be caused if you resta
> > > > > < from 2.4.3 to 2.5.0. This may be a one time restart problem, it was
> > > > > 
> > > > > Still bad.
> > > > 

Gee, Dominik, I went in, did a CVS update, made my changes and
started to test.  On my first test I just quit and reinvoked FVWM.
All my icons showed up as solid outlines.  They only paint when they
get focus.

Thinking something was wrong with my change, I deleted events.c,
did another update, and rebuilt.  The problem is still there.

Did you break something?

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 23 Mar 2002 18:49:20 +0100

> did another update, and rebuilt.  The problem is still there.

Probably the criteria when a title redraw is necessary are too
strict :-) 

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 23 Mar 2002 18:50:30 +0100

On Sat, Mar 23, 2002 at 08:14:23AM -0500, Dan Espen wrote:
> > he
> > rted
> >  fix

Just keep in mind that my patch had a reason :-)  Sometimes, the
icon position hint was honoured although it contained only random
data.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 03:08:47 +0100

> did another update, and rebuilt.  The problem is still there.

Fixed.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 23 Mar 2002 21:47:55 -0500

> > did another update, and rebuilt.  The problem is still there.

Nope, icons don't update on page changes, quit, restart, or just being
covered and exposed.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 11:23:05 +0100

> Nope, icons don't update on page changes, quit, restart, or just being

And now?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 24 Mar 2002 06:58:07 -0500

> > Nope, icons don't update on page changes, quit, restart, or just being

Nope.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 14:10:17 +0100

> > > Nope, icons don't update on page changes, quit, restart, or just being

I need instructions to reproduce this (for each of the cases).

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 14:52:46 +0100

> I need instructions to reproduce this (for each of the cases).

Hm. Fixed?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 24 Mar 2002 09:01:13 -0500

> I need instructions to reproduce this (for each of the cases).

No you don't, you just fixed it.

I use pixmap icons with no titles.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 15:29:15 +0100

> Dominik Vogt <[email-masked]> writes:
[snip]
> back closer to where is was originally.

Something else is broken too:

  AddToFunc Iconify3
  + i iconify
  + i iconify
  + i iconify

Using this function on any window results in an empty frame.  The
window is iconified, but the frame is mapped instead of the icon.
We had this on occasion in the past.  Some patch in the devel
branch broke it.  2.4.x worked fine.  There may be a relation to
the IxonBox problem.  Can you keep your eyes open for any hints
about this problem, please?

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 17:10:28 +0100

> 	icon position hint was sometimes used although it was not set

Finally, I am able to reproduce the problem.  It does not happen
for all applications (xterm has the problem, rxvt and xemacs do
not).  And the -dont-preserve-starte option to restart prevents it
too.  Nota that it is usually correct to call Iconify with x/y =
0 since the auto place code does not use these values normally.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Mar 2002 20:25:39 +0100

> > 	icon position hint was sometimes used although it was not set

Fixed.  SOme hack in ewmh_events.c was broken by a rewrite of the
icon geometry code.  I have cleaned up that ugly window/icon state
and icon placement code with all the global variables.  All the
information is contained in a single structure that is passed
between the recapture/icon/add_window code.  A side effect is that
the "start iconic" window flag is gone and can't be passed to the
modules anymore.  The starticonic *style* is still there, though. 

Anyway, it is possible that the rewrite broke something, so please
report any icon placement anomalies.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 24 Mar 2002 14:56:33 -0500

Dominik Vogt <[email-masked]> writes:
> not).

Everything works fine for me now.

I was trying to track it down but when I noticed the EMWH
code I just skipped over it.

I had the problem with XEmacs and rxvt too.
The only icon that didn't have the problem was xlogout which
I start iconic and give an icon geometry.

> And the -dont-preserve-starte option to restart prevents it
> too.

Never use it, but that makes sense.

> Note that it is usually correct to call Iconify with x/y =

I see that now.  Shouldn't this kind of thing be commented:

  Iconify(Fw,0,0);        /* 0,0 is arbitrary */

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Mar 2002 00:19:15 +0100

> I start iconic and give an icon geometry.

I'm not sure why only xterm had the problem.  It was hard to
understand all the stuff going on with the initial window state.
Hopefully, the cleaned up code will prove more robust in the
future.  After all, it wasn't as complicated as we always thought,
only hard to understand because all of the global variables.  The
information was passed doen a simple hierarchy:

  (Re)Capture code
    |
    v
  HandleMapRequestKeepRaised
    |
    V
  AddWindow (modified by session.c in MatchWinToSM)
    |
    v
  Placement code
    |
    v
  Icon placement code

Collecting the information in a struct and then passing it from
function to function was easy enough - with only a few side
entrances.

> Never use it, but that makes sense.

Actually, I wouldn't use it if a normal restart didn't preserve
the current viewport.

>   Iconify(Fw,0,0);        /* 0,0 is arbitrary */

Or better:  write explanation of the arguments to Iconify().  I'll
write a few comments on the new data type.  The Iconify()
arguments are gone anyway.

Bye

Dominik ^_^  ^_^