From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14490 invoked by alias); 16 Dec 2014 17:23:31 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 14365 invoked by uid 89); 16 Dec 2014 17:23:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: iport-acv1-out.ucsd.edu Received: from iport-acv1-out.ucsd.edu (HELO iport-acv1-out.ucsd.edu) (132.239.0.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 16 Dec 2014 17:23:29 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJhpkFSE7/kU/2dsb2JhbABagwaEMMYYgk0CgRkWAQEBAQEBfIQMAQEBAQIBIxVAEQsJDwICBRYLAgIJAwIBAgFFEwgBAYggCL53kU0BhHEBAQgCIIEhjgNVgmiBQQWJPoUxiAKBC4RuIYUShg0ihA2DEAEBAQ X-IPAS-Result: Ah4FAJhpkFSE7/kU/2dsb2JhbABagwaEMMYYgk0CgRkWAQEBAQEBfIQMAQEBAQIBIxVAEQsJDwICBRYLAgIJAwIBAgFFEwgBAYggCL53kU0BhHEBAQgCIIEhjgNVgmiBQQWJPoUxiAKBC4RuIYUShg0ihA2DEAEBAQ Received: from act-bufferout-a1.ucsd.edu ([132.239.249.20]) by iport-acv1-out.ucsd.edu with ESMTP; 16 Dec 2014 09:22:19 -0800 Received: from [132.239.152.162] (geowk11.ucsd.edu [132.239.152.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rcunningham@ad.ucsd.edu) by act-bufferout-a1.ucsd.edu (Postfix) with ESMTPSA id 36E80F9BED for ; Tue, 16 Dec 2014 09:22:19 -0800 (PST) Message-ID: <54906A47.4090802@ucsd.edu> Date: Tue, 16 Dec 2014 17:23:00 -0000 From: rcunningham User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: startxwin.exe no longer exists? References: <548C82A3.9080604@gmail.com> <54905E8F.40809@ucsd.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00040.txt.bz2 On 12/16/2014 9:06 AM, Erik Soderquist wrote: > > >> 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/