Re: [Lxde-list] About the future of LXPanel

[Marty J. <mar...@co...>]

I agree with a lot of your LXPanel bullet points.  Could you say more about exactly what you think the problem is that needs to solved for these, and/or a sketch of what your solution would be:

Current multi-panel support is quite dirty and needs some rework 
netstatus plugin need some examinations and fixes.
Create a separate plugin specifically for applications menu

I will write more in a few days about why I have made some of the choices I have made that reject the GObject model for properties and signals.  That said there are a few things that we should definitely rely on GTK for.  The three most important being that our customers expect GTK themes to work, it is an excellent implementation vehicle for the configuration dialogs, and it implements the icon theme specification.  For now I will note that

So it will be much easier to upgrade to gtk+ 3 or even to change GUI toolkit in the future.

is a good reason to decrease, rather than increase, reliance on the toolkit.  Not that I think a change of toolkit is a good idea because of point 1 above.

There is no reason why out-of-process plugins can't be developed and shipped using tray icons right now.  This is essential for any complex plugin such as the often requested weather applet, that is so complex it might take down the entire panel if it were in-process.  We already had experience with this and the network plugin.  They would need to be clearly identified as external and not subject to the panel style, because otherwise you have to invest in an elaborate IPC protocol trying to communicate the panel style properties to the external plugin, including an event when they change; I would resist doing that because I think it falls outside "lightweight".  Same if you try to allow Gnome plugins, except that it then is an IPC protocol outside our control.

I am not willing to publish any code at this time.  It is still in heavy development, I may still decide to make invasive design changes, and I have no intention of putting out a half finished piece of garbage for others to find problems with.

On 04/17/2010 01:58 AM, PCMan wrote:
> Previously Marty Jack asked me about LXPanel.
> I got some ideas and I put them here:
> http://wiki.lxde.org/en/LXPanel_Roadmap
> 
> I think some cleanup of the infrastructure is needed for future
> development. We can utilize what's already provided by GObject given
> this won't hurt performance.
> 
> Please comment.
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Lxde-list mailing list
> Lxd...@li...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>