Subject: FVWM: icons

From: [email-masked] (Graeme McCaffery)
Date: Fri, 22 Aug 1997 10:05:27 +0100 (BST)

this is just a thought I had last night (it may be really stupid!!!)

would it be possible to put all xpm icons in one file in a format that
fvwm would find easier and faster to access, as sort of cache. this could
be compressed so that the icons took up less room (or are these 2 points
a contradiction)

then the icons could be accessed by a small archiver program that would
add and subtract icons and ensure that they all shared the same colour map.

as it is right now, xpm's work for most of us, but having them in this format
makes it more difficult for casual users to change their setup.

one possbile advantage of this system would be to take naming inconsistancies
between icons and mini icons away correlating them. this may also help any
config program.

any comments???

Graeme

p.s. I found a bug (I think) in FvwmButtons

I'm running solaris 2.5 with fvwm 2.0.46 and X11R5

the line in my setup, in an fvwmbuttons file, that doesn't work is

Back            #30c8c8

if anyone else has this problem could you please tell me. I posted a patch
yesterday, however some people don't seem to be affected by the bug and I 
would like to know exactly how it occurs
--
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: Bruce Stephens <[email-masked]>
Date: Fri, 22 Aug 1997 11:13:04 +0100

[email-masked] said:
> would it be possible to put all xpm icons in one file in a format 
> that fvwm would find easier and faster to access, as sort of cache. 
> this could be compressed so that the icons took up less room (or are 
> these 2 points a contradiction) 

What format were you thinking of?  Given that fvwm uses the xpm library, xpm 
format is about as convenient as it can get!  Another point against this is 
that it's convenient to be able to use standard tools to fiddle with the 
pixmaps, and standard tools aren't going to understand a nonstandard format.

Having said that, I don't see a problem with your other suggestion, of 
allowing a program to provide pixmaps.  Users could provide an PixmapProgram 
or something, which would be executed with the PixmapPath and the desired 
pixmap name, and would either return an EOF immediately (indicating that no 
such pixmap is available) or print the desired pixmap to standard output.  
Maybe an error status would be better for indicating no pixmap.

That would allow you to store pixmaps however you wanted, so long as you could 
turn them into xpm format (presumably you'd want to be able to do this 
reasonably quickly, too, although that would mostly be a startup cost).  If 
you wanted, you could throw in a quantize to reduced colourmap or whatever.  
You could check the name of the pixmap, and if it didn't exist, but stripping 
off a leading "mini-" did, you could reduce the pixmap's size on the fly.  All 
kinds of things would be possible.  If starting up the process costs too much, 
the whole thing could be stuck in a module, I suppose (although I'd guess 
you'd have to extend the module interface a little).

-- 
Bruce Stephens	[email-masked]
Isode Ltd.	<URL:http://www.isode.com/>

---

From: Dan Espen <[email-masked]>
Date: Fri, 22 Aug 1997 08:40:16 -0400

> be compressed so that the icons took up less room (or are these 2 points

There  already is some form  of caching of pixmaps  in fvwm2.  See the
routine "libs/Picture.c:CachePicture()".

The XPM library allows the  XPM file to be  compressed.  When you tell
it  the  icon is "icon.xpm" it  also  searches for "icon.xpm.gz".  The
icon is held in memory in another format altogether.

> add and subtract icons and ensure that they all shared the same colour map.

There is a  patch that is  scheduled for  2.0.47  that will force  all
icons and other XPM decorations  to use the same set  of colors.  (The
colorlimiting patch.)  This should achieve what you want.

--
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: [email-masked] (Graeme McCaffery)
Date: Fri, 22 Aug 1997 15:08:21 +0100 (BST)

> icon is held in memory in another format altogether.

would it be possible to store all the xpms in this memory format so that
they are simply loaded straight into the program with as little processing
as possible?

Graeme

---

From: Drew Lebauer <[email-masked]>
Date: Fri, 22 Aug 1997 08:39:58 -0600

I just downloaded fvwm2.0.46 to my workstation, running HP-UX 10.20.
When I do MakeMakefiles (after xmkmf) I get the following error:

!defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE < 199309L)
                                                      ^--- expecting )

in the following files/lines:
"GetFont.c":572
"bindings.c":572
"xpmroot.c":572
"FvwmAudio.c":572
"FvwmAuto.c":572
"FvwmBacker.c":572
"FvwmBanner.c":572
"FvwmButtons.c":572
"FvwmCascade.c":572
"FvwmCpp.c":572
"FvwmIconBox.c":572
"FvwmIconMan.c":572
"FvwmIdent.c":572
"FvwmM4.c":572
"FvwmPager.c":572
"FvwmSave.c":572
"FvwmSaveDesk.c":572
"FvwmScroll.c":572
"FvwmTalk.c":572
"FvwmTile.c":572
"FvwmWinList.c":572

Can anyone tell me how to make this work? I had no such problem with
2.0.45 on the same box/operating system.

  ) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 (  | Drew Lebauer | Phone: (303) 802-1416 | Fax: (303) 802-1420
  ) |    Evolving Systems, Inc.   |   mailto:[email-masked]
c[] *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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: Fri, 22 Aug 1997 10:43:19 -0400

> they are simply loaded straight into the program with as little processing

No.  The formats I was  referring to involve  the  use of pointers  to
memory locations.

What is the problem  you  are trying to solve?    I don't  notice  any
performance problems with XPM access.  (Even on my 25mhz Sparc 1+ home
machine.)

---

From: "Patrick K." <[email-masked]>
Date: Fri, 22 Aug 1997 21:49:12 -0700 (PDT)

Hello,

Sometime in the late 1900s [email-masked] (Graeme McCaffery)
wrote:

GM> would it be possible to put all xpm icons in one file in a format that
GM> fvwm would find easier and faster to access, as sort of cache. this could
GM> be compressed so that the icons took up less room (or are these 2 points
GM> a contradiction)

   I personally do not like this idea for the reason that this will make
   the icons un-accessible to any other program such as xv or gimp (etc.).

   In general I do not like proprietary formats in any system.  Especially
   if the storage format is in binary!  Example the Windows95/NT Registry!
   Explaining why I like how most (if not all) Unix applications (especially
   wm's) have text init files.  Since even if they are in proprietary format
   they are still viewable through ANY text editor.

   I am not sure if I make sense or if others would agree with my logic but
   I tend to not like "closed" systems.

   I like to be able to look at my icons using xv and this format that has
   been suggested would make it difficult, if not impossible, for me, and
   any other user, to do this.

GM> then the icons could be accessed by a small archiver program that would
GM> add and subtract icons and ensure that they all shared the same colour map.

GM> as it is right now, xpm's work for most of us, but having them in this format
GM> makes it more difficult for casual users to change their setup.

   How does it make it difficult?  I don't follow.  Sorry.

GM> one possbile advantage of this system would be to take naming inconsistancies
GM> between icons and mini icons away correlating them.

   This may be true.  But don't think it is much of a gain compared to
   the sacrifice.

Patrick K ...
[email-masked] (development and consulting)

---

From: Kendrick Vargas <[email-masked]>
Date: Tue, 26 Aug 1997 19:39:07 -0400 (EDT)

> this is just a thought I had last night (it may be really stupid!!!)

Well, I had a similar idea about 1-2 months ago, so if you're stupid, then
I am too :)

> add and subtract icons and ensure that they all shared the same colour map.

Well, my idea was simply to be able to have a multiple xpm/image bank
format (.mxb/.mib? :) which was simply a file containing multiple xpm's.
The file format would simply be a small bank/archive/package of multiple
xpm's, each with a name or tag. I envisioned this as being used in the
following fashion... A user could specify something like this:

Style "xload"	Icon BeOS-xload.xpm
Style "trash"	Icon BeOS-trash.xpm
Style "xfm"	Icon BeOS-folder.xpm
Style "rxvt"	Icon BeOS-xterm.xpm

as the following:

Style "xload"	Icon xload:BeOS.mxb
Style "trash"	Icon trash:BeOS.mxb
Style "xfm"	Icon folder:BeOS.mxb
Style "rxvt"	Icon xterm:BeOS.mxb

Maybe even make fvwm (or whatever program) smart enough to realize that an
image request with a : in it is an mxb!

In the above example, the user would primarily be saving on # of files,
which could mean several different things, as I'll explain after this
commercial break :)

> between icons and mini icons away correlating them. this may also help any

Well, it actually makes it easier, yet messy... If you moved to something
like what I mentioned before, it would make things much easier to
organize. For example, all xterm type icons could be in xterm.mxb, and it
would contain tabs for sun, sgi, NeXT, etc.. which would each return the
respective icons. This would also help start the move to creating
"themes" ... for example, someone could distribute an fvwm2rc with a .mxb
file. Someone else can redistribute another mxb which has the same tags as
the original, however holding different looking icons. This would
be an easy way to change looks without having to manually specify
different files. 

This has an organizational advantage and might/would be very usefull to
some programmers especially since many icons are in 1 file instead or 5-25
different ones.

I originally came up with this idea for use with the Xclass C++ X11
toolkit and the fOX project, however noone has really offered to try doing
it. 

I think it should be a feasible and relatively simple hack to the xpm
library. In forward messages (after this one), someone mentioned that xpm
looks for image.xpm and image.xpm.gz if they try to load image.xpm. I'm
assuming then that a full path is fed to xpm listing directories to
search as well as an icon name to search for in that path. If this is
true, then the search algorithm can be modified to identify a second
argument (icon name) with a : in it as an mxb, and then act accordingly.
This should afford any program that is dynamicly linked to xpm to
automagically support the .mxb format (as soon as the library is
recompiled :)

However, I doubt that's how it works. 

I'm more likely to believe that the search for the file within the
IconPath is performed with fvwm2 itself, and then te full path to the
filename is sent to libXpm. But then again, I'm no programmer (yet :)
			-peace

--- BEGIN GEEK CODE BLOCK ------------+-----------
GAT d- s:+ !a C+(+++) UI/L/S/B++(+++) | "In the morning glad I see
P>+ L+(++) E---- W+++ N+ o? K? w++++  |  My foe outstrech'd beneath the tree."
O--- M-- V PS+++@ PE Y-- PGP+ t++ 5   |               -The Poison Tree
X++ R- tv+ b DI++ D+ G e>*  h*(!) r-  |                William Blake
y*(+) ------ END GEEK CODE BLOCK -----+