On Mon, Nov 11, 2013 at 11:44 AM, .. ink .. <mhogomchu...@gmail.com> wrote:
>
> On Sun, Nov 10, 2013 at 12:08 AM, PCMan <pcman...@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]
>
> [0] http://tinypic.com/r/2w7lhl2/5
> [1]
> http://developer.ubuntu.com/resources/technologies/application-indicators/
> [2]
> http://api.kde.org/4.5-api/kdelibs-apidocs/kdeui/html/classKStatusNotifierItem.html
> [3]
> https://raw.github.com/mhogomchungu/qCheckGMail/master/src/statusicon.h
>
>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
