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/