Forum

Results 1 to 5 of 5
  1. #1
    Join Date
    January 2010
    Location
    Switzerland
    Posts
    6

    void ts3plugin_configure(void* handle) - how to use it?

    Hi

    I'm currently developing a client plug-in. Its core functionality is already working quite well, but now I want to implement a configuration dialog using ts3plugin_configure hook. Unfortunately, this hook is rather undocumented and I'm out of ideas what else I can try.

    I was assuming that I'm supposed to use a QT dialog to display my configuration window. Here's what I did so far:

    I made my plug-in build with qmake and c++ (I'm developing on a Mac) instead of just the C compiler, so I could even use Qt.

    Then I created a minimalistic QDialog with some widgets using Qt Designer and implemented the corresponding header file and basic implementation (just the basics, no functionality yet).

    Then the problems started. I first thought I shoud be able to just create a instance of my QDialog to get it displayed. That horribly failed because Qt required me to have an QApplication instance first, that despite there shouldn't be more than one instance of that class in an application and I'm developing a plug-in here that gets loaded into a Qt based application which for sure has an instance of QApplication :-). So my QDialog did'nt seem to see the QApplication that was there. Checking QApplication::instance() returned a null pointer, which is no good of course. Reading another post in this forum pointed me in the right direction, I was linking against another version of Qt (4.6, ts3 seems to use 4.5.3). It seems some global stuff like QApplication of the ts3 application is unavailable from the plug-in when you do that, probably just static class variables stored in some different place. However, after alot of fiddling, I got my plug-in to link against the correct Qt libraries (the ones from the app bundle) when it's loaded by ts3. Nasty console warnings about different Qt versions available at ts3 startup disappeard, so this seems fine. And even better, I can now 'see' the ts3 client's QApplication from within my plug-in's code using QApplication::instance().

    Still I cannot do much. When launching my plugin configuration dialog from ts3's plugin window, ts3 crashes like this:

    Code:
    qapp pointer: 0xbffff5ac
    QPixmap: It is not safe to use pixmaps outside the GUI thread
    QPixmap: It is not safe to use pixmaps outside the GUI thread
    Bus error
    The relevant code is only trying to create an instance of my dialog:

    Code:
    /* Plugin might offer a configuration window.I f ts3plugin_offersConfigure returns 0, this function does not need to be implemented. */
    extern "C" void ts3plugin_configure(void* handle) {
        printf("qapp pointer: %p\n", QApplication::instance());
        configDialog *dialog = new configDialog();
        //dialog->exec();
        //dialog->show();
    }
    Bottom line, ts3plugin_configure hook seems not to be called by the Qt main thread, which disallows any use of Qt functionality that could be painting something, i.e. my dialog :-).

    So, what am I doing wrong? Am I not supposed to use Qt in this hook? But what else?

    And whats void* handle pointing to? :-)

    Thanks in advance for any hints.
    Last edited by ch4llenger; January 12th, 2010 at 08:14 PM. Reason: corrected code copy paste mistake

  2. #2
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    The QApplication instance should be accessible via the qApp macro. When we tested a Qt widget inside a plugin, we could access qApp just fine. But that was the same Qt version (just the one installed on my dev box where I built the client as well). So yes, Qt version mismatch can be a problem. But, as you already pointed out, as we deploy the Qt shared libraries, people can link against ours to avoid this issue.

    Next, the plugin configure function is indeed called from a QThread. We had changed it this way because our volumecontrol plugin opens a Windows dialog which would block the Qt event queue, so it has to be opened from a thread. However, for Qt dialogs this is bad as Qt wants to paint its widgets from the main GUI thread, not an own thread. As we cannot abandon to run configure from an own thread completely for Win32 windows (and possibly other UI systems?), I would currently consider the best solution to let the plugin decide if it wants to run configure in a thread or not. Perhaps via:

    ts3plugin_offersConfigure
    - return 0 -> no configure dialog
    - return 1 -> run as own thread
    - return 2 -> run in Qt GUI thread

    Then a Qt plugin like yours would return 2 and things should be fine.

    A Qt demo plugin might be an idea, but I don't know if I manage to get that done before next client release.

    EDIT: Forgot to mention: The void* parameter is the window handle of the plugin dialog, required for Win32 based dialogs. For Qt dialogs you can ignore it.

  3. #3
    Join Date
    January 2010
    Location
    Switzerland
    Posts
    6
    Peter,

    thanks for your reply.


    Quote Originally Posted by PeterS View Post
    The QApplication instance should be accessible via the qApp macro. When we tested a Qt widget inside a plugin, we could access qApp just fine. But that was the same Qt version (just the one installed on my dev box where I built the client as well). So yes, Qt version mismatch can be a problem. But, as you already pointed out, as we deploy the Qt shared libraries, people can link against ours to avoid this issue.
    Yeah, that part is absolutely solvable, though maybe it'd make sense to document this somewhere to safe other people from going through the hassle.


    Quote Originally Posted by PeterS View Post
    Next, the plugin configure function is indeed called from a QThread. We had changed it this way because our volumecontrol plugin opens a Windows dialog which would block the Qt event queue, so it has to be opened from a thread. However, for Qt dialogs this is bad as Qt wants to paint its widgets from the main GUI thread, not an own thread.
    Everything starts to make sense, even _why_ you did it like this :-). Thanks for the clarification.


    Quote Originally Posted by PeterS View Post
    As we cannot abandon to run configure from an own thread completely for Win32 windows (and possibly other UI systems?), I would currently consider the best solution to let the plugin decide if it wants to run configure in a thread or not. Perhaps via:

    ts3plugin_offersConfigure
    - return 0 -> no configure dialog
    - return 1 -> run as own thread
    - return 2 -> run in Qt GUI thread

    Then a Qt plugin like yours would return 2 and things should be fine.
    Sounds like a decent plan. Is there a feature/bug request somewhere to track this? Or is it just going to be in the next beta release?

    IMO you should really make it possible to use Qt for the plugin configuration dialog, because some developers like me assume Qt is the best or preferred choice since TS3 is using it itself. Maybe you should even encourage developers to use Qt for plugins, as other UI frameworks are most likely not cross-platform or end users lack the libraries because they're not distributed with TS3. It being available on 3 operating systems including Mac is just great, would be a pitty if all plugins written end up being windows only, just because Qt dialogs are unusable. Though I have to admit mine will be Mac-specific despite using Qt because talking to iTunes is quite platform-dependent ;-).


    Quote Originally Posted by PeterS View Post
    A Qt demo plugin might be an idea, but I don't know if I manage to get that done before next client release.
    Would be a good thing, but could be quite a lot of work depending on how much you want to cover on the Qt side. I might make my plugin opensource once its finished, but that will take some time too :-).
    Last edited by ch4llenger; January 13th, 2010 at 08:46 AM. Reason: corrected typo

  4. #4
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Sounds like a decent plan. Is there a feature/bug request somewhere to track this? Or is it just going to be in the next beta release?
    It's not in our bugtracker, but I've just implemented it like suggested above, so it will be in the next beta release. For your plugin you have to wait, I'm afraid, as the new plugin SDK will not be compatible with current beta9 client (because of other changes, not this one).

    The new function in our test plugin:
    Code:
    /* Tell client if plugin offers a configuration window. If this function is not implemented, it's an assumed "does not offer" (PLUGIN_OFFERS_NO_CONFIGURE). */
    int ts3plugin_offersConfigure() {
    	printf("PLUGIN: offersConfigure\n");
    	/*
    	 * Return values:
    	 * PLUGIN_OFFERS_NO_CONFIGURE         - Plugin does not implement ts3plugin_configure
    	 * PLUGIN_OFFERS_CONFIGURE_NEW_THREAD - Plugin does implement ts3plugin_configure and requests to run this function in an own thread
    	 * PLUGIN_OFFERS_CONFIGURE_QT_THREAD  - Plugin does implement ts3plugin_configure and requests to run this function in the Qt GUI thread
    	 */
    	return PLUGIN_OFFERS_NO_CONFIGURE;  /* In this case ts3plugin_configure does not need to be implemented */
    }
    IMO you should really make it possible to use Qt for the plugin configuration dialog.
    Yes, Qt should be working for plugins. I agree it's a good choice, but we don't want to tell people what to use for their plugins. That's up to the plugin authors. My task is to make the plugin system work, what people are doing with it is their decision. Plugins with Qt for all platforms? Great. Win32 API or even .Net for Windows only stuff? Cool. Cocoa with AppleScript support for Mac? Killer! Possibilities are endless. I'm eager to watch what kind of plugins people will come up with during the next months.

  5. #5
    Join Date
    January 2010
    Location
    Switzerland
    Posts
    6
    Quote Originally Posted by PeterS View Post
    It's not in our bugtracker, but I've just implemented it like suggested above, so it will be in the next beta release. For your plugin you have to wait, I'm afraid, as the new plugin SDK will not be compatible with current beta9 client (because of other changes, not this one).
    I can wait. Thanks a lot!


    Quote Originally Posted by PeterS View Post
    Yes, Qt should be working for plugins. I agree it's a good choice, but we don't want to tell people what to use for their plugins. That's up to the plugin authors. My task is to make the plugin system work, what people are doing with it is their decision.
    Absolutely. I wasn't saying you should force anyone into using Qt, just encourage them e.g. by providing examples. If you don't depend on OS specific libraries/frameworks for your plugin and you write the plugin in C/C++ as opposed to ObjC, C# etc., Qt for the config dialog is simply the best way to maintain portability.


    Quote Originally Posted by PeterS View Post
    Plugins with Qt for all platforms? Great. Win32 API or even .Net for Windows only stuff? Cool. Cocoa with AppleScript support for Mac? Killer! Possibilities are endless. I'm eager to watch what kind of plugins people will come up with during the next months.
    Yeah, I hear you, my plugin is using AppleScript through Carbon to control iTunes volume. Very easy, and yes possibilities are endless :-).

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. ConnectServer void Errors
    By TheAppService in forum Client Plugins / Lua Scripts
    Replies: 8
    Last Post: November 6th, 2014, 05:50 PM
  2. TS Ban ( Without that you can handle this )
    By Acetylcholin in forum General Questions
    Replies: 3
    Last Post: November 8th, 2012, 01:42 PM
  3. Handle leak
    By Paril in forum Client Support
    Replies: 13
    Last Post: March 20th, 2010, 11:23 PM
  4. ts3plugin_configure(void* handle)
    By Fraq! in forum Client Plugins / Lua Scripts
    Replies: 2
    Last Post: December 23rd, 2009, 04:31 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •