Well, we already have lxsession, but for some reason, it does not start on
my laptop sometimes and I haven't find out the cause yet. I also did some
hack with lxsession in my experimental branch trying to simplify its
codebase, such as replacing all app launching part with xdg autostart spec
and deprecate others. However, currently apps are launched in several
different ways in lxsession and some are coupled with some external gtk
tools and changing this part will break them. So I stopped the work
temporarily since I have no good solution at the moment. Instead, I took
some time to fix the original razor-session and rename it to lxqt-session.
Now it's an alternative lxsession. I added config files required for using
lxqt-session in the "lxqt-session" branch of
lxqt-common repo. With that branch, LxQt will run lxqt-session instead of
lxsession. I also did some more hack to replace the two busy loops inside
lxqt-session with some X11 event handling tricks.
Currently lxqt-session works out of the box with only two issues remained.
* Much more memory usage compared with lxsession. (more than doubled)
* no settings daemon, no xsettings (this can be solved by runing lxsession
as a settings daemon, but this will increase memory usage, again)
Options I can figure out to improve the current condition are:
1. do refactor for lxsession, but care must be taken not to break its gtk
support.
2. add xsettings and settings daemon support to lxqt-session and keep
optimizing it to get memory usage lower
3. do not put setting daemon stuff in lxqt-session. Extract the settings
daemon part from lxsession, and run it as a separate autostart app in
lxqt-session.
About systemd:
I studied session management with systemd a little bit. It's not suitable
for our use because of the following reasons.
1. it requires additional config files with its own format and cannot use
existing xdg autostart files at all.
2. it cannot support DE-specific config files (OnlyShowIn, NotShowIn). It
seems that you cannot create different sessions for different DEs or
different sets of profiles for the same DE.
3. Doing hacks to make things work with systemd and keep it compatible with
others will be much more work than just writing our own session manager. So
after some evaluation, now I'm against the idea of replacing the session
management part with systemd.
About freedesktop.org xsettings spec:
I also hacked the xsettings code of gtk 2 and gtk 3. It seems that they
share the same set of settings, but if some config values are missing from
xsettings, they'll be read from falback source, that's gtk-2.0.rc in gtk2
and ~/.config/gtk+-3.0/settings.ini in gtk 3.
So, we can remove Gtk/ThemeName key from our xsettings daemon so gtk2 and
gtk3 will read that value from their own config files and won't be forced
to use the same value from xsettings anymore.
With this fix, xsettings can be safely kept and remain work well for gtk2
and gtk3 at the same time. So we don't need to deprecate xsettings.
Any comments? Thanks!
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
