Re: [QDVDAuthor-devel] QDvdAuthor and Qt4 again
Brought to you by:
qdvdauthor
Menu
▾
▴
Re: [QDVDAuthor-devel] QDvdAuthor and Qt4 again
|
From: Varol O. <va...@mo...> - 2010-08-19 12:10:57
|
ZSolt,
Let me think a bit more about adding a new branch. I still think simply
using a new repos mihgt be an easier way forward. My development effort
has slowed down and I don't think there will be too much to eventually
port over to the Qt4.x branch. Mostly bug fixes.
The reason for m_waiter is to enforce the protocol between qrender (
thankfully already in Qt 4 ) and QDVDAuthor. So in that sense it is not
so much a MT issue as an IPC issue.
The lock / unlock is there or the MP ( Manager and the Clients ), though
the Clinet::m_mutex only protects m_fProgress, not sure this is all that
important.
At line 847, the waiter is actually just waiting for the file to be
trnasferd ( CLIENT_TAKE_A_FILE ). This will cause qrender to respond
with SERVER_GOT_A_PIECE, which is handled in Client::socketReadyRead and
calls receivedFileAck and sendNextPacket.
Once the server receives the whole file it will issue an
SERVER_MY_STATUS_SIRE message which will execute receivedServerState,
and then call m_waiter.wakeAll()
At this point line 847 will continue ...
AS A NOTE: I have been playing a lot with ZeroMQ lately and I like the
approach and the fact I would not have to wory so much about the lower
level stuff. Simply sending a message and waiting for a response is so
much easier and will be so much more reliable ... So maybe at some point
I'll replace this part with ZeroMQ ...
On 08/19/2010 04:27 AM, Zsolt Branyiczky wrote:
> Hello Varol,
>
> ok, so if you wish that QDVDauthor to be ported, my effort might be not just
> waste of time :) For the time being I have plenty of time to work on it... I
> thought I was working alone, so I just downloaded the actual source
> (offline) from the repo. It can be considered as a new branch trunk made on
> 20100811 from the head. If you wish to participate in this task "actively",
> or someone wants to join and help us later, we may really start a new cvs
> branch (based on the aforementioned date) named e.g. b_Qt3to4 and we can use
> that. In this case I would copy my modifications done from 20100811 to that
> branch. Meanwhile you may also work in the head (and in other branches if
> you have more) independently, I saw that you made several commits recently.
> If the port process is finally ready, our branch will be merged to the head.
> The only disadvantage of this "starting new cvs branch idea" is that if the
> porting is somehow failed (hopefully not!), the branch cannot be removed
> from the cvs repo, it remains for ever as a garbage inside. Although I
> cannot see this so big problem, the repo consumes sourceforge's resource :-)
> If I were you, I would use this new cvs branch for the purpose of the qt4
> port. But I would never merge the final and ready Qt3to4 branch into the
> head, on the contrary I would merge the head into the ready Qt3to4 branch
> for testing. If the application runs perfectly in Qt4, I would create a new
> SVN repo and its initial source of QDVDAuthor2(?) would become the source of
> our branch.
> I have used git with my previous project named QMP3Gain, but to be frankly
> it was a one-man project, and I have used no branches there, so I do not
> have too much experiences with git. Nevertheless I was content with its
> services, I could easily use with Linux and Windows in parallel.
>
> But let me start with the first technical question! :)
>
> qdvdauthor/render_client.cpp
>
> 826 bool Client::sendFile ( QString qsFileName )
> 827 {
> 828 if ( m_pFile )
> 829 return false;
> 830
> 831 if ( m_bRemoteServer ) {
> 832 m_pFile = new QFile ( qsFileName );
> 833 if ( ! m_pFile->exists ( ) ) {
> 834 delete m_pFile;
> 835 m_pFile = NULL;
> 836 return false;
> 837 }
> 838 m_pFile->open ( IO_ReadOnly );
> 839 }
> 840
> 841 // This will kick off the sendPacket protocol until the whole file
> is transmittet.
> 842 QDataStream stream ( m_pSocket );
> 843 stream << (Q_UINT16)CLIENT_TAKE_A_FILE << (Q_UINT64)m_pFile->size (
> );
> 844 stream << qsFileName;
> 845
> 846 // This function will wait until the whole file has been sent to the
> server.
> 847 m_waiter.wait ( ); // in mSec or ULONG_MAX
> 848
> 849 return true;
> 850 }
>
> Do you know how m_waiter.wait() works in line 847? In Qt4, QWaitCondition
> has only wait method with (QMutex*, ulong) parameters. I suppose "wait"
> should run for ever, except if a m_waiter.wakeOne/All method of another
> thread pushes it over. I'm not very acquainted in parallel programming in
> Qt, without knowing how this code works exactly, I'm afraid I cannot
> introduce a new QMutex variable. By the way, there is already an m_mutex
> variable in the code, it has 2 lock and unlock methods, just it should be
> used with wait methods somehow.
>
> Regards
> Zsolt
>
>
> On 2010. 08. 19. 1:36, Varol Okan wrote:
>
>> Zsolt,
>>
>> I would love to get QDVDAuthor ported to Qt 4.x. I will support this
>> effort as much as my 'spare' time permits.
>>
>> I know of no other program that can create a DVD with a few mouse
>> clicks but yet offer as much flexibility. There are so many things that
>> could be added easily to a re-freshed version ( Like a render farm
>> through qrender, which is only missing a few additional lines of code [
>> and maybe a monitoring GUI ] )
>>
>> Just this weekend I created a DVD with over 1000 images in under 30
>> minutes ( compiling took the whole night though )
>>
>> Anyhow, I can try to set up a new SVN repos somewhere, so that I can
>> chip in when I find some time.
>>
>> Let me know what you think.
>>
>> Varol :)
>> Ps. GIT might be a better option but I would have to study up on its
>> usage first.
>>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> QDVDAuthor-devel mailing list
> QDV...@li...
> https://lists.sourceforge.net/lists/listinfo/qdvdauthor-devel
>
|