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

[Benjamin Poulain]

On 11/11/2010 05:05 PM, ext Andrea Diamantini wrote:
> 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?

Binary compatibility is a pain in the ass. I would prefer to avoid it as 
long as possible.

What about assuming all the main plugins are gonna live in the Rekonq 
repository anyway and we can modify the plugins along with the API?

We can publish the changes in API like do Firefox or Django so external 
plugin can be adapted.


> 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.

I don't understand this :)

cheers,
Benjamin