RE: Need help to replicate old behavior of my X setup scripts with latest Xfree86 update
> -Original Message- > From: Marco Atzeri [mailto:marco.atz...@gmail.com] > Sent: Tuesday, December 23, 2014 2:17 PM > To: cygwin-xfree@cygwin.com > Subject: Re: Need help to replicate old behavior of my X setup scripts with > latest Xfree86 update > > > > > try putting "sleep inf" in .startxwinrc > It should simulate the old behaviour > > Regards Thanks for the suggestion. I actually figured out something similar. I launched fbpanel instead with this command: exec /usr/bin/fbpanel -p multiwindow I also discovered that the X server is not always opened on display 0, which I wanted to force, so I did some digging and found I can do that by creating a ~/.xserverrc file to change how it launches the X server. I put this in the file instead: /usr/bin/XWin :0 -multiwindow -nolisten tcp I don’t need external connections as I’m primarily using the X server for local programs or with ssh -Y, so the nolisten switch works fine for me. I also didn’t want xterm to start up at launch, so I had to create an empty ~/.Xclients file. Finally, I had change my startup script so that, if the X server isn't running yet, it would launch startxwin in the background and loop until it sees the fbpanel process in the process list, or time out (after 30 seconds). If it sees the process start, it sets up my configurations as before. It works, albeit not as cleanly as before. I get the extra icon in my taskbar for fbpanel since it’s running, and I see the job number get echoed out to the terminal when it backgrounds the startxwin script. It also takes longer to start since I’m launching fbpanel on top of the server, though I suppose putting the sleep command would alleviate some of that. I’ll look into it. Thanks! Sincerely, Benjamin Richards -- 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: Need help to replicate old behavior of my X setup scripts with latest Xfree86 update
On Tue, Dec 23, 2014 at 08:17:21PM +0100, Marco Atzeri wrote: try putting "sleep inf" in .startxwinrc It should simulate the old behaviour Running sleep or any command from .startxwinrc adds an icon to the Win7 taskbar now (I'm referring specifically to the part of the taskbar showing icons for running appliecations, not the tray - it's always been in the tray and that's fine). Is there are any to keep the X server running without the extra clutter after these new changes? Thanks, Jake -- 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: Need help to replicate old behavior of my X setup scripts with latest Xfree86 update
On 12/23/2014 7:24 PM, Ben Richards wrote:
Up until the recent update to xinit-1.3.4-1 which overhauled X session
handling, I had my session set up nicely for my purposes. With the
following code in my .zshrc and an empty .startxwinrc, when I launched
Cygwin, Xwin.exe would start on display :0.0, it would set the
$DISPLAY variable, and automatically kill the X server when I exited
that terminal. I like mintty so this let me use that as my shell.
.zshrc contents:
=
startxwin &> xserver.log
x_start_success=$?
if [[ $x_start_success == 0 ]]; then
export DISPLAY=:0.0
pid=`ps | grep '/usr/bin/XWin' | awk '{print $1;}'`
alias kill_xwin="kill $pid"
if [[ $TMUX == "" ]] && [[ $x_start_success == 0 ]]; then
alias exit="kill $pid ; \exit"
fi
fi
The aforementioned update disrupted this flow so I’m wondering if
anyone has any suggestions on how I can regain a similar sort of
functionality. I don’t like using xterm in Cygwin and would like to
keep using mintty as my main terminal interface.
try putting "sleep inf" in .startxwinrc
It should simulate the old behaviour
Regards
--
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/
Need help to replicate old behavior of my X setup scripts with latest Xfree86 update
Up until the recent update to xinit-1.3.4-1 which overhauled X session
handling, I had my session set up nicely for my purposes. With the
following code in my .zshrc and an empty .startxwinrc, when I launched
Cygwin, Xwin.exe would start on display :0.0, it would set the
$DISPLAY variable, and automatically kill the X server when I exited
that terminal. I like mintty so this let me use that as my shell.
.zshrc contents:
=
startxwin &> xserver.log
x_start_success=$?
if [[ $x_start_success == 0 ]]; then
export DISPLAY=:0.0
pid=`ps | grep '/usr/bin/XWin' | awk '{print $1;}'`
alias kill_xwin="kill $pid"
if [[ $TMUX == "" ]] && [[ $x_start_success == 0 ]]; then
alias exit="kill $pid ; \exit"
fi
fi
The aforementioned update disrupted this flow so I’m wondering if
anyone has any suggestions on how I can regain a similar sort of
functionality. I don’t like using xterm in Cygwin and would like to
keep using mintty as my main terminal interface. Before, when I ran
startxwin it would launch the server and quit with an error status as
to whether it was successful or not, leaving Xwin.exe running in the
background. Now it stays in the foreground unless I specify otherwise.
However, my startup script relied on the assumption that Xwin.exe was
running by the time startxwinrc finished, which I cannot guarantee if
I run it as a background task. It also used the exit status where if
it was nonzero, I could assume that I already had X running and it
wouldn’t kill the server if I typed ‘exit’ to exit any subsequent
mintty windows I launched with Alt+F2.
I've tried various configurations and read through the man pages but
haven’t come up with an elegant solution other than the idea of
looping on the ‘ps’ until I see Xwin.exe in the list. Is there a
better way?
Sincerely,
Benjamin Richards
--
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/
