[rekonq] One process per tab: TODO list for 0.3 [RFC]

[Andrea Diamantini]

On Tuesday 11 August 2009 17:29:02 Lionel Chauvin wrote:
> Le mardi 11 août 2009 15:56:35, Andrea Diamantini a écrit :
> > On Tuesday 11 August 2009 11:24:46 Lionel Chauvin wrote:
> > > - remove global menu
> >
> > I'd like hear different voices here. I'm ok with this, but I'm not sure
> > there is general consensus.
> > And for me this implies also moving from KXMLGuiWindow to KMainWindow
> 
> There will never be consensus. We must propose something different. Users
>  can always use konqueror. We don't want a Swiss Army Knife, we want a
>  Katana. (Good name no ?)

For general consensus I mean you, me, pano, ivan, lindsay... others??
Now we are 2 vs 0 :)
Plus hearing some opinions from kde-usability staff. I'm interested in their 
ideas about rekonq  :)
 
> > There are others things to do before the "multitask rekonq process":
> > - KDE history support (to think about, perhaps copying and pasting some
> > konqueror classes :)
> > - KDE proxy support
> > - Unit Tests (UnitTests branch, I'm going to publish it in some days)
> > - rekonq documentation
> >
> > - DECIDE FOR QtWebKit vs WebkitKDE
> 
> I fear that WebkitKDE will not give us the flexibility for testing one
>  process per tab. For KDE history support, I agree. For others I don't
>  know.

That's probably true. But they are working hard now. And we have always to use 
our WebView/WebPage classes. Just changing inheritance from QWebView/Page to 
KWebView/Page.
It doesn't seem difficult.

> > My idea is to stop again development here and release 0.3 with full KDE
> > support (but kwallet) and then ask for inclusion in extragear/network.
> > I'd also like moving	 rekonq in the KDE developers group in gitorious.
> 
> If you stop the development of 0.3 here you will not do something different
>  than webkitkde. Let them work on the integration of webkit and kde. We can
>  work in parallel (It doesn't imply we will not use parts of their code).

I didn't understand this. If we stop two or three weeks development in master 
branch (continuing that on multitask one), stabilizing code and releasing a 
full KDE support rekonq, what's the problem? WebkitKDE is a library, rekonq is 
an app. They are surely different. And have surely different targets.
Perhaps things go smooths and we can release a "multitask 0.3 rekonq", perhaps 
not. And we have to work a bit more on it. That's all!

> > For "multitask rekonq" we can use "multitask git" :) developing these
> > changes in a separate branch to let things go up together.
> > (And merge it when we are sure it works well..)
> 
> Ok.
> 
> > > - duplicate main, application, mainwindow, mainview for rekonq_tab
> > > process
> >
> > Why duplicating mainwindow and mainview? I think we need just a QWebView
> > as tab widget. Or not?
> 
> Because with only QWebView you will not have something fully fonctionnal.
> For XEmbed you need a window. You will not be able to compile a tab process
>  if you remove all code of application, mainwindow and mainview. This is
>  why I propose to first use the existing code and transfert
>  fonctionnalities one by one from rekonq_tab to rekonq. At each transfert
>  we manage the communication. You see what I want say ?

No, sorry. QWebView is a window. And in my first idea about (again, I can be 
wrong) the tabwidget is in the rekonq main application. the tabs (so, the 
WebViews) will become separate apps.

Perhaps I can provide a simple example in code about (after 0.2 release, 
obviously).


> > > - manage rekonq_tab's winId registration in the cookiejar
> >
> > not sure here.
> > My idea (I repeat, I'm not sure) is that we have to use the same winId
> > for our tabs to let users open different tabs in the same context.
> > For example to open a different (logged-in) tab of gitorious in your
> > browser, you need to have the same winId in the two tabs.
> > Isn't it?
> 
> I am not sure it works like that. I fear that if you use the same winId, a
>  tab close the communication of another tab. We must investigate.

Yes, we surely need to investigate a bit here :)


> > >  make rekonq_tab and
> > >  rekonq communicate via dbus
> >
> > I really need to study and test something here. Really no idea about :)
> 
> You will not have the choice. There are several processes not several
>  threads. Processes don't share the same memory. The benefice is: if a tab
>  crash, the others not. (It can potentially take too much memory, this is
>  the chalenge)

Yes, I was saying just I'm not used to work with dbus..

-- 
Andrea Diamantini,
rekonq project
WEB: http://rekonq.sourceforge.net
IRC: adjam_AT_freenode
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20090811/03a46f38/attachment-0001.htm