[rekonq] NO MERGING ISSUES

Andrea Diamantini adjam7 at gmail.com
Sun Apr 19 08:27:43 CEST 2009


On Saturday 18 April 2009 13:33:49 you wrote:
> > 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.


You can just take a look at Arora bookmarks menu, with a separate dir 
containing all the bookmarks to be stored in the bm tab

> > - 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"

Support for bookmarks:/ protocol (and for all other kioslaves) will come with 
next version, porting rekonq to WebkitKDE.

Can you pls write some about this mainview "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...
>
> From that KIO::job we can link to (and just do it) to KDE notification
>
> > system,
> > to kget or to every other download manager supporting KDE technologies.
> > It's fast, simple and safe. So (again), what's better?
>
> IMHO always the best solution is to follow the convention ("Convention over
> configuration" principle) and established convention is to "handle
> download" (that's what user cares of - "I want to download it and I don't
> care how it is implemented")
> Most browsers ask user what to do with the download (open/save as...), and
> then opens stuff for them (if they wanted).
> And this is great because I can install application (openSUSE 1-click
> feature) just by clicking on the link (this is something that firefox can't
> do because it doesn't integrate with the environment) and this is something
> that download manager provides.

This is definitely true, mainline/master download system is bugged, I'm going 
to fix it with your suggestions.

> So rekonq have to have some sort of downloads manager.
> To stay lightweight we can make simple icon/button in (for e.g lower-right
> corner) witch would appear only when there are downloads (completed or
> active) along with number of downloads (active/completed).
> If clicked it can show thin downloads bar on the bottom (sort of like
> firefox plugin), but I'm not entirely convinced with this idea since we
> want to integrate with KDE notifications system.
> Alternatively we can try to call KDE notification by DBus to show itself.
>
>
> And to add something form myself, we need to write a lots of unit tests, to
> test automatically at least 50% of the code. And to add regression tests
> (especially for issues, to have a rule: "new bug fix committed = new
> regression test committed", this would be off course ideal situation but if
> we'll follow this mostly it will make our lives easier). I've started to
> add tests for things I work with, but we would benefit from more unit tests
> to have sort of "safety net" while doing changes. It's part of so called
> "defensive programming".
>
> Regards

PS: please, write directly to rekonq ml, no need to write me and then CC 
there.

Regards,
-- 
Andrea Diamantini
MAIL: adjam7_AT_gmail_DOT_com
WEB: http://www.adjam.org
IRC: adjam_AT_freenode
PGP/GPG : 91A712C1
Fingerprint: 571E DFF4 19EF A597 2CCD A811 6CB6 3538 91A7 12C1

tadarattadara tattà tatatatatà tadarattadara tattà tattattattattà..
(me, taking a shower...)


More information about the rekonq mailing list