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
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
