On Sun, Nov 10, 2013 at 12:08 AM, PCMan <firstname.lastname@example.org> wrote:
I haven't start doing this since Александр Соколов knows this much better than me, and also your comments and suggestions are needed.About #1, making core plugin API its own library liblxqt-panel is needed. Though without this back-linking from the plugins to the executable still works, it's not portable.After these are done, we can develop plugins outside the lxqt-panel source tree. So other third parties can develop lxqt panel plugins as well. We can also develop some distro-specific panel plugins, such as libindicator plugin for ubuntu.
I think the plugin API could be simplified further to mimic the most common usecase,the use case appindicator and kstatusitemnotifier are aiming for and that is to simply show an icon as a mean to represent the program status and a context menu to drive the application somehow.
The current API is too wide open and i think that will lead to confusion.For example,most plugins i have seen seem to use "QToolButton" object as an interface object.If this is the most popular use case,why not standardize on it by giving an API that abstract it.
Having a simple API like the appindicator one or kde one will be better i think.This is my API i use to give my application a single API to work with to support kde's status API,lxqt plugin API and QSystemTray API.
The only thing my application needed was "irazorpanel.h" and "irazorpanelplugin.h" header files soi assume plugins dont seem to need that much.Currently, i have a local copy of mentioned header files to allow my plugin to be buildable. Having them namespaced and installable will be appreciated.
Some projects prints a very big,fat warning when an unstable API is used or require a variable to be set to expose unstable APIs.Something similar could be done for API that are publicly accessible but are not stable.
qCheckGMail on lxqt looks like this