[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