modularity of DISPLAYMANAGERS

Rudolf Kastl che666 at uni.de
Wed Sep 1 15:30:28 UTC 2004


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 at uni.de> 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
> 
> 





More information about the fedora-devel-list mailing list