Review Request: Implementation of KPart listing notification extension for Dolphin

[Frank Reininghaus]

> On Sept. 6, 2012, 12:47 p.m., David Faure wrote:
> > dolphin/src/dolphinpart.cpp, line 718
> > <http://git.reviewboard.kde.org/r/106333/diff/1/?file=83835#file83835line718>
> >
> >     IMHO this is worse than a DolphinView::fileItemModel() method, because it will break at runtime rather than at compile time.
> 
> Dawit Alemayehu wrote:
>     Well, I doubt the Dolphin guys would allow the addition of such accessor function to the public API of DolphinView. The reason why I am taking this approach in the first place is because they did not like the idea of having new signals added to KFileItemModel and DolphinView. See the discussion @ https://git.reviewboard.kde.org/r/106289/.
> 
> David Faure wrote:
>     I know, and I'm telling them (and you) that either they'll have to accept an accessor (or signals), or you'll have to find another solution. A dynamic object retrieval is a *worse* solution than an accessor, I'm completely against it, it just makes things more fragile.
>     
>     The equivalent, less fragile, solution would be a private accessor and making DolphinPart a friend. This way it's not public API that will get used elsewhere, but at least the compiler will tell us when it breaks again.

I'm against signals and public accessors, but the 'friend' solution looks OK. A private accessor is not really needed because DolphinPart can just access m_view->m_model directly then.

Please add a comment that explains why it needs to be a friend (for examples, do 'grep "friend class" * -r' in Dolphin's source).


- Frank


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


On Sept. 5, 2012, 4:33 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106333/
> -----------------------------------------------------------
> 
> (Updated Sept. 5, 2012, 4:33 p.m.)
> 
> 
> Review request for Dolphin and KDE Base Apps.
> 
> 
> Description
> -------
> 
> The following patch implements the new KParts listing notification extension in Dolphin. This implementation does not add new signals to KFileItemModel and DolphinView classes as the previous solution. Instead it relies on the QObject's introspection to look for KDirLister and connect to the desired signals. 
> 
> This solution is based on the "hack" that was originally implemented in the directory listern plugin. However, unlike that implementation, this one will not suffer from sudden and unexpected changes in Dolphin's code changes because it is closer to the source and it looks for the directory lister directly in KFileItemModel. This is something that cannot be done at the plugin level because it would require the plugin to link against dolphin.
> 
> 
> Diffs
> -----
> 
>   dolphin/src/dolphinpart.h f9c0bbf 
>   dolphin/src/dolphinpart.cpp bf3d2a5 
> 
> Diff: http://git.reviewboard.kde.org/r/106333/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120906/995ec636/attachment.htm>