[openbox] New theme format proposal

Tim Riley tr at slackzone.org
Sun Sep 7 00:38:40 EDT 2003


On Sat, 2003-09-06 at 11:05, Andy Holmes wrote:
> Here is my proposal for a new theme format. I took a complete theme 
> using the format as of openbox3-beta1 and changed what I thought should. 
> It's fairly thouroughly commented and should be pretty easy to follow 
> given some prior experience with the format.
> 
> Since this is a proposal I don't *expect* everything or anything to be 
> accepted but I think that some of the changes I've made are logical and 
> make for a simpler themerc.

To dear Andy, and all interested openboxers,

Thanks for the time you have invested into drawing up this proposal. 
Since you haven't written much of the rationale behind your proposed
changes, I would like to ask a few questions, which I will place in the
relevant points of the theme file below.

> 
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> 
> !! Top Level Settings
> 
> !! Should be changed, maybe paddingWidth or something more descriptive...
> bevelWidth:					3

Agreed.

> !! Replace with menu.border.color, menu.border.width, 
> window.border.color and
> !! window.border.width
> !!
> !! borderColor:					#272727
> !! borderWidth:					1
> 
> menu.border.color:				#272727
> menu.border.width:				1
> 
> window.border.color:				#272727
> window.border.width:				1

If these are separated, do you think theme writers will ever bother to
give them different settings?

> !! Replaced with window.handle.width
> !!
> !! handleWidth:					0
> window.handle.width:				0
> 
> !! Should be changed...no solid ideas though :/
> frameWidth:					0
> 
> !! Replaced with menu.overlap
> !!
> !! menuOverlap:					0
> 
> menu.overlap:					0

My beef with what you have done with the global settings is as follows:

As they stand, most of the settings are indeed global, so they don't
need, by definition, to have a parent.  I agree that menuOverlap could
be changed to menu.overlap, and the same for handleWidth, but in the
case of frameWidth, bevelWidth, borderWidth, and borderColor, these
settings are indeed used globally and I don't think there's much point
in moving them around.

I think you want a lot more dots to appear in the theme file.  In some
cases, like I just mentioned, I agree that this is warranted, but I'd
like to head your reasons for the other cases.

> !! Menu Settings
> 
> !! Axe these two as they should get their fore and background color from
> !! menu.items.unselected.fg.color, menu.items.unselected.bg.color,
> !! menu.items.selected.fg.color and menu.items.selected.bg.color
> !!
> !! menu.bullet.imageColor:			#272727
> !! menu.bullet.selected.imageColor:		#8a8a8a

Despite what I said in #openbox, yes, I agree, we should use the
textColour for these.  "KISS." :)

> !! Replace this and add a background and texture property to make it more
> !! consistent with the rest of the resources
> !!
> !! menu.disabled.textColor:			#ffffff
> menu.items.disabled:				sunken solid bevel1
> menu.items.disabled.bg.color:			#000000
> menu.items.disabled.fg.color:			#ffffff

You are proposing that the disabled menu item have its own texture a la
the selected menu item?  Why do you think this is necessary?

> !! Replace these to reflect a more logical resource pattern, essentially the
> !! the same, just reorganized names
> !!
> !! menu.items:					raised solid bevel1
> !! menu.items.color:				#8d8d8d
> !! menu.items.colorTo:				#000000
> !! menu.items.font:				courier,monospace:bold:pixelsize=11:shadow=n
> !! menu.items.textColor:			#272727
> 
> menu.items.unselected:				raised solid bevel1
> menu.items.unselected.bg.color:			#8d8d8d
> menu.items.unselected.bg.colorTo:		#000000
> menu.items.unselected.fg.color:			#272727
> menu.items.unselected.font:			courier,monospace:bold:pixelsize=11:shadow=n

Aren't menu items, by nature, unselected?   Why do you think this added
qualifier is needed?

On another issue, the current format of having colour, colourTo (if
required), font, and textColour seems pretty simple & clear, in my
opinion.  The property names relate directly to whichever elements they
affect.

I have no problems with the term "bg," but I do think that the link
between "fg" and the text settings seems a little tenuous.  Also, you
add an extra hierarchical level ('fg') that will only ever contain one
element within it.  Firstly, why do you think that 'fg' clearer and
easier to understand than textColor?  Secondly, why do think it warrants
adding this extra level of depth to the property hierarchy?  To me this
just seems to be a case of adding superfluous "dots" just because we can
:)

Also, you propose that we have:

foo.bar: texture descriptiong here (eg. raised solid bevel1)
foo.bar.bg.color: #colour
foo.bar.bg.colorTo: #colour

Since the texture description relates only to the bg, shouldn't it be
like this?

foo.bar.bg: texture description here (eg. raised solid bevel1)

> !! Only the color properties change here
> !!
> !! menu.title:					raised gradient vertical bevel1
> !! menu.title.color:				#272727
> !! menu.title.colorTo:				#5a5a5a
> !! menu.title.textColor:			#8d8d8d
> !! menu.title.font:			 
> courier,monospace:bold:pixelsize=11:shadow=y:shadowtint=50
> !! menu.title.justify:				center
> 
> menu.title:					raised gradient vertical bevel1
> menu.title.bg.color:				#272727
> menu.title.bg.colorTo:				#5a5a5a
> menu.title.fg.color:				#8d8d8d
> menu.title.font:			 
> courier,monospace:bold:pixelsize=11:shadow=y:shadowtint=50
> menu.title.justify:				center

Since the justification refers only to the foreground, shouldn't it be
menu.title.fg.justify?


> !! Here, in addition the the colors, unfocus changes to blur
> !!
> !! window.button.disabled.unfocus:		parentrelative
> !! window.button.disabled.unfocus.color:	#000000
> !! window.button.disabled.unfocus.colorTo:	#000000
> !! window.button.disabled.unfocus.imageColor:	#ffffff
> 
> window.button.disabled.blur:			parentrelative
> window.button.disabled.blur.bg.color:		#000000
> window.button.disabled.blur.bg.colorTo:		#000000
> window.button.disabled.blur.fg.color:		#ffffff

I'd like to know why you think "blur" is a better/clearer/simpler term
than unfocus?  The terms "focused" and "unfocused" wrt windows are
common in window manager parlance, and no doubt would appear in user
documentation.  I see no reason why they should be hidden from the theme
format.

> !! Colors change and window.button.* becomes window.button.enabled.* to 
> match
> !! window.button.disabled.*. I've also considered normal or default...
> !! unfocus also changed to blur here.
> !!
> !! window.button.focus:				parentrelative
> !! window.button.focus.color:			#000000
> !! window.button.focus.colorTo:			#000000
> !! window.button.focus.imageColor:		#8d8d8d
> !!
> !! window.button.unfocus:			parentrelative
> !! window.button.unfocus.color:			#000000
> !! window.button.unfocus.colorTo:		#000000
> !! window.button.unfocus.imageColor:		#272727
> 
> window.button.enabled.focus:			parentrelative
> window.button.enabled.focus.bg.color:		#000000
> window.button.enabled.focus.bg.colorTo:		#000000
> window.button.enabled.focus.fg.color:		#8d8d8d

This is like your change of menu.items to menu.items.selected.  Aren't
buttons by default, by nature, enabled?   Disabled buttons are certainly
the rarer case.  To be consistent, shouldn't you be having
window.button.unpressed to match with window.button.pressed?

> !! Change focusColor to focus.color and unfocusColor to blur.color
> !!
> !! window.frame.focusColor:			#000000
> !! window.frame.unfocusColor:			#000000
> 
> window.frame.focus.color:			#000000
> window.frame.blur.color:			#000000

Agreed.  (apart from the "blur" thing) :-)

> !! Just unfocus->blur here. No color changes needed since there is no 
> foreground

or no text, rather.

Let me just summarise what I think, and even make a counter-proposal
(ooh! aah!  *GASP*).

In this message I've intentionally taken a conservative point of view,
because I think the changes that Ben has made to the theme format to
date have been really good, and we are now very much in a position of
the theme format being "not broke."  If it's not broke, don't fix it,
&c.  

I agree that some further small tweaks could improve it (like
bevelWidth->paddingWidth, and removing the menu bullet imageColours, for
exmple).

However, I really do question the point of the bg & fg changes, and the
unfocus->blur change (as examples) when what we have now already makes
structural sense and is quite clear.  That is why I have written this
email - to help ascertain the rationale you have for these changes.

One of the other changes I have questioned is the addition of the extra
"unselected" and "enabled" layers for the menu.items and window.buttons
respectively.  In these cases, these elements do have two states, but
one state is clearly the 'default,' or the more common case, and thus
the extra qualifier for this state is not necessary.

It is from this point of view that I make my (*GASP* &c.)
counter-proposal!

I like the theme format as it is.  For sure, I think some of Andy's
changes are good and should be considered, as I mentioned previously.  I
would also like to extend what I mentioned with regard to elements
having two states, with one of them being the default.  We can use this
to further eliminate some bloat from the theme format.

Instead of having .focus and .unfocus qualifiers for all the window
elements, we could eliminate one, as follows:

I would see the 'default' in this case to be the 'active' (focused)
window, so then we would have this:

window.title...
window.title.unfocus...

window.label
window.label.unfocus...

window.button
window.button.unfocus
window.button.hover
window.button.hover.unfocus
window.button.pressed
window.button.pressed.unfocus
window.button.disabled
window.button.disabled.unfocus

You get the idea.  This is consistent with the current settings for the
menu.items (ie. there is only menu.items and menu.items.selected) and
the window.buttons (ie. we don't have window.button.unpressed and
window.button.pressed).

I make this proposal just to offer an alternative and show Andy's
changes in a new light.  Hopefully now that this format is a subject of
open discourse, we can settle upon what rocks most, or rather, sucks
least :)

Thanks again Andy for your proposal, and thanks to Ben for his hard work
on the window manager.

With love,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/openbox/attachments/20030907/1a532338/attachment.pgp>


More information about the openbox mailing list