[rekonq] Rekonq API (aka first step to support plugins)

Andrea Diamantini adjam7 at gmail.com
Thu Nov 11 17:05:17 CET 2010


Hi all,
while I'm preparing rekonq 0.6.2 release with the infamous "print & find from 
parts" bug fixed and based on KDE 4.5.4 (it will have a fix in KIO important for 
kdewebkit), I was thinking a bit about "the future"...

basically, what I have in mind is to try finding out what methods in our 
classes can be tagged to be our API. I propose to add a tag like this

// REKONQ API SERIES 1

saying that that method is part of our API and will be available for plugins.
This will mean that the methods tagged with that sign will NO MORE CHANGE 
until we'll move to the SERIES 2 (hopefully, in 10 years..).
The function should be also well documented to present a decent document for 
people (..us??) wanting to try implementing a plugin for rekonq.
The plan is to release a stable API for 0.7 and go with plugin support in 0.8.

What do you guys think about?


...

Second proposal.. working on part (better) integration, I noticed the troubles 
of implementing an alternative to web* signals to communicate with the GUI 
(basically, the webtab <---> mainview communication), so I thought: why don't 
we "hide" in the code ALL the webkit signals implementing a sort of interface 
in the WebTab class?
We just have a couple of situations (icons, titles) where this could be 
usefull.
Opinions?? (BEFORE starting coding..??)

Regards,
-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.sourceforge.net
IRC: rekonq at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20101111/73b6b872/attachment.htm 


More information about the rekonq mailing list