[rekonq] NO MERGING ISSUES

Andrea Diamantini adjam7 at gmail.com
Sun Apr 19 17:36:30 CEST 2009


On Sunday 19 April 2009 10:38:33 Paweł Prażak wrote:
> 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?

As avaddon understood me in a while, I think I was so much clear. You asked me 
about and I explain in different words. Wouldn't be easier to just say "Ok, 
thanks" ?

> > > > - 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 :(

As before, there's no really meaning to be offensive. I just asked your opinion 
about. 
It's quite strange asking for a better mailing list communicative and 
maintaining this behaviour.

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

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