Re: [Protux-devel] reimplementation of GlobalProperties

[Luciano Giordana]

On Thursday 16 January 2003 06:54 pm, Martin Herren wrote:
> On Thu, 16 Jan 2003 15:02:42 -0200
>
> Luciano Giordana <address@hidden> wrote:
> > > ok, it's implemented know and seems to work fine. i'm thinking about
> > > additionally let MustuxGlobalProperties emit a signal when a specific
> > > key changes... so you can get notified in a more QTish way when a key
> > > changes, and that won't required to have static callback functions.
> >
> > That is good. I had many problems with static callbacks (remember
> > Reinhard ;-) in 2001
>
> hope there will be less here !
>
> There is just a small problem with using signal and slots with
> MustuxGlobalProperties: only objects derived from QObject can emit and
> receive qt-signals, but MustuxGlobalProperties is not a class. So i see 2
> solutions:
>
>  - make MustuxGlobalProperties a class derived from QObject. This means
> also that there won't be any more static functions to access
> MustuxGlobalProperties, but you'll have to call a member function of an
> object of this class. Of course the pointer to this object will be declared
> global. So the application using Mustux will have to instanciate such an
> object at the begining (instead of the current init(), which will be
> performed by the constructor). (application code will have to do a
> properties->set() instead of a MustuxGlobalProperties::set())

it is a good solution, we could even have a public object inside every 
MustuxApplication that
is exactly the MustuxGlobalProperties object. When construction 
MustuxApplication, it would
instantiate a MGP automaticaly. The application would normally init it as you 
suggested last email.


>
>  - keep all function of MustuxGlobalProperties static, and deriving the
> internal class KeyData from QObject. This would need a new
> MustuxGlobalProperties function: get_keydata(QString key), so that the
> application can connect to it. Furthermore KeyData must then be declared in
> a header file, but i prefere keeping this whole class private.

> So i recommend the first solution, as it's more clean, and from the
> application perspective it will also be easier to use. And there is only
> one step required to connect to it (connect), instead of two (get_keydata
> and connect).

mee too. Since MGP is a low CPU consumer engine, there is no problem in beign a 
object.
Mixer will be a single and public object too, since it must be a Q_OBJECt and 
be commonly
accessed by all Track objects. So, I see no problem is making MGP a common 
public object.

There is another reason for that. If we have two instances of protux running, 
or 2 mustux applications
running together, it will be easier to make them communicate between them if 
MGP are different object for each one.

Regards