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.
> 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.
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.
> 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
changes.
> 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?
-...@pcmanfm --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?
-pcmanfm
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.
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.
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.
> 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
desktop-manager?
Regards,
Christoph
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
