Qt4-preview-feedback Archive, January 2008
Various bugs and suggestions to Qt4.4-tp1
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Let's do some more picking on the poor Designer + UIC configuration...
A classic... tab widget + two tabs + changing tab text.
Result made by uic:
tabWidget->setTabText(tabWidget->indexOf(tab),
QApplication::translate("Form", "AAA", 0, QApplication::UnicodeUTF8));
tabWidget->setTabText(tabWidget->indexOf(tab_2),
QApplication::translate("Form", "BBB", 0, QApplication::UnicodeUTF8));
Same history, custom widget, two pages, changing the title.
Result by uic - incompatible.
Current workaround - use windowTitle of each page as the property that holds
the text and apply an event filter on each page so that the container
intercepts changeEvent() and can react on QEvent::WindowTitleChange. Crude,
dirty but should work. But! (there is always a but) a similar workaround
for an icon won't work even if one uses windowIcon (as I currently try to
do), because changeEvent() doesn't have an appropriate event type to look
for.
Let's continue -- assuming it is not Designer's fault that there is no such
event (because it's not its fault), how to work it around without using
existing properties of pages. For the tab widget Designer stores the title
as an attribute:
<attribute name="title" >
<string>AAA</string>
</attribute>
For custom widgets attributes are not stored (after all that's what the docs
say, right?) and even if they were, there would be no way of accessing them
in a logical way from UIC generated code.
A possible workaround to everything (but I haven't tried it) is to associate
a script in QtScript that will inspect properties of pages and call correct
methods of the container - I remember there was some extension class or
method in one of other extenstions allowing to run a script when a form is
created. But it's all very ugly and we should get a decent interface for
manipulating the xml tree stored in the .ui file in a bit wider manner than
now (currently the only thing we can do is store properties).
Sorry for being so monotopical :) I find many new Designer features great
(view code, extended icon support, new widgets accessible from Desginer),
but the cooperation between Designer's custom widgets support and UIC is
lagging behind since Qt3 times and little has been done to reduce the gap.
Regards,
W.
--
[ signature omitted ]
Message 17 in thread
> Andreas Aardal Hanssen wrote:
> >
> > Hm. But if you're the one adding the button, you're also changing the
> r/o
> > property yourself,
>
> Not really. The button is part of the lineedit's subclass, the lineedit's
> readOnly property might be changed in Designer (or in code) and there is
> no
> direct access to the button. The class looks more or less like this:
>
> class X : public QLineEdit {
> public:
> X(...) : QLineEdit(...){
> b = new QToolButton(this);
> setContentsMargins(0, 0, b->sizeHint().width()+1, 0);
> }
> protected:
> void resizeEvent(...){
> b->move(contentsRect().right()+1, 0);
> ...
> }
> private:
> QToolButton *b;
> };
>
> Anyway this is only a use case. A general rule is that if you use
> QLineEdit
> itself, you don't need the notification, because you are the one who
> changed the property in the first place, but if you subclass and want to
> react to changes within the subclassed widget (code modularity and stuff),
> you are not the one changing the property thus such a notification might
> be
> useful. In this case changeEvent() would probably be a better choice
> because it embeds the notification in the widget without notifying the
> environment.
>
After reading this email correspondence go back and forth regarding the
QLineEdit subclass and the request for a new signal, I am compelled to offer
a possible solution. I believe that Witold may be able to solve his problem
using a solution I found in the Trolltech Labs (highly recommended
resource):
http://labs.trolltech.com/blogs/2007/06/06/lineedit-with-a-clear-button/
I used this very solution to create a Filter line edit that I needed. It
works great. The button is *only* visible when the user has typed some text
and invisible otherwise, therefore if the line edit is read-only, the user
will never be able to type text making the button visible. So, there is no
need for a signal indicating that the state changed. Just promote the line
edit in Designer to the class that is provided from the above link. The
other great thing is that you can tweak the code to your needs and use
stylesheets to get the look and feel you want. It is very flexible.
Michael Booker
LifeLine Software, Inc.
>
> > do you still really need notification? :-)
>
> Yep :) Unless of course you consider the paintEvent workaround a good
> design :)
>
> A side note - the funny thing is that having:
>
> Q_PROPERTY(type name READ name WRITE setName NOTIFY nameChanged)
>
> could allow moc to generate code that would emit nameChanged() or even
> nameChanged(...) by itself, without having to modify anything in the class
> code. Moc would just have to track if the change really occured.
>
>
> You know what? Now that I think of it, there is a general problem with Qt
> widgets (hi, Widget Team Leader! ;)). Their API is fine if you just want
> to
> use those ready made widgets, but it's often hard to subclass them to add
> new functionality. Either the required functionality is hidden inside
> P-IMPL or the API just lacks a protected or virtual protected method to
> access what is needed. And unfortunately protecting the ABI reduces the
> chance of having such a functionality introduced at a later stage of
> development.
>
> Cheers,
> W.
>
> --
> Witold Wysota
> QtCentre Admin Team
>
> To unsubscribe - send "unsubscribe" in the subject to qt4-preview-
> feedback-request@xxxxxxxxxxxxx
>
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 18 in thread
Michael Booker wrote:
>
> After reading this email correspondence go back and forth regarding the
> QLineEdit subclass and the request for a new signal, I am compelled to
> offer
> a possible solution. I believe that Witold may be able to solve his
> problem using a solution I found in the Trolltech Labs (highly recommended
> resource):
>
> http://labs.trolltech.com/blogs/2007/06/06/lineedit-with-a-clear-button/
Thanks. I'm aware of that and actually my class uses that solution too, but
my real class is a bit more generic than the one mentioned in this thread.
It can place the button in one of four positions - on the left or right of
the line edit and inside or outside it. Both inside versions use the
stylesheet solutions while the outside ones modify the contentsRect
instead. But that's all only a use case showing that the button can't be
controlled by the person setting the readOnly property.
> I used this very solution to create a Filter line edit that I needed. It
> works great. The button is *only* visible when the user has typed some
> text and invisible otherwise, therefore if the line edit is read-only, the
> user
> will never be able to type text making the button visible.
What if the widget already contains some text and then is made readOnly? In
that situation you end up with a button that shouldn't be used - it should
either be disabled or hidden which won't happen if you make the line edit
widget read only - the button will still be clickable. A solution is to
make the whole widget disabled - as the button is child of the line edit,
it will get disabled as well. But it will still be visible. And besides
there are other usecases not related to clickable buttons where
notification would be useful. The change of the "enabled" property is
broadcasted using changeEvent(), I don't see why "readOnly" should behave
differently -- it's very similar to "enabled" (I guess the difference
depends on the style used).
The most flexible solution would be to have a changeEvent() with a new
QEvent type - QEvent::PropertyChange telling the name of the property and
its previous and current values and that's probably what Andreas was
talking about. The question is - is the (rare) use of it worth an
additional overhead during each property change? I'd say - no, think of
another solution. Registering properties that should be monitored for
changes and only posting the event in case a monitored property of a
desired instance of a class is changed? Maybe that's a better idea... But
is there one that is even better?
Regards,
W.
--
[ signature omitted ]
