Bug 57230 - behaviour of shared library libtaskbar.so is unpleasant
Summary: behaviour of shared library libtaskbar.so is unpleasant
Status: RESOLVED DUPLICATE of bug 56251
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-14 20:44 UTC by psane
Modified: 2003-04-14 20:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description psane 2003-04-14 20:44:35 UTC
Version:            (using KDE KDE 3.1.1a)
Installed from:    RedHat RPMs
OS:          Linux

I  am writing a plugin framework which has nothing to do with KDE (or any other window manager for that matter). My framework tries to open all the shared libraries in the directory it is pointed to. After loading the shared object, it looks for the libraries using my framework. If the loaded library is not written with the framework, it immediately closes it. I pointed this application to /usr/lib directory, since some of my plugins reside there. libtaskbar.so terminated my application with message "QPaintDevice: Must construct a QApplication before a QPaintDevice".

I have fair idea what's happening here. There's some code in the _init routine within libtaskbar.so is determining that it's not loaded within right context and hence (must be) calling abort.

I don't think this is the right way to handle things. Merely loading this library should not terminate (any) application.
Comment 1 Lubos Lunak 2003-04-14 20:58:35 UTC

*** This bug has been marked as a duplicate of 56251 ***