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: rek...@freenode
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
