> Don't take my words like I were insisting that things have to go my way. I

think that only discussing pros/cons with many people things can go better.
Ok, I can subclass, full stop. But this is a solution that I would use for
special needs. Put the vertical line. If the person who complained about it
only subclassed the component, no other would have benefit from the
improvement.

> What I want to discuss here is about general IBO improvements.
> You have outlined some points I was not thinking about, like documentation

already printed, for instance.

> But when a component provider like Woll2Woll realize a new version of a

component, I don't think that he defaults it's behaviour to the old one:
people pay for the new, improved look and performances.

> If 100 people use the calendar, and 80 think that it's hard to read, is it

better put default to the most user friendly look, or to the "old style"?
Maybe the remaining 20 people should set the property the way they like, not
the 80 (they can subclass ;)).

> What I mean is: what is the deciding factor between compatibility and

innovation?

> I think that "core" components should be, by default, compatible, while

visual one should be, by default, innovative. What's your feeling about
that? I like improving components, and I think that with the help of you and
IBO users we can make it better and better :)

I believe in innovation as you suggest but not from one sub-release to the
next. If you want to keep a list of changes that would be appropriate for a
minor version increment, like from 4.2 to 4.5 that is a time I would
consider making more visible changes to visual components.

If I can make 100% of the users at the least 90% satisfied as opposed to
only 80% of the users at least 95% satisfied I am going to chose the first.
I cannot make everyone 100% satisfied but I can find something everyone
would find reasonably acceptable.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com