[rekonq] NO MERGING ISSUES

[Paweł Prażak]

>
> About bookmarks questions, my idea is to refactor rekonq bookmarks system
> in
>  this way:
> - create a separate dir for bookmarks tab (like Arora), not exposing ALL
> bookmarks.


Sorry but I don't understand, maybe show us some code proposal, a sort of
draft implementation or please try to write more about it.


> - support KDE bookmarks:/ protocol
> For me the second should be right alternative to bookmarks sidebar.


this is nontrivial work, it would depend on major refactoring of the tabs
subsystem (which is planned because mainview is a "maintainability
nightmare"


> About download class... I'm going to review again your code ;) Perhaps I
> pulled some half works, really cannot think some other...
>
> rekonq isn't (and has not) a download manager. It just can (obviously)
> start
> file downloading. And creating a new instance of download class is (for me)
> the
> right way of doing so.


This is not so simple. You start the download and what?
When you close the app it still runs in the background (because of
downloads) and when you start it again it crashes without proper handling
(which I solved by some nontrivial debugging and global fixes). And above
the all, modular code is easier to use, maintain, test and debug.
You can't just create object and forget about it, this isn't Java. You have
to track the ownership of the object and delete all objects that are owned
by your classes or you'll introduce another memory leak. And to do this you
have to track(manage) your download objects and for this you need download
manager (it's a container).
And what if user cancels the download in KDE notification? You still have to
delete the object.
And what if there was error during download? etc...