linuxaudio.org

--0016363b9bf89b8dae0489142091

Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 15, 2010 at 7:34 AM, Paul Davis wrote:
> On Tue, Jun 15, 2010 at 3:49 AM, Jeremy  wrote:

quoted text
>

> > Hi,

> > So I've written a GUI, and I've gotten a better understanding of how the

> Qt

> > framework works.  It seems to me that all that would be necessary is for

> the

> > host to pass a pointer to a QWidget, which the plugin adds itself to, and

> > the rest can behave exactly like the ui:GtkUI.  If I'm not mistaken, all

> > that would be necessary it to write a new rdf file.

>

> far from true. That would be enough to make the GUI work in a Qt host.

> But the problems of making it work in a GTK host, or vice versa,

> making a plugin using ui:QtUI work in a Qt host, would remain.

>

> torben, dave and i had some detailed discussions on IRC recently about

> some new ideas on how to make this work, but i don't think its easy

> and its not likely to appear any time soon.

>

> nothing like the plethora of choices implied by open source

> development to royally screw up basic things.

>

How about this idea?  The plugin is responsible for creating its own window

if the host doesn't know how to do it.
So for example 1, a Qt application looks at the rdf and sees it is a Qt GUI.

 It opens up a new internal frame, and calls the plugins intantiation

function.
example 2, a Gtk application looks at the rdf file and sees it is a Qt GUI.

 It calls the plugin's "createWindow" method, which creates a standalone

window to host the widget, and returns the necessary callbacks.  Then the

host calls the plugin's instantiation function with the newly created window

as an argument.
This way I can create a new toolkit and it will work with any existing

(well, after this is implemented) host, but be non-integrated.  It also

allows tight integration with hosts in the right circumstances, where it

might be very useful (Qt GUIs in LMMS for example).  It would even allow the

qtg or gtq embedding to be easily implemented at a later point and work with

the existing system.
This has all the benefits of an external UI, and all the benefits of an

internal UI (when possible).
Jeremy
--0016363b9bf89b8dae0489142091

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Tue, Jun 15, 2010 at 7:34 AM, Paul Da=

vis <pau=

l@linuxaudiosystems.com> wrote:
On Tue, Jun 15, 2010 at 3:49 AM, Jeremy <jeremybubs@gmail.com> wrote:
> Hi,

quoted text
> So I've written a GUI, and I've gotten a better understanding =

of how the Qt

quoted text
> framework works. =A0It seems to me that all that would be necessary is=

 for the

quoted text
> host to pass a pointer to a QWidget, which the plugin adds itself to, =

and

quoted text
> the rest can behave exactly like the ui:GtkUI. =A0If I'm not mista=

ken, all

quoted text
> that would be necessary it to write a new rdf file.

far from true. That would be enough to make the GUI work in a Qt host=

.

But the problems of making it work in a GTK host, or vice versa,

making a plugin using ui:QtUI work in a Qt host, would remain.
torben, dave and i had some detailed discussions on IRC recently about

some new ideas on how to make this work, but i don't think its easy

and its not likely to appear any time soon.
nothing like the plethora of choices implied by open source

development to royally screw up basic things.

How about this idea? =A0The plugin is responsib=

le for creating its own window if the host doesn't know how to do it.So for example 1, a Qt application looks at the rdf=

 and sees it is a Qt GUI. =A0It opens up a new internal frame, and calls th=

e plugins intantiation function.
example 2, a Gtk application looks at the rdf file and =

sees it is a Qt GUI. =A0It calls the plugin's "createWindow" =

method, which creates a standalone window to host the widget, and returns t=

he necessary callbacks. =A0Then the host calls the plugin's instantiati=

on function with the newly created window as an argument. =A0
This way I can create a new toolkit and it will work wi=

th any existing (well, after this is implemented) host, but be non-integrat=

ed. =A0It also allows tight integration with hosts in the right circumstanc=

es, where it might be very useful (Qt GUIs in LMMS for example). =A0It woul=

d even allow the qtg or gtq=A0embedding=A0to be easily implemented at a lat=

er point and work with the existing system.
This has all the benefits of an external UI, and all th=

e benefits of an internal UI (when possible).Jere=

my
--0016363b9bf89b8dae0489142091--