Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.

BUG:215923


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdebase@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

1 files changed, 243 insertions, 0 deletions

diff --git a/kdm/TODO b/kdm/TODO
new file mode 100644
index 000000000..12a1ec545
--- /dev/null
+++ b/kdm/TODO
@@ -0,0 +1,243 @@
+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