On Mon, Jul 26, 2010 at 6:28 PM, Christoph Wickert <[email protected]> wrote: > 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 work? 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 user-custom one. 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 the migration? 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 convinient. > 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 sometimes. 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 > 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. 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 > desktop-manager? Seems that it's possibly a bug. Actually the original lxsession execute global file unconditionally regardless of the content of user-custom file. 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 cases). 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 work? > 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
