Summary: | Unable to create label or legend with transparent background and visible border | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | Andrew Walker <arwalker> |
Component: | general | Assignee: | George Staikos <staikos> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | kst |
Priority: | HI | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Andrew Walker
2005-12-20 23:12:12 UTC
On Tuesday 20 December 2005 17:12, Andrew Walker wrote:
> There is no way for the user to create either a label or legend with a
> transparent background and visible border. This is clearly somthing that
> the user might want to do, but is currently not permitted.
??? We just went through this whole ordeal about how we don't want this to
happen. Now we do?
Anyway it is possible via KstScript.
I don't think saying it is possible via KstScript is a solution for the interactive user. On Tuesday 20 December 2005 17:25, Andrew Walker wrote:
> ------- I don't think saying it is possible via KstScript is a solution for
> the interactive user. _______________________________________________
Ok we have to make a choice here. Either we want #118676 or we want this
one. They are contradictory. We can't have both...
#118676 pointed out the dangers of setting the border to 0 and transparent fill. At present if we set transparent fill for labels or legends we automatically get border = 0, which this bug report says is not desirable. I see no contradiction. On Tuesday 20 December 2005 17:53, Andrew Walker wrote: > ------- #118676 pointed out the dangers of setting the border to 0 and > transparent fill. > > At present if we set transparent fill for labels or legends we > automatically get border = 0, which this bug report says is not desirable. > > I see no contradiction. Oh, I see. I had it backwards. On Tuesday 20 December 2005 17:53, Andrew Walker wrote: > ------- #118676 pointed out the dangers of setting the border to 0 and > transparent fill. > > At present if we set transparent fill for labels or legends we > automatically get border = 0, which this bug report says is not desirable. > > I see no contradiction. Ok I found the proper contradiction. #118148 You implemented it so that transparent labels did not draw the border. I changed it so that it did this while still calling the proper base class. Which one, again, do you want? :) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Quoting Andrew Walker <arwalker@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. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ What I implemented was a quick hack to make painting and printing consistent. It was not the best solution (in terms of functionality), which is what I'm proposing now. Clearly the user should be able to set transparent fill with a visible border. On Tuesday 20 December 2005 18:20, Andrew Walker wrote:
> ------- What I implemented was a quick hack to make painting and printing
> consistent. It was not the best solution (in terms of functionality), which
> is what I'm proposing now. Clearly the user should be able to set
> transparent fill with a visible border.
Ok if everyone agrees on this, I will adjust. The fix is very easy.
In case you want my $0.02, yes, it should be possible to have transparent background with visible borders. SVN commit 490163 by staikos: allow borders on transparent objects again - also avoid QRegExp when we don't need it, for speed BUG: 118753 M +6 -9 kstviewlabel.cpp M +1 -1 kstviewlegend.cpp --- trunk/extragear/graphics/kst/kst/kstviewlabel.cpp #490162:490163 @@ -567,10 +567,8 @@ } else { // replace \n & \t with tabs and newlines for the text edit box QString tmpstr = text(); - QRegExp cr("\\\\n"); - QRegExp tab("\\\\t"); - tmpstr.replace(cr,"\n"); - tmpstr.replace(tab,"\t"); + tmpstr.replace(QString("\\n"), "\n"); + tmpstr.replace(QString("\\t"), "\t"); widget->_text->setText(tmpstr); widget->_precision->setValue(int(dataPrecision())); @@ -592,6 +590,7 @@ return true; } + bool KstViewLabel::readConfigWidget(QWidget *w) { ViewLabelWidget *widget = dynamic_cast<ViewLabelWidget*>(w); if (!widget) { @@ -599,11 +598,9 @@ } // Replace tabs and newlines in text edit box with \n and \t - QRegExp cr("\n"); - QRegExp tab("\t"); _txt = widget->_text->text(); - _txt.replace(cr, "\\n"); - _txt.replace(tab, "\\t"); + _txt.replace(QString("\n"), "\\n"); + _txt.replace(QString("\t"), "\\t"); setDataPrecision(widget->_precision->value()); setRotation(widget->_rotation->value()); @@ -615,7 +612,7 @@ setTransparent(widget->_transparent->isChecked()); setAutoResize(widget->_autoResize->isChecked()); - setBorderWidth(transparent() ? 0 : widget->_border->value()); + setBorderWidth(widget->_border->value()); setBorderColor(widget->_boxColors->foreground()); setBackgroundColor(widget->_boxColors->background()); setPadding(widget->_margin->value()); --- trunk/extragear/graphics/kst/kst/kstviewlegend.cpp #490162:490163 @@ -487,7 +487,7 @@ setFontName(widget->_font->currentFont()); setTransparent(widget->_transparent->isChecked()); - setBorderWidth(transparent() ? 0 : widget->_border->value()); + setBorderWidth(widget->_border->value()); setBorderColor(widget->_boxColors->foreground()); setBackgroundColor(widget->_boxColors->background()); setPadding(widget->_margin->value()); Hmm there's still a bug here. Working on it.. more work is needed. Should be fixed for 1.2.1 release SVN commit 503879 by staikos: Merge the branch painting changes. Painting is now split into three phases: paint(): only in KstViewObject updateSelf(): this is for updating the internal state - adjusting contents based on other variables, etc paintSelf(): this is the -only- place where painting of an object should be done. It only paints itself, and not its children. Introduces a minor regression in X-Y guidelines, and a major one in labels. Fixes many old issues. BUG: 120740, 118753 M +69 -14 extensions/js/bind_box.cpp M +13 -3 extensions/js/bind_box.h M +2 -6 extensions/js/bind_legend.cpp M +0 -2 extensions/js/bind_legend.h M +65 -71 kst2dplot.cpp M +3 -3 kst2dplot.h M +15 -9 kstborderedviewobject.cpp M +1 -1 kstborderedviewobject.h M +0 -4 kstplotbase.cpp M +0 -2 kstplotbase.h M +2 -2 kstplotdialog_i.cpp M +8 -12 kstplotgroup.cpp M +1 -1 kstplotgroup.h M +1 -27 ksttoplevelview.cpp M +39 -2 kstviewarrow.cpp M +3 -1 kstviewarrow.h M +66 -23 kstviewbox.cpp M +24 -6 kstviewbox.h M +9 -16 kstviewellipse.cpp M +1 -1 kstviewellipse.h M +78 -47 kstviewlabel.cpp M +8 -1 kstviewlabel.h M +76 -36 kstviewlegend.cpp M +10 -1 kstviewlegend.h M +7 -4 kstviewline.cpp M +1 -1 kstviewline.h M +91 -47 kstviewobject.cpp M +6 -1 kstviewobject.h M +57 -26 kstviewpicture.cpp M +4 -2 kstviewpicture.h M +6 -0 kstviewwidget.cpp M +1 -0 kstviewwidget.h |