Re: Suggestion for improving xinit 1.3.4

[Yaakov Selkowitz <yselkowitz at cygwin dot com>]

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/