[openbox] New theme format proposal

[Andy]

Tim Riley wrote:
> 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?
> 

Point taken. I'd like to retract that change (proposal) having reconsidered.

> 
>>!! 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.
> 

Having not experimented thouroughly with the themes I thought frameWidth 
applied only to windows; if this is not the case then you are right and 
it should stat frameWidth. (already commented on borderWidth and 
borderColor)

> 
>>!! 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?
> 

Well, being a theme everything is superficial and not necessary, but I 
could see a situation where I might want disabled items to be sunken, or 
something else rather than just a different text color. Personal preference.

> 
>>!! 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?

It was my opinion that 'items' referred to all the items in the list and 
that they had two states: selected and unselected, and having them as 
menu.items and menu.selected didn't make much sense to me. I considered 
renaming to menu.selected and menu.unselected but that might cause 
further confusion.

> 
> 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.

The change from color/colorTo to bg.color/bg.colorTo was an attempt to 
clarify that color and colorTo were referring to the background color 
since this might be confusing to someone who hadn't read the docs yet 
(which is his/her error anyways, but the idea of this is to make the 
format as clear as possible, and if done well enough might remove the 
need for extensive docs and tutorials). textColor->fg.color just seemed 
a consistent change.

> 
> 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
> :)

I agree that it does appear that I'm adding .'s a bit extraneously, but 
what I'm really trying to do is clarify the properties which sometimes 
ends up making them seem a little verbose :/ I'd be glad to accept more 
concise property names as long as they were a little clearer and more 
logically organized than the current ones.

> 
> 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)

I would dare to argue that the texture doesn't actually affect either 
the background nor the foreground but only serves to give it dimension ;)

> 
> 
>>!! 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.

You've probably noticed a lot of the changes I make are parallel to web 
standards and this is what I'm familiar with. If 'unfocused' is more 
common in the WM scope of things I have no problem with it as my 
unfocused->blur change was not really important and on reflection might 
cause more confusion than it's worth.

> 
> 
>>!! 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?

The way I saw it there were 5 states of the buttons: enabled, disabled, 
pressed, hovered and toggled with focus and unfocus extending these. So 
it seemed illogical that disabled, pressed, hovered and toggled have 
their own heirarchies and 'enabled' (or normal or default or whatever) 
not have it's own. window.button.focus sounds to me like it affects all 
states of a button when the window is focused, rather than just enabled 
buttons.

> 
> 
>>!! 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 :)

That would certainly reduce the size of it, and I consider it a good 
idea, but like I mentioned before window.button sounds like it affects 
all window buttons regardless of any other state, almost as if it were a 
shorthand for window.button.*.textColor/fg.color

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

Thanks for your comments on my proposal, and many thanks to Ben for 
making window managin beyond bearable (:

-Andy