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

[Paweł Prażak]

Hi All!

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.

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

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

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

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

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

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

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

Best regards,
Paweł