flatborder hack

[Ben Jansens]

On Sat, Sep 07, 2002 at 03:43:52AM -0500, Youngjin Hahn wrote:
> Better, but if you're going to implement it, implement it RIGHT, don't 
> you think?
> 
> If that means rewriting significant sections of the code, that's the way 
> to go.  Otherwise, just take the whole feature out.  Because, it is, 
> after all, a FEATURE.
> 
> 
> What I mean by correct implementation is:
> 
> - Any border drawn should be drawn outside the element, allowing for any 
> bevel, gradient combination.  Its width should be variable, and still 
> preserve the bevelwidth.

I'm not sure this would be good. Beveled borders are drawn inside the
element, so why not the flat border? Also, to put them outside, makes
all the window decorations and menus suddenly get much larger very
easily. Openbox is great because its decorations are minimal. Putting
the border inside the element is not inconsistant, its the same way
the bevel border works.

> - If "border" must be specified for labels and buttons, but is "default" 
> for titlebars, handles, menu titles, etc. we have a serious styling 
> inconsistency.  How much do you want to maintain compatibility with 
> blackbox?  Total consistency, to me, means that you must specify 
> "border" on titlebars to have borders on titlebars, and "border" on 
> handles to have borders on handles, and so on.  This would, of course, 
> break compatibility with blackbox styles.  Is this something to think 
> about?  Yes.

"border" can be specified for any texture. It is not specific to
buttons or labels or anything. It is a property of all textures.

> - What about borderColor and borderWidth?  How shall we handle these? 
> If they can be specified specifically for buttons and labels, why not 
> other elements?  As with the previous example, either draw every single 
> border specifically (menus, toolbars, titlbars), or have one universal 
> borderColor and borderWidth.  Anything else would, again, be inconsistent.

borderColor can be specified on every element. Just like "border" it
is now a property of a texture. It is not specific to buttons or
anything like that.

The width.. Take a look at how bevelWidth works. It ends up increasing
the space around elements, but it does not increase the size of the
drawn border. Now I could add a borderWidth that did the same thing,
except that bevelWidth already does that, so we can't have two options
that do the same thing.

So, basically what I'm trying to say, is that I think the flat border
_is_ consistant with what exists. It behaves the way the beveled
border "always" has, except that it is flat, and its color can be
specified uniquely.

> I very much like Openbox's development, because it PROGRESSES.  Having 
> watched nyz develop blackbox for 3 or 4 years, I have become accustomed 
> to his method of carefully deliberating over any changes or added 
> features.  Thinking and planning a feature does not mean never writing 
> it (*cough* shaleh).  It means that the feature will not degrade the 
> integrity of the existing design, and improve it, as any feature should.
> 
> Next time a feature like this comes around, I would recommend spending a 
> considerable amount of time discussing and thinking about how it should 
> be implemented.  Look before you jump, and even then, make sure you can 
> land.

Ben
-- 
I am damn unsatisfied to be killed in this way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20020907/b4fa8954/attachment.pgp>