Re: [gtk-list] relief, borderwidth, and padding

Shawn T Amundson writes:
>It seems to me that padding, borderwidth, and relief should all
>be done at the widget level.  
>I have looked at how padding is done in the misc widget, and 
>fail to understand why it is not in the general widget code.  It
>is not complex or bloated; it is very clean.  So why not make it 
>available for everything?  I know you can emulate the same 
>affect with containers, but it is not nearly as clean.

A large concern in the GtkWidget design (and in the GtkObject design
as well) is size. Its not an overriding concern, and its easy to take
it to an extreme, but I want to be fairly careful not to add cruft to
the base widget class which won't be used much. 

My gut feeling is I don't think relief (shadow type) should be done at
the base widget level. But I'm having a hard time thinking up reasons
why. Perhaps that means it should be done at the base widget
level. There is even room in the widget class due to the way padding
works. I'll have to think about this some more. 

Styles used to have a border_width field. (Back in the beginning...)
It worked almost exactly liked it does in Motif. This was when gtk
looked almost exactly like Motif. If you look at Motif shadows you'll
see they are fairly simple. No problems.

At some point I decided the Motif look was too simplistic and I liked
the Windows 95 look better. If you look at the Win95 (or the gtk)
shadows you'll notice they aren't exactly simple. I haven't used Win95
much (never really), but all the shadows I see are 2 pixels wide. The
problem with allowing border_widths other than 2 is that I don't know
how they should be drawn. Just using Motif's simplistic method looks
really out of place. I guess if someone sent me a picture showing
different border widths in Win95 (if this can actually be done in
Win95) I could probably do it. But its not really high on my priority
list. In Motif, using border_widths other than 2 usually (always?)
looks bad. Maybe an example of when it wouldn't look bad and how this
is necessary would change my mind.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]