Subject: Re: FVWM: M_MINI_ICON packets

From: [email-masked] (Jose M. Pereira)
Date: 17 Apr 1997 23:34:44 +0100

> * As with the window-shade packets I pointed to earlier this week, the
> * standard  3 args are missing from the start of this packet.

I don't see why you insist to consider that a problem. There simply exist
*several* packet types. Yes, the world of interface library making would be a
much easier place if there was only one type, but... ;-)

I don't exactly know how to do it in Perl, but if you don't mind looking at
something written in Python, you can look at my fvwm.py, posted in this list
just a few years ago :-)

I believe there's another Python interface, by Barry Warsaw. (He complained
recently about a common problem: *nobody* seems to be interested in these
interfaces... :-( )

Sigh,
-- 
Jose' Pereira
	     INESC (Inst. Eng. Sistemas e Computadores)
             R. Alves Redol 9, 6. 1000 Lisboa, PORTUGAL.
             Phone.: +351 1 3100223 Fax...: +351 1 3145843
 e-mail: [email-masked] PGP PUBLIC KEY: finger -m pereira @sabrina.inesc.pt
		<< Hit any user to continue >>
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: "Randy J. Ray" <[email-masked]>
Date: Thu, 17 Apr 1997 16:44:05 -0600

> much easier place if there was only one type, but... ;-)

Why do I find this a problem. Hmmmm.

How about this: all of the packets which contain data specific to one managed
window have this triple. Of course M_DESK doesn't, or M_STRING. But if a packet
pertains to a specific window, all other packet types have the triple. Except
M_MINI_ICON (unless you chose not to apply my patch to the windowshade packets,
in which case you have three packets that don't). The module docs not only
frequently refer to this triple is the means of identifying fvwm-managed
windows, it specifically refers to the third element, the "internal index"
(actually the hex representation of the struct's memory address), as well-
suited for use as an index of sorts for programs that list and index windows.

Yes, there are several packet types (more accurately, each packet is its own
type, there are several classes into which packets fall). But M_MINI_ICON has
a relationship to a specific subset of the packet types, and as such should
conform to them.

> Sigh,

Indeed.

Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS         Phone: (303)595-2869
                Denver, CO                                     [email-masked]
"It's not denial. I'm just very selective about the reality I accept." --Calvin
===============================================================================
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: [email-masked] (Jose M. Pereira)
Date: 18 Apr 1997 02:11:47 +0100

"Randy J. Ray" <[email-masked]> writes:

> window have this triple. Of course M_DESK doesn't, or M_STRING. But if a
> packet pertains to a specific window, all other packet types have the
> triple. Except M_MINI_ICON (unless you chose not to apply my patch to the
> windowshade packets, in which case you have three packets that don't). The

Sorry, I didn't know M_MINI_ICON was window-specific (I have to add these new
packet types to fvwm.py one of these days). The "windowshade" ones must be
window-specific for sure!

> suited for use as an index of sorts for programs that list and index

my fvwm.py needs it (keeps track of windows, of course - I chose the wid for
it). I don't have fvwm sources handy, so I don't know what M_MINI_ICON is
supposed to do, but if it refers to a single window, the packet ought to carry
its id. If you say that the windowshade ones don't, that's strange... What are
the modules supposed to do with them then?

(I'll search for your patch)

PS:
I suppose this isn't exactly a popular theme in the list, since only the
module interface library programmers need to think of this. Let's see how many
for: the C library, yours in Perl, and the 2 (?) in Python... (I'm sure there's
a tcl library, but never heard of it)

Now, you module programmers: let's see those wonderful new modules you are
writing! As you see, there's plenty of language support for you ;-)

Cumprimentos,
		(clever, funny, wise, witty citation missing)

---

From: [email-masked]
Date: Fri, 18 Apr 1997 10:05:57 -0400

> "Randy J. Ray" <[email-masked]> (I think) writes:
> PS:
> a tcl library, but never heard of it)/

tkgoodstuff (of which I am author) has a tcl fvwm2 library.  I would love to
have mini-icon file names included in the M_MINI_ICON packet.

Mark
http://www-personal.umich.edu/~markcrim/tkgoodstuff

---

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 18 Apr 1997 16:54:07 -0600

> window-specific for sure!

Yes-- the purpose of M_MINI_ICON is to inform a module of a mapping between
mini's and windows. Each window can conceivably have one. Part of the debate
over the packet format is based on the fact that the current implementation
sends the X server pixmap ID, which is not useful to non-C modules (which means
you actually have a stake in this :-).

> (I'll search for your patch)

The windowshade packets (M_WINDOWSHADE/M_DEWINDOWSHADE) only contained the
X window ID for the main window. My patch merely has them contain the regular
three values.

Randy

---

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 18 Apr 1997 16:57:11 -0600

> have mini-icon file names included in the M_MINI_ICON packet.

What I am beginning to wonder is the status of 2.0.46, or whatever is to follow
upon 2.0.45. I'd be happy to work up a patch for the M_MINI_ICON packet that
standardizes the integer args, leaves in the X ID for C programmers, and still
adds on the name for the rest of us (I believe the mini-icon name is stored in
the window struct, so that will be easy enough).

What I am nervous about is that with the variety of patches floating around--
my windowshade packet patch, the ColorLimit patch, etc.-- isn't it about time
a new "official beta" was cobbled together?

Randy

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 21 Apr 1997 09:27:21 -0400

>>>>> "R" == Randy J Ray <[email-masked]> writes:

>> have mini-icon file names included in the M_MINI_ICON packet.

R> What I am beginning to wonder is the status of 2.0.46, or whatever
R> is to follow upon 2.0.45.

It will be 2.0.46, since a few more things still need to be cleaned up
before 2.1.0 can be put out there.

As for it's status, I've done a little on it, but not enough yet.

Why, you ask?  To elaborate slightly on FAQ question #34 for this
particular situation, I've been insanely busy with work, my martial
arts school, repairs & upgrades to my home computer, getting ill
(which has been happening all too often this past year), going out of
town to visit family, having all 4 wisdom teeth removed (which
actually went quite well), etc., and haven't quite had a chance to
finish up what I wanted to get in there (and been real quiet on the
lists, as I'm sure people have noticed).

But...things are looking up right now and I hope to have some time in
the next couple of weeks to finish some stuff and finially get it out,
as it has been a while (and I really want to sit down and do some work
on it), but as always I make no guarantees...

R> I'd be happy to work up a patch for the M_MINI_ICON packet that
R> standardizes the integer args, leaves in the X ID for C
R> programmers, and still adds on the name for the rest of us (I
R> believe the mini-icon name is stored in the window struct, so that
R> will be easy enough).

R> What I am nervous about is that with the variety of patches
R> floating around-- my windowshade packet patch, the ColorLimit
R> patch, etc.--

Well, as I often like to say and put int the FAQ a while back, not all
patches that get submitted get into the distribution, but I do agree
with your patches to standardize the last few module packets and have
no problems with adding the filename to the mini icon packet.  As for
the colorlimit patch, I'll have to look at that one again.  Right now
I don't recall what my feelings were about it when it was first
posted.

But I have all of the submitted patches lying around and will try to
look into most of them for 2.0.46.  Some of them have already been
integrated and/or added to my list to investigate.

R> isn't it about time a new "official beta" was cobbled together?

As soon as I get a chance.  Remember, they say that patience is a
virtue, and good things come to those who wait. :)

Now, I must get back to work...

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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, 21 Apr 1997 11:21:35 -0400

"Charles Hines" <[email-masked]> writes:
> As for

Well I don't want  to be  pushy, but bear  in mind,  the colorlimiting
patch directly addresses these 2 items from the fvwm2 TO-DO list.

  - Reduce number of colors used in xpms included
  - Reduced (limit Xpm choices) color set

If you do include it, please remember to remove those 2 lines from the
TO-DO list, my patch neglected to do that.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Peter S Galbraith <[email-masked]>
Date: Wed, 23 Apr 1997 09:01:18 -0400

> before 2.1.0 can be put out there.

Wouldn't a Linux-like tree be best?

Release stable code as 2.2.0, with patches for bug fixes to 2.2.X
Start development work on 2.3.0, with development patches to 2.3.X

Just a thought.
--
Peter Galbraith, research scientist             <[email-masked]>
Maurice-Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada  418-775-0852 - FAX 418-775-0546