[rekonq] rekonq 0.2 development (and rekonq 0.1 release)

[Andrea Diamantini]

On Tuesday 12 May 2009 19:20:16 you wrote:
> Hi All!

Hi Pavel, welcome back.

> On Tue, May 12, 2009 at 12:35 PM, Andrea Diamantini <adjam7 at gmail.com> 
wrote:
> > As we are safely moved to kde svn rekonq code, fixed (quite all)
> > translations, documentation (not yet ready) is in the right place and
> > unit tests are coming, we are pretty near rekonq 0.1 release.
>
> As I see the current state of 0.1 I'm very skeptical 'bout this,
> 'cause there is hell of a lot of regressions and some questionable UI
> changes comparing to what we left in fork with avaddon. There is some
> stuff, mentioned before, missing as well.

Can you please explain what you are referring about? Anyway, I can't see any 
"hell" in rekonq here now.
 
> > This is intended to be just a 1st release to check all things are working
> > quite well and people like our job.. ;)
> >
> > rekonq 0.2 dev is going to start in these days. As promised, we need an
> > initial moment to check out our intentions and decide new feature list
> > and development plan.
> >
> > So, here are my intentions for rekonq 0.2:
> >
> > 1.
> > move rekonq to WebkitKDE. This means a major refactoring of
> > networkaccessmanager, webpage && webview classes.
>
> Actually this means that great portion of them is no longer needed, as
> kdewebkit provides this stuff. :)

Hopefully, yes!!

> > Anyway I think this is the moment to move there to really fully embrace
> > KDE technologies.
> > My idea is not to use the webkitKDE kpart component, but just the
> > inherited KWeb{Page,View} classes.
> > If someone is interested in this part of development, just ask me to
> > coordinate our efforts.
>
> To really empbrace "KDE way" we should go for the KParts, this would
> make our life easier, as there would be less code to maintain ourself
> and more code(and settings) shared with konqueror.
> First of all we would have to make a major refactoring to move rekonq
> to kdewebkit, so why not go for webkitkde (the kpart)?

Yeah, perhaps the "KDE way" was going for kparts, this is true. But it's also 
true that KDE never had a "real" browser. And that's (for me) because kparts 
are too much generic technology.
They are really perfect for konqueror, giving it an incredible power.. But 
they are not really "browsing oriented". And they are a really an heavy dep.
So, why should we adopt kparts, if we can do quite the same without them?

> I've been doing recently some webkitkde work, some debugging and
> enhancements. There are still some problems, but it would be
> beneficial for the community if we use webkitkde.
>
> Nice thing is that it would allow us to better modularize and divide
> parts of rekonq into logical blocks, and it would allow us to focus
> more on users experience and new features than about how to make
> underlying code to work and to reassemble decent browser ;)

Isn't this our passion?!

> > 2.
> > Refactor Bookmarks classes to separate bookmarks tab, providing one
> > separate folder for that and implementing bookmarks panel.
>
> Sorry, I don't understand what do you mean, Bookmark classes are on
> the back end and you've mentioned some UI/Usability changes, so I'm a
> bit lost here, could you help me out?

Yeah, sorry about that.

Bookmarks classes refactor: modify them to provide a separate group (and a 
separate storage? don't know) for bookmarks in the toolbar.
This lets us (in the UI part) to provide a separate folder for them in the 
bookmarks menu.
We also need to reimplement the "add bookmark" action to let user choose where 
saving bookmark: 
	in the usual menu-->where?
	in the toolbar
	(both?)
I'd like adding this action to the main toolbar (near the urlbar).

Hope this sounds better ;)


> > We can also add an action to
> > main toolbar, near the urlbar to add bookmarks.
>
> IMHO there's too much stuff in the tool bar already.
>
> > If someone wanna manage *ALL* this part and became the "maintainer" of
> > this code, I will be very happy about that. We can start in this way to
> > work a little bit more organized ;)
> >
> > 3.
> > remove internet search bar providing search, history and bookmarks
> > suggestions in the main Urlbar. (A-LA chrome).
> > This will improve usability a lot (for me). Comments and ideas are
> > welcome.
>
> Yes, I was thinking about it. Rewrite of UrlBar would be needed, but
> it's worth it.

So, you are 1st candidate ;)

> > 4.
> > MimeType Manager
> > I'd like to implement a sort of mimetype manager (?) as firefox does,
> > providing a list of actions for mimetype.
> > Images explain better than words..(http://imagebin.ca/view/q7rsnKH.html)
>
> KDE manages the mime types, so we can point user to system settings by
> providing easy access to it.
> Actually there is KIO for this:
> 'settings:/advanced/advanced-user-settings/filetypes'

I'm not sure I understood well, but why do we need this? Providing easy access 
to system settings means let user change global settings. We need just, for 
each mimetype, to know what user would like to do:
1. save
2. open with foo
3. open with bar
where foo && bar are applications managing that mimetype (e.g. okular for pdf 
files).
Anyway, perhaps I didn't understand well your idea.

> > Just these 4 points mean a lot of work to do. Anyway, please this is the
> > moment for suggestions, ideas, new features requests, that need to be
> > implemented before others, or just that you wanna to implement instead of
> > those here.
> > Because we are here just for fun. Aren't we?
>
> Nice thing would be to use the fact that we need to refactor some
> stuff and to rethink some parts of rekonq, to focus on nearly instant
> launch (minimize the amount of things needed on start, especially
> eliminate as much IO as possible or move to worker IO thread), to
> ensure that UI is snappy and responsive (ensure we always use
> asynchronous IO and never block UI).
>
> Modularization would be nice. We can make only 'core' rekonq code
> (basic features only) and all other stuff move to plugins/kparts. This
> way it would be easier to enchance and customize rekonq in the future
> and make possible to use it in different setups making it very
> versatile and reusable.

We could surely work on this field, yes.
Anyway, I'm working as developer on kipi-plugins, managing the gallery export
plugin stuffs and (perhaps, one day) providing a unique export plugin.
And I'm quite sure plugins are NOT a solution here.
What can really improve things is.. profiling!
And refactoring some crucial part of the code (usually, every IO action).

Multithreading support is always a good idea (and perhaps a long term goal, so 
not for 0.2 but for 0.3. Or perhaps for 0.2, we can decide..)

> Best regards,
> Paweł

Regards,

-- 
Andrea Diamantini,
rekonq project
WEB: http://rekonq.sourceforge.net
IRC: adjam_AT_freenode
PGP/GPG : 91A712C1
Fingerprint: 571E DFF4 19EF A597 2CCD A811 6CB6 3538 91A7 12C1