<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:7pt; font-weight:400; font-style:normal;">On Tuesday 11 August 2009 17:29:02 Lionel Chauvin wrote:<br>
> Le mardi 11 août 2009 15:56:35, Andrea Diamantini a écrit :<br>
> > On Tuesday 11 August 2009 11:24:46 Lionel Chauvin wrote:<br>
> > > - remove global menu<br>
> ><br>
> > I'd like hear different voices here. I'm ok with this, but I'm not sure<br>
> > there is general consensus.<br>
> > And for me this implies also moving from KXMLGuiWindow to KMainWindow<br>
> <br>
> There will never be consensus. We must propose something different. Users<br>
> can always use konqueror. We don't want a Swiss Army Knife, we want a<br>
> Katana. (Good name no ?)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>For general consensus I mean you, me, pano, ivan, lindsay... others??<br>
Now we are 2 vs 0 :)<br>
Plus hearing some opinions from kde-usability staff. I'm interested in their ideas about rekonq :)<br>
<br>
> > There are others things to do before the "multitask rekonq process":<br>
> > - KDE history support (to think about, perhaps copying and pasting some<br>
> > konqueror classes :)<br>
> > - KDE proxy support<br>
> > - Unit Tests (UnitTests branch, I'm going to publish it in some days)<br>
> > - rekonq documentation<br>
> ><br>
> > - DECIDE FOR QtWebKit vs WebkitKDE<br>
> <br>
> I fear that WebkitKDE will not give us the flexibility for testing one<br>
> process per tab. For KDE history support, I agree. For others I don't<br>
> know.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
It doesn't seem difficult.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> > My idea is to stop again development here and release 0.3 with full KDE<br>
> > support (but kwallet) and then ask for inclusion in extragear/network.<br>
> > I'd also like moving rekonq in the KDE developers group in gitorious.<br>
> <br>
> If you stop the development of 0.3 here you will not do something different<br>
> than webkitkde. Let them work on the integration of webkit and kde. We can<br>
> work in parallel (It doesn't imply we will not use parts of their code).<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
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!<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> > For "multitask rekonq" we can use "multitask git" :) developing these<br>
> > changes in a separate branch to let things go up together.<br>
> > (And merge it when we are sure it works well..)<br>
> <br>
> Ok.<br>
> <br>
> > > - duplicate main, application, mainwindow, mainview for rekonq_tab<br>
> > > process<br>
> ><br>
> > Why duplicating mainwindow and mainview? I think we need just a QWebView<br>
> > as tab widget. Or not?<br>
> <br>
> Because with only QWebView you will not have something fully fonctionnal.<br>
> For XEmbed you need a window. You will not be able to compile a tab process<br>
> if you remove all code of application, mainwindow and mainview. This is<br>
> why I propose to first use the existing code and transfert<br>
> fonctionnalities one by one from rekonq_tab to rekonq. At each transfert<br>
> we manage the communication. You see what I want say ?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>No, sorry. QWebView <span style=" font-weight:600;">is</span> 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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Perhaps I can provide a simple example in code about (after 0.2 release, obviously).<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> > > - manage rekonq_tab's winId registration in the cookiejar<br>
> ><br>
> > not sure here.<br>
> > My idea (I repeat, I'm not sure) is that we have to use the same winId<br>
> > for our tabs to let users open different tabs in the same context.<br>
> > For example to open a different (logged-in) tab of gitorious in your<br>
> > browser, you need to have the same winId in the two tabs.<br>
> > Isn't it?<br>
> <br>
> I am not sure it works like that. I fear that if you use the same winId, a<br>
> tab close the communication of another tab. We must investigate.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Yes, we surely need to investigate a bit here :)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> > > make rekonq_tab and<br>
> > > rekonq communicate via dbus<br>
> ><br>
> > I really need to study and test something here. Really no idea about :)<br>
> <br>
> You will not have the choice. There are several processes not several<br>
> threads. Processes don't share the same memory. The benefice is: if a tab<br>
> crash, the others not. (It can potentially take too much memory, this is<br>
> the chalenge)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Yes, I was saying just I'm not used to work with dbus..<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Andrea Diamantini,<br>
rekonq project<br>
WEB: http://rekonq.sourceforge.net<br>
IRC: adjam_AT_freenode<br>
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p></body></html>