[Kst] extragear/graphics/kst/kst

[Andrew Walker]

The problem is that we have two concepts of transparent:

for a rectangle (aka box) transparent means draw a rectangle
for a label (text within a box) transparent means draw the text only

Different behaviour for the same property, so they properly shouldn't
have the same parent class. The correct fix would to be change
the object hierarchy, but I believe we want to get out this release
without making significant changes.

Clearly what I've done is a bug fix as behaviour that was broken
now works. I agree it is not an elegant bug fix, but I think the 
confidence we can have in the fix is worth the temporary hack.

Andrew

On December 17, 2005 5:15 pm, George Staikos wrote:
> Quoting Andrew Walker <arwalker at sumusltd.com>:
> > SVN commit 489316 by arwalker:
> >
> > CCBUG:118148 no longer display borders for transparent label - this is
> > consistent with legend behaviour
>
>    This is inconsistent with all the other bordered view objects though.
> Furthermore it's certainly the wrong place to put this kind of thing.  If
> the goal is really to have a feature like this, it should be inside
> KstBorderedViewObject since the transparent property belongs to even a base
> class of that.  Circumventing the base class can cause unexpected results
> when other changes are made in the future.
>
>    Anyway I don't see why we should force borders and anything else in that
> base class to be disabled if the transparent bit is set.  This is for the
> user to decide.  We could put a helper in the UI, but I don't like
> disabling it like this.  (And I don't really consider this to be a bugfix
> at this point.)