forwarding the mail I sent just to Anton by mistake. ---------- Forwarded message ---------- From: andrea diamantini <[email protected]> Date: 2012/8/11 Subject: Re: Concept for the New Tab Page To: Anton Kreuzkamp <[email protected]>
Hi Anton, you are welcome to work on your concept. Anyway, just to be precise, Pierre's concept was not laking an OK to be merged, but it was just "unmergeable" because it was containing not just the "newtabpage concept", but in sparse order: - a new implementation of the download manager - a BIG change in the newtabpage load (moving to use QNAM, instead of the Protocol Handler, but not fully porting it to) - various local fixes (merged in mainline later by hand) - something like more than 50 commits not rebased at merge's request time. So, to avoid going to /dev/null, just: - work on one concept to be merged per time. - keep synced with master (i.e., rebase it) Finally, Pierre's merge request on ReviewBoard has not been discarded exactly to not let go to /dev/null the good concept he designed, waiting for someone rewamping it. Good luck for it, 2012/8/7 Anton Kreuzkamp <[email protected]> > Hi, > During my vacation the last two weeks, I've thought of a concept for a > better > structure of the new tab page. To avoid it to go to /dev/null, like > Pierre's > concept unfortunately did, I'd like to get an OK before I start > implementing > it. > > Instead of invoking actions via reloading the page with a special url (like > about:preview/add), I'd create a Q_INVOKABLE function for each action > inside > NewTabPage and expose the NewTabPage object to JS. Then the actions would > be > triggered via JS. > Moreover, I'd also do the loading of sections via JS, so I'd make the > favoritesPage(),bookmarksPage(),... -functions Q_INVOKABLEs, too, which > means, > we simply have to invoke those functions from within JS and the new section > will be shown. (The section-creating functions themselves need nearly no > change at all.) The newtabpage-class-structure would then look something > like > that: http://paste.kde.org/530210/ > > This concept brings > -slightly better performance (we don't need to always reload the whole > page) > -more power (some things, like an icon-selection-dialog, are simply not > doable > (sensibly), without the possibility to invoke c++-functions from js) and > -a imo way easier understandable code. > > Regards, Anton > -- Andrea Diamantini WEB: http://www.adjam.org rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode -- Andrea Diamantini WEB: http://www.adjam.org rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
