Various starting X problems

[Harold L Hunt II]

Phil,

Phil Betts wrote:

> Hi Harold,
> 
> Firstly, it's generally bad form to quote verbatim email addresses -
> although Luke did so in his original posting, so he can't complain
> if a spam harvester latches onto him ;-).

You know, I know that, but as you said, if they did it to themself first 
then I'm not going to lose sleep over it, nor am I going to waste my 
time confirming that I'm not reposting something that has already been 
posted since the cat is already out of the bag.

> Now...
> 
> Luke said:
> 
>>>In my .xinitrc I *don't* have an explicit path for xterm.  However, I
>>>see xterm has moved from /usr/X11R6/bin to /usr/bin!  Did many other
> 
> X
> 
>>>applications also move into there?  > > My system does not have a
>>>problem finding xterm in /usr/bin because > /usr/bin should always be
>>>in your Cygwin shell path... something else is > wrong with your
> 
> Cygwin
> 
>>>setup if that is not the case.
> 
> 
> Slightly OT: I noticed that the start menu entry for xterm no longer
> works.  Entering the command from the shortcut directly into the cmd.exe
> shell returns without an error or any output (that I can find).  From
> bash, the command works fine.  The other shortcuts that I've tried
> (e.g.. xcalc) all worked, so there is presumably something unusual about
> the way that xterm starts that causes a silent exit when started from a
> vanilla DOS/Windows shell.  My guess is that it's relying on some env
> var.

I'm aware of this.  I don't remember the exact details, but there is a 
sort of Catch-22 situation for setting the "start in" folder for the 
xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for 
different reasons.  Furthermore, I believe that the script that creates 
the shortcuts needs to be modified to be able to support shortcuts to 
programs that live in /usr/bin.  You'll notice that the emacs shortcut 
also does not work for the same reason.

I don't have time to fix this.  I would appreciate it if someone else 
would grab the -src package for X-start-menu-icons via setup.exe and 
work on fixing it; I don't want a half-assed untested patch either, I 
want one that has been thoroughly tested (you know, tough stuff like 
clicking at least one of the tree classes of shortcuts: /usr/bin X 
programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal 
programs) since the sort of changes required may break the other links 
that the scripts create (this is part of the Catch-22 I was talking about).

>>>Maybe keep the "exec wmaker" and set display to :1 ...  No, "startx
>>>-multiwindow -- :1" triggers the "no program named
>>>"/usr/X11R6/bin/xterm" in PATH" crash.  So I don't quite see how to
>>>achieve that.  I tried xinit -multiwindow but that started up a full
>>>desktop.
>>
>>Seriously, the easiet way is to use startxwin.bat and modify it 
>>according to the instructions in that file.  Or, if you really want to 
>>start from a Cygwin shell, use startxwin.sh and modify it accorinding
> 
> to 
> 
>>its instructions.  There are pre-made lines that are just commented out
> 
> 
>>that start a window manager etc.
>>
>>Lets have you try these things first and see where it goes.
>>
>>Harold
> 
> 
> Harold, I'm quickly coming to the opinion that .bat should really be
> spelled .bad !!
> 
> My / is the recommended C:\cygwin, but /usr is mounted on D:\cygwin\usr.
> This means that the all of the %CYGWIN_ROOT%\usr based paths in the
> script
> are all wrong.  There is no way (major kludges aside) to generate the
> correct paths in a generic .bat file.  Consequently, every time I
> install
> a newer version, I need to hack the new .bat file (or patch my own
> script
> with any changes you've made).

I wrote a short utility called "find_cygwin" using Open Watcom but I 
haven't finished it yet.  The problems I ran into were that I could get 
the paths I needed, but exposing them to the batch file as a variable of 
some sort was darn near impossible.

> If you'd be interested in a unified approach, where the .bat just runs
> bash -c startxwin.sh (which will probably in turn be just a wrapper for
> startx) I might be able to make time for this.

Yes, I think that may be the way to go at this point since we are 
starting to waste a lot of cycles trying to do things in batch files 
that are easily supported in shell scripts using *nix-style utilities.

Give it a try.  Download the X-startup-scripts -src package via 
setup.exe and hack away.  I don't think it would be too hard... the 
batch file will basically be just like /cygwin.bat but it will launch a 
given script instead of displaying a console... you might have to use 
"run" to prevent it from popping up a console that sticks around until 
all of the spawned processes finish, but maybe not.

> The ultimate goal being to make any configuration of startup
> parameters external to the scripts and therefore remove ANY need for
> users to hack the scripts themselves.

I wouldn't go for the gold yet... just make a batch file that runs the 
shell script first so that people can still create Windows shortcuts to 
the batch file, then we can go from there.

> There was mention a while ago of making multiwindow a standalone window
> manager.  Has anything been done in this direction?  It would certainly
> ease making a "one size fits all" startup and remove much of the
> confusion
> this thread typifies - i.e. the rule would be:
>   "always run one window manager"
> rather than
>   "always run a window manager unless you start X with -multiwindow
>    (whether you're aware that you are or not) in which case you etc..."

This isn't really a viable option at this time.  Splitting the window 
manager out introduces its own set of problems and still requires a 
command-line parameter to initialize the sub-system within XWin.exe that 
communicates with the external window manager that uses Windows windows 
as frames while all other window managers do not require that this 
subsystem be initialized.  So, this approach doesn't really do anything 
for us.

What I would rather see is some very minor tweaks (I have been thinking 
about doing these myself) that let the mutli-window window manager 
silently exit without causing a crash if another window manager is 
detected.  In fact, I would also like to create another dialog box that 
lets you check boxes to enable and disable -multiwindow and -clipboard 
during the current session.  The first thing this will require a is a 
continuation of the cleanup that I have been doing to the shutdown 
process for the -clipboard code and a cleanup of the shutdown process 
for the -multiwindow code.

> If you're interested, I'd appreciate some advice on how you'd like the
> patches submitted.  I'm assuming that I'll need to check out the latest
> CVS source, make the changes and submit the diffs as a patch. Since I've
> only ever seen tiny patches appear in this list, do most patches get
> sent
> directly to you?

Well, there are two steps to this:

1) Submit a handful of patches to the list (usually one or two is all I 
need) that show that you know what you are doing and that you code cleanly.

2) I'll ask you for an ssh dsa key and we'll get you a cvs account on 
freedesktop.org so that you can commit your patches directly.  This is a 
lot easier than mailing patches back and forth.  If you start screwing 
things up, we will shame you publically into behaving.  :)

Keep in mind, the above refers to the packages for the X Window System 
only... the ancillary packages that I have made (X-startup-scripts, 
X-start-menu-icons, etc.) are not in CVS anywhere; their source is 
distributed via setup.exe only.

Happy coding,

Harold