[rekonq] rekonq 1.0 approaching: TODO List

[andrea diamantini]

Hi all,
after another fantastic development period for our favourite browser, we are
approaching our 1.0 release, that it seems going to be a very important one
:)
According to our schedule (http://techbase.kde.org/Projects/rekonq/Schedule),
that we promised to respect for this release, we have:
- August, 20: feature freeze && beta release
- September 12: rekonq 1.0 release.

The most important thing to notice now is that we have feature freeze in 3
days. I'd really like to schedule now ALL the things that we are working on
that could be merged for that date. I'd like having the most possible
collaboration to test everything BEFORE deciding if its time to merge it or
it could be better wait some time for the next development period.

Here is the jobs schedule:

1) History Review
I made a branch about this (
http://gitorious.org/rekonq/mainline/commits/HistoryReview2). PLEASE, test
it and let us know if it works well. Debating about it with Lionel, I found
an interesting optimization for our history management based on History
items offset position. We now have just ONE QList to store all items and ONE
QHash<QString, int> for the history searches. This is based on Ben Meyer
first work on history management.

2) OpenSearch engine
Lionel started implementing an opensearch engine for the urlbar. I cleaned a
bit code and pushed it in one branch in master. Here you are (
http://gitorious.org/rekonq/mainline/commits/opensearch). It is based (for
1.0) on Google suggestions, but it will work with every engine. Please, TEST
IT and let us know if you find it good for a merge.

3) Drag & Drop for the bookmark toolbar
It's merge request #173 from Yoann. It's an "incomplete" feature (it works
just with root items now), but I'm sure Yoann can fix &&/|| improve it quite
soon. And if it works well, we can merge it also in this state.

4) bookmark icon:
rekonq 1.0 will have a bookmark icon in the urlbar. Yoann implemented it and
it seems working pretty well. The problem is about the bookmark icon
position. On the right, following 0.5 scheme or on the left, substituting
urlbar favicon, as it is in master now? NOTHING has been decided yet, I just
followed Pano's suggestion about merging it now and waiting for people
comments.

5) Favicons
We all know favicons don't work well now. But in my opinion, we have 2
different problems with them. First is about usual site favicons, that don't
work well because QWebSetting cache does not. It is a QtWebKit bug and it
has to be fixed there. Second is about search favicons (the ones we DON'T
see in the search item of the urlbar suggestions). Those favicons IMHO have
to be cached separately and rekonq should do it on its own. I just debated a
bit about it with shadeslayer, but I decided to postpone it, because the
OpenSearch feature requires a SearchEngine class review that has not been
merged yet.

6) KDE SC 4.5, Qt 4.7, QtWebKit 2.x deps
I postponed this waiting for Qt 4.7 stable release, but now I fear we'll
release our next stable before Qt, so...
rekonq 1.0 has to depend at least on the combination QtWebKit 2.0 - KDE SC
4.5. They both contain important fixes for us, also if the code can be (yet)
compiled on previous platforms. I need to ensure this before 1.0 beta
release to let people test it in the right conditions.

7) Your unknown feature/job for 1.0
If you are working on something and you think it can be ready for 1.0,
please let us know ASAP.

So, this is the plan.
Please, spend one hour this afternoon, compiling and testing these three
branches (historyreview, opensearch, mr173) and reply here writing a small
comment about and about your opinion on the bookmark icon position and (if
you have one) on rekonq deps.

Have a nice day,
Andrea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20100817/7c173995/attachment.htm