[Kommander-devel] Making a Kommander editor using Designer 4

[Eric Laffoon]

On Wednesday 16 April 2008 12:50:05 pm Andras Mantia wrote:
> Hi Eric,
>
> On Wednesday 16 April 2008, Eric Laffoon wrote:
> > QWidget *ButtonGroupKmdrDesignerPlugin::createWidget(QWidget *parent)
> > {
> >   return new ButtonGroup(parent);
> > }
> >
> > The compiler rightly points out this is not correct as the
> > constructor requires another vairable, the name variable. However I
> > added this locally so it calls
>
> Assuming it is about the ButtonGroup widget inside
> kde-trunk/kdewebdev/widgets the compiler was right. ;) But somehow I
> don't understand why you want to create a ButtonGroup widget in a
> plugin when there is one in the main Kommander. Ah, I see, this is
> about the designer plugin.
> First of all, I'm not happy at all that these classed ended up in the
> widgets directory and the libkommanderwidgets plugin.
> This plugin should have ONLY the widgets themselves. Otherwise we would
> bloat the executor with designer (editor) specific code, and will make
> moving of the executor to kdebase close to impossible.
> If the problem is that you need access to the classes, we will find some
> other solution.

Apologies all around. I had asked your advice/opinion and not gotten a 
response. Initially I just wanted to be sure it worked. Logically these 
should go in the editor directory, but the whole thing is not being built and 
I suspect is messy, though I guess I could have done the CMakeList.txt to 
deal with it. I will move these, unless you already have.
>
> > The changes to headers were made and everything is right... Except of
> > course that I'm mucking with not just the widget constructor, but the
> > virtual function in the QDesigner plugin. Now it is not happy...
> >
> > /home/eric/kdesvn/kdewebdev/kommander/widgets/kmdrdesignerwidgets.cpp
> >
> >:18: error: cannot allocate an object of abstract
> >
> > type 'ButtonGroupKmdrDesignerPlugin'
> > /home/eric/kdesvn/kdewebdev/kommander/widgets/buttongroupkmdrdesigner
> >plugin.h:26: note:   because the following virtual functions are pure
> > within 'ButtonGroupKmdrDesignerPlugin':
> > /usr/local/Trolltech/Qt-4.4.0-beta1/include/QtDesigner/customwidget.h
> >
> >:73: note: virtual QWidget*
> >
> > QDesignerCustomWidgetInterface::createWidget(QWidget*)
>
> This means that you inherit from an "abstract" class, that has abstract
> (pure virtual) methods. Those are the methods declared as:
>  void methodName() = 0;
> (or similar).
>
> These methods are not implemented at all in the base class, this is why
> they are abstract. The class also cannot be instantiated as an object.
> So you need to subclass it (as I understood you did), and write the
> implementation of the abstract methods (all of them!). So you need a
> QWidget* createWidget(QWidget*);
> declaration in the class header file, and the impelementation of this
> method in the cpp file.
>
> Now that I see this code, I'm wondering what is wrong. :)

Yeah, well most was copied from the Qt examples. In fact I made a Kommander 
dialog to make it cookie cutter easy... if only it worked. :)

> Ok, so the problem here was only the (first) compiler error. There is no
> complain about the pure virtual methods. So maybe you messed your local
> checkout up by adding a name argument to the createWidget declaration?

I think we're close. Yes, the first time I did not have a name in the 
createWidget declaration and I get a complaint from the Kommander widget 
class that I didn't use the name. I add the name and I get a complaint from 
the virtual class for Designer. As I see it there is no way to decouple the 
name issue the way the code is written. In fact trying that gets a weird 
error from the Kommander class effectively saying it's undeclared.
>
> > So what is happening with the name in the constructor?
>
> Name is the object name assigned to the widget. In Qt3 all widgets had a
> name argument. In Qt4 none of them has and you have to use
> widget->setObjectName(name).
> They are useful to find/identify an widget (or to be more precise,
> QObject).

Okay, but this comes back to the question about runtime. If we wipe the names 
from the constructor I think we can add them with a plugin from the object 
inspector if we can maybe do something like a signal from this module to say 
a new widget has been created and the type and it's probably not hard to get 
that... I hope. That should clear the first hurdle. What happens to the 
widgets if I change the constructuctors? I'm thinking that it has to parse 
the XML for runtime so it's not using this there, right? If so I can remove 
them, and then the issues is getting the name.
>
> > Is Kommander
> > being passed the widget name here?
>
> No.
>
> I hope this helps, I committed the "fixed" buttongroup stuff, but others
> still failing. They need the same change though.
>
> Andras
Oh... well if you have one widget working I should be able to work from there. 
Thanks much!.


-- 
Eric Laffoon
Project Lead - kdewebdev module