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

[Lionel Chauvin]

> Rekonq is a lightweight browser based on webkit and KDE technologies.
> For me this are the the core concepts:
> - lightweight
> - webkit
> - KDE technologies

Nothing new :)

> Lightweight comes first because I'm quite sure that a browser HAS to be so.

I agree with you, People when using a computer spend majority of their time on 
internet. Speed for a browser is a very important criterion. For me, 
Lightweight == Fast, not necessarly memory efficient (while it not decrease the 
speed).
Anyway, while we don't have test a startup of Rekonq with 20 openned tabs (a 
real use case), I will not be convinced that Rekonq is lightweight. I don't 
want limit the user in order to say It is lightweight. If we do that, Rekonq 
will never be used by other people than geeks.

> I'm really "critic" (not sure this is right term..) with this
> plugins/extensions idea based on firefox (and Gecko) experience and
> implementation.
> 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.

I think you are right.

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

The advantage of plugin is let the user personalize its browser. The 
developers can then work on other things like html, javascript engines.
On firefox I use:
- Stop and Reload in one button (Firefox has 2 buttons).
- A plugin to add a "new tab" button at right near tabs (included now in 
firefox 3.5).
- An other to hide the menu.
On my netbook, an add on to autohide the status bar (save precious vertical 
space)
=> All cosmetics we introduced in Rekonq :)
Adblock to make the web faster.

A very interesting plugin interesting is Weave: 
http://labs.mozilla.com/projects/weave/
Like Foxmark, it crypts you personal config data (bookmarks, passwords, plugin 
used, opentabs) and sends them on a server. So, if I take another computer, or 
if I format it, I can easily restore them.
I think in the near futur it can be done with kde technologies and 
opendesktop.

For Rekonq I agree with you, we must not create a plugin system, but we must 
focus on features really useful for the user and integrate them. We must also 
make Rekonq code source easily extensible/versatile for futur needs.

Adblock for example can be taken from konqueror's plugin, to make Rekonq 
faster (Google will not be happy :) ).

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

My mockups that synthetizes UI concepts seen in all browsers must make you 
happy :)

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

I am impressed with webkit but I don't think khtml is dead. Netscape is not 
dead and has reborn with Firefox. I don't underestimate the khtml developers.
What I hope is, if it reborn, solutions we put in Rekonq will be reused.

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

Ok, I have questions about isolates tab processes:
- Do you want use QXEmbed like Ivan ? If we make this choice, Rekonq will not 
be part of KDE on Windows/Mac because it will depend on X. Is it possible to 
do something portable ?
- There will be one or several url bars ? I think the processes must be 
lighter as possible. An url bar in each tab is not a good idea. With one url 
bar, the protocol between processes and the main process will be more 
complicated but the application will take less memory.

For KWallet, I agree, it must be integrated.

> I know about a guy working on KDE bookmarks re-implementation. I'm really
> interested about this because I'm really not happy about the current one.
> And we can work there to insert also rss feeds.

Yeah cool.

> We surely need to follow KDE kio classes improvements in Qt history/cookies
> classes improvements and so on.

I don't understand.

I am sorry about my english skillz. I hope this mail is readable.

(Sorry for the mail duplication Andrea)