>>>>> Martin Cartwright writes:
M> => From: D.Kennedy_at_Queens-Belfast.AC.UK (David Kennedy)
M> =>
M> => I'd like a very different colour for highlighted icons while
M> => retaining the same highlighted/ordinary colour for pixmaped
M> => border windows. Might I suggest extending (and slightly
M> => complicating, but only slightly) the pixmap borders patch to
M> => include a config file line like "Icon highlight colour"
M> => or something. Most fvwm users will be fine with this, but
M> => for "pixmap border patch" users this would be useful.
M> => I reckon this would be very simple to implement.
M> =>
M> Why stop at icon highlight colour? If the Great Style Flag ReWrite goes
M> ahead I'd suggest you have the attributes HighlightColour,
M> IconHighlightColour, Colour, and IconColour, and
a switch FvwmLanguage= English/American English ;^)
I guess "Color" would be more consistent :-( - 'though I like Oxford english
M> make them appicable on
M> a per window basis. I mean one thing that stuck me as a bit daft, was having
M> a global highlight colour when you can make all your other windows different
M> colours. The same sort of thing applies to attributes like TitleStyle and
M> font and so on. The more of these things that can be applied per window
M> the better, in my (somewhat self-centred opinion). It's what puts the F
M> into FVWM... Fun. Flexibility. take your pick.
no, it's f!_at_#%$^ (the CDA doesn't apply to me, since I'm european :-)
small memory footprint, which is certainly a thing.
All those option are currently in a big (>2 Pages) structure, which is
allocated for every window. And those options want to be set, too.
How much of those options do you actially use ?
I have some 5 styles defined ("Undecorated", "Emacs", "Xterm", "Netscape"
and one or two derivatives)
Ok, we don't all use the same 5 styles, but I guess no one uses more than
20 of over a billion possibilities (just a wild guess, probably higher).
This cries for a sparse table or packed solution.
A lot of the config space could be saved, if we attach "style packets" to a
window: every window has just a linked list ptr, pointing to a chain of
"styling packets" which are traversed when the window is redrawn.
set_backcolor, set_forecolor, set_icon color, ...
there doesn't have to be just one list:
there could be one for each major "state" of the window i.e:
IconStyle -> { fg_color blue, ... }
IconFocusStyle -> { fg_color skyblue, ... }
WindowStyle -> { fg_color green, ... }
WindowFocusStyle -> { fg_color red, ... }
TransientStyle -> { no icons }
splitting is done while parsing:
IconStyle "*" ... IconFocusStyle "*" ...)
IconStyle "transient" nomapping, no decorations,
windolistskip, circulateskip, ....
or by using prefixes for actual style commands:
Style "transient" icon unmapped, window mapped,
icon WindowlistSkip,
windowfocus color black/red,
window color black/blue
by UseStyle "transient", the pointer is appended to the linked list.
Inheritance is still possible (the latter packet overwrites former
definitions - there's a bitmap which options are "active")
One can have as many styles, as one wants. Bloatage^H^H^H^H^H^H^H^Hmemory
usage is linear to these wants.
If I only define 5 styles, only five style packets are allocated in my
system, since the windows are pointer-linked to them.)
The size of the style struct is nearly unimportant then, since bloatage
comes from the number of styles defined (=number of style packets), which
is << the number of windows, since it's limited by the patience of the
user, when changing his .fvwm2rc.
Speed is no limitation either, since there is only little pointer
dereferencing involved (we're not talking about users defining 200+ styles
here).
/begin rant
We could add a Startupfunctions to the style, which could solve
things like StartsOn, ... by using Goto and would open infinite
possibilities. This can really be interpreted, since it's only
used once, before & after the window is mapped.
/end rant
any takers, I don't have the time now, since I'm doing my military service
from next tuesday on.
albrecht
PS: I'd love to use a C++ class for these styles
--
How many Windows support staff does it take to change a light bulb?
Well, we have an exact copy of your bulb here, and it works fine.
Did you check your CONFIG.SYS?
--
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 Sep 26 1996 - 09:07:55 BST