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

[Lionel Chauvin]

Le mardi 11 août 2009 15:56:35, Andrea Diamantini a écrit :
> On Tuesday 11 August 2009 11:24:46 Lionel Chauvin wrote:
>
> Here is what I think:
> > - one url bar for all tabs
>
> Sure!
>
> This also implies simplifying error and icon management.
>
> > - 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 ?)
> 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.
> 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).
> 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 ?
> > - modify cmakelists.txt for compile rekonq and rekonq_tab executables
>
> sure
>
> > - modify main, application, mainwindow, mainview of rekonq_tab for:
> > - multiple execution of rekonq_tab
>
> ok
>
> > - remove toolbars, remove tabs
>
> ?
It will be easier to reuse, modify and remove than build something new from scratch.
> > - 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.
> > - modify mainview of rekonq for xembed rekonq_tab in a new tab (but keep
> >  also the current implementation of tabs)
>
> sure
>
> > When the previous todo list is done begin:
> > - simplify rekonq_tab for make it lightweight as possible: history, icon
> >  manager, (network manager ?) in rekonq process
>
> This will be ever true in rekonq!
Yes we can perhaps delegate history manager to another process, but I don't think we can remove icon manager and network manager from rekonq.
> >  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)
> > - handle crashs of rekonq_tab
> > - automatically reload a crashed tab
> > - if  3+ crashs display an error page in this tab for reload manually
>
> these three are the same task for me.
Yes :)


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20090811/7c516ea6/attachment.htm