Richard Lister <listerrj_at_helios.aston.ac.uk> writes:
> 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?
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
--
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 Thu Jun 13 1996 - 08:39:34 BST