On 12/16/2014 9:06 AM, Erik Soderquist wrote:
<snip>

Shouldn't the startxwin script check for running instances and delete all
lock-files related to non-existent instances?  Why must this be a manual
operation?
I generally recommend against automagic cleanup of lock files from
dead sessions being a general default because that also wipes out
warning that something went wrong.  I do it in my situation because I
have it on (essentially) dumb terminals where the session working is
much more important than knowing something went wrong, and the dumb
terminals are on flaky power, so most of the dead sessions are due to
power failure anyway.

Then the script should provide a popup (via zenity, yad, dialog, or whatever) that informs the user that a prior session crashed, and offer a "Continue/Abort" choice. Don't force casual X users to learn about lock-files. By default, also provide a popup whenever a running server is detected, to avoid redundant servers being launched inadvertently.

Help normal users get on with their work, rather than providing a surprisingly different environment requiring specialized knowledge to resolve.

The prior startxwin.exe "just worked", and this new replacement script is
clearly creating problems for previously happy CygwinX users, where no
problems existed before (or, at least the problems weren't visible and
didn't affect normal use).
I actually have no experience with startxwin; I always called the X
server directly with the options I wanted.  However, I can say that
freeing of lock files is the job of the process that created the lock
files.  If you kill the process, stray lock files are a normal
expectation.

Evidently, that isn't being done. But the prior startxwin.exe never, in my experience, created the issues of the new startxwin script.

I would have preferred to have seen startxwin.exe retained, and this new
script phased in gradually, perhaps as "startxwin_new" in the first release.
Then, when startxwin_new stabilizes, rename the executable to
startxwin_old.exe and the script to startxwin. Several updates later,
quietly remove startxwin_old.exe.

It seems nonsensical to treat all CygwinX users as alpha testers. I'm more
than willing to help test new features, but not in the dark: Make it very
clear when significant subsystems are being evolved, and provide a way to
try the new without losing the old.
The changes were announced, and the announcement already sited in this
thread.  Having read the announcement again, it looks like the
replacement has as one of its goals bringing the X system more in line
with general X and *nix standards, which, as far as I know, has always
been a general goal of the entire Cygwin set of projects.

I never used this list until AFTER the update killed my previously stable CygwinX environment.

It is silly to expect all CygwinX users to actively monitor a list just to avoid getting their systems broken.

-BobC

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Reply via email to