From: Julien L. <gi...@ub...> - 2011-11-29 22:08:38
|
Hi, I'm working since some times to some improvements to lxsession. With my experiments, I ended to rewrite some part in Vala, since C have problems with me :) You can find the result on the options branch of lxsession : http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/options The main new features are : * Add initial applications by default support (panel, screensaver ...). It's a way to configure applications started by default, rather than just adding a line in autostart * Add initial options support (Keymap, XRandr, Keyring). It's the ability to add some options add start-up, like a screen resolution (instead of using a .desktop file in autostart directory). * Add initial Dbus support (draft of org.lxde.SessionManager interface, GNOME compat mode) You can have a look at the new desktop.conf file for the new options available : http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=blob;f=desktop.conf.example;h=8ae0636a452b6a2e8e8728c039c5d3f0397996c4;hb=refs/heads/options It should be already usable, the only regression I know is the logout function of lxsession-logout which is broken. I'll appreciate comments on this :) Especialy on the Dbus interface, what do you expect from a session manager to be available via Dbus ? Do you expect other features from the session manager ? I would like in the future to take the maintainance of lxsession and try to add more improvements, like : * Duplicate check, to not autostart an application twice * Merge back lxpolkit and lxsession-edit changes in lxsession * More application by default, and more automatic / smart detections * Finalize the Dbus interface * Improve lxsession-edit to configure the new options. Regards, Julien Lavergne |
From: PCMan <pcm...@gm...> - 2011-11-30 04:24:02
|
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! On Wed, Nov 30, 2011 at 6:08 AM, Julien Lavergne <gi...@ub...> wrote: > Hi, > > I'm working since some times to some improvements to lxsession. > With my experiments, I ended to rewrite some part in Vala, since C have > problems with me :) > > You can find the result on the options branch of lxsession : > http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/options > > The main new features are : > * Add initial applications by default support (panel, screensaver ...). > It's a way to configure applications started by default, rather than just > adding a line in autostart > * Add initial options support (Keymap, XRandr, Keyring). It's the ability > to add some options add start-up, like a screen resolution (instead of > using a .desktop file in autostart directory). > * Add initial Dbus support (draft of org.lxde.SessionManager interface, > GNOME compat mode) > > You can have a look at the new desktop.conf file for the new options > available : > http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=blob;f=desktop.conf.example;h=8ae0636a452b6a2e8e8728c039c5d3f0397996c4;hb=refs/heads/options > > It should be already usable, the only regression I know is the logout > function of lxsession-logout which is broken. > > I'll appreciate comments on this :) Especialy on the Dbus interface, what > do you expect from a session manager to be available via Dbus ? Do you > expect other features from the session manager ? > > I would like in the future to take the maintainance of lxsession and try > to add more improvements, like : > * Duplicate check, to not autostart an application twice > * Merge back lxpolkit and lxsession-edit changes in lxsession > * More application by default, and more automatic / smart detections > * Finalize the Dbus interface > * Improve lxsession-edit to configure the new options. > > Regards, > Julien Lavergne > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: Julien L. <gi...@ub...> - 2011-12-08 22:42:36
|
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 |
From: PCMan <pcm...@gm...> - 2011-11-30 04:49:26
|
For the session manager, I also have some other ideas. Is it possible for lxsession to expose an interface for client tools to change environment variables. For example, clients can ask lxsession to do setenv("http_proxy", ...), so later newly launched applications will use new proxy settings. We can also use this to change locale settings on the fly. Of course, there should be some limitations and some environment variables should not be changeable. Is this possible? |
From: <u-l...@ae...> - 2011-11-30 09:14:40
|
Hello PCMan, On Wed, Nov 30, 2011 at 12:49:18PM +0800, PCMan wrote: > For the session manager, I also have some other ideas. > Is it possible for lxsession to expose an interface for client tools to > change environment variables. In my eyes, this function does not belong to the "session", rather to the application starters. I'd hate to change the session properties back and forth (and potentially influence more than I need) only to run a single application instance against a different proxy or with a different locale than the other ones. A possibility to easily create a starter/wrapper with a differing environment for a certain application would feel much better. > For example, clients can ask lxsession to do setenv("http_proxy", ...), so > later newly launched applications will use new proxy settings. > We can also use this to change locale settings on the fly. What you presumably mean is to "change locale setting per application instance". Then the approach should be rather "fire once" and/or "per application" kind of setting, not "for all future new processes". Another catch is that quite a few applications insist on reusing existing processes instead of creating new instances - there your approach would fail, but a starter might include additional command line options to convince the concerned application to create a new instance. With a great appreciation for your work, regards, Rune |