From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3922 invoked by alias); 7 Jan 2015 06:08:24 -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 3906 invoked by uid 89); 7 Jan 2015 06:08:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 07 Jan 2015 06:08:19 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0768HgR000929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 7 Jan 2015 01:08:17 -0500 Received: from [10.10.116.17] ([10.10.116.17]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0768F0i025215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 7 Jan 2015 01:08:17 -0500 Message-ID: <54ACCD52.1010309@cygwin.com> Date: Wed, 07 Jan 2015 06:08:00 -0000 From: Yaakov Selkowitz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: Suggestion for improving xinit 1.3.4 References: <54AA7981.7080805@blankersfamily.com> <54AACD28.9060407@cygwin.com> <54ABACF8.90406@blankersfamily.com> In-Reply-To: <54ABACF8.90406@blankersfamily.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00021.txt.bz2 On 2015-01-06 03:38, Laurens Blankers wrote: > On 5-1-2015 19:17, Yaakov Selkowitz wrote: >> On 2015-01-05 11:43, Yaakov Selkowitz wrote: >>> On 2015-01-05 05:46, Laurens Blankers wrote: >>>> [..] >>>> 1. Handling of empty .startxwinrc >>>> [..] >>> >>> And what if it's not zero-length but still blank? >> >> I could have startxwin check if ~/.startxwinrc is executable, and skip >> if it not, which might also cover many of these empty .startxwinrc's. >> OTOH all that might accomplish is trade the "why won't it start" for >> "why doesn't it respect my config". :-) > Nice edge case, well, you could use sed to filter commented lines and > white space and determine whether the file is effectively empty. But I > guess that might be even more surprising to people who don't expect it. > > How about this: Handle a missing execution flag on .startxwinrc as if > the file was missing, thereby executing the default behaviour. That's exactly what I'm considering. > How would you feel about adding a few more > items there may be "XWin Server (background)" and "XWin Server > (background, listen)". I would consider this too, but: > There shortcuts could execute code similar to the > one suggested by Angelo Graziosi [1] basically something like: > > run.exe /usr/bin/bash.exe -l -c /usr/bin/XWin -multiwindow -clipboard > -silent-dup-error -nolisten tcp > > for the first and > > run.exe /usr/bin/bash.exe -l -c /usr/bin/XWin -multiwindow -clipboard > -silent-dup-error -listen tcp > > for the second. One of the recent improvements to startxwin was that it would now find an available $DISPLAY itself, just like startx does. Using -silent-dup-error doesn't do that; think of the case where another user on the same system has started an X server first, then you wouldn't get an X server at all. > On 5-1-2015 18:43/19:17, Yaakov Selkowitz wrote: >> xinit -- the startx and xinit parts -- is an upstream X.Org package, >> and they determine the package version. The startxwin components are >> Cygwin-specific additions to the package, as they have been since we >> first released modular X11R7.4. Therefore, changing the version in >> this way isn't a viable option here. > I didn't think about the link with upstream. You are right, using a > different versioning scheme as upstream would be even more confusing. > > Although, technically, since your startxwin script is no longer an > adaptation of xinit it qualifies as an original program and could be put > in a package on its own, with its own versioning. I am not suggesting > you do this, without support for transitional packages in Cygwin this > would be even more confusing to users. But you script is now more than > just a patch to xinit! Now it's more a patch to startx instead. -- Yaakov -- 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/