RE: Multiple XWin.exe programs loading and no xterm

["Phil Betts" <Phil dot Betts at heis dot co dot uk>]

On Friday, April 08, 2005 3:58 PM, Igor Pechtchanski wrote:

> On Fri, 8 Apr 2005, Phil Betts wrote:
>> An alternative that I've not seen raised before: I was wondering if
it
>> would be possible to run XWin as a Windows service (presumably via
>> cygserver).
>
> Services are run by 'cygrunsrv', not 'cygserver'.  'cygserver'
provides
> Unix shared memory and IPC services for Cygwin.

Indeed.  A communication glitch between my brain and fingers I fear.

>Well, I don't recall if XWin has a way of selecting the next available
>display (I do know it's not on by default, even if it exists), but that
>would be pretty much a must in coping with an X service when one needs
to
>also start an XDMCP query, for example.

Unless it's been slipped in quietly, I don't believe it does.  Even if
it's possible, I think that until newbies stop running startxwin.bat
in order to get an xterm, it's safer to leave this option well
hidden, otherwise users will end up with 50 servers running at once
and the list will be full of out-of-memory complaints!

>> I know zip about the issues involved in running as a Windows service,
>> but if it's simple, it may be something to consider, perhaps as a
>> default installation.
>
>It's pretty simple to start a program as a service.  One wouldn't want
to
>have it as a default option, certainly, but a config script akin to
that
>of other service packages (e.g., cron, openssh, cygserver, etc) that
>*installs* such a service for the user to start would be very useful.

It wasn't the starting per se that I was concerned about.  I was
wondering whether the exe would need to be changed.  I.e. XWin.exe is
a Windows application (WinMain and all that), can *any* Windows
application be started as a service, or do they need special
initialisation code and/or linkage?  Is there not some issue over
whether services can be interactive (which XWin certainly is)?

>It would be trivial to write a "keepX" program that connects to the
server
>and does nothing (but is a client, so X stays around even if no other
>clients are present).  If such a program were contributed to the xorg
>packages (or, better yet, the upstream X distribution), the default
>xinitrc could invoke it in the background before the xterm.

An interesting idea.  If I get time this weekend I'll knock one up on
Linux, but I'll only be able to test it on XWin on Monday.

Surely its place would be in the foreground after starting xterm in
the background.  startx quits when the xinitrc script has finished,
not when the last client closes.  I.e. if your xinitrc ends like this:

  xterm -title xterm1 &
  exec xterm -title xterm2

Closing xterm2 would close X (on Unix at least), regardless of whether
xterm1 was still running or not.

Changing this to:
  xterm -title xterm1 &
  xterm -title xterm2 &
  exec keepX
would leave you free to close either or both xterms without losing X.
Only once keepX was killed would X close.

This is getting a bit OT, but it strikes me that "keepX" would be a
more logical place for the trayicon menu handling code.  If the icon
is also an X window (or can be regarded as such by an X application),
it should be relatively easy for an X client to attach a menu to it,
and it would be easier to reconfigure a lightweight client than
having to restart the server.  Comments?

Cheers,
  Phil
-- 

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************