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

[Andrea Diamantini]

On Wednesday 13 May 2009 09:04:31 you wrote:
> 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ł

Thanks for your fast answer, Pawel. I surely wanna debate these things with 
you (an "the others", of course).
And continue rekonq dev altogether. There are surely some "regressions" due to
my fault and a little bit communication failing. Anyway rekonq will not stop 
with 0.1 release, so we can surely fix things, debating them or dividing area 
responsibility.
I'll be one (or two) days out for work. I'll try replying better during the 
lunch break.

Have a nice day,
-- 
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