Am Mi, den 01.09.2004 um 11:10 Uhr -0400 schrieb Jeff Spaleta: > On Wed, 01 Sep 2004 16:45:15 +0200, Rudolf Kastl <che666@xxxxxx> wrote: > > The switchdesk guis need a rewrite. so if theres just a bit sanity there > > could be change in the way DMs are handled too and you could even reuse > > the same gui. > > First of all.. switchdesk i think is aimed primarily at being a tool > for individual users to set their prefered desktop environment inside > a user's home directory. Changing which DM is used is system-wide and > would need administration privs to work. right and we could use the regular means like pam auth to solve that problem. > Personally I do not think its > a good idea to add this feature to the switchdesk interface. you understood that wrong. i say you build one gui and use the same gui for both tasks (as 2 different tools) with a minimal change. thats why my above solution solves not only one "problem". if youd use .desktop entrys for the DMs too you could use a dynamical gui for both tasks (every gui scans a dir for .desktop files and sets a default symlink. one does it for windowmanager and one for the displaymanager) > You are > thinking one user, one system. I think its very important when > thinking about gui's to think multi-user, and make sure there is a > distinction between what non-admin users see in terms of tools and > what admin users see as tools, becuase I certaintly don't want > end-user seeing or interacting with the gui for DM selection, i want > to lock that down so only users with admin privs see that. perhaps we need to get the fd.org menu standard in this way expanded too --show-only-in-root ;) /sbin fine for me. ;) > But yeah the script logic controlling how prefdm works is mighty... crusty. yup its thats what i thought. i never said it doesent work. but no one can really convince me that the current solution is good. > But its just script logic. I'm sure if you wanted to try your hand at > rebuilding the /etc/X11/prefdm script to make it easier to allow for > additional DM's that would not be unwelcomed coding work. well if i find enough spare time i will for sure look into it. i just thought that i would throw up a discussion and perhaps other people would recognize the needs here too. It would need a bit help to get the standards forward here. > Once you > have an example script replacement or patch to the current prefdm > submitted to bugzilla, there might be more to talk about in terms of a > gui. yes right. for start a console tool that plain does a symlink would be enough. > My guess is the lack of more generalized prefdm logic is partly > if not mostly manpower/priority constraints related. So volunteering > to rebuild the prefdm script and submit it for review might move this > discussion forward. Well as always. do it yourself ;) but of course as always a productive answer. thanks! I am well aware that my short email contains enough material to write a few pages about details but even after reading it myself it seems to be that the ideas are reflected rather short but still straightforward. > > -jef > >
