Subject: FVWM: frame_x and frame_y in FvwmPerl

From: Ben Winslow <[email-masked]>
Date: Tue, 20 Jan 2004 09:56:57 -0500

I was wondering why frame_x and frame_y are handled in FvwmPerl as
unsigned numbers.  Since the positions are given relative to the current
viewport, -1024 (e.g.) is a perfectly normal X coordinate; therefore, it
doesn't make much sense to use an unsigned number (as it'll usually need
to be converted back to a signed number to be useful.)  The C modules
treat frame_x/frame_y as ints, which are implicitly signed, so the
behavior doesn't match in that case either.

Additionally, I wanted to point out that the example in the
documentation for FVWM::Module::Gtk2 doesn't work (Gtk2 needs to be
initialized before FVWM::Module::Gtk2 if Debug is set--otherwise, the
module will explode when it tries to create the debug window.)

Thanks,
-- 
Ben Winslow <[email-masked]>

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 20 Jan 2004 16:03:36 +0000

> I was wondering why frame_x and frame_y are handled in FvwmPerl as

Please don't refer to the FVWM Perl library as FvwmPerl. You may refer
to it as "fvwm perllib". FvwmPerl is just one concrete module for
preprocessing and scripting purposes that happens to use this library.

> behavior doesn't match in that case either.

You are right, I will mark these fields to be signed in FVWM::EventNames.

> module will explode when it tries to create the debug window.)

You are right, I will fix this.

It seems the examples are also broken in that $dialog->window returns now
undef for me if called before $dialog->show_all. It worked just fine.
I am not sure what was changed in my setup since the last time it worked,
X, GTK or the fvwm's way of mapping windows. Anyway, I will fix the
command order too.

Regards,
Mikhael.
--
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: Ben Winslow <[email-masked]>
Date: Tue, 20 Jan 2004 11:14:15 -0500

> preprocessing and scripting purposes that happens to use this library.
Sorry, I wasn't thinking about that when I wrote the mail--FvwmPerl just
popped into my head (no doubt because of previous references to that
module.)

> You are right, I will mark these fields to be signed in FVWM::EventNames.
Excellent, thanks.