Re: Suggestion for improving xinit 1.3.4

2015-01-07 Thread 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

Re: Suggestion for improving xinit 1.3.4

2015-01-06 Thread 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

Re: Can't open display with PuTTY and xinit 1.3.4-1

2015-01-06 Thread Laurens Blankers
On 5-1-2015 18:31, Yaakov Selkowitz wrote: Wait, are you talking about a Windows version of PuTTY? There is a PuTTY for *nix? And it has been ported to Cygwin? I didn't know. That is, let's say, amazing :-) Yes I mean the native PuTTY for Windows. This will be added to the FAQ in due course.

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

2015-01-05 Thread Laurens Blankers
On 5-1-2015 10:48, Yaakov Selkowitz wrote: Just .startxwinrc, and the changes were explained in the announcement. The information is contained within the announcement, but it is a bit difficult to figure out what to do from just the list of changes. A more detailed step-by-step guide, preferably

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

2015-01-05 Thread Laurens Blankers
On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote: So I'm guessing with your statement above that English isn't your primary language. [..] 1. I am not the maintainer of the xinit package. [..] English is indeed not my first language, but that is no excuse for not carefully reading your replies

Can't open display with PuTTY and xinit 1.3.4-1

2015-01-05 Thread Laurens Blankers
When using PuTTY with X11 forwarding enabled X clients are no longer able to connect to the X server running locally. When reverting back to 1.3.2-1 the problem goes away. This may be related to the -nolisten tcp which is now the default[1]. If this is indeed the case it would be create of adding

Suggestion for improving xinit 1.3.4

2015-01-05 Thread 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

Backwards compatibility

2015-01-04 Thread Laurens Blankers
to acknowledge that user experience matters. Before you ask, yes, I did post this to the cygwin-xfree mailing list. However I am not getting anywhere there. So I am interested in the thoughts of the wider, beyond X11, Cygwin community on backwards compatibility. Thanks, Laurens Blankers -- Problem

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

2015-01-04 Thread Laurens Blankers
On 2015-01-04 00:02, Larry Hall (Cygwin-X) wrote: The fact that the recent changes interfere with previous usage is an issue that needs attention for sure but reverting, while the maintainer's call, just trades misbehaviour in the eyes of one group for that of the other. That may be true, but

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

2015-01-03 Thread Laurens Blankers
On 3-1-2015 04:48, Larry Hall (Cygwin-X) wrote: But the functionality in the latest release of the xinit corrects some long-standing Cygwin incompatibilities with startx, so there's no benefit to turning back as a strategy. This is exactly why I have such hard time convincing people that using

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

2015-01-02 Thread Laurens Blankers
On 2-1-2015 21:10, schilpfamily wrote: this has worked for years, now when i run this command, a window very briefly blinks into existence but then goes away. any idea why this would stop working now? This is most likely due to a major rewrite of the xinit package which contains all start-up

xinit-1.3.4-1: breaking backwards compatibility

2014-12-30 Thread Laurens Blankers
all the time that everyone, and not in the least Yaakov, invests into maintaining Cygwin/X. However as a user and software engineer myself I also very much appreciate systems continuing to function after minor upgrades. Sincerely, Laurens Blankers -- Unsubscribe info: http://cygwin.com/ml

Re: xinit-1.3.4-1: breaking backwards compatibility

2014-12-30 Thread Laurens Blankers
On 30-12-2014 13:46, Angelo Graziosi wrote: What about changing the way X server is started? I could change the way I start X, and I have successfully gotten things to work by doing so. But that is not my point. My point is that I need to make significant changes to the configuration to get back

Re: xinit-1.3.4-1: breaking backwards compatibility

2014-12-30 Thread Laurens Blankers
On 30-12-2014 17:04, Angelo Graziosi wrote: The same you can do with the link created as suggested in my previous replay. You are probably right, but again, that is not the issue. The point I am trying to make is that breaking configurations which have worked for many years in a patch release is