[rekonq] Fwd: Concept for the New Tab Page

[andrea diamantini]

forwarding the mail I sent just to Anton by mistake.

---------- Forwarded message ----------
From: andrea diamantini <adjam7 at gmail.com>
Date: 2012/8/11
Subject: Re: Concept for the New Tab Page
To: Anton Kreuzkamp <akreuzkamp at web.de>


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 <akreuzkamp at web.de>

> 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 at freenode





-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rekonq/attachments/20120811/71ff45de/attachment.html>