public inbox for
help / color / mirror / Atom feed
From: rcunningham <>
Subject: Re: startxwin.exe no longer exists?
Date: Tue, 16 Dec 2014 17:23:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

>> 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.


Unsubscribe info:
Problem reports:

  reply	other threads:[~2014-12-16 17:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-13 16:20 Will Parsons
2014-12-13 18:17 ` Marco Atzeri
2014-12-16  2:50   ` Will Parsons
2014-12-16  2:56     ` Larry Hall (Cygwin-X)
2014-12-16  3:30       ` Will Parsons
2014-12-16  3:35         ` Larry Hall (Cygwin-X)
2014-12-16 14:29     ` Mark Hansen
2014-12-16 16:00     ` Erik Soderquist
2014-12-16 16:36       ` rcunningham
2014-12-16 17:06         ` Erik Soderquist
2014-12-16 17:23           ` rcunningham [this message]
2014-12-16 22:58           ` Will Parsons
2014-12-16 23:39             ` Erik Soderquist
2014-12-17 17:29               ` mathog
2014-12-17 17:40                 ` Erik Soderquist
2014-12-17 17:52                   ` mathog
2014-12-17 18:36                     ` Erik Soderquist
2014-12-17 19:02                       ` mathog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).