Review Request: Do not use the Tp::AbstractClientHandler to control when ft-handler should exit

[George Kiagiadakis]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102306/#review5692
-----------------------------------------------------------



src/filetransfer-control.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5076>

    KDE_ISUNLIKELY would be nice here



src/filetransfer-control.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5077>

    KDE_ISUNLIKELY would be nice here as well



src/filetransfer-handler.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5073>

    Something is wrong here. The first time that a job is started, newJob() will probably return 0 (as the initial reference count is 0), so setFinishedWithError() will be called, right?
    
    In addition, I don't really see why the else branch is needed... If this code is being executed, the handler has obviously not quit yet, so the job can be handled just fine.



src/filetransfer-handler.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5074>

    The same here



src/main.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5078>

    You could also create this object on the stack, like KApplication. It will avoid leaking the memory on exit, which will help tracking real leaks with valgrind.



src/main.cpp
<http://git.reviewboard.kde.org/r/102306/#comment5075>

    If I were you, I would move this call inside the FileTransferControl class (in the constructor), just to have it all in one place.
    
    Plus, execute this code only if persist == false


- George


On Aug. 11, 2011, 2:31 p.m., Daniele Elmo Domenichelli wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102306/
> -----------------------------------------------------------
> 
> (Updated Aug. 11, 2011, 2:31 p.m.)
> 
> 
> Review request for Telepathy and David Edmundson.
> 
> 
> Summary
> -------
> 
> To handle metadata we will need another Tp::AbstactClientHandler for streamtubes, therefore it's not good to use the FileTransferHandler class to control the whole program
> 
> This patch adds a new class (FileTransferControl) that works almost like a singleton (without using K_GLOBAL_STATIC that doesn't work for QObjects) and moves control of the flow of the program into this class.
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt 9e84a8b9d427505a8babc79713ca41f1ec223a2a 
>   src/filetransfer-control.h PRE-CREATION 
>   src/filetransfer-control.cpp PRE-CREATION 
>   src/filetransfer-handler.h 6fd6c4b19859ea41f50caec48699253b8fe6b0be 
>   src/filetransfer-handler.cpp 0e4624e46b4a702afa962dc3efcff37d4dae54ff 
>   src/main.cpp c8c52d356afe378d8839175b1f88e311b42955e6 
> 
> Diff: http://git.reviewboard.kde.org/r/102306/diff
> 
> 
> Testing
> -------
> 
> Tried file transfers (just on my laptop) still exits when it is supposed to exit.
> 
> 
> Thanks,
> 
> Daniele Elmo
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20110814/19f259fd/attachment-0001.html>