lubuntu-desktop team mailing list archive

[Julien Lavergne <gilir@xxxxxxxxxx>]

Le 11/30/2011 05:23 AM, PCMan a écrit :
> Looks quite good generally and source code written in vala is much
> more readable then GObject/C. :-)
> Some comments:
>
>   * initial applications by default stuff:
>     gnome classifies applications by stages rather than types.
>     some applications should be loadad during initialization stage.
>     some are loaded along with the desktop panel, such as some applets
>     some are loaded when the panel is loaded and when the desktop
>     icons are being loaded
>     others are loaded thereafter.
>     To ensure applications are loaded at right time, interaction with
>     session manager is needed.
>     For example, the desktop panel should inform the session manager
>     when it's fully loaded.
>     Then, the session manager enters next stage and loads applications
>     of the next stage.
>     Applications which cannot communicate with the session manager
>     cannot support this.
>     Executing a command earlier doesn't guarantee that it will finish
>     loading earlier. This is an issue to solve.
>   * Regarding to the implementation, an application class with a data
>     member named type is enough IMHO.
>     for example:
>     public enum AppType {
>         WM,
>         PANEL,
>         DESKTOP
>     }
>     public class App {
>         private AppType type;
>     }
>
>     Defining a class registering a new GObject class at runtime and
>     create much overhead since C has no object supports. OO is not
>     that cheap with GObject though using it is quite easy in Vala. I'd
>     avoid overuse of classes.
>     To reduce overhead of GObject, we can use [Compact] attribute when
>     defining classes when some features provided by GObject, like
>     signals, is not absolutely needed.
>
>   * Use of LibGee
>     Most of the time, static arrays or built-in data strucures
>     provided by glib itself should be enough. Maybe we don't need
>     LibGee here.
>
>   * Initial options support is good, especially the keyboard and
>     xrandr one.
>
>   * Plugin actually is a good idea. I wanted to do that for quite a
>     long time, but I don't have the time to do it.
>
>   * For Dbus interface, I'd suggest using the same interface as gnome
>     rather than using our own namespace. Most of the gnome
>     applications and in the future, gtk3 applications, has built-in
>     supports to interact with gnome session manager. If we use
>     different dbus interfaces, than we need to patch every
>     applications to add lxsession support, which can be very painful.
>
>   * For lxsession-edit, merging it with lxsession should be good for
>     maintainance since it's useless when used along.
>
>   * If you're going to take its maintaince, it's highly appreciated.
>     Thanks for the great job!
>

Thanks for the comments, I added them to the TODO list. I'm not sure
about the timing to implement them :)

Next plan is to release it in PPA for wider testing. I consider it now
"stable" and with at least the same features than before the rewrite.
If there is no complain, I'm going to merge it in trunk, and prepare it
for an alpha release (0.4.9.1).

I plan to follow the Ubuntu schedule for lxsession, which mean :
 * No new features on February (the final list of features will depend
on the time I have).
 * Some beta releases during February / March
 * String freeze on March
 * A final version at the end of March

Regards,
Julien Lavergne