On Mon, Nov 11, 2013 at 11:44 AM, .. ink .. <mhogomchungu@gmail.com> wrote:

On Sun, Nov 10, 2013 at 12:08 AM, PCMan <pcman.tw@gmail.com> wrote:

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 haven't start doing this since Александр Соколов knows this much better than me, and also your comments and suggestions are needed.

 
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.
Sounds good, but this approach is less flexible.
For example, the sysstat plugin requires using its own widget for painting.
Other 3rd party plugin developers might figure out some interesting usage of the panel plugin that we don't know.
So I think current API is good enough and there is no need to be too restricted.
Ideally every panel plugin manages the rectangular area it owns and can do whatever it wants in it.
The only thing needed is integration with the panel's background, looks & feels and comply with the UI guideline.
Making the API too restricted may hinder some potentially creative usage that we don't know yet.

Having a simple API like the appindicator one[1] or kde one[2] will be better i think.This is my API[3] 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.
This is partially true. The panel plugins also use the ConfigDialog class, which is owned by lxqt-panel.
So irazorpanel.h and irazorpanelplugin.h are not enough. I tried it earlier and found this.
Also, since IRazorPanel and IRazorPlugin are only abstract interfaces, plugins don't have other details about the objects.
For example, the panel object is actually a QObject, but in the plugins, we only get a IRazorPanel (now LxQtPanel) interface, and it's not possible to convert this pointer to QObject.
Maybe it's good to hide implementation details and only provide an abstract interface.
However, in some rare cases, you might want to read a QObject property from the panel object or install some event filter on it. This is evil, but in some special plugins this might be needed.
So, having the ability to expose the QObject pointer to the plugin authors might be useful.

QObject IRazorPluginImplementation::getQObject() {
  return static_cast<QObject*>this;
}
Directly convert the IRazorPlugin or IRazorPanel pointer to QObject in the plugin code won't work since QObject is not a parent class of IRazorPlugin or IRazorPanel.


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[0]