Subject: FVWM: Wishlist: NoIconPixmap

From: Richard Lister <[email-masked]>
Date: Wed, 12 Jun 1996 11:51:55 +0100

Chuck

Come the Great Style Flag Rewrite how about a NoIconPixmap style to
complement the existing NoIconTitle?

I currently use fake pixmap names to achieve icons with just the
little title window (e.g. Style "*" none.xpm). Obviously this is
inelegant, but the main problem is that it doesn't work for applications
that supply their own icon (e.g. netscape).

Actually, on the subject of elegance, it would be quite nice to have
a syntax like Jarl's buttons, i.e.:

Style "name"	Element (PropertyList), Element (PropertyList)

e.g.:

Style "Netscape"  Window (NoTitle, Sticky), Icon (Title, Sticky, NoPixmap)

What do you think?

In the meantime, while we wait for the GSFR how about including the
following horrible hack to icons.c which allows us to say 'Icon NoPixmap'
and override the application's icon?

Ric

--- icons.c     Wed Jun 12 11:19:53 1996
+++ icons.c.nopixmap    Wed Jun 12 11:22:37 1996
@@ -85,6 +85,14 @@
          (tmp_win->wmhints)&&(tmp_win->wmhints->flags & IconPixmapHint))
     GetIconBitmap(tmp_win);
 
+  /* Allow override of application icon using 'Icon NoPixmap' */
+  if ( (tmp_win->icon_bitmap_file != NULL) &&
+       !(strncasecmp(tmp_win->icon_bitmap_file, "NoPixmap", 8)) ) {
+    tmp_win->icon_p_height = 0;
+    tmp_win->icon_p_width = 0;
+  } 
+
+
   /* figure out the icon window size */
   if (!(tmp_win->flags & NOICON_TITLE)||(tmp_win->icon_p_height == 0))
     {

 ~~~~~~~~~~~~~~ Richard J. Lister    [email-masked] ~~~~~~~~~~~~~~~~
            Research Assistant, Neural Computing Research Group
                  Aston University, Birmingham B4 7ET, UK
 ~~~~~~~~~~~~~~~~~ http://www.ncrg.aston.ac.uk/~listerrj/ ~~~~~~~~~~~~~~~~~~
--
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: Albrecht Kadlec <[email-masked]>
Date: 13 Jun 1996 15:21:18 +0200

> Style "Netscape"  Window (NoTitle, Sticky), Icon (Title, Sticky, NoPixmap)

strongly seconded.
much clearer, better separation of elements.
Since the elements seem to represent some sort of window "states"
(when-to-use), I'd prefer "Iconified (NoIcon)" over Icon (NoIcon). 

How many such "states" do we have?

	Start:		Iconic/Normal/Maximized,
			Display #/CurrentDisplay, 
			Desk #/Currentdesk,
			Page # #/CurrentPage.

	Window:		NoTitle/Title, NoButton/Button #, BorderWidth #,
			NoHandles/Handles, HandleWidth #, 
			StaysOnTop/StaysOnBottom/StaysPut, 
			Color #/# /ForeColor #/BackColor #

	Iconified:	Title/NoTitle, NoIcon/Icon Str, Sticky/Slippery
	Windowlist:	WindowListSkip/WindowListHit

	IconBox:	#/# #/# (coordinates)

	maybe more for additional module-styles ? -> see below

#   ... number
Str ... String Parameter

ok, I threw in some things from the todolist (start maximized &
Display/Page Note: StartsAnyWhere is the equivalent of CurrentDisplay
& CurrentDesk & CurrentPage) and some things I (and others too, as we
already talked about most of them) would like to see. 

all of these extensions are for completeness (Start options) or
symmetry (StaysOnBottom, can be used to inset an Xload into the
X background without decoration, without ever gaining focus, without
ever being raised. - I used that before I used GoodStuff/FvwmButtons.)

btw: there was some SkipFocus flag mentioned somewhere, was that real,
it isn't mentioned in the docs.

sure does reduce tokens, that have to be recognized (both for the
parser and for the humans writing config files) and makes things
clearer.

comments ?

one more strange Idea regarding styles:
what about dynamically allocating style flags, when parsing the
.fvwm2rc file.

I envision :-) the following:

Wile parsing the .fvwm2rc, style bits are allocated in the order of
appearance, with the proper handling function being recorded in a
global static array of identifiers, and one variable per style flag,
telling the actual allocated position. (this is some data, but it's
not per window, but once for entire fvwm2) 
This variables are used for indirection, when a specific flag is to be
obtained.

e.g: after
	Style "*" Window (NoTitle), Icon (NoTitle, Sticky), \
		  Start (Page 2 3, Desk 1, Display 0)

the arrays would look like:
	BitArray[32] = { WindowTitle, IconTitle, IconSticky,
					0,0,0, ... }
	ParameterArray[10] = { 0, 1, 2/3 }
	
	WindowTitleBit	0
	IconTitlebit	1
	IconStickyBit	2

	StartPageParameter	0	
	StartDeskParameter	1
	StartDisplayParameter	2

the default window structure would look like:

	StyleBits: 0 0 1
	StyleParameters: 515(=2*256+3) 1 0

and If I want to know the setting of the IconTitle bit in the code, 
I use 
	(WindowTitleBit >=0 ? 
		(window_struct -> StyleBits) & (1 << WindowTitleBit) :
		DefaultWindowTitleBit	/* this is #define'ed somewhere */

(well this would certainly go into a little C++ class, or the
C-equivalent:  an extraction macro/function ;-)			)

Who needs this, anyway ?

	Well it'd extend the support for modules. Fvwm2 could
	handle abstract module-specific style bits for every
	window. And since nobody (at least nobody sane) would
	modify all styles of all modules, very little window
	structure-space would be needed. 
	And if someone tried to use all possible style options, 
	he'd simply get an "Out of style flags" error, since 
	that's	what he deserves.

	The module would have to register an array of 
	(Style_name #Parameters Command AllocatedPlace) where

	Style_name is the text needed for parsing, 
	Parameters is the number of parameters for that style (0 if binary)
	Command is a command to send to the module, when a window with
		that style is created, and
	AllocatedPlace is set to the bit number (number of 1st
		parameter) in the window structure that was allocated
		for that style by fvwm. (this is the equivalent of
		WindowTitleBit for that module style)

	well the registering could be a problem, but could be done via
	a ~/.fvwm-module-styles (ack), if we leave out AllocatedPlace
	from the structure and let the module query, if it should need
	this info. Maybe someone has a better idea for this ?

Pro:
	it doesn't bloat the window structure, as the total number of
	style flags can be limited to say 32 binary and 10 with a
	parameter (nobody uses all combinations of all flags).
	Maybe a little bit more, don't know exactly, how much is
	needed. 

	One could make the UseStyle a style with a parameter and do
	runtime lookups, if the current option isn't overridden
	locally - well maybe this is a space saving functionality, but
	certainly not an acceleration ;-(

	It'd allow any thinkable extension using styles from modules.

Con:
	no data bloatage, but tradoff
		speed penalty (function) - code bloatage (macros) 

	sure someone can add something here ;-)

chuck, what do you mean?
worth more thoughts?
"A Module doesn't need own styles!" ?  hmmmm.... ;^)

albrecht