tdebase/kdm/TODO

theming (#37349):
- maybe add a Themable plugin flag. if not set and no talker, abort.
- minor: show QWidgets only when the layout is ready and the theme was painted.
  but one can't hide the widgets in a QLayout, as they have no size then.
- add attribute inheritance. apply attributes extracted from particular
  elements of the (hidden) talker.
- make plugin return a QDom instead of embedding a QLayoutItem (QLabels look
  just awful in the themed greeter). big problem: there is no KdmGrid ... try
  to (ab)use QLayout.
- extract background from theme. use explicit node-id "background", i think.
- automatic talker node detection/creation. same for background, possibly.

- remote login can have the chosen host as the sessName
- popup menu grabs keyboard. that means it is ungrabbed afterwards ...
- error label uses fixed colors. red might be ok, but not black.

- message after switching to text mode

- handle non-linux VTs:
  on systems without VT_GETSTATE, try activating all consoles in turn to
  find free ones. wow, this sucks so much.
  - BSD: 1st: pcvt, /dev/ttyC[0] (OpenBSD), /dev/ttyv[0] (other),
              also emulated by wscons on /dev/ttyE.
         2nd: syscons, /dev/ttyv[0], fallback /dev/vga
  - Lynx, /dev/atc[0]
  - Solaris, /dev/vt[00]
  - SVR4, /dev/vc[00] (ESIX), /dev/vt[00] (other)
  - SCO, /dev/tty[00], query current with CONS_GETINFO, counts 0-based
  ref: xorg/programs/Xserver/hw/xfree86/os-support/xf86_OSlib.h
- act on BSD_INIT
- before nuking X server on other vt, save current vt and restore it before
  disallocating server vt. or just make the xserver not switch wildly.

- possibly parse Xserver log to find failure cause. this is very hacky.

- try harder to get rid of processes, see X servers failure cleanup path

- make auto-re-login a per-user option; save in .dmrc.

- add Xserver option set selection (#56329)
- add support for XRandR (#48602)
save these options to .dmrc?

- per-display sections in .dmrc. read-only, as far as kdm is concerned, as
  otherwise the GUI would become insanely complex.

- make config position independent
- parse /etc/kderc?
- merge multiple kdmrcs in the style of kconfig. how to set section priorities?
- genkdmconf: treat backgroundrc as an ini file, not as a text blob
- add proper quoting and dequoting to genkdmconf ini parser & writer

- write generic conversation plugin
- write modern conv plugin. or maybe this should be a parallel vs. serial
  setting of the classic plugin?

- actually implement the libpam_client support

- check if pam works before trying to authenticate
- test whether nis, kerberos4 & kerberos5 work
- sync BSD_AUTH from xdm, sync osfc2 from kcheckpass

- swap pam_setcred and pam_open_session order.
- check how the system specific functions like setpcred (AIX) and
  setusercontext (BSD) combine with pam_setcred.

- Move clock from greeter dialog to desktop
- add more clock types (#18178)
- add icons to action menu. icon theme selection!

- Add XDMCP _client_ to core (for remote login like in dtlogin).
  Currently this is done by simply restarting the x-server with -query.

- add login restrictions for reserve displays (#59353)

- possibly do the authentication for the reserve display on the display it
  is launched from (relates #59353)

- remote-accessible command sockets for remote shutdown, etc.
  or maybe implement it as an xdmcp extension?
- LoginMode=DirectQuery

- "XDMCP over FiFo" - or at least a "manage <dpy> [<xauth>]" command
- the per-display sockets are in fact nonsense; gdm's approach is better

- add bgset to XDM_MANAGED
  add FiFo command "background\t{inprogress,aborted,done}"

- lilo boot option <default>, i.e., -R with no argument
- support lilo -A mode

- support sleep/suspend in the shutdown menu. should this be really treated
  like a shutdown? (#33839)

- add language selection (export as LC_*). kde should respect this until the
  language is explicitly configured. and later? option "use system setting"?
  integrate with $KDE_LANG somehow. (#55379, #63804)
- add keymap selection (via xkb) (#51245, #64642)
for both, one would preset a list of available options and make one entry
the greeter's own setting. explicitly setting it sets it for both the greeter
and the session. .dmrc later affects only the session, not the greeter.

- handle failsafe internally, take care of focus. see #32973

- TryExec for "custom" session type. always show the entry, but disable it
  if it is unavailable for the selected user.

- cursor theming support via Xcursor (#66829)

- add screensaver (#41941)
- support DPMS (#18597)

- add a minimalistic window manager to the greeter (#17716, #51039)

- write a separate configurator application, as kcontrol does not scale well
  enough to cover all of kdm's options.

- Different logos for each session type (see #74500)
- User pictures in logo field
- display user's .plan/.project (or .person? .userinfo?) in the greeter?
  text area/label would suck -> tooltip?

- allow disabling full names or login names in userview (#54110)
- user list loading in the background (after first few to get a reasonable
  width estimate)

- faking session parameters (type, language, etc.) of nonexistent users based
  on statistical analysis of actual users ... severe overkill!?

- export password to the startup/session scripts. somehow ... (#35396)

- maybe reset CapsLock in the greeter. there is some CapsLock vs. ShiftLock
  confusion, though.

- maybe add kiosk mode: the user and his options are preset and locked in
  the greeter. i doubt it's usefulness, though.

- make builtin xconsole hideable; it should free the device when invisible.
  possibly auto-hide it on vt switch - see kdesktop_lock for the x event
  handling.

- ssh-agent/gpg-agent integration (#44177, #65709)

- lbxproxy integration (tell ghakko)

- in kcm_kdm, detach backgroundrc change status from kdmrc change status.

- when a shutdown is scheduled, don't remove all login possibilities.
  instead, display a warning in the greeter. use SIGUSR1 to notify already
  running greeters about changes.
- user notification about scheduled shutdown (and cancelled forced shutdown):
  - wall
  - greeter popup
  - d-bus message. this would be best, particularly because screen savers
    would need no special handling then.
- maybe bomb DefaultSdMode, save in state file instead. compare with ksmserver.

- gdm changelog indicates that PAM sometimes
  - continues despite PAM_CONV_ERR
  - asks user name twice
- gdm avoids the PAM_MESSAGE message box vs. prompt problem by displaying
  everything in one "error area". all messages are simply appended; an empty
  message clears the area.
- gdm stops cursor blinking on not used (remote) displays after 20 secs to
  save bandwidth.

internal stuff:
- improve signal handling in the subdaemon, it's incredibly racy (GOpen/GClose).
  depends on proper main loop.
  alternative extreme measure: launch greeter from master daemon?
- the process reaping from GClose should be in sync with the main loop.
- kill warning on AIX - see bug #13628 (really present?)
- implement auto-re-login by keeping the display subdaemon alive instead
  of starting a new one and feeding it the old auth data.
- options for running the greeter and the core unprivileged. problem: xauth.
- rethink the coupling of the kdm components, particularily the config reader.
  options:
  - keep things basically as-is, make the Xaccess interface even more flexible,
    add capability flags.
  - as previous, but don't use #defines, but textual constants. even more
    flexible, but slower, bigger, no compile-time checking, and the typing
    system would have to be more core-based. keys in the rc are considered
    invalid if they were not queried.
  - completely opposite: no explicit queries, but hard-code everything. that
    kills the idea of having one backend binary for multiple frontends, but
    that's a BlueSkyDream anyway.
    following that path, the config reader could be nuked at all.

ralf says:
- put the kmenu sidebar image on the left of the greeter
- enable the clock by default

thoughts (not really todo):
- PAM sucks. big time.
  historically, it is completely incapable of operating in event-driven contexts
  when it comes to non-console authentication schemes. the module just hangs in
  pam_sm_authenticate() (pam_authenticate() to the outside), waiting for input
  from its device.
  then came linux-pam 0.58, introducing PAM_BINARY_{MSG,PROMPT} to the
  conversation function interface. no conversation function could handle the
  binary prompts generically, of course. so came linux-pam 0.63 with a client
  library that would add another layer of indirection, so the conversation
  function could simply call into it and it would do whatever was configured
  by the admin. and everbody was happy, right? wrong! i've yet to see a single
  module (except for the demo module in linux-pam, of course) that actually
  uses this feature. not to mention the non-existing portability (you don't
  seriously expect TOG to extend the PAM standard within the next decade, do
  you?). so we're right where we started from.
  this imposes problems in two use cases:
  - cancelling authentication alltogether. this happens when the user changes
    the authentication method or when the greeter exits for some reason. if
    the process waits in the conversation function, it can simply return
    PAM_CONV_ABORT. if the module hangs, we're screwed.
  - suspending authentication. this is needed for shutdowns that need auth.
    if the module hangs, we're screwed, of course. if we're waiting in the
    conversation function, we have three options: 1) just abort the auth
    cycle and start a new one. this is what is done currently. 2) just open
    a second pam handle and authenticate with it, all from within the "outer"
    pam_authenticate(). if we're lucky, no involved modules use static variables
    and things work out. 3) linux-pam 0.65 introduced the following: the
    conversation function can return PAM_CONV_AGAIN. this in turn makes the
    module and consequently libpam return PAM_INCOMPLETE, requesting the
    application to call the resp. libpam function again. in theory this
    guarantees that authentication with a second pam handle is safe. of course,
    PAM_INCOMPLETE is just as popular and thus useful as PAM_BINARY_PROMPT.
  we could just longjmp() out of hanging modules from a signal handler.
  however, this might lead to resource leaks and even leave us with an unstable
  libpam. killing the hanging process seems like the most viable solution.
  however, for this we first need to make the greeter a child of the master
  daemon. also, the display sub-daemon (which happens to do the main auth.)
  is responsible for keeping the initial X connection open. killing it would
  terminate the session according to the XDMCP spec. other issues are probable.
- multiple conv. plugins could be used in a row, each serving a pam module.
  the plugins would have to detect that it's their turn by filtering messages
  and prompts.
- consider making the menu an actions-only menu again and put an "options >>"
  button somewhere. relates #63401, #61492
- pipe .xsession-errors through the daemon and put a size limit on it.
  remove old logs in disk-full situation.
- set LC_ALL in the backend for i18n-capable PAM libs - does one exist?


last sync with XFree86 HEAD: 2004-04-02