[openbox] New theme format proposal

[Ben Jansens]

Hello,

I'm going to reply to 2 emails in one here, kind of bad form but I'm allowed
to since it is 3am :)

On Sat, Sep 06, 2003 at 10:56:20PM -0700, Andy wrote:
> Tim Riley wrote:
> >On Sat, 2003-09-06 at 11:05, Andy Holmes wrote:
> >>!! Top Level Settings
> >>
> >>!! Should be changed, maybe paddingWidth or something more descriptive...
> >>bevelWidth:					3
> >
> >Agreed.

Here too.

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

frameWidth does only apply to windows. Its the width of the "inner frame
border". I don't know what to call it, hence the lack of a sane name change.
It should be at least in the window 'namespace' of the themes I feel.

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

As do I.

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

I disagree with this change. Currently the background is applied to the
entire menu, behind all the items, not on a per-item basis. Only the
selected item gets its own texture, and I agree with that.

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

I agree with having both selected and unselected. While one may be default,
they are both states in which the menu items exist, and specifying both is
more clear.

> >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 like bg.color also. The texture is also the bg though. This is alluded to
further on in the previous email, but I think the texture deserves the .bg
class also.

The .fg qualifier may do more damage than good for clarity. It is indeed
consistant, but I'm not sure which is more important.

...label.text.color could also work to replace current textColor.
...label.text.font might also be nicer.

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

menu.title.text.justify is nicer here also, perhaps that isn't such a bad
idea :)

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

"unfocus" is definitely more clear than "blur" and I'd perfer to use that in
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?
> >
> 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.

This sums up my opinion... mostly. The focus and unfocus bit I will get to
shortly.

> >>!! 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 what is the "window.frame"? From what I can tell, "frame" was used in
the blackbox theme format as a bit of a filler word when he didn't have
something better to call it. e.g. frameWidth. I think that a proper name
needs to be found for that inner border.

This property also doubles as the color of the window's background when
enlarging the window with drawContents turned off in the rc.xml, as well as
the color briefly seen when the client unmaps if the decorations don't
disappear before a screen refresh.

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

I actually want to take this in a very different direction. I think focus
state belongs much higher in the 'heirarchy'. Everything about the window's
decorations' appearance depends upon the focus state of the window. This
should be represented by having properties such as:

window.focus.title...
window.unfocus.title...
window.focus.label...
window.unfocus.label...
window.focus.button...
window.unfocus.button...

The only thing that slightly irks me here is the word "unfocus". I don't
really like "blur" either though.

As well, the menu properties use "menu.items.selected", but these do not
use "focused". Difference tenses. And shortening both of these would be
appreciated. :)

End of thoughts.

Cheers,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20030907/dcf6a662/attachment.pgp>