Qt-interest Archive, August 2007
Why QWidget::show () is not virtual?
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Why QWidget::show () is not virtual?
I want my dialog class has a clean constructor, which benefits none-gui
mode. Only after I switch from none-gui to gui mode I may want to "show"
the dialog. So my show means "build" and "show" --- that's why I need
QWidget::show () to be virtual to hook my "build", unfortunately, it is
not. Does anyone has thought on this?
Thanks,
Lingfa
--
[ signature omitted ]
Message 2 in thread
Lingfa Yang wrote:
> Why QWidget::show () is not virtual?
>
> I want my dialog class has a clean constructor, which benefits
> none-gui mode. Only after I switch from none-gui to gui mode I may
> want to "show" the dialog. So my show means "build" and "show" ---
> that's why I need QWidget::show () to be virtual to hook my "build",
> unfortunately, it is not. Does anyone has thought on this?
>
You can try implementing the virtual showEvent(QShowEvent* event) and do
your magic in there.
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 3 in thread
Two answers:
1) QWidget::show() is not visible, but it just calls
QWidget::setVisible(true), and QWidget::setVisible() is virtual so you
coulddo your initialization in there.
2) However, read the last paragraph of the documentation for that method (
http://doc.trolltech.com/4.3/qwidget.html#visible-prop), and it will explain
a better way to do what you want.
Tom
On 8/23/07, Lingfa Yang <lingfa@xxxxxxx> wrote:
>
> Why QWidget::show () is not virtual?
>
> I want my dialog class has a clean constructor, which benefits none-gui
> mode. Only after I switch from none-gui to gui mode I may want to "show"
> the dialog. So my show means "build" and "show" --- that's why I need
> QWidget::show () to be virtual to hook my "build", unfortunately, it is
> not. Does anyone has thought on this?
>
> Thanks,
> Lingfa
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 4 in thread
Tom Panning wrote:
> Two answers:
> 1) QWidget::show() is not visible, but it just calls
> QWidget::setVisible(true), and QWidget::setVisible() is virtual so you
> could do your initialization in there.
> 2) However, read the last paragraph of the documentation for that
> method (http://doc.trolltech.com/4.3/qwidget.html#visible-prop), and
> it will explain a better way to do what you want.
>
> Tom
Justin and Tom,
Thank you both providing me solutions. Catching the showEvent() and
overwriting virtual function QWidget::setVisible() both are good
solutions. I would like try both to see which one is more elegant.
Thanks,
Lingfa
--
[ signature omitted ]
Message 5 in thread
On torsdag den 23. August 2007, Lingfa Yang wrote:
> Why QWidget::show () is not virtual?
>
> I want my dialog class has a clean constructor, which benefits none-gui
> mode. Only after I switch from none-gui to gui mode I may want to "show"
> the dialog. So my show means "build" and "show" --- that's why I need
> QWidget::show () to be virtual to hook my "build", unfortunately, it is
> not. Does anyone has thought on this?
I don't understand why you want to abuse the visible property of a dialog for
this. It would be much cleaner if you introduce a system around it that would
call show() once you go to gui mode.
Bo.
--
[ signature omitted ]
Message 6 in thread
Bo Thorsen wrote:
> On torsdag den 23. August 2007, Lingfa Yang wrote:
>> Why QWidget::show () is not virtual?
>>
>> I want my dialog class has a clean constructor, which benefits none-gui
>> mode. Only after I switch from none-gui to gui mode I may want to "show"
>> the dialog. So my show means "build" and "show" --- that's why I need
>> QWidget::show () to be virtual to hook my "build", unfortunately, it is
>> not. Does anyone has thought on this?
>
> I don't understand why you want to abuse the visible property of a dialog
> for this. It would be much cleaner if you introduce a system around it
> that would call show() once you go to gui mode.
I believe that is what the OP wants to do, but as show() isn't virtual, you
can not delay setting up the GUI by doing that in a reimplemented show()
instead of in the constructor. So, in that sense, I think the question is
valid.
To OP:
However, I think the problem can (and should) be solved in another way. If
you also can run your work in a non-GUI "mode", why don't you create a
separate object that does the actual work, and let your dialog just be a
GUI that you create when going to GUI mode, after which you set up the
needed connections between your worker object and your dialog. This way,
you get a nice and clean separation between the components. It might even
make it possible to compile your app completely without GUI support if
needed, and it makes it possible to let the worker run in it's own thread
if you want.
Regards,
André
--
[ signature omitted ]
Message 7 in thread
On fredag den 24. August 2007, André Somers wrote:
> Bo Thorsen wrote:
> > On torsdag den 23. August 2007, Lingfa Yang wrote:
> >> Why QWidget::show () is not virtual?
> >>
> >> I want my dialog class has a clean constructor, which benefits none-gui
> >> mode. Only after I switch from none-gui to gui mode I may want to "show"
> >> the dialog. So my show means "build" and "show" --- that's why I need
> >> QWidget::show () to be virtual to hook my "build", unfortunately, it is
> >> not. Does anyone has thought on this?
> >
> > I don't understand why you want to abuse the visible property of a dialog
> > for this. It would be much cleaner if you introduce a system around it
> > that would call show() once you go to gui mode.
>
> I believe that is what the OP wants to do, but as show() isn't virtual, you
> can not delay setting up the GUI by doing that in a reimplemented show()
> instead of in the constructor. So, in that sense, I think the question is
> valid.
My point is that what he wants is not to do a show(), so why would he call it?
He wants a showWhenTheAppIsInGUIMode(). So implement that instead.
Bo.
--
[ signature omitted ]
Message 8 in thread
Bo Thorsen wrote:
>On fredag den 24. August 2007, André Somers wrote:
>
>
>>Bo Thorsen wrote:
>>
>>
>>>On torsdag den 23. August 2007, Lingfa Yang wrote:
>>>
>>>
>>>>Why QWidget::show () is not virtual?
>>>>
>>>>I want my dialog class has a clean constructor, which benefits none-gui
>>>>mode. Only after I switch from none-gui to gui mode I may want to "show"
>>>>the dialog. So my show means "build" and "show" --- that's why I need
>>>>QWidget::show () to be virtual to hook my "build", unfortunately, it is
>>>>not. Does anyone has thought on this?
>>>>
>>>>
>>>I don't understand why you want to abuse the visible property of a dialog
>>>for this. It would be much cleaner if you introduce a system around it
>>>that would call show() once you go to gui mode.
>>>
>>>
>>I believe that is what the OP wants to do, but as show() isn't virtual, you
>>can not delay setting up the GUI by doing that in a reimplemented show()
>>instead of in the constructor. So, in that sense, I think the question is
>>valid.
>>
>>
>
>My point is that what he wants is not to do a show(), so why would he call it?
>He wants a showWhenTheAppIsInGUIMode(). So implement that instead.
>
>Bo.
>
>
>
André and Bo,
Thank you both for replies. The following code is another way to speak
out my question.
class Generator : public QWidget
{
public:
Generator();
virtual void show();
// methods . . .
private:
//Core-data members . . .
// accessable by none-gui scripting or gui
bool built;
void build();
};
Generator::Generator()
: built(false)
{
// clean constructor. No any gui related things
}
void Generator::build()
{
// build GUI components and setLayout()
// to display/modify Core-data of this class
built = true;
}
void Generator::show()
{
if(!built) build(); // The very first time show() means build() and
show()
QWidget::show();
}
class test
{
test()
{
QHash<QString, QWidget *> widgets;
widgets.insert("Generator", new Generator);
// ...
widgets["Generator"]->show(); // Call by name
// Generator::show() will not be invoked because QWidget::show()
is not virtual.
// Thanks Justin and Tom providing solutions by using
QWidget::setVisible() or showEvent()
};
};
Any thoughts are welcome,
Lingfa
--
[ signature omitted ]
Message 9 in thread
Lingfa Yang wrote:
> André and Bo,
>
> Thank you both for replies. The following code is another way to speak
> out my question.
>
> Any thoughts are welcome,
Here's a thought:
Nobody was really waiting for another way to look at the problem. What was
it you did not understand about the solutions offered?
Regards,
André
--
[ signature omitted ]
Message 10 in thread
André Somers wrote:
>Lingfa Yang wrote:
>
>
>
>>André and Bo,
>>
>>Thank you both for replies. The following code is another way to speak
>>out my question.
>>
>>Any thoughts are welcome,
>>
>>
>Here's a thought:
>Nobody was really waiting for another way to look at the problem. What was
>it you did not understand about the solutions offered?
>
>Regards,
>
>André
>
>
>
Andre,
If I had no last post, where your understanding cames from?
Below is what you wrote:
"
MyTwistedClass::comeOutOfHiding() {
createGuiStuff();
show();
}
"
Lingfa
--
[ signature omitted ]
Message 11 in thread
Lingfa Yang wrote:
>>Nobody was really waiting for another way to look at the problem. What was
>>it you did not understand about the solutions offered?
> Andre,
> If I had no last post, where your understanding cames from?
> Below is what you wrote:
> "
> MyTwistedClass::comeOutOfHiding() {
>
> createGuiStuff();
> show();
> }
> "
This is what - I think - Bo mend in his posts. Especially his second post is
quite clear. Also, I already did offer another solution (splitting the
thing in a GUI and worker class), with no reply from you at all, other than
you posting some code.
Still, I may have sounded a bit harsh. Sorry about that.
Regards,
André
--
[ signature omitted ]
Message 12 in thread
>This is what - I think - Bo mend in his posts. Especially his second post is
>quite clear. Also, I already did offer another solution (splitting the
>thing in a GUI and worker class), with no reply from you at all, other than
>you posting some code.
>Still, I may have sounded a bit harsh. Sorry about that.
>
>Regards,
>
>André
>
>
>
Andre,
I'm sorry too. My delay came from my doubt.
As I have a class called Generator, I know it has its own properties.
To modify these properties through GUI, I have to make a modifier. My
point is this modifier belongs to the Generator class. Why I have to
separate the data and modifier dialog?
If I access Generator by scripting, I will never call show(), so that no
dialog will be built. Is this not clean?
Lingfa
--
[ signature omitted ]
Message 13 in thread
Lingfa Yang wrote:
> As I have a class called Generator, I know it has its own properties.
>
> To modify these properties through GUI, I have to make a modifier. My
> point is this modifier belongs to the Generator class. Why I have to
> separate the data and modifier dialog?
Because:
a) you don't want to use them together all the time. You want to use your
Generator without your Modifier.
b) they perform a different function: the Generator does some work, the
modifier presents a GUI to the user.
There is no OOP violation by separating the two. Still, if you prefer to use
them together, you can still use Bo's suggestion and just use another
function name than show() to create your GUI.
> If I access Generator by scripting, I will never call show(), so that no
> dialog will be built. Is this not clean?
In my view: not really. Why carry all the baggage of a GUI class if you
don't use it as such? You could even give your (non GUI) Generator class a
show() method that just creates a (GUI) Modifier class instance and connect
it to the itself. That way, you won't have to deal with two classes in the
rest of your code at all, and you'll still have a clean solution to your
problem.
I hope this helps.
Regards,
André
--
[ signature omitted ]
Message 14 in thread
André Somers wrote:
>Lingfa Yang wrote:
>
>
>
>>As I have a class called Generator, I know it has its own properties.
>>
>>To modify these properties through GUI, I have to make a modifier. My
>>point is this modifier belongs to the Generator class. Why I have to
>>separate the data and modifier dialog?
>>
>>
>Because:
>a) you don't want to use them together all the time. You want to use your
>Generator without your Modifier.
>b) they perform a different function: the Generator does some work, the
>modifier presents a GUI to the user.
>There is no OOP violation by separating the two. Still, if you prefer to use
>them together, you can still use Bo's suggestion and just use another
>function name than show() to create your GUI.
>
>
>
>>If I access Generator by scripting, I will never call show(), so that no
>>dialog will be built. Is this not clean?
>>
>>
>In my view: not really. Why carry all the baggage of a GUI class if you
>don't use it as such? You could even give your (non GUI) Generator class a
>show() method that just creates a (GUI) Modifier class instance and connect
>it to the itself. That way, you won't have to deal with two classes in the
>rest of your code at all, and you'll still have a clean solution to your
>problem.
>
>I hope this helps.
>
>Regards,
>
>André
>
>
André,
Thank you for your detailed explanation. You are an expert on design pattern. To follow your idea of separating core and gui a question is what is the relationship between the Generator class and its gui? Here list several, which one is correct?
class Generator
{
public:
Generator();
private:
int m_width;
friend class GeneratorGui1;
};
class GeneratorGui1 : public QWidget
{
Q_OBJECT
public:
GeneratorGui1(Generator &gen);
private slots:
void updateToMember();
private:
Generator &generator;
QLineEdit *lineEdit;
};
GeneratorGui1::GeneratorGui1(Generator &gen)
: generator(gen)
{
QHBoxLayout *hbox = new QHBoxLayout;
hbox->addWidget(new QLabel("Width"));
lineEdit = new QLineEdit(QString::number(generator.m_width));
hbox->addWidget(lineEdit);
this->setLayout(hbox);
connect(lineEdit, SIGNAL(editingFinished()), SLOT(updateToMember()));
}
void GeneratorGui1::updateToMember()
{
generator.m_width = lineEdit->text().toInt();
}
//============================================================
class GeneratorGui2 : public QWidget
{
public:
GeneratorGui2();
// ...
private:
Generator *generator;
};
//============================================================
class GeneratorGui3 : public QWidget, Generator
{
public:
GeneratorGui3();
// ...
};
//============================================================
class GeneratorGui4 : public Generator
{
public:
GeneratorGui4();
// ...
private:
QWidget *myDialog;
};
//============================================================
class GeneratorGui5
{
public:
GeneratorGui5(Generator &gen);
// ...
private:
QWidget *myDialog;
Generator &generator;
};
//============================================================
class GeneratorGui6
{
public:
GeneratorGui5();
// ...
private:
QWidget *myDialog;
Generator *generator;
};
. . .
Thanks,
Lingfa
--
[ signature omitted ]
Message 15 in thread
Lingfa Yang wrote:
> Bo Thorsen wrote:
>
>> On fredag den 24. August 2007, André Somers wrote:
>>
>>
>>> Bo Thorsen wrote:
>>>
>>>> On torsdag den 23. August 2007, Lingfa Yang wrote:
>>>>
>>>>> Why QWidget::show () is not virtual?
>>>>>
>>>>> I want my dialog class has a clean constructor, which benefits
>>>>> none-gui
>>>>> mode. Only after I switch from none-gui to gui mode I may want to
>>>>> "show"
>>>>> the dialog. So my show means "build" and "show" --- that's why I need
>>>>> QWidget::show () to be virtual to hook my "build", unfortunately,
>>>>> it is
>>>>> not. Does anyone has thought on this?
>>>>>
>>>> I don't understand why you want to abuse the visible property of a
>>>> dialog
>>>> for this. It would be much cleaner if you introduce a system around it
>>>> that would call show() once you go to gui mode.
>>>>
>>> I believe that is what the OP wants to do, but as show() isn't
>>> virtual, you
>>> can not delay setting up the GUI by doing that in a reimplemented
>>> show()
>>> instead of in the constructor. So, in that sense, I think the
>>> question is
>>> valid.
>>>
>>
>> My point is that what he wants is not to do a show(), so why would he
>> call it? He wants a showWhenTheAppIsInGUIMode(). So implement that
>> instead.
>>
>> Bo.
>>
>>
>>
> André and Bo,
>
> Thank you both for replies. The following code is another way to speak
> out my question.
>
>
> class Generator : public QWidget
> {
> public:
> Generator();
> virtual void show();
> // methods . . .
> private:
> //Core-data members . . .
> // accessable by none-gui scripting or gui
> bool built;
> void build();
> };
> Generator::Generator()
> : built(false)
> {
> // clean constructor. No any gui related things
> }
> void Generator::build()
> {
> // build GUI components and setLayout()
> // to display/modify Core-data of this class
>
> built = true;
> }
>
> void Generator::show()
> {
> if(!built) build(); // The very first time show() means build() and
> show()
> QWidget::show();
> }
>
> class test
> {
> test()
> {
> QHash<QString, QWidget *> widgets;
> widgets.insert("Generator", new Generator);
> // ...
>
> widgets["Generator"]->show(); // Call by name
> // Generator::show() will not be invoked because
> QWidget::show() is not virtual.
> // Thanks Justin and Tom providing solutions by using
> QWidget::setVisible() or showEvent()
> };
> };
>
> Any thoughts are welcome,
> Lingfa
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
The idea is to completely separate GUI from Core.
For Example:
MyClass: public QObject {
// Core code: no gui is included at all
};
MyClassGUI: public MyClass {
// Here GUI is introduced
};
Then depending on your needs in main(...) use appropriate class: MyClass
or MyClassGUI.
Samvel.
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
