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

On Thu, 29 May 1997, Peter Mattis wrote:

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

Guts work in mysterious ways. ;-)  

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

I can honestly say I've never used Motif.  But Tk shows all the same
or like characteristics.

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

Look is important.  A border_width > 2 on a relief of raised or
sunken can act like internal padding.  You need it there because 
you don't want to require a border_width of > 0 on some widgets
like labels.  

But when would border_width be important to have at more than 2?
Well, ridged and groove should both flexible in this area.  Ridged
and groove are mostly label things.  But now I want my calendar 
to have a ridge on the button currently selected. (only an example)

I _could_ create calendar_button with all the stuff to be able
to do what I want.  That is a fine solution, but a *lot* of work
for an application programmer.  But perhaps the most important 
thing is that if different widget styles are introduced into GTK,
then applications that went their own way deriving widgets like
mad for composite widgets will potentially look "goofy" because
they did their own thing.

I much prefer the approach of defining calendar_day instead,
which just mucks with how the buttons in the array look by
using standard functions, and add signals to control how they

How easy could toggle button be?  Here is a Perl/Tk example:

use Tk;
$relief = 'raised';
$window = new MainWindow;
$button = $window->Button(
                          -text    => "push me",
                          -relief  => $relief,
                          -command => \&toggle


sub toggle {
    if ($relief eq 'sunken') {
        $relief = 'raised';
    } else {
        $relief = 'sunken';
    $button->configure(-relief => $relief);

Do a s/raised/ridged/g on this using sed and now you've got
a new widget which is more like what I used when I prototyped
my calendar widget in Perl/Tk.

Not only is this important for buttons, but for other widgets
as well like text widgets.  Say I am writing a small little
editor which will only use the most basic of text widget features.
Should I need to derive a widget to get it to be flat?  It 
has to be flat, of course, because the sunken look doesn't look
too cool right under the raised menu bar.  

We ran into using a lot of this type of thing when we
prototyped Aorta in Perl/Tk.  We were *extremely* thankful
for this flexibility.  ;-)

Shawn T. Amundson		University of Minnesota
Systems Administration	 	Computer Science System Staff     	

You can't talk to a PSYCHO like a normal human being!!!!  -Poe

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