John: >>>> kdm has dependencies on libX11.so, libXext.so, libXau.so, >>>> libXdmcp.so, libsocket.so, libresolv.so, and the optional security/ >>>> authentication libraries: MIT KRB5, pam, rpcsvc. It doesn't have >>>> any dependencies on KDE libraries. >>> Really? I didn't know that.
If it doesn't depend on any KDE libraries, I would guess it does not have any accessibility support. >>> Is this the case for kdm4 as well? >> Yes. > > Cool, whereas.... This is a bit unfair. Many of the interfaces GDM uses would need to be used by KDM too if you properly ported it to support Solaris. > $ ldd gdm-binary > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libpam.so.1 => /lib/libpam.so.1 KDM uses the above. > libwrap.so.1 => /usr/sfw/lib/libwrap.so.1 You would probably want TCP wrappers support for XDMCP security even with KDM. > libcmd.so.1 => /usr/lib/libcmd.so.1 Needed for defopen() to check /etc/default/login. A feature you would need for KDM to support these interfaces needed to replace CDE login functionality. > libsecdb.so.1 => /lib/libsecdb.so.1 > libbsm.so.1 => /lib/libbsm.so.1 Needed for Solaris audit, which you'ld want even if using KDM. > libdevinfo.so.1 => /lib/libdevinfo.so.1 You'ld want KDM to support logindevperm. > libXdmcp.so.6 => /usr/openwin/lib/libXdmcp.so.6 > libXau.so.6 => /usr/openwin/lib/libXau.so.6 > libX11.so.4 => /usr/openwin/lib/libX11.so.4 > libXext.so.0 => /usr/openwin/lib/libXext.so.0 Also used by KDM. > libc.so.1 => /lib/libc.so.1 > /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 I'd bet KDM uses this too. > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libast.so.1 => /usr/lib/libast.so.1 > libtsol.so.2 => /lib/libtsol.so.2 > libnvpair.so.1 => /lib/libnvpair.so.1 > libsec.so.1 => /lib/libsec.so.1 > libgen.so.1 => /lib/libgen.so.1 > /platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1 I believe all the above are used by Solaris audit and Trusted Solaris, features that would need to be added to KDM for full Solaris support. > libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 > libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 > libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 > libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 > libgdk_pixbuf-2.0.so.0 => /usr/lib/ > libgdk_pixbuf-2.0.so.0 > libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 > libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 > libcairo.so.2 => /usr/lib/libcairo.so.2 > libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 > libpangocairo-1.0.so.0 => /usr/lib/ > libpangocairo-1.0.so.0 > libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 > libpng12.so.0 => /usr/lib/libpng12.so.0 These are GTK+ interfaces. Some of these provide a11y support, and libpng is needed to support displaying PNG style images, which GDM uses. I'd guess if KDM doesn't use something like pango, it probably doesn't work with right-to-left languages? > libmlib.so.2 => /usr/lib/libmlib.so.2 > /usr/lib/cpu/sparcv9+vis2/libmlib.so.2 GTK+ uses mediaLib for hardware acceleration. > libXi.so.5 => /usr/lib/libXi.so.5 I'd think you would want Xinerama support even if using KDM. > libXfixes.so.1 => /usr/sfw/lib/libXfixes.so.1 > libm.so.2 => /lib/libm.so.2 > libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 > libXrandr.so.2 => /usr/X11/lib/libXrandr.so.2 > libuutil.so.1 => /lib/libuutil.so.1 > libavl.so.1 => /lib/libavl.so.1 > libz.so.1 => /usr/lib/libz.so.1 > libfreetype.so.6 => /usr/sfw/lib/libfreetype.so.6 > libXrender.so.1 => /usr/sfw/lib/libXrender.so.1 > libexpat.so.0 => /usr/lib/libexpat.so.0 > Some of these are probably sucked in because GTK+ depends on them (such as Xrender and expat). Not sure about them all, though. I guess I'm surprised if KDM wouldn't use some of these (such as fontconfig and freetype). Perhaps it doesn't have very robust font support? > So, why use GDM instead of KDM then? Other than "because it's there" ? If someone wants to make KDM support Solaris, I think that would be great. As I explained, I think a11y support was the main reason we picked GDM over KDM initially. Brian _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
