On Fri, 22 Aug 1997, Graeme McCaffery wrote:
> 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 :)
> 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.
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 :)
> 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.
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+++_at_ 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 -----+
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Aug 26 1997 - 18:39:23 BST