Recently David shared some issues with starting Trinity. In his case the probable cause seemed to be stale profile cache file or profile cache files using the old prefix names.

Today I stumbled across a way to stall the session startup. I changed some settings in KControl.

What caught my eye with this bug is the xsession log error, which David saw as well:

ksmserver: '<wm>' missing.
ksmserver: Use --help to get a list of available command line options.

I traced the cause to these lines in my profile twinrc:

[ThirdPartyWM]
WMAdditionalArguments=
WMExecutable=twin

Those lines and group do not exist in a twinrc backup file and is the only difference between the files.

This is not a hard freeze. Trinity exits gracefully back to the command line, which is how I start X/Trinity.

The problem is with tdeinit_phase1. I commented out that command in starttde. I successfully substituted all of the following:

kwrapper ksmserver --windowmanager twin --windowmanageraddargs ""

kwrapper ksmserver --windowmanager twin

kwrapper ksmserver

Looking at the tdeinit_phase1 source code, I see that when WMExecutable is undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1 always started.

When I changed some settings in KControl to cause twinrc to update with including the ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver --windowmanager %1 --windowmanageraddargs %2."

Changing the twinrc WMAdditionalArguments to WMAdditionalArguments=--lock allowed Trinity to start using tdeinit_phase1.

I think the solution then is to add the following condition test to tdeinit_phase1:

  else if (wmArguments == "") {
    return_code = system((TQString("kwrapper ksmserver --windowmanager %1").arg(wmToLaunch)).ascii());

Comments?

Darrell