Suggestion for improving xinit 1.3.4

Suggestion for improving xinit 1.3.4

[Laurens Blankers]

Hi,

As requested [1] a separate thread for suggesting improvements to xinit,
in order to solve some of the issues people have been having since the
release of 1.3.4-1 [2].

1. Handling of empty .startxwinrc
Given the new behaviour of startxwin having an empty is never a correct
configuration. It would be really nice if startxwin could check for a
zero length .startxwinrc and in that case just start the X server
without any programs, as it used to do in 1.3.2-1. This would solve a
problem reported several times [3, 4] and also solve the problem of
having an icon on the task bar for 'sleep inf' [5].

2. Adding a hint about 'sleep inf' to the FAQ
Not everyone reads the release notes, most people, when running into
problems will read the FAQ first. How about adding an entry similar to
this one:

Q: startxwin exits immediately on start-up without error
A: ~/.startxwinrc must be executable and block or else X server will
exist, adding a 'sleep inf' to the end of the file should help, also see [2]

3. Adding 'listen' option to the FAQ
Consider adding something similar:

Q: X server is no longer accepting client connections, how come?
A: For security reasons, by default the X server no longer listen for
tcp connections, if you really want this add '-listen' to the start-up
parameters.

Also see [6].

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.

I hope these suggestions don't require too much work. I think they would
have a significant positive impact on UX.

Laurens

[1] https://cygwin.com/ml/cygwin-xfree/2015-01/msg00012.html
[2] https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html
[3] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00012.html
[4] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00013.html
[5] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00059.html
[6] https://cygwin.com/ml/cygwin-xfree/2015-01/msg00013.html
[7] http://semver.org/


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

Re: Suggestion for improving xinit 1.3.4

[Yaakov Selkowitz]

On 2015-01-05 05:46, Laurens Blankers wrote:
> As requested [1] a separate thread for suggesting improvements to xinit,
> in order to solve some of the issues people have been having since the
> release of 1.3.4-1 [2].
>
> 1. Handling of empty .startxwinrc
> Given the new behaviour of startxwin having an empty is never a correct
> configuration. It would be really nice if startxwin could check for a
> zero length .startxwinrc and in that case just start the X server
> without any programs, as it used to do in 1.3.2-1. This would solve a
> problem reported several times [3, 4] and also solve the problem of
> having an icon on the task bar for 'sleep inf' [5].

And what if it's not zero-length but still blank?

> 2. Adding a hint about 'sleep inf' to the FAQ
> Not everyone reads the release notes, most people, when running into
> problems will read the FAQ first. How about adding an entry similar to
> this one:
>
> Q: startxwin exits immediately on start-up without error
> A: ~/.startxwinrc must be executable and block or else X server will
> exist, adding a 'sleep inf' to the end of the file should help, also see [2]

Yes, something along these lines should be added to the FAQ soon.

> 3. Adding 'listen' option to the FAQ

See my response to your PuTTY thread.

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

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.

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

Re: Suggestion for improving xinit 1.3.4

[Yaakov Selkowitz]

On 2015-01-05 11:43, Yaakov Selkowitz wrote:
> On 2015-01-05 05:46, Laurens Blankers wrote:
>> As requested [1] a separate thread for suggesting improvements to xinit,
>> in order to solve some of the issues people have been having since the
>> release of 1.3.4-1 [2].
>>
>> 1. Handling of empty .startxwinrc
>> Given the new behaviour of startxwin having an empty is never a correct
>> configuration. It would be really nice if startxwin could check for a
>> zero length .startxwinrc and in that case just start the X server
>> without any programs, as it used to do in 1.3.2-1. This would solve a
>> problem reported several times [3, 4] and also solve the problem of
>> having an icon on the task bar for 'sleep inf' [5].
>
> 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". :-)

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

Re: Suggestion for improving xinit 1.3.4

[Laurens Blankers]

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/

Re: Suggestion for improving xinit 1.3.4

[Yaakov Selkowitz]

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/

Re: Suggestion for improving xinit 1.3.4

[Laurens Blankers]

On 7-1-2015 07:08, Yaakov Selkowitz wrote:
> 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.
It would be very nice if that functionality, and anything else that
might be added in the future, applies regardless of which shortcut you
click. Would it be difficult to maintain an addition option to startxwin
e.g. --skip-rc?

>> 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.
I still consider it an original program rather than just a patch :-)

Laurens

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