>Wouldn't it be better to expand the TDM search paths to include
>/usr/share/apps/kdm/sessions/ then?
Looks to me as though the default search paths are defined in
tdebase/tdm/config.def:1931:
===================================
Key: SessionsDirs
Type: list
Default: "/usr/share/xsessions,/var/lib/menu-xdg/xsessions,"
TDMDATA "/sessions"
User: core
User: greeter-c
Instance: */"/usr/share/xsessions,/var/lib/menu-xdg/xsessions,"
TDMDATA "/sessions"
Comment:
The directories containing session type definitions in .desktop
format.
Description:
A list of directories containing session type definitions.
# See <xref linkend="tdmrc-sessions"> for details.
===================================
We could add /usr/share/apps/kdm/sessions/, but what happens when
KDE4 is not installed to /usr? Or different distro maintainers
install kdm/sessions to different locations? If we add search
support for the default paths for KDM, then why not add the default
locations for other login managers such as GDM and SliM? Seems this
could get out of hand.
We already supply our own session files, as do other login
managers. The default search paths expands the built-in TDM list
and includes known default locations. Does adding those two files
cause harm?
Darrell
Tim,
With the latest git from today, I see the foolowing build errors:
x_10.cpp:16439:5: error: 'x_TDEApplication::x_TDEApplication(bool,
bool)' cannot be overloaded
x_10.cpp:16418:5: error: with
'x_TDEApplication::x_TDEApplication(bool, bool)'
x_10.cpp:16446:5: error: 'x_TDEApplication::x_TDEApplication(bool)'
cannot be overloaded
x_10.cpp:16425:5: error: with
'x_TDEApplication::x_TDEApplication(bool)'
x_10.cpp:16453:5: error: 'x_TDEApplication::x_TDEApplication()'
cannot be overloaded
x_10.cpp:16432:5: error: with 'x_TDEApplication::x_TDEApplication()'
Darrell
>Wait... As for me kdm-3.5.13 parses desktop files located in the
>/usr/share/xsessions/ and displays KDE 4 session as "KDE plasma
>workspace".
>If r14 doesn't this is a regression.
TDM recognizes /usr/share/xsessions/ in R14 too. I recall I raised
that issue and was part of the testing.
That said, the KDE4 session desktop files are not installed in
/usr/share/xsessions/. They are installed in
/usr/share/apps/kdm/sessions/, which is why TDM does not find the
files. :)
Darrell
In a multi-user environment the option should be available when
KDE4 is installed. All we need are some desktop files in
tdebase/tdm/kfrontend/sessions. We need only copy the files from
KDE4:
/usr/share/apps/kdm/sessions/kde-plasma-safe.desktop
/usr/share/apps/kdm/sessions/kde-plasma.desktop
I tested adding the files on a system with KDE4 installed and
another without. With the former the options appeared as expected
and with the latter the options did not appear as expected.
Comments?
Darrell
Tim,
I have the latest sources, updated this morning. I started a clean
full package set starting with tqt3. The FTBFS:
/dev/shm/tdebase/kcontrol/hwmanager/devicepropsdlg.cpp:784:85:
error: no matching function for call to
'TDEStorageDevice::mountDevice(TQString&, TQString&, TQString*)'
Darrell
I am unable to login through TDM when the account uses IceWM. I can
login with KDM (4.10.2) using IceWM. This seems to affect all
accounts.
No problems with IceWM when logging in from the command line and
startx.
No problems using TDM with other window managers or desktops, such
as Xfce or Fluxbox.
Anybody else experience this or confirm?
Thanks. :-)
Darrell
>Same on my laptops. Last time I remember it working was on debian
>kernel 2.6.32.
Thank you. Bug report 1615 filed and added to the R14 etherpad road
map.
Darrell
Anybody using TDEPowersave?
I can't seem to get the app to send the laptop to sleep mode
(suspend-to-ram). The screen blanks but the laptop does not enter
sleep mode when the sleep/suspend timer expires. The moment I
execute any user event, such as move the mouse or touch the
keyboard, then TDEPowersave goes into sleep mode.
Darrell
