[rekonq] Re : [RFC] THE ROAD TO REKONQ 0.2

Emmanuel Surleau emmanuel.surleau at gmail.com
Wed Jul 29 00:19:41 CEST 2009


On Tuesday 28 July 2009 22:37:06 Andrea Diamantini wrote:
> On Tuesday 28 July 2009 19:19:23 Lionel Chauvin wrote:
> > Can you tell me your vision of Rekonq's futur ?
>
> Sure :)
>
> > I extrapolate you ideas, perhaps I am wrong.
>
> eh eh..
>
> Rekonq is a lightweight browser based on webkit and KDE technologies.
> For me this are the the core concepts:
> - lightweight
> - webkit
> - KDE technologies
>
> Lightweight comes first because I'm quite sure that a browser HAS to be so.
> I'm really "critic" (not sure this is right term..) with this
> plugins/extensions idea based on firefox (and Gecko) experience and
> implementation.

Well, that's the idea with plugins... if you want more functionalities, you 
add plugins. Maybe you'll end up with something bloated eventually, but 
that'll be your own fault. If you don't need additional functionalities, you 
don't install plugins. This way, the core browser can remain as lightweight as 
it needs to be.

> And I'm quite disappointed from current KDE plugin support implementation.
> There are two main (core) problems: plugins has to be loaded at startup or
> when its action is exposed and (more important) a plugin crash let
> application crash.

Are plugins necessarily C++ components? Can't they use high-level languages? 
In which case I assume it would make it easier to sandbox them.

> Anyway, apart from technical reason, I never used more than two minutes a
> firefox extension and I'd like asking you all: what is the REAL advantage
> from this plugin support? What are the really useful plugins?

Adblock, Firebug if you are in the web development department. There are tons 
of others (StumbleUpon, user agent switcher, etc...). More than anything, it's 
plugins which have made Firefox's success, because they gave it versatility 
and are relatively easy to develop (being Javascript).

And while you might not feel the need for any of them personally, there is 
clearly a need for it as Firefox demonstrates.

> Webkit is rekonq rendering engine. I'm really impressed from webkit
> escalation. And from Webkit Qt API. I'm quite sure it's just a matter of
> time it will become "standard" open source web rendering engine. 
> And prefix RE- in rekonq's name means just a re-thinking (KDE) web browsing 
aspects

Webkit is pretty good. I just wish it was a bit less memory-hungry, though...

> KDE technologies are widely used in rekonq. And rekonq will ever be a KDE
> product. There are dualism (eg: khtml vs webkit) but (for me) my ideas
> about are quite clear.
>
> ---------------
>
> This first one is the general part. About the "develop" part, I think you
> just know my ideas.
> rekonq 0.3: isolates tab processes and integrate kwallet. That's all!

I'll toss up some ideas: 
- setting an image as wallpaper from the context menu (unfortunately, Webkit 
is not very good at telling whether one is right-clicking on an image or not)
- integration with Okular to display PDFs in the browser
- integration with Dolphin for browsing FTP/Webdav
- integration with KGet for download management
- being able to open a new Rekonq window if Rekonq is already open (sometimes 
you *do* want to look at two pages side by side - also extremely convenient 
for working with multiple desktops), and moving tabs from one to the other
- "awesome bar" like Firefox (though Opera and I believe Chrome have also 
something similar) which would let you find past history entries from URL, 
title, etc... - maybe Nepomuk could help with that.

Thoughts?

Cheers,

Emm


More information about the rekonq mailing list