Wow, sounds good!

Sign me up. :D

Keep us informed. A new (or at least bugfixed) panel would be awesome.

On Tue, 27 Dec 2011 13:19:32 +0800
PCMan <> wrote:

> Recently there are some discussions about lxpanel on the mailing list,
> which is really great.
> Hope that we can have a new maintainer for it.
> The original lxpanel, however, is bound to gtk2, xlib, and some
> linux-specific stuff.
> This makes migration to new technology very difficult.
> Much has happened in recent years.
> 1. gtk3 replaces gtk2.
>   The management of window geometry and underlying drawing parts have
> radical and backward incompatible changes.
>   Background image support will be completely broken in gtk3 as many
> deprecated APIs are removed from gtk3, especially the pixmap-related ones.
> 2. HAL is deprecated and now we have udisks/upower (linux-only), and things
> never work for other unix variants.
> 3. logout/shutdown should be done with ConsoleKit now.
> 4. Xlib is going to be replaced by xcb.
> 5. Xorg will sooner or later be replaced by Wayland in some distros
> 6. gio and dbus became widely used nowadays.
> 7. pulse audio is widely used, and direct ALSA access sometimes causes
> problems
> Hence, making old code work with new tech might even be more difficult then
> a rewrite.
> That's why a rewrite/redesign is planned.
> A project without many maintainers should not be trapped in the vicious
> cycle of fixing the broken compatibilities again and again.
> We have only one way out, reusing existing libraries whenever possible and
> trying not to touch too low level stuff.
> Now I mainly focus on finishing pcmanfm 1.0, but previously I already have
> a proof-of-concept prototype for lxpanel2. It's now 40% finished.
> Here is the spec of the new lxpanel2.
> 1. Mainly written in Vala, and use C when absolutely needed to speed up
> developement
> 2. Directly based on gtk3 and does not mess with gtk2. Drawing stuff will
> be done completely with cairo.
> 3. Built with CMake instead of automake (already done)
> 4. Use standard widgets whenever possible to get proper accessibility
> support (important!!)
> 5. Network monitor part is based on libgtop (90% finished)
>     Libgtop is a nice lightweight library designed for system monitoring.
> It works for major systems, not Linux-only.
>     Even better, it has no gnome dependency.
> 6. Pager and task manager part will use libwnck. (80% finished)
>     With libwnck, we do not touch underlying X11 stuff and can be much more
> portable and resistant to future changes of X.
>     Though it's a gnome lib, it only depends on gtk and has no other gnome
> dependencies.
>     The implementation is quite clean and complete and the APIs are well
> documented, making it nice to work with.
> 7. Battery monitor will use dbus + UPower. (70% finished)
>     Glib/gio has built-in dbus support now so no additional deps are
> needed. Vala even has dbus integration at the language level. Great!
>     This may be much better than read from /sys as upower devs will handle
> future incompatible changes and provide a constant dbus interface.
> 8. IPC stuff will use dbus instead of XSelection hacks. (dbus is quite
> common now and glib has built-in support)
> 9. The config file might become a single xml file (not sure, still under
> evaluation. Ini file based solution is not very handy for tree like data
> structure)
> 10.The UI might be similar than that of the old lxpanel initially, but in
> the future we need to be more unique and won't be Windows-like.
> 11.Volume control should be an additional plugin or systray applet instead
> of built into the panel. So we won't depend on ALSA by default.
> Instead of reinventing everything in a poor manner, this time I will reuse
> existing implementations whenever possible
> if they are lightweight enough. This should decrease maintenance load to a
> minimum and guarantee tolerance to future changes.
> With Vala, coding became much faster than before. To achieve the same
> functionality as in C, I felt that only 1/3 of code is needed.
> Though the new lxpanel2 will not be available soon, it will be pushed into
> repo once I got a first working version.
> Of course, this should happen after the file manager 1.0 is done.
> Thanks for your patience.

Michael Rawson <>

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to