Re: [linux-audio-dev] Visual plugins again...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Visual plugins again...
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Apr 12 2001 - 23:54:29 EEST


>If you see in TheKompany link mentioned, you will note that this system is
>platform and toolkit less...
>They won't intended to be used just in KDE/QT environment. By the way, are
>samples for Microsoft Windows, BeOS, AtheOS, showing that can be used
>anywhere.

No, you don't get what I mean. You can't use multiple X Window
toolkits from the same app (without some really ugly hacks to each
toolkit concerned). So whichever version of kodelib you chose to use
would have been compiled for a particular toolkit. If you tried to use
a plugin that used a different toolkit than the version of kodelib that
the plugin host was compiled with, then you're stuck.

For our purposes, their example is stupendously empty. It doesn't
provide any idea of how a GUI-using plugin would interact with the
host (though from their screenshots, such things obviously
happen). Thats the area where our discussions have been focused, and I
don't see anything here, either in actual code or their design
description, that would help with any of these problems.

>My whole point is that could be an good middleware to anywone write GUI
>independent plugins. Big part of discussion are always involving GUI and
>religious-person like GUI's... This really doesn't matter, the main target is
>easily interoperate between Application and plugin. Which way the plugin are
>"cartoon" drawed, or even a deamon is a plugin developer worry...

Sorry, but this a fantasy right now. As long as the event loop used to
handle X events is toolkit-specific, this kind of interoperability is
never going to be straightforward or easy to work with.

the kodelib stuff for plugins actually addresses a very tiny area,
which is loading, accessing and unloading plugins. this is hardly a
problem area for anyone right now, least of all people with a
committment to Linux rather than "every OS under the sun". yes, the
idea of a platform-independent API for that is nice, but its just
another API to go along with libtool's ltdl, glib's gmodule and
several others.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Apr 13 2001 - 00:22:46 EEST