Re: Suggestion for improving xinit 1.3.4

[Laurens Blankers <laurens at blankersfamily dot com>]

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.
Technically this should be what people expect since they should not
expect non executable scripts to be executed. Although people would
probably still be confused, but at least X will start and the question
people will ask will be "why is my config not working?" rather than "why
is X not starting?", which is much easier to handle in a FAQ/mailing
list. If you really want to make it fancy you can consider popping up a
dialog when .startxwinrc exists but is not executable and referring them
to the FAQ (clickable link?!).

That would still not solve my use case, in which the .startxwinrc is
empty and I expect the X server to start in the background without
starting any programs. But may be this is a special case which should be
handled separately. Currently the Cygwin-X program group only contains a
single item "XWin Server". How would you feel about adding a few more
items there may be "XWin Server (background)" and "XWin Server
(background, listen)". 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.

Not really the *nix approach, but probably what Windows users would
expect. I believe this is how Hummingbird Exceed (a commercial X server
for Windows) handled it.

You could add FAQ items like:

Q: How do I start X without any programs or window manager?
A: Use "XWin Server (background)"

Q: How do I allow PuTTY to connect to X?
A: Use "XWin Server (background, listen)", but be aware that this may
open a security vulnerability.

On 5-1-2015 18:43/19:17, Yaakov Selkowitz wrote:
> 4. Semantic versioning
>> Signalling major changes in the version number makes it a lot easier to
>> find the problem, at least for me. Semantic versioning [7] suggest does
>> thing. Practically this would have mend calling the latest release
>> 2.0.0-1 rather than 1.3.4-1. No additional effort required, but a clear
>> signal to people to read the release notes.
>
> 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!

> However, from personal experience, I disagree that a different version
> number would have made a bit of difference.  Either people will read
> the announcements -- and the subject of mine should have indicated
> that this wasn't a routing update -- or they won't.
Personally I do check release notes on major updates, but I admit I am
probably an anomaly.

[1] https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html

-- 
Laurens

_____________________________________________________________________
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?



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