public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
* Suggestion for improving xinit 1.3.4 @ 2015-01-05 11:46 Laurens Blankers 2015-01-05 17:43 ` Yaakov Selkowitz 0 siblings, 1 reply; 6+ messages in thread From: Laurens Blankers @ 2015-01-05 11:46 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggestion for improving xinit 1.3.4 2015-01-05 11:46 Suggestion for improving xinit 1.3.4 Laurens Blankers @ 2015-01-05 17:43 ` Yaakov Selkowitz 2015-01-05 18:17 ` Yaakov Selkowitz 2015-01-06 9:38 ` Laurens Blankers 0 siblings, 2 replies; 6+ messages in thread From: Yaakov Selkowitz @ 2015-01-05 17:43 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggestion for improving xinit 1.3.4 2015-01-05 17:43 ` Yaakov Selkowitz @ 2015-01-05 18:17 ` Yaakov Selkowitz 2015-01-06 9:38 ` Laurens Blankers 1 sibling, 0 replies; 6+ messages in thread From: Yaakov Selkowitz @ 2015-01-05 18:17 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggestion for improving xinit 1.3.4 2015-01-05 17:43 ` Yaakov Selkowitz 2015-01-05 18:17 ` Yaakov Selkowitz @ 2015-01-06 9:38 ` Laurens Blankers 2015-01-07 6:08 ` Yaakov Selkowitz 1 sibling, 1 reply; 6+ messages in thread From: Laurens Blankers @ 2015-01-06 9:38 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggestion for improving xinit 1.3.4 2015-01-06 9:38 ` Laurens Blankers @ 2015-01-07 6:08 ` Yaakov Selkowitz 2015-01-07 21:39 ` Laurens Blankers 0 siblings, 1 reply; 6+ messages in thread From: Yaakov Selkowitz @ 2015-01-07 6:08 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggestion for improving xinit 1.3.4 2015-01-07 6:08 ` Yaakov Selkowitz @ 2015-01-07 21:39 ` Laurens Blankers 0 siblings, 0 replies; 6+ messages in thread From: Laurens Blankers @ 2015-01-07 21:39 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-07 21:39 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-05 11:46 Suggestion for improving xinit 1.3.4 Laurens Blankers 2015-01-05 17:43 ` Yaakov Selkowitz 2015-01-05 18:17 ` Yaakov Selkowitz 2015-01-06 9:38 ` Laurens Blankers 2015-01-07 6:08 ` Yaakov Selkowitz 2015-01-07 21:39 ` Laurens Blankers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).