[rekonq] NO MERGING ISSUES

[Paweł Prażak]

On Sun, Apr 19, 2009 at 8:27 AM, Andrea Diamantini <adjam7 at gmail.com> wrote:

> 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


OK, I know what you mean. You want bookmarks bar's bookmarks to be shown in
bookmarks menu as a separate folder. Wouldn't be easier if you just write
what you mean?


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


What porting? And what WebKitKDE? Do you mean webkit KPart? I hope this is
nontrivial task and If we want to use KPart we need rewrite lots of code. I
was thinking about this, but until I take a look at the code I can't tell
how difficult it would be and in what shape it is (as far as I see in
Konqueror it's in terrible state, but isn't maybe because of that the KDE
4.2 is compiled against Qt 4.4 AFAIK). Generally I think this is a good idea
to give it some thought and it would benefit the community, but as I said,
we need to investigate this further and if we want this, we need to start
now, there is no sense of doing refactoring and then delete the code and
write again. :F


> Can you pls write some about this mainview "maintainability nightmare"?


Have you seen the MainView code? Have you seen changes I started to make?
How can I explain to you that the code the class is bloated? Try to make UML
diagram of the class hierarchy.
It need to be divided in to classes, refactored to DRY to achive bette
encapsulation and maintanability, so it would be easier to test and debug.
If you don't know what I'm talking about than there is now way I could
eplain it to you, sorry :(


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



Those are not suggestions, but facts, issues that had been alredy adressed
by avaddon and me, so no need for fix (other than bugs we missed or
introduced by accident)


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


This is default GMail behaviour and usualy I'm to lazy to change it... ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20090419/5d278bf7/attachment.htm