netterfield at astro.utoronto.ca
Sun Dec 18 21:43:51 CET 2005
OK... this is my and Rick's fault... (Rick had a bug, and I wavered on whether
I liked it, decided I did, and propagated it to legends.)
In any case, lets go ahead and move legends and labels to George's intended
behavior, which is for transparency to only refer to the background and not
When this is done, I will modify the UI to reflect this.
On December 17, 2005 05:47 pm, Andrew Walker wrote:
> Do you also want transparent legends to have a border?
> On December 17, 2005 5:35 pm, George Staikos wrote:
> > Quoting Andrew Walker <arwalker at sumusltd.com>:
> > > 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
> > The definition of transparent has to be clear. When I put it in
> > there, it was defined to mean the background is transparent, and nothing
> > else.
> > > 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.
> > Object hierarchy is a -huge- issue for scripting. We can't change the
> > object hierarchy of these later - the casting will fail. I also don't
> > understand why border and background have to be linked. This is
> > fundamentally wrong. They're separate properties and should be treated
> > as such. There's nothing wrong with forcing the border width to be 0 in
> > the GUI when transparency is set on, but ugly hacks in the object
> > hierarchy are just not what I want to see in here at this stage.
> Kst mailing list
> Kst at kde.org
More information about the Kst