> > 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
> > 
> 
> 
> This is starting to make sense. On the session before I
> started experiencing crashes with starttde, I had updated the background to be
> displayed in kcontrol -> login manager. I suspect what you were able to
> traceback more thoroughly that I was the root cause of the crashes I experienced as well.
> Good catch!

I have a patch that I ask somebody either test or provide a peer review signoff.

I added new code, albeit only a single "else if" test.

I have tested the patch in both a VM and physical machine. No more halts in the session startup.

Here is the patch:

http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_phase1.diff

If testing the patch then do so like this:

* Before patching and updating tdebase, start a Trinity session.
* Open KControl, Appearance & Themes, Window Decorations.
* Toggle any nominal setting and select the Apply button.
* Exit the session.
* Login to start a new session.
* Verify the session stalls and won't start.
* Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM."
* Login to verify that once again Trinity starts.
* Log out.
* Install the patched tdebase.
* Start the session and repeat the KControl exercise.
* Exit the session.
* Start the session.
* Verify Trinity now starts without stalling.

Thanks!

Darrell