QWidget: Cannot create a QWidget when no GUI is being used

[marcel]

Can't you make those functions static( name, description)? This way a QWidget won't have to be instantiated when you call the functions, therefore no QtGui ( I think... ).

But this is useful only if you can make them static...

Anyway, it doesn't matter that you don't actually show the widget. It is there, so when you hide it ( I assume that's how you don't show it ) it will emit a QHideEvent... Who's gonna catch that?

Regards

[KShots]

No, I simply don't call the show() function. You also don't have to connect all the slots.

As far as static goes, I don't think that will work either. This is a plugin, so an instance must be instantiated to gain access to the functions.

My only alternative is to do this with a GUI over a VNC connection... and as we all know, Qt does not reliably show icons and other graphics over VNC, so it would become spotty at best.

[wysota]

Make those plugin not inherit QWidget but return an instance of a QWidget. Then you'll be able to create an instance of a plugin without creating a QWidget. Unfortunately you'd have to redesign your plugin system for that to work.

[KShots]

Make those plugin not inherit QWidget but return an instance of a QWidget. Then you'll be able to create an instance of a plugin without creating a QWidget. Unfortunately you'd have to redesign your plugin system for that to work.

I think I could see that working. Basically, the plugin would be a factory class that would pass a QWidget-based object via a function call on request. The main class would then load the plugin, qobject_cast it, then request the QWidget (if appropriate).

Ok, I think I can do this relatively easily at this stage - my current plugins don't yet do anything, so there's not a whole lot to re-write. Thanks!

EDIT: Actually, I think this will greatly simplify things now, as I can now create signals and slots in my plugin interface (as long as the interface header itself does not include the signals and slots).

Basically, it's like this:

Interface - contains some basic code to hand back a QWidget (or QObject, depending on the plugin type)
Shared abstract base class - contains signals and slots that the QWidget (or QObject) should contain that is passed back. As the interface itself only knows that it's something called a QWidget (or QObject), and doesn't know what either of those are (not including the headers), it should work. I think you just helped me find a way to cleanly implement my plugin structure. Thanks!