[Qt-interest] Generic input widgets for varying types - how to?

[Andreas Pakulat]

On 27.03.09 21:03:25, Helge Preuss wrote:
> Andreas Pakulat wrote:
> > On 27.03.09 20:18:05, Helge Preuss wrote:
> >   
> >> Question 1:
> >> Is this a good way to do it? Differently put, is there a /better/ way
> >> ;-) ? In particular, I am a bit concerned about deriving the concrete
> >> input widgets from QWidget twice - once via ParameterInput and once via
> >> QSlider/QLineEdit.
> >>     
> >
> > Thats not supported by Qt, you can only derive from QObject once. So
> > make the input class a pure interface and inherit first from the gui
> > widgets.
> >   
> Uh-oh. How would I make a dialog contain a ParameterInput then? It must
> be a QWidget, else it cannot be a sub-widget, am I right?

That depends on what you actually want to achieve. I just had another
look at your initial mail. The part about manually editing a uic
generated file is problematic. It basically makes using the
uic-generated file completely meaningless, the whole point of doing that
is to easily update the gui without having to touch code, which is not
possible with your idea.

And if you're creating the gui in code by using a factory, there's no
reason why that factory cannot return a QWidget*  that can be casted to
either a specific QWidget subclass (like lineedit, spinbox) or your
ParameterInput interface.

So you could just do
QWidget* inputWigdet = Factory::create( LineEdit );
dynamic_cast<ParameterInput*>(inputWidget)->setValue( "SomeString" );

Or even pass around the "widget" only by using the ParameterInput
pointer so no code outside the place that actually creates the widgets
from the factory sees which widget is behind the ParameterInput.

> >> Question 2:
> >> This does not really work. The ParameterInput widgets are not displayed.
> >> I assume I must implement some QWidget methods to make the widgets
> >> display. Which methods would that be?
> >>     
> >
> > I suggest to fix the above first and then revisit this, all kinds of
> > weird things may happen when you subclass twice from qwidget. In
> > particular in your case probably the paintEvent of QWidget is being
> > called (just painting a grey background) instead of the one from the
> > actual widgets.
> >   
> That's probably what happens, yes.
> 
> So if my above hunch about ParameterInput having to be a QWidget is
> correct, I'll probably have to use composition in the derived classes.
> Such as:
> 
> class ParameterLineEdit: public ParameterInput {
>   private:
>     QLineEdit *delegateLineEdit;
>     void setValue(const QString &s) { delegateLineEdit->setText(s); }
>     //  etc.
> }

Well, you'd need the delegating for setValue/value anyway, but more
importantly in this case you'd need to delegate the whole QLineEdit API
to make it work. Thats going to be a lot of work for no gain (that I can
currently see).

Andreas

-- 
Your sister swims out to meet troop ships.