RE: [Tile-dev] Heads up -- upcoming changes

[Jeff H. <je...@Ac...>]

Steve Landers wrote:
> Fourth

-1.  See below ...

> On 10/08/2005, at 10:35 PM, Damon Courtney wrote:
> >     Third.  Clam was the only one on UNIX that actually looked decent. 
> > I've never really cared for its darker color scheme, but I definitely 
> > appreciate the softer, more-rounded look of it all.  My multiplatform 
> > stuff definitely uses Clam as the default on UNIX systems until 
> > something better comes along.

> >> Mats Bengtsson <ma...@pr...> wrote:
> >> Why is "Clam" going away? To me this is definitely the best looking 
> >> theme on unix. Very clean and with soft contrasts.

Just going through the demos again, aside from the scrollbars,
I don't see much improvement over a mix of Default and
Revitalized.  The clipped corners seems ok for some things
(like the entry), but the button looks ill-defined.  Of the
three, here are my unix prefs (and maybe now is the time to
mix/match the "best" default):

Radio/Checkbuttons:  revit (clam is close)
normal buttons:      default
notebook:            revit
scrollbar:           clam (like the [|||] handle)
scale:               clam (like the [|||] handle)
progressbar:         default
labelframe:          default/revit
entry:               default (maybe clam)
menubutton:          revit (like arrow, don't like fat bd)
general colors:      NOT clam
tree:                default

> >> Joe English wrote:
> >>> will involve a few important user-visible changes. Mainly: all of 
> >>> the transitional compatibility options are going away sooner rather 
> >>> than later.

FWIW, this is a good, albeit short-term painful thing.  I had
a bug in our code because -vcmd for entries wasn't supported,
only the extended -validatecommand, although nothing complained.
This is *bad* when trying to "port" code.  On a side note, I do
question why we can't keep the shorter opt names.  I lk to abbr
thgs.

> >>> The "Step", "Clam", and possibly "Classic" themes 
> >>> are also going away, possibly to return as separate loadable 
> >>> extensions.

Will this save us lots of code?  I do prefer the idea that we
strengthen the "default" look.  Less can be more (as we've
seen in options, choice can paralyze).  However, I would want
to encourage focus on whatever can make the unix side pick up
either kde and/or gnome looks.

Jeff