[Mythtv-soc] Config-revamp update Jun 30,2006

[Justin M. Hunt]

----- Daniel Kristjansson <danielk at cuymedia.net> wrote:
> On Fri, 2006-06-30 at 21:38 -0400, Justin M. Hunt wrote:
> > Hi everyone,
> > This week I've continued getting the advanced & expert modes
> working,
> > I am almost ready to commit the advanced mode and framework for
> expert
> > mode.  Right now I'm battleing QT's signals and slots, when I
> change
> > anything something else breaks, so its very slow going.   I should
> have
> > advanced mode commited tonight and expert by tuesday next week.  
> 
> Yikes, I should have told you about the Qt problems in
> settings.{h,cpp}
> 
> There are certain rules you need to observe when using QObject
> which are not observed by many classes in settings.{h,cpp}
> 
> * Multiple inheritance can never include more than one class
>   derived from QObject. When multiple inheritance is used,
>   the one QObject derived class must be first.
> * Virtual inheritance of QObject derived classes is also verboten.
> 
> Neither the compiler nor moc will stop you from doing this, but the
> signals will be sent to the wrong places or you will experience
> random
> core dumps as Qt writes to random parts of memory. So basically part
> of the UI rewrite has to include fixing these problems (otherwise
> you are in for a world of pain).
> 
> There are other rules, see:
>   http://doc.trolltech.com/3.1/moc.html
> But I think we are OK with respect to the other ones. There are rules
> not in the moc gotchas page, such as not allowing the use of "delete"
> directly on QObject derived classes outside the Qt event thread, and
> requiring you to remove all incoming signals not originating in the
> Qt event thread before calling deleteLater() or allowing Qt to call
> deleteLater(), as it does for you when tearing down the UI.
> 
> ===
> 
> To everyone, no Qt classes are thread-safe, except for QMutex and
> friends. This includes QString and other Qt container classes like
> QMap. To pass a QString or other Qt container classes between threads
> you must use QDeepCopy or convert them to some non-qt data type as
> an intermediary step in assignment.
> 
> Some methods on some classes, such as QRegExp, are reentrant.
> This meaning that multiple threads can use the method, so long as it
> is impossible for another thread to change the underlying class while
> a reentrant method is running. Other methods in the same class may
> not be reentrant, for example QRegExp has other methods that are
> both non-threadsafe and non-reentrant. If one of these methods is
> running, no other method of the class, including reentrant ones, can
> be running in another thread.
> 
> Since MythTV is a highly threaded application, this is something
> to keep in mind whenever you use Qt classes. Also when you look
> at Qt the documentation, look at Qt 3.1 documentation. Some problems
> with thread-safety and reentrancy have been fixed in later editions
> of Qt, plus there may be additional methods in later versions which
> you can't use.
> 
> -- Daniel
> 
> _______________________________________________
> mythtv-soc mailing list
> mythtv-soc at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-soc

Hey Daniel,

I did find this information in my quest to get things working, turned out 
the majority of my problems were caused by a missing virtual keyword.  Once 
I got that in and had the dialog redraw properly (hide() doesnt do what I 
thought it would...)

Anyway, now I need to come up with a expert interface and get all the settings
implemented.

Cheers,
Justin