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

[Paweł Prażak]

On Wed, May 13, 2009 at 1:42 AM, Andrea Diamantini <adjam7 at gmail.com> wrote:
> 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.

By "hell of a lot" I meant that there are 'many' regressions and
missing features in mainline.

Like e.g.
- the tabs don't display favicons and close buttons well (and close
button is from Qt not KDE),
- search bar and navbar are not even,
- pages are to small again,
- new tab close tab buttons are missing along with appropriate settings,
- there is add new tab button in main tool bar by default and this is ugly
- zoom feature doesn't work as it should:
    - crtl+= and ctrl+_ shortcuts missing,
    - zoom text only option is missing from the view menu,
    - zoom actions should be zoom in/zoom out/normal zoom(or actual size),
- search bar bugs that I've fixed are missing too:
    - suggestion shows up when user lost his interest in in searching,
    - ctrl+k doesn't work
    - users previous search terms are cleared on focus in
    - when user focuses in but looses his interest in searching and
focuses away without searching he looses his previous search terms as
well,
- f6 doesn't work again
- history menu shows up after help menu as the last one
- back button doesn't have a menu again
- there are no unit tests and there is no support for them either

...and this is only the obvious stuff that I see in first 5 minutes of
using the rekonq and I remember fixing them and in terms of LOC those
are cosmetic changes from coding POV, but big improvements for the
overall look and feel. There's probably more.

It's a bit discouraging when you puts a lot of effort to do something
and you don't see effects.

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

I understand your point, but please remember that kparts is just a
tool, it's up to us how we'll use it. We don't have to make bloated
browser just because someone did it. ;)

> They are really perfect for konqueror, giving it an incredible power.. But
> they are not really "browsing oriented".

Kkparts not, but webkitkde kpart is browser oriented.

> And they are a really an heavy dep.
heavy dep.?
> So, why should we adopt kparts, if we can do quite the same without them?

As I just said, it would provide us better modularization, allow us to
focus on making users experience better instead of fighting with 'the
plumbing', it would allow better reusability of the code in KDE and
would be beneficial for the whole community. There is code in
webkitkde part that we would have to write anyway and making changes
upstream, konqueror users would be happier as well. It also means more
testing for the major component of the browser.

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

Yes separate group would be sufficient, but than we would lost the
Konuerors bookmarks parity.

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

I'd like to avoid adding anything to toolbars. Users if they like they
can add as many bottons as the want but by default there should be as
little as possible IMHO.

About the action, I'd like to avoid adding steps to the process - it
makes users experience worse. We can implement drag and drop - that
would be best of both worlds IMHO.

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

Thanks, I'd love to, but as for now I don't have enough spare time. :(

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

We can make settings dialog with options open/save/ask but making
separate mime types settings is bad idea, we want to integrate with
KDE as much as possible (and that's why KDE is so cool - integration),
but we can expose system settings in our settings to make users life
easier. I suppose there is corner case when user want to open
something in something different than usual, but  for this we should
provide context menu option like 'open with' or 'actions'.

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

--
Paweł