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.


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