I've experimented with the 0.70 styles. Style authors will be pleased, there's
more flexibility and now every last interface element can have it's own border
of custom thickness and color, or none, in which case the element's level
(raised, flat, sunken) takes over. This will make for some very interesting
possibilities. There's added flexibility in other places too. There are
however some rough spots. I think it's important to get them out of the way
before styles start appearing in mass, because some of them may require syntax
or rules changes.
These are the various issues I ran into while testing 0.70 styles. Most of
them have to do with the styles. Please tell me if any of them deserve to be
registered in the tracker.
Is the README.styles document up to date? I'm guessing it isn't, since it's
the same size as in 0.65.0. A simple text list with all the valid directives
and all the accepted values would make things a lot easier for style
developers. I'm offering to make a small and concise tutorial out of it.
* "Sunken" (for the menu?) doesn't work. It produces "raised" instead.
* ".font" seems to have become very flexible and can be added to more
elements. Can we add take it from "window.font" and move it to
"window.focus.font" and "window.unfocus.font" instead? This way font usage
would be consistent all over the style and would add more flexibility.
* I can't seem to be able to control the menu bullet anymore. Is this
intended? If so, is "menu.bullet" still valid? How about
"menu.bullet.position"?
* How do you produce a menu separator? I was under the impression that it can
be done. Can its appearance be controlled? I'm thinking at the very least
color and thickness, although it would be nice if they had the full range of
options (sunken/border/color/colorTo/borderWidth/borderColor).
* The resize of the window (with Alt+drag) should affect the corner the
pointer was the closest to.
* I'm thinking that the color of the pressed button should differ for the
focused and unfocused windows. So we should have:
window.button.{focus|unfocus}.pressed
window.button.{focus|unfocus}.pressed.color
* From what I gather, all the elements have their own borders, which become
active when the "border" keyword is added, and they can be controlled with
something.borderWidth and something.borderColor. This is very nice, but what's
the use for the simple borderColor and borderWidth directives? Since every
element controls its own border, those two actually mean "window.borderColor"
and "window.borderWidth" because that all that's left. So I suggest that a
change of name to this respect would make things more intuitive.
* Furthermore, when used as a wildcard at the bottom of the style file,
"*borderColor" (and "*borderWidth") affects the borders that weren't
explicitly specified. I would've expected it to affect all borders, and to be
overwritten by more specific something.borderColor directives placed after it.
This allows for a logical and intuitive inheritance relation to be
established. Perhaps I'm biased by the web style sheets.
* I haven't checked in depth how much liberty can be taken with wildcards. I
would expect wildcards to work everywhere and at the very least for the
directive suffixes (such as picColor, color, colorTo etc.) but it would be
even nicer if any portion (between the dots) of a directive could be
wildcarded. Of course, that may be too bothersome to program. But at least
some consitency is needed. Right now some suffixes support wildcarding and
some don't, for no apparent reason.
* The global "bevelWidth" (with or without a wildcard in front) fails to
affect the menu.
* The slit inherits all the attributes of the lower "toolbar." slate. Just
food for thought, perhaps it could deserve its own "slit." directives.
* The icons on the "right" buttons on the toolbar should be moved 1 pixel to
the right. They're too close to the left margin of the buttons.
* I see that "rootCommand" is still a full-fledged command. I remember there
was talk a while back about malicious styles using this as a security hole.
IIRC, a possible workaround was proposed back then: change "rootCommand" to
"rootOptions" and always prepend "bsetroot" to it. Another improvement was to
allow the user to define his own "rootCommand" in his ~/.blackbox/rc and to
produce the actual command by concatenating rootCommand with rootOptions. This
may force style authors to supply several alternative rootOptions (for
esetroot, xsetroot, bsetroot...) but then again they already had to do this
since they didn't know which one the user has on his system.
--
Ciprian Popovici
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
List archives: http://asgardsrealm.net/lurker/splash/index.html
Trouble? Contact [EMAIL PROTECTED]
