On Mon, Jul 26, 2010 at 6:28 PM, Christoph Wickert
> Am Montag, den 26.07.2010, 10:40 +0800 schrieb PCMan:
>> The question is, should we override global settings completely with
>> user-custom file?
>> Normally, user-custom file should override the global one and this is
>> a general practice.
> Thus we should follow it. It is the standard unix behavior for decades.
Agree, but consider the case maybe someday some core components of the
desktop will be replaced by better alternatives, than how can this
For example, something like the migration from kde3 to kde4 or from
gnome 2.x to gnome shell. Core components are changed. Of course we
can prevent this kind of breakage by not doing incompatible changes to
core components, but what if it's needed in the future? This kind of
change happened in the evolution of every well known desktop
environment. It's possible that some new nice programs emerge and we
want to replace our old ones with them. If we always read the
user-custom config file only, this kind of migration cannot be done.
Another similar issue is that should we merge system-wide config file
and the user's custom one on a per-key basis, or just read the
In addition, this reflects a major drawback of our current rolling
release model. As we don't have a major version of the whole desktop,
it's hard to do some migration like gnome 2 -> gnome 3 or kde3 -> kde4
since we don't have version numbers to stick to. With this, we can
guarantee compatibilities among minor releases of the same series.
>> However, this approach has some drawbacks for desktop environment.
>> If we override the global file with the user's, later the session will
>> always start the programs the user specified only. If we made some
>> changes to the DE and add new programs or removing some old ones from
>> startup, these changes won't be propagated to user's custom file. Then
>> the user will have a broken desktop.
> Additional programs should not lead to a broken desktop, they should
> enhance it. I think we really need to stop the architectural changes in
> each and every release. We should make the current one work instead of
> switching to something new again.
Totally agree, but what if someday it's really needed? How can we do
Besides, the newly added programs enhancing the desktop won't be
executed since it's not in the user's custom autostart file. So the
user won't get the new enhancement after uprgading the desktop. A
possible solution is to put this in /etc/xdg/autostart so it will
always work, but as you see for core component this is less
> Think of a recent breakage we had when you changed the pcmanfm option
> for showing the icons. I don't think we could have prevented that even
> with your negotiation approach.
The problem happens because lxde-commons is not updated at the same
time. Because pcmanfm2 is not yet ready for production use, I didn't
make a new release for it.
But I agree that it's my fault and this needs to be avoided in the future.
This is the design error of the old pcmanfm. Having a checkbox in
preferences dialog for desktop manager looks reasonable at first, but
later this becomes confusing. When the user start the program, he/she
expects that it will show a file manager window, but instead you get a
desktop wallpaper with icons, but no file manager window. The second
time you execute this, it shows a file manager window. It can be
suppress by pcmanfm --no-desktop, but this can create some confusion
Having pcmanfm --desktop actually treat the desktop management part
like a separate program. You run a command for the desktop manager,
and another for normal file manager window. You won't get unexpected
thing if you don't execute it. If you want a desktop manager, execute
the command for it explicitly. After thinking for a long time, I found
this a more reasonable design which always gives you expected
behavior. You can treat the desktop manager as a different program. It
even has its own preference dialog. It's the current implementation
that puts the desktop manager and file manager in the same binary for
performance reason. That's all. XFCE put desktop manager and file
manager in different programs, xfdesktop4 and thunar, too.
>> A possible solusion to this is to add a custom desktop session with
>> custom config files and choose that session from display manager
>> instead of default LXDE. (Just like what Lubuntu did). However, I
>> agree this is not easy enough for users.
> This is not an option for a user because it requires a new file
> in /usr/share/xsessions. I want something that requires no global
>> Another possible solution is to completely drop support for the
>> "autostart" file and only use xdg autostart spec and load startup
>> programs with desktop entry files. However this can make things more
>> complicated and we need to implement extension to desktop entry spec
>> to specify orders of the startup programs and to restart crashing
>> programs. In addition, parsing several desktop entry files can be much
>> slower than loading a simple autostart file with few lines. Moreover,
>> it's hard to know how many programs you start on startup since you
>> need to check the content of all desktop entry files yourself. Of
>> course find /etc/xdg/autostart -name "*.desktop" and grep "LXDE" may
>> help, this is far less handy.
> Agreed, I don't think we should drop the autostart file and switch to
> xdg based autostart file completely. For the core components of the
> desktop IMHO is it the best solution and other desktops like GNOME and
> Xfce are doing the same thing.
>> Another solution previously proposed is to enable negation in
>> user-customed autostart file. So users can disable global command in
>> /etc/xdg/autostart from their user-custom file. This is easy to
>> implement and easy to use, but there were some objections on the
>> mailing list so I didn't do this.
> I agree to the objections:
> * Negation is confusing.
> Imagine the global file has
> @pcmanfm --profile lxde --desktop
> What could negate that? Does is need to match exactly? If so,
> what is the match?
> -@... --profile lxde --desktop
> -pcmanfm --profile lxde --desktop
> Is the order of options important? Think of
> -pcmanfm --desktop --profile lxde
> Or will the command be enough?
> Does the profile matter? One could argue that two instances of
> pcmanfm with different profiles are something different and
> should not be negated.
> You see there are quite a few possibilities.
> * With all these possibilities, it's easy to break the users
> configuration. The original problem was that a change in the
> global file was not reflected in the user's configuration, but
> with negation a change in the user's file might easily BREAK the
> user's configuration, which is IMHO even worse.
> * We really should settle with one way to configure. The changes
> in the architecture are the biggest source of bugs. It's hard
> for the package maintainers to maintain packages when there are
> incompatible changes all the time. I have a couple of bugs that
> I cannot fix in Fedora 12 because I would have to reset the
> users configuration - this is just what you wanted to avoid.
OK, this really looks like a bad idea. Let's not do it.
> Site note: Things get worse when the architecture of a component changes
> but there is no release of dependent components after the change.
> * menu-cache 3.0 was released 2010-02-14 and since that day
> lxlauncher is broken. The fix only exists in git.
> * lxsession 0.4.0 was released 2009-12-08 and since then lxinput
> is broken. A fix in Git exists, but it wont build due to an
> issue with the Makefiles.
OK, I'll take the responsibility and try to handle this within days.
Thank you for the patience.
> We MUST stop this breakage! The code from GIT should be in a buildable
> state all the time. A developer must not do releases that break
> dependent programs without updating the dependencies too.
Even alpha release?
>> Either way, lxsession needs to be fixed to solve this but there needs
>> to be a better idea to solve this issue.
>> Any comments?
> What is so bad about the current implementation - given it worked? It is
> the normal behavior that everybody expects, that is documented in the
> README and was used for quite a while.
> I still don't understand why the setup I choose doesn't. On the one
> hand, changes in the personal file make a difference, on the other they
> are ignored. Can you explain why pcmanfm is always started with the
Seems that it's possibly a bug. Actually the original lxsession
execute global file unconditionally regardless of the content of
The original design treat the lines in user's autostart file as
programs "additional to the default core component" and doesn't
override the global with the user's one. It merges them. So there is
no way to turn off system-wide thing from the user side. This is
against general practice of UNIX, but without this it's hard to handle
incompatible major migration in the future. (of course this should be
avoided whenever possible, but it can still be inevitable in some rare
Or, we can assume that users who know how to edit config files are
advnaced users, so they can read the README and fix their user-custom
file according to the content of the global one once things don't