PDA

View Full Version : QWidget: Cannot create a QWidget when no GUI is being used



KShots
23rd April 2007, 21:00
I'm getting the subject message in my QCoreApplication. The problem is, I'm not trying to display the widget, I'm simply trying to poll information from it.

The idea here is that I've got a console configuration program for another application, which tells the application which plugins to load on startup. The plugins are not to be loadable while the program is running, but should be configurable via a shell program.

Therefore, I created an application which uses the Qt core module and makes use of the ncurses, panel, and menu libraries (just to make it fancy). Unfortunately, upon loading up available plugins, the code crashes with the above message on those plugins that inherit QWidget. My original idea was to have functions in the plugin which would have it describe itself (A QString name() function, and another QString description() function). This doesn't appear possible :(. Any way around this? I'm not actually trying to display the QWidget...

marcel
23rd April 2007, 21:08
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
23rd April 2007, 22:10
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
24th April 2007, 00:06
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
24th April 2007, 14:18
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!