Discussion:
rfe: seamless windows integration
Jack Tanner
2003-08-05 02:03:50 UTC
Permalink
This is a pipe dream, but it's a pipe dream worth striving for.

1. X should run as a service. There's no reason for it to run as a
user-launched app.

2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.

3. Exiting X (e.g., by stopping the service) should list all cygwin
processes that were launched under X and prompt the user to terminate
them. For example, an ssh-agent launched from an xterm should be killed
automatically.

I know there are ways of approximating these behaviors now; I'm just
suggesting that these be built in.

-JT
Harold L Hunt II
2003-08-05 02:36:55 UTC
Permalink
Jack,

Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.

Harold
Post by Jack Tanner
This is a pipe dream, but it's a pipe dream worth striving for.
1. X should run as a service. There's no reason for it to run as a
user-launched app.
2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.
3. Exiting X (e.g., by stopping the service) should list all cygwin
processes that were launched under X and prompt the user to terminate
them. For example, an ssh-agent launched from an xterm should be killed
automatically.
I know there are ways of approximating these behaviors now; I'm just
suggesting that these be built in.
-JT
Jack Tanner
2003-08-05 22:54:08 UTC
Permalink
Post by Harold L Hunt II
Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.
Harold,

Thanks. If I wanted to hear you be dismissive and condescending, I
could've just gone back and read the list archive.

I'm not a developer, but I am a user interested in the development of
this project, and I'm doing what I can to contribute through testing and
reporting bugs. Moreover, I have a fair amount of academic traning in
human-computer interaction and user experience engineering, and my
suggestions are based on a thought-out analysis.

Enmity aside, it wouldn't take too long to actually consider and respond
to what I suggested, and I would welcome discussion.

Regards,
JT
Harold L Hunt II
2003-08-05 23:46:43 UTC
Permalink
Post by Earle F. Philhower III
Post by Harold L Hunt II
Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.
Harold,
Thanks. If I wanted to hear you be dismissive and condescending, I
could've just gone back and read the list archive.
Dismissive and condescending? No, that was not my intention, sorry that
you got that impression.
Post by Earle F. Philhower III
I'm not a developer, but I am a user interested in the development of
this project, and I'm doing what I can to contribute through testing and
reporting bugs. Moreover, I have a fair amount of academic traning in
human-computer interaction and user experience engineering, and my
suggestions are based on a thought-out analysis.
I don't doubt that you have plenty of training.

However, have you read your suggestions and talked to some programmers
about them? Here, lets take a look. [Yes, now you should be intrepting
my remarks as generally pissy, snotty, dismissive, and condescending].

1. X should run as a service. There's no reason for it to run as a
user-launched app.

This really doesn't matter and, in fact, is probably incorrect.
Cygwin/XFree86 needs to interact with the display (else you could use
Xvfb), so running it as a service that won't always have a desktop
connected is pointless. Furthermore, a machine shared by multiple users
(like a Terminal Services server) will not be able to service all users
with a single instance of XFree86 running. Another point is that, I
believe, services that interact with the desktop need to run under an
actual user account and it would be silly to have XFree86 running under
'bill' when 'steve' is logged in.

Besides, this could be done with a simple shortcut in the Startup group
in the Start menu. In fact, that should be done and had all of the bugs
worked out before anyone talks any further of services.


2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.

This is icing on the cake. This is the kind of thing that Microsoft
hires 500 college interns to write in the summer because it takes a hell
of a lot of time and attention to detail to get it 'right', whereas the
overall benefit is very small in comparison.

Furthermore, this requires interacting with the Cygwin setup developers.
You think I am mean?

3. Exiting X (e.g., by stopping the service) should list all cygwin
processes that were launched under X and prompt the user to terminate
them. For example, an ssh-agent launched from an xterm should be killed
automatically.

Huh? Exiting X right now kills all connected clients. There is already
an "Are you sure?" warning dialog. Free software is all about bang for
the buck; the above feature might be nice, but it only matters to
marketroids.
Post by Earle F. Philhower III
Enmity aside, it wouldn't take too long to actually consider and respond
to what I suggested, and I would welcome discussion.
Yes it would. It took me like 10 minutes to write this reply. I don't
have to be party to any and all discussions that take place on this
list. I wrote my reply and said my piece. Others were free to jump all
over your email and praise it.

Furthermore, you got a reply to your message from Earle indicating his
interest. So, I don't see why you have to have a beef with me when you
appear to already have another supporter with influence.

After all of that, my position is exactly as I stated, without malice,
in my original email: those suggestions will go on the wish list, below
other more fundamental problems like crashes (-clipboard when copying
large amouns of text) and startup failures (with -clipboard and
-multiwindow). There is still a lot of architectural work that needs to
be done before we will start worrying about icing the cake.

Harold
Christopher Faylor
2003-08-06 03:17:10 UTC
Permalink
Post by Jack Tanner
2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.
This is icing on the cake. This is the kind of thing that Microsoft
hires 500 college interns to write in the summer because it takes a hell
of a lot of time and attention to detail to get it 'right', whereas the
overall benefit is very small in comparison.
Furthermore, this requires interacting with the Cygwin setup developers.
You think I am mean?
The setup developers aren't all that mean, actually. But, then neither
are you.

However, I don't see why this would require any setup changes. A
postinstall script should be able to set up icons, etc. I can't decide
if the thought of a folder filled with scores of icons for X programs is
intriguing or frightening, though.

cgf
Brian E. Gallew
2003-08-06 13:07:07 UTC
Permalink
Post by Christopher Faylor
However, I don't see why this would require any setup changes. A
postinstall script should be able to set up icons, etc. I can't decide
if the thought of a folder filled with scores of icons for X programs is
intriguing or frightening, though.
First, create a folder in the Programs section of your Start Menu named
"Cygwin-XFree86". Then, the following script will produce working
links, BUT it's not what you want.

cd /usr/X11R6/bin
for d in *.exe
do
mkshortcut -P --icon=/cygwin.ico \
--arguments="$d -display :0" \
--name=Cygwin-XFree86/$(basename $d .exe) \
--workingdir=$HOME /usr/X11R6/bin/run.exe
done

This skips any shell scripts, which is (usually) what you want.
Unfortunately, there are a lot of programs in that directory which
really want a terminal (e.g. xdpyinfo). Further, there are programs in
there that don't belong here like this (e.g. Xwin.exe).

So, to do this *right*, we'd need a couple things:
1) A canonical hierarchy structure (e.g. Start Menu/Program/Cygwin/XFree86)
2) A script which defines two shortcut functions (or more?), one like
the above shortcut for "real" X11 programs, and one which appends
"|xterm -e more" to the commands
3) Someone to take the time to carefully pick and choose which kind of
shortcut (if any!) gets generated for each application.

The up side of this is, if implemented, we could then ask other package
maintainers to add an appropriate shortcut for their X-enabled
application (e.g. emacs, vim). I wouldn't ask that of the GNOME or KDE
port, though, as they already have menu setups that work.
Harold L Hunt II
2003-08-06 13:41:03 UTC
Permalink
Post by Brian E. Gallew
Post by Christopher Faylor
However, I don't see why this would require any setup changes. A
postinstall script should be able to set up icons, etc. I can't decide
if the thought of a folder filled with scores of icons for X programs is
intriguing or frightening, though.
First, create a folder in the Programs section of your Start Menu named
"Cygwin-XFree86". Then, the following script will produce working
links, BUT it's not what you want.
cd /usr/X11R6/bin
for d in *.exe
do
mkshortcut -P --icon=/cygwin.ico \
--arguments="$d -display :0" \
--name=Cygwin-XFree86/$(basename $d .exe) \
--workingdir=$HOME /usr/X11R6/bin/run.exe
done
This skips any shell scripts, which is (usually) what you want.
Unfortunately, there are a lot of programs in that directory which
really want a terminal (e.g. xdpyinfo). Further, there are programs in
there that don't belong here like this (e.g. Xwin.exe).
1) A canonical hierarchy structure (e.g. Start Menu/Program/Cygwin/XFree86)
2) A script which defines two shortcut functions (or more?), one like
the above shortcut for "real" X11 programs, and one which appends
"|xterm -e more" to the commands
3) Someone to take the time to carefully pick and choose which kind of
shortcut (if any!) gets generated for each application.
The up side of this is, if implemented, we could then ask other package
maintainers to add an appropriate shortcut for their X-enabled
application (e.g. emacs, vim). I wouldn't ask that of the GNOME or KDE
port, though, as they already have menu setups that work.
Brian,

Interesting idea. Probably the easiest thing to do here would be to
either create a list of 'term' programs or 'non-term' programs along
with a list of excluded programs. Of course, we would want to figure
out which list, 'term' or 'non-term', was going to be shortest before
deciding which to make.

To skirt the setup "Create Cygwin/XFree86 icons?" step, we could simply
stuff the above lists and a modified version of your script in a new
package called, for example, XFree86-start-menu-icons-4.3.0-1.tar.bz2.

What do you think of that?

I think this would work just fine as a sort of confirmation that the
user wants start menu icons. We could leave the package out of the
XFree86-base dependency list, so only those users that really wanted the
icons would end up getting them.

Sure, it would be nice to eventually add a setup question, but doing the
above first would at least demonstrate to the setup folks that we
actually have something completed.

Harold
Brian E. Gallew
2003-08-06 16:48:51 UTC
Permalink
Post by Harold L Hunt II
To skirt the setup "Create Cygwin/XFree86 icons?" step, we could simply
stuff the above lists and a modified version of your script in a new
package called, for example, XFree86-start-menu-icons-4.3.0-1.tar.bz2.
What do you think of that?
Actually, this is probably a really, really easy way to handle it. If
you want, I'll take a stab at such a script.
Harold L Hunt II
2003-08-06 17:06:07 UTC
Permalink
Yes please.
Post by Brian E. Gallew
Post by Harold L Hunt II
To skirt the setup "Create Cygwin/XFree86 icons?" step, we could
simply stuff the above lists and a modified version of your script in
a new package called, for example,
XFree86-start-menu-icons-4.3.0-1.tar.bz2.
What do you think of that?
Actually, this is probably a really, really easy way to handle it. If
you want, I'll take a stab at such a script.
Sam Edge
2003-08-06 17:06:08 UTC
Permalink
Post by Harold L Hunt II
To skirt the setup "Create Cygwin/XFree86 icons?" step, we could simply
stuff the above lists and a modified version of your script in a new
package called, for example, XFree86-start-menu-icons-4.3.0-1.tar.bz2.
/Much/ better idea. :-D
--
Sam Edge
Jack Tanner
2003-08-06 19:15:41 UTC
Permalink
Post by Harold L Hunt II
Interesting idea. Probably the easiest thing to do here would be to
either create a list of 'term' programs or 'non-term' programs along
with a list of excluded programs. Of course, we would want to figure
out which list, 'term' or 'non-term', was going to be shortest before
deciding which to make.
To skirt the setup "Create Cygwin/XFree86 icons?" step, we could simply
stuff the above lists and a modified version of your script in a new
package called, for example, XFree86-start-menu-icons-4.3.0-1.tar.bz2.
I would go a step further. As Brian (and others) have pointed out, the
default X install contains a bunch of programs that aren't really
"important", e.g., xlogo. Creating a huge list of them in the start menu
would indeed be "clutter", and I concede that what I initially suggested
(shortcuts for all clients) would be silly. I don't know the
functionality of 90% of what's in /usr/X11R6/bin/*.exe, but I'm sure
some things are used more widely than others, and some are more and some
less appropriate for the start menu.

Here's what would be useful, though: if I install a Cygwin-ized Emacs,
for example, there should be a shortcut for it in the start menu.
Granted, I should be taking this request to Emacs' packagers, but the
folks here have unique expertise suited to this task, and perhaps could
work with apps' packagers to provide this functionality.

It would be a bad idea to install icons for apps that aren't there,
though, and so I'm tempted to argue against a
XFree86-start-menu-icons-4.3.0-1.tar.bz2. On the other hand, there may
be a smart way of writing the scripts for that tarball, such that a
particular icon is installed only if the app is actually present. This
way Emacs and all the other packages wouldn't have to be altered.

The rule of thumb for what's a good application to add to the start menu
could be this: if you use it as a GUI, and you can get reasonable
mileage out of the app without passing varying parameters on start up,
it should have a shortcut. (Filename parameters would be easy exception
to pass using the standard windows technique of drag-and-drop to start
menu.)

-JT
Brian E. Gallew
2003-08-06 19:27:07 UTC
Permalink
Post by Jack Tanner
It would be a bad idea to install icons for apps that aren't there,
though, and so I'm tempted to argue against a
XFree86-start-menu-icons-4.3.0-1.tar.bz2. On the other hand, there may
be a smart way of writing the scripts for that tarball, such that a
particular icon is installed only if the app is actually present. This
way Emacs and all the other packages wouldn't have to be altered.
Yes, there's a "good" way to do this. And it will be done that way.
Further, I'll write it so that it checks for certain common things that
aren't X packages, but still make sense to be there (e.g. emacs).
Finally, it'll be hierarchical because flat menu spaces (unlike flat
address spaces) are Evil(tm).

Oh, yeah, and my intent is to have a copy of the script in Harold's
capable hands some time tonight.
Harold L Hunt II
2003-08-06 19:58:40 UTC
Permalink
Post by Jack Tanner
Post by Harold L Hunt II
Interesting idea. Probably the easiest thing to do here would be to
either create a list of 'term' programs or 'non-term' programs along
with a list of excluded programs. Of course, we would want to figure
out which list, 'term' or 'non-term', was going to be shortest before
deciding which to make.
To skirt the setup "Create Cygwin/XFree86 icons?" step, we could
simply stuff the above lists and a modified version of your script in
a new package called, for example,
XFree86-start-menu-icons-4.3.0-1.tar.bz2.
I would go a step further. As Brian (and others) have pointed out, the
default X install contains a bunch of programs that aren't really
"important", e.g., xlogo. Creating a huge list of them in the start menu
would indeed be "clutter", and I concede that what I initially suggested
(shortcuts for all clients) would be silly. I don't know the
functionality of 90% of what's in /usr/X11R6/bin/*.exe, but I'm sure
some things are used more widely than others, and some are more and some
less appropriate for the start menu.
Yes, most of the programs would go in the 'exclude' list.
Post by Jack Tanner
Here's what would be useful, though: if I install a Cygwin-ized Emacs,
for example, there should be a shortcut for it in the start menu.
Granted, I should be taking this request to Emacs' packagers, but the
folks here have unique expertise suited to this task, and perhaps could
work with apps' packagers to provide this functionality.
It would be a bad idea to install icons for apps that aren't there,
though, and so I'm tempted to argue against a
XFree86-start-menu-icons-4.3.0-1.tar.bz2. On the other hand, there may
be a smart way of writing the scripts for that tarball, such that a
particular icon is installed only if the app is actually present. This
way Emacs and all the other packages wouldn't have to be altered.
I think the package should probably be called 'XFree86-bin-icons', that
way it is clear that you are installing icons only for the programs in
XFree86-bin. I don't want this package to have to be updated every time
someone makes a new package for Cygwin/XFree86 that might need an icon.
This was new packages could have their own -icons package if they
chose to do so. This also splits the maintenace of the icons to the
current maintainers of each Cygwin/XFree86 package, which is very important.
Post by Jack Tanner
The rule of thumb for what's a good application to add to the start menu
could be this: if you use it as a GUI, and you can get reasonable
mileage out of the app without passing varying parameters on start up,
it should have a shortcut. (Filename parameters would be easy exception
to pass using the standard windows technique of drag-and-drop to start
menu.)
Of course.

Harold
Harold L Hunt II
2003-08-06 13:23:08 UTC
Permalink
Post by Christopher Faylor
Post by Jack Tanner
2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.
This is icing on the cake. This is the kind of thing that Microsoft
hires 500 college interns to write in the summer because it takes a hell
of a lot of time and attention to detail to get it 'right', whereas the
overall benefit is very small in comparison.
Furthermore, this requires interacting with the Cygwin setup developers.
You think I am mean?
The setup developers aren't all that mean, actually. But, then neither
are you.
Heh heh...
Post by Christopher Faylor
However, I don't see why this would require any setup changes. A
postinstall script should be able to set up icons, etc. I can't decide
if the thought of a folder filled with scores of icons for X programs is
intriguing or frightening, though.
I think the thing that would require modification is the part where we
confirm with the user whether or not they want such icons to be created.
It would probably be worse to just create 100 icons without asking
than it would be to not create them at all.

Harold
Igor Pechtchanski
2003-08-06 15:53:24 UTC
Permalink
Harold,
Post by Harold L Hunt II
Post by Christopher Faylor
Post by Jack Tanner
2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.
This is icing on the cake. This is the kind of thing that Microsoft
hires 500 college interns to write in the summer because it takes a hell
of a lot of time and attention to detail to get it 'right', whereas the
overall benefit is very small in comparison.
Furthermore, this requires interacting with the Cygwin setup developers.
You think I am mean?
The setup developers aren't all that mean, actually. But, then neither
are you.
Heh heh...
Indeed.
Post by Harold L Hunt II
Post by Christopher Faylor
However, I don't see why this would require any setup changes. A
postinstall script should be able to set up icons, etc. I can't decide
if the thought of a folder filled with scores of icons for X programs is
intriguing or frightening, though.
CGF is right (on both counts ;-)). The cygwin-doc package already does
that, BTW.
Post by Harold L Hunt II
I think the thing that would require modification is the part where we
confirm with the user whether or not they want such icons to be created.
It would probably be worse to just create 100 icons without asking
than it would be to not create them at all.
Harold
I believe the suggestion of a "dialog" utility for postinstall script user
interaction has floated up on the cygwin-apps list a couple of times.
The main problem is propagating the unattended mode of setup onto it, so
there must be some setup integration (i.e., you don't want setup to sit
there waiting for user input from the desktop when running over ssh on a
remote machine). Perhaps setting an environment variable in setup to
notify the postinstall scripts that they should use the console, for
example? If you're seriously considering the icon creation suggestion,
this might be a good time to revive that discussion.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
Earle F. Philhower III
2003-08-05 04:21:20 UTC
Permalink
Howdy Harold,
Post by Harold L Hunt II
Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.
There sure are a lot of managers and architects around here recently. ;)

In any case, since it's been a couple years since I did any parser work,
I've hacked out a flex/bison parser for a generic extensible xwin.rc format,
and gotten all the info stuffed into a reasonably simple structure, now
all I need to do is crawl the structure and do CreateMenu()/AddMenuItem()
accordingly and LoadIcon(), and when creating windows compare the class
name to the ones in the prefs structure and possibly replace icon and/or
add to the system menu of that window.

I'm attaching a tar.bz2 below, give it a look-see whoever's interested
in the whole customizable menus thing, and if you want to integrate the
prefs structure parser let me know. The file format's simple and
explained in the input.rc, and has support for pretty much all that
XWin.exe can do now as far as customizations. [ Sure, you could add
an ALPHA {} block that would change the alpha-blend of windows under
Win2K and XP, but I'm not sure how really useful that would be. Maybe
a PaletteWindow style, though, for xload or xcalc... ]

For me the most interesting part was getting back up to speed on lex/yacc,
the implementing in the server is reasonably "plug-n-chug" as my physics
prof used to say.

Harold, if this is something you don't like for XWin just let me know...

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Harold L Hunt II
2003-08-05 23:31:49 UTC
Permalink
Earle,

Can't remember if I replied to this yet. I am in the process of getting
my Inspiron 8500 returned after having it replaced (bought it 3 weeks
ago). Both the original and the replacement randomly freeze. Google
for ["Inspiron 8500" freeze] and you'll see exactly what I mean. I have
been setting up computers for the past two weeks now.

I have finally ordered a Gateway 450X notebook. Hopefully that will
work better and allow me to spend a little more time looking at patches.

In other words, I might look at your patch tomorrow, or I might look at
it next week. Can't say for sure.

In any case, thanks for the patch, I like the idea and am looking
forward to seeing what it does.

Thanks for contributing,

Harold
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.
There sure are a lot of managers and architects around here recently. ;)
In any case, since it's been a couple years since I did any parser work,
I've hacked out a flex/bison parser for a generic extensible xwin.rc format,
and gotten all the info stuffed into a reasonably simple structure, now
all I need to do is crawl the structure and do CreateMenu()/AddMenuItem()
accordingly and LoadIcon(), and when creating windows compare the class
name to the ones in the prefs structure and possibly replace icon and/or
add to the system menu of that window.
I'm attaching a tar.bz2 below, give it a look-see whoever's interested
in the whole customizable menus thing, and if you want to integrate the
prefs structure parser let me know. The file format's simple and
explained in the input.rc, and has support for pretty much all that
XWin.exe can do now as far as customizations. [ Sure, you could add
an ALPHA {} block that would change the alpha-blend of windows under
Win2K and XP, but I'm not sure how really useful that would be. Maybe
a PaletteWindow style, though, for xload or xcalc... ]
For me the most interesting part was getting back up to speed on lex/yacc,
the implementing in the server is reasonably "plug-n-chug" as my physics
prof used to say.
Harold, if this is something you don't like for XWin just let me know...
-Earle F. Philhower, III
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Earle F. Philhower III
2003-08-06 04:56:26 UTC
Permalink
Howdy Harold,
Post by Harold L Hunt II
Can't remember if I replied to this yet. I am in the process of getting
my Inspiron 8500 returned after having it replaced (bought it 3 weeks
ago). Both the original and the replacement randomly freeze. Google for
["Inspiron 8500" freeze] and you'll see exactly what I mean. I have been
setting up computers for the past two weeks now.
I have finally ordered a Gateway 450X notebook. Hopefully that will work
better and allow me to spend a little more time looking at patches.
Good luck, on the bright side since it went south so fast you didn't
lose too much data on the drives.
Post by Harold L Hunt II
In other words, I might look at your patch tomorrow, or I might look at it
next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking forward
to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was really just
a parser that read the config file. It took a few hours of futzing around
today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and submenus for
the taskbar icon and each window, and can replace icons with ones specified
in the rc file.

I'm attaching the diffs against test95 below, please use these for any testing
you do (there are several new files, so if patch asks: you do want to make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the documentation
on the RC format anyone'd need. If the file's not found, you get the exact
same behaviour as test95 as far as menus/icons/etc.

** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **

Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...

Below's the sample config that I'm running that replaces the X.ico with one
that's
floating in my Windows directory, and replaces Xterm's with another, and adds
custom menus to Xterm, all other windows, and the toolbar window...

---
// Below are just some silly menus to demonstrate writing your
// own configuration file.

// Make some menus...
menu importantapps {
xsol exec "xsol -display 127.0.0.1:0.0"
xv exec "xv -display 127.0.0.1:0.0"
}

menu root {
// Comments fit here, too...
xterm exec "xterm -display 127.0.0.1:0.0"
notepad exec notepad
xload exec "xload -display 127.0.0.1:0.0" # Comment
separator
"Good Apps" menu importantapps
SEParATOR
}

menu aot {
Separator
"Always on Top" alwaysontop
}

menu xtermspecial {
"Emacs" exec "emacs" # test
"Always on Top" alwaysontop
SepArAtor
}

RootMenu root

DefaultSysMenu aot atend

SysMenu {
"xterm" xtermspecial atstart
}

IconDirectory "c:\winnt\"

DefaultIcon "reinstall.ico"

Icons {
"xterm" "uninstall.ico"
}

DEBUG "Done parsing the configuration file..."
---

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
David Fraser
2003-08-06 05:09:14 UTC
Permalink
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
In other words, I might look at your patch tomorrow, or I might look
at it next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking
forward to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was really just
a parser that read the config file. It took a few hours of futzing
around today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and
submenus for
the taskbar icon and each window, and can replace icons with ones specified
in the rc file.
I'm attaching the diffs against test95 below, please use these for any testing
you do (there are several new files, so if patch asks: you do want to make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the documentation
on the RC format anyone'd need. If the file's not found, you get the exact
same behaviour as test95 as far as menus/icons/etc.
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
Below's the sample config that I'm running that replaces the X.ico
with one that's
floating in my Windows directory, and replaces Xterm's with another, and adds
custom menus to Xterm, all other windows, and the toolbar window...
Wow! This is great! Just what we were discussing earlier...
Just one comment: Is it not possible to automatically set the DISPLAY
variable from X so that it automatically starts the xterms etc in the
right X display, rather than having to pass a commandline parameter? (In
fact, if they inherited the environment, this might happen anyway, but I
don't know if X defines DISPLAY inside itself...)

David
Harold L Hunt II
2003-08-06 13:30:40 UTC
Permalink
Earle,
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
Can't remember if I replied to this yet. I am in the process of
getting my Inspiron 8500 returned after having it replaced (bought it
3 weeks ago). Both the original and the replacement randomly freeze.
Google for ["Inspiron 8500" freeze] and you'll see exactly what I
mean. I have been setting up computers for the past two weeks now.
I have finally ordered a Gateway 450X notebook. Hopefully that will
work better and allow me to spend a little more time looking at patches.
Good luck, on the bright side since it went south so fast you didn't
lose too much data on the drives.
That is really the problem: the machines don't die; they just freeze.
So I have a computer sitting here that I can't keep my hands off but it
randomly freezes between a couple of times an hour and once every couple
of hours. Oh well, the return is authorized now, so I have to send it
back within five days :)
Post by Earle F. Philhower III
Post by Harold L Hunt II
In other words, I might look at your patch tomorrow, or I might look
at it next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking
forward to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was really just
a parser that read the config file. It took a few hours of futzing
around today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and submenus for
the taskbar icon and each window, and can replace icons with ones specified
in the rc file.
Okay.
Post by Earle F. Philhower III
I'm attaching the diffs against test95 below, please use these for any testing
you do (there are several new files, so if patch asks: you do want to make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the documentation
on the RC format anyone'd need. If the file's not found, you get the exact
same behaviour as test95 as far as menus/icons/etc.
Okay, documentation is good.
Post by Earle F. Philhower III
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Could you elaborate just a little on what this problem was? Do you
expect it to fix any crashes?
Post by Earle F. Philhower III
Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
In the end I am probably not ready to code anyone into submission, so I
will probably just accept what works, which will become the defacto
standard, etc.
Post by Earle F. Philhower III
Below's the sample config that I'm running that replaces the X.ico with
one that's
floating in my Windows directory, and replaces Xterm's with another, and adds
custom menus to Xterm, all other windows, and the toolbar window...
Interesting. I like the point raised by David Fraser about maybe making
a substitutable %DISPLAY% variable for the config file so that you can
reference the current display. How hard would that be?


Thanks for contributing,

Harold
Earle F. Philhower III
2003-08-06 14:27:43 UTC
Permalink
Howdy Harold...
That is really the problem: the machines don't die; they just freeze. So I
have a computer sitting here that I can't keep my hands off but it
randomly freezes between a couple of times an hour and once every couple
of hours. Oh well, the return is authorized now, so I have to send it
back within five days :)
That's why it's always brand-X Frankenstein machines for me. Unfortunately
laptops are the only type of machine today that really need a manufacturer.
For desktops, everyone just slaps together the same parts. I'll take good
note of the Inspiron crashes, my company is offering to buy us a computer
at Dell and I don't feel like getting a piece of junk.
Post by Earle F. Philhower III
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Could you elaborate just a little on what this problem was? Do you expect
it to fix any crashes?
Possibly some crash fixes, but definitely anything that looked at the res_name
portion of the winMultiWindowGetClassHint() function would get an unterminated
string in the heap...

len_name = strlen ((char *) prop->data);
(*res_name) = malloc (len_name + 1); <= allocated space for trailing 0
if (!*res_name) { return 0; }
strncpy ((*res_name), prop->data, len_name); <= won't copy that trailing 0!

Just changing the strncpy to
strncpy ((*res_name), prop->data, len_name+1); <= will copy that trailing 0
is the patch.
Post by Earle F. Philhower III
Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
In the end I am probably not ready to code anyone into submission, so I
will probably just accept what works, which will become the defacto
standard, etc.
You may still be correct with your worries, I'm sure there's a file descriptor
that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing
/bin/sh -c <command string>
Interesting. I like the point raised by David Fraser about maybe making a
substitutable %DISPLAY% variable for the config file so that you can
reference the current display. How hard would that be?
That's just laziness on my part. The function HandleCustomWM_COMMAND
in winmultiwindowprefs.c can do some peeking at the server setup (or
it can be passed in in the LoadPreferences() call) and then do a
strcpy followed by search-n-replace in the copied portion. The started
app sees all ENV variables that XWin.exe saw at startup, so if you set
your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
options.

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Alexander Gottwald
2003-08-06 14:49:21 UTC
Permalink
Post by Earle F. Philhower III
The started
app sees all ENV variables that XWin.exe saw at startup, so if you set
your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
options.
Don't rely on that. At our company many people are using just XWin and no
startup scripts (were using it to connect to a compute server). There is
no DISPLAY variable set.

And you don't know if the Microsoft Services for Unix will preset DISPLAY
so some very strange value *g*

bye
ago
--
***@s1999.tu-chemnitz.de
http://www.gotti.org ICQ: 126018723
Igor Pechtchanski
2003-08-06 16:10:21 UTC
Permalink
Post by Alexander Gottwald
Post by Earle F. Philhower III
The started
app sees all ENV variables that XWin.exe saw at startup, so if you set
your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
options.
Don't rely on that. At our company many people are using just XWin and no
startup scripts (were using it to connect to a compute server). There is
no DISPLAY variable set.
And you don't know if the Microsoft Services for Unix will preset DISPLAY
so some very strange value *g*
bye
ago
Two small notes here:
1) You can actually call setenv("DISPLAY", value) inside the XWin process,
which will be inherited by XWin's children.
2) You can pass an explicit environment pointer to execl (well, execle,
actually).

Either way, you don't have to rely on the outside environment.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
Igor Pechtchanski
2003-08-06 16:19:26 UTC
Permalink
Post by Igor Pechtchanski
Post by Alexander Gottwald
Post by Earle F. Philhower III
The started
app sees all ENV variables that XWin.exe saw at startup, so if you set
your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
options.
Don't rely on that. At our company many people are using just XWin and no
startup scripts (were using it to connect to a compute server). There is
no DISPLAY variable set.
And you don't know if the Microsoft Services for Unix will preset DISPLAY
so some very strange value *g*
bye
ago
1) You can actually call setenv("DISPLAY", value) inside the XWin process,
^^^^^^^^^^^^^^^^^^^^^^^^
Umm, make that {char buf[80]="DISPLAY=";putenv(strcat(buf,value));}
Sorry. The point remains, however.
Post by Igor Pechtchanski
which will be inherited by XWin's children.
2) You can pass an explicit environment pointer to execl (well, execle,
actually).
Either way, you don't have to rely on the outside environment.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
Harold L Hunt II
2003-08-06 16:29:48 UTC
Permalink
Igor,
Post by Igor Pechtchanski
Post by Igor Pechtchanski
1) You can actually call setenv("DISPLAY", value) inside the XWin process,
^^^^^^^^^^^^^^^^^^^^^^^^
Umm, make that {char buf[80]="DISPLAY=";putenv(strcat(buf,value));}
Sorry. The point remains, however.
Post by Igor Pechtchanski
which will be inherited by XWin's children.
2) You can pass an explicit environment pointer to execl (well, execle,
actually).
Either way, you don't have to rely on the outside environment.
I like your suggestions. Both of these are simpler than adding a
variable substitution system to the preferences file, and neither
require that the person writing the preferences file have any knownledge
of needing to pass any informationa about which display to run the
program on.

Harold
Harold L Hunt II
2003-08-06 15:59:01 UTC
Permalink
Post by Earle F. Philhower III
Howdy Harold...
Post by Harold L Hunt II
That is really the problem: the machines don't die; they just freeze.
So I have a computer sitting here that I can't keep my hands off but
it randomly freezes between a couple of times an hour and once every
couple of hours. Oh well, the return is authorized now, so I have to
send it back within five days :)
That's why it's always brand-X Frankenstein machines for me. Unfortunately
laptops are the only type of machine today that really need a manufacturer.
For desktops, everyone just slaps together the same parts. I'll take good
note of the Inspiron crashes, my company is offering to buy us a computer
at Dell and I don't feel like getting a piece of junk.
I concur. I just built a desktop machine to serve as a backup until the
Gateway gets here. I have an Inspiron 7500 that powers off due to a
heat problem caused by me sticking a 5400 RPM drive into it that pulls a
little too much juice. With this setup I will basically use the 7500 as
a dumb terminal to RDP into the new desktop machine. When the 7500
crashes I can just reboot it and log back in to my RDP session without
losing any work. :)

The Inspiron 8500 is the only computer of the bunch where if you google
for the model name and freeze you get a forum with 500 messages about
freezing problems. The exact query I used was "Inspiron 8500 freeze".
Of course, I didn't find this out until after I had the problem with two
machines. Below is a link to the forum:

http://delltalk.us.dell.com/supportforums/board/message?board.id=insp_general&message.id=52179&page=1
Post by Earle F. Philhower III
Post by Harold L Hunt II
Post by Earle F. Philhower III
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Could you elaborate just a little on what this problem was? Do you
expect it to fix any crashes?
Possibly some crash fixes, but definitely anything that looked at the res_name
portion of the winMultiWindowGetClassHint() function would get an unterminated
string in the heap...
len_name = strlen ((char *) prop->data);
(*res_name) = malloc (len_name + 1); <= allocated space for trailing 0
if (!*res_name) { return 0; }
strncpy ((*res_name), prop->data, len_name); <= won't copy that trailing 0!
Just changing the strncpy to
strncpy ((*res_name), prop->data, len_name+1); <= will copy that trailing 0
is the patch.
This is good. This could be the cause of some crashes, especially since
most of those have been access violations, IIRC.
Post by Earle F. Philhower III
Post by Harold L Hunt II
Post by Earle F. Philhower III
Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
In the end I am probably not ready to code anyone into submission, so
I will probably just accept what works, which will become the defacto
standard, etc.
You may still be correct with your worries, I'm sure there's a file descriptor
that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing
/bin/sh -c <command string>
Hmm... that is a good point. We have the Win32 message queue file
handle open, a feature Cygwin provides, so that we get bumped each time
a message hits the queue. After the fork shouldn't you be looping
through all file descriptors and closing all but stdin, stdout, and stderr?
Post by Earle F. Philhower III
Post by Harold L Hunt II
Interesting. I like the point raised by David Fraser about maybe
making a substitutable %DISPLAY% variable for the config file so that
you can reference the current display. How hard would that be?
That's just laziness on my part. The function HandleCustomWM_COMMAND
in winmultiwindowprefs.c can do some peeking at the server setup (or
it can be passed in in the LoadPreferences() call) and then do a
strcpy followed by search-n-replace in the copied portion. The started
app sees all ENV variables that XWin.exe saw at startup, so if you set
your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
options.
Okay. Does this mean you are going to implement the search-n-replace or
not? Just want to know whether or not to wait for it.

Harold
Earle F. Philhower III
2003-08-06 14:33:14 UTC
Permalink
Howdy David....
Post by David Fraser
Wow! This is great! Just what we were discussing earlier...
Just one comment: Is it not possible to automatically set the DISPLAY
variable from X so that it automatically starts the xterms etc in the
right X display, rather than having to pass a commandline parameter? (In
fact, if they inherited the environment, this might happen anyway, but I
don't know if X defines DISPLAY inside itself...)
Spawned commands should inherit the ENV settings at the time XWin.exe was
started, so if your startx script sets DISPLAY before starting XWin.exe then
you don't need any cmdline options.

A simple string replacement in the HandleCustomWM_COMMAND() function
in winmultiwindowprefs.c would also work to allow things like
"xterm -display %display%" to work, but it's not in the code in the patch.

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Harold L Hunt II
2003-08-10 16:58:43 UTC
Permalink
Earle,

I have committed your patch to my local tree. However, I wonder why all
of the files are prefixed with "winmultiwindow". Is the code purely
intended only for multiwindow modes? If so, that is fine. It not,
perhaps we should rebrand this before we start releasing it and
committing it to CVS.

Other than that, everything looks great. It builds fine and runs, but I
haven't had a chance to play around with the prefs file yet (my paths
are different than yours, etc.).

Thanks for contributing,

Harold
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
Can't remember if I replied to this yet. I am in the process of
getting my Inspiron 8500 returned after having it replaced (bought it
3 weeks ago). Both the original and the replacement randomly freeze.
Google for ["Inspiron 8500" freeze] and you'll see exactly what I
mean. I have been setting up computers for the past two weeks now.
I have finally ordered a Gateway 450X notebook. Hopefully that will
work better and allow me to spend a little more time looking at patches.
Good luck, on the bright side since it went south so fast you didn't
lose too much data on the drives.
Post by Harold L Hunt II
In other words, I might look at your patch tomorrow, or I might look
at it next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking
forward to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was really just
a parser that read the config file. It took a few hours of futzing
around today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and submenus for
the taskbar icon and each window, and can replace icons with ones specified
in the rc file.
I'm attaching the diffs against test95 below, please use these for any testing
you do (there are several new files, so if patch asks: you do want to make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the documentation
on the RC format anyone'd need. If the file's not found, you get the exact
same behaviour as test95 as far as menus/icons/etc.
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Oh yeah, a simple "if (fork()==0) { execl(); exit(0); }" seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
Below's the sample config that I'm running that replaces the X.ico with
one that's
floating in my Windows directory, and replaces Xterm's with another, and adds
custom menus to Xterm, all other windows, and the toolbar window...
---
// Below are just some silly menus to demonstrate writing your
// own configuration file.
// Make some menus...
menu importantapps {
xsol exec "xsol -display 127.0.0.1:0.0"
xv exec "xv -display 127.0.0.1:0.0"
}
menu root {
// Comments fit here, too...
xterm exec "xterm -display 127.0.0.1:0.0"
notepad exec notepad
xload exec "xload -display 127.0.0.1:0.0" # Comment
separator
"Good Apps" menu importantapps
SEParATOR
}
menu aot {
Separator
"Always on Top" alwaysontop
}
menu xtermspecial {
"Emacs" exec "emacs" # test
"Always on Top" alwaysontop
SepArAtor
}
RootMenu root
DefaultSysMenu aot atend
SysMenu {
"xterm" xtermspecial atstart
}
IconDirectory "c:\winnt\"
DefaultIcon "reinstall.ico"
Icons {
"xterm" "uninstall.ico"
}
DEBUG "Done parsing the configuration file..."
---
-Earle F. Philhower, III
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Earle F. Philhower III
2003-08-10 18:18:55 UTC
Permalink
Howdy Harold,
Post by Harold L Hunt II
I have committed your patch to my local tree. However, I wonder why all
of the files are prefixed with "winmultiwindow". Is the code purely
intended only for multiwindow modes? If so, that is fine. It not,
perhaps we should rebrand this before we start releasing it and committing
it to CVS.
Other than that, everything looks great. It builds fine and runs, but I
haven't had a chance to play around with the prefs file yet (my paths are
different than yours, etc.).
You're correct, the taskbar menu configuration is done for single window
mode, too. Whether that's a useful thing, I'm not really sure (it'll work
fine, but normally you'd just use your window manager's root menu and not
touch the X taskbar icon).

Before a commit, I do have a bugfix or two to post. xwinrc.2.diff throws
out a window custom icon if the window is closed thru the Windoze close
box, and the setsid() CGF suggested isn't in there either. I also added
an on-the-fly reload menu command so you don't need to restart X to
update the icons/menus. Would you like a diff against xwinrc.2.diff or
against test95?


-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Harold L Hunt II
2003-08-10 22:13:26 UTC
Permalink
Earle,
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
I have committed your patch to my local tree. However, I wonder why
all of the files are prefixed with "winmultiwindow". Is the code
purely intended only for multiwindow modes? If so, that is fine. It
not, perhaps we should rebrand this before we start releasing it and
committing it to CVS.
Other than that, everything looks great. It builds fine and runs, but
I haven't had a chance to play around with the prefs file yet (my
paths are different than yours, etc.).
You're correct, the taskbar menu configuration is done for single window
mode, too. Whether that's a useful thing, I'm not really sure (it'll work
fine, but normally you'd just use your window manager's root menu and not
touch the X taskbar icon).
Should we change the file prefixes to something along the lines of
"winprefs" then?
Post by Earle F. Philhower III
Before a commit, I do have a bugfix or two to post. xwinrc.2.diff throws
out a window custom icon if the window is closed thru the Windoze close
box, and the setsid() CGF suggested isn't in there either. I also added
an on-the-fly reload menu command so you don't need to restart X to
update the icons/menus. Would you like a diff against xwinrc.2.diff or
against test95?
Please send the diff against xwinrc.2.diff. I know that a patch can add
new files, but will it know to remove the winmultiwindow files that are
getting renamed? If not, I will try to manually remove the new files
that are renamed.

Thanks for contributing,

Harold
Igor Pechtchanski
2003-08-10 23:34:54 UTC
Permalink
[snip]
Please send the diff against xwinrc.2.diff. I know that a patch can add
new files, but will it know to remove the winmultiwindow files that are
getting renamed? If not, I will try to manually remove the new files
that are renamed.
$ patch --help
[snip]
-E --remove-empty-files Remove output files that are empty after patching.
[snip]

HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
Earle F. Philhower III
2003-08-11 04:41:27 UTC
Permalink
Howdy Harold,
Post by Harold L Hunt II
Should we change the file prefixes to something along the lines of
"winprefs" then?
Done in the attached patch, you'll want to
rm winmultiwindowprefs.[cho] winmultiwindowyacc.[ycho]
winmultiwindowlex.[lco]
to get rid of the old files. The usual drill: make Makefile; make clean;
make depend
Post by Harold L Hunt II
Please send the diff against xwinrc.2.diff. I know that a patch can add
new files, but will it know to remove the winmultiwindow files that are
getting renamed? If not, I will try to manually remove the new files that
are renamed.
I'm attaching a diff -U3 -N against xwinrc.2. It's got all the stuff
as before (custom icons, menus, etc.) with a new RELOAD command for
a menu item to reload the config files, and the bugfix for overridden
icons when closing windows through their title bars, and the setsid()
call after the FDs are closed after the fork().

The system.XWinrc file has all the documentation I've written, but I've
not been able to make myself sit down and write a man page...

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Harold L Hunt II
2003-08-12 12:49:17 UTC
Permalink
Earle,

I am taking a look at this now.

Harold
Post by Earle F. Philhower III
Howdy Harold,
Post by Harold L Hunt II
Should we change the file prefixes to something along the lines of
"winprefs" then?
Done in the attached patch, you'll want to
rm winmultiwindowprefs.[cho] winmultiwindowyacc.[ycho]
winmultiwindowlex.[lco]
to get rid of the old files. The usual drill: make Makefile; make
clean; make depend
Post by Harold L Hunt II
Please send the diff against xwinrc.2.diff. I know that a patch can
add new files, but will it know to remove the winmultiwindow files
that are getting renamed? If not, I will try to manually remove the
new files that are renamed.
I'm attaching a diff -U3 -N against xwinrc.2. It's got all the stuff
as before (custom icons, menus, etc.) with a new RELOAD command for
a menu item to reload the config files, and the bugfix for overridden
icons when closing windows through their title bars, and the setsid()
call after the FDs are closed after the fork().
The system.XWinrc file has all the documentation I've written, but I've
not been able to make myself sit down and write a man page...
-Earle F. Philhower, III
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Earle F. Philhower, III
2003-08-06 16:48:57 UTC
Permalink
Howdy Harold...

..
Post by Harold L Hunt II
Post by Earle F. Philhower III
You may still be correct with your worries, I'm sure there's a file
descriptor
that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing
/bin/sh -c <command string>
Hmm... that is a good point. We have the Win32 message queue file
handle open, a feature Cygwin provides, so that we get bumped each time
a message hits the queue. After the fork shouldn't you be looping
through all file descriptors and closing all but stdin, stdout, and stderr?
..

That's the exact thing I was thinking about, but unfortunately I haven't
got a clue how to get a list of all open file descriptors under cygwin.
There's a Solaris function fdwalk(), but I don't think that's POSIX standard
or even available on cygwin. I suppose after the fork() you could do:
struct rlimit rl;
int i;
getrlimit(RLIMIT_NOFILE, &rl);
for (i = STDERR_FILENO+1; i < rl.rlim_max; i++)
(void) close(i);
but that seems wasteful to iterate over rlim_max...

..
Post by Harold L Hunt II
Okay. Does this mean you are going to implement the search-n-replace or
not? Just want to know whether or not to wait for it.
I like the put_env() idea that folks are suggesting, but I think it'd probably
still be worthwhile to also do the string substitution. It's not that big of a
deal to add both. Tonight I'll give that a go, adding the put_env() call in
the LoadPrefs as well as a %display% substitution in LoadPrefs()...
--
-Earle F. Philhower, III
***@ziplabel.com
http://www.ziplabel.com
Harold L Hunt II
2003-08-06 17:06:55 UTC
Permalink
The for loop that you have is the way I have seen it done before.

Harold
Post by Earle F. Philhower III
Howdy Harold...
..
Post by Harold L Hunt II
Post by Earle F. Philhower III
You may still be correct with your worries, I'm sure there's a file
descriptor
that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing
/bin/sh -c <command string>
Hmm... that is a good point. We have the Win32 message queue file
handle open, a feature Cygwin provides, so that we get bumped each time
a message hits the queue. After the fork shouldn't you be looping
through all file descriptors and closing all but stdin, stdout, and stderr?
..
That's the exact thing I was thinking about, but unfortunately I haven't
got a clue how to get a list of all open file descriptors under cygwin.
There's a Solaris function fdwalk(), but I don't think that's POSIX standard
struct rlimit rl;
int i;
getrlimit(RLIMIT_NOFILE, &rl);
for (i = STDERR_FILENO+1; i < rl.rlim_max; i++)
(void) close(i);
but that seems wasteful to iterate over rlim_max...
..
Post by Harold L Hunt II
Okay. Does this mean you are going to implement the search-n-replace or
not? Just want to know whether or not to wait for it.
I like the put_env() idea that folks are suggesting, but I think it'd probably
still be worthwhile to also do the string substitution. It's not that big of a
deal to add both. Tonight I'll give that a go, adding the put_env() call in
the LoadPrefs as well as a %display% substitution in LoadPrefs()...
Christopher Faylor
2003-08-06 17:29:18 UTC
Permalink
Post by Harold L Hunt II
The for loop that you have is the way I have seen it done before.
Me too. However, if you can find an API specification for something
which does something similar in the Single Unix Specification, I'd be
happy to implement it in the cygwin DLL. It is trivial to do. I just
want to provide a standard interface, if possible. Couldn't find one in
my brief search of SUSv3.

cgf
Post by Harold L Hunt II
Post by Earle F. Philhower, III
That's the exact thing I was thinking about, but unfortunately I haven't
got a clue how to get a list of all open file descriptors under cygwin.
There's a Solaris function fdwalk(), but I don't think that's POSIX standard
struct rlimit rl;
int i;
getrlimit(RLIMIT_NOFILE, &rl);
for (i = STDERR_FILENO+1; i < rl.rlim_max; i++)
(void) close(i);
but that seems wasteful to iterate over rlim_max...
Earle F. Philhower III
2003-08-07 01:45:22 UTC
Permalink
Howdy Christopher, Igor, and Harold...

...
Post by Igor Pechtchanski
1) You can actually call setenv("DISPLAY", value) inside the XWin process,
which will be inherited by XWin's children.
...
Post by Igor Pechtchanski
Post by Harold L Hunt II
The for loop that you have is the way I have seen it done before.
Me too. However, if you can find an API specification for something
which does something similar in the Single Unix Specification, I'd be
...>> getrlimit(RLIMIT_NOFILE, &rl);
Post by Harold L Hunt II
Post by Earle F. Philhower, III
for (i = STDERR_FILENO+1; i < rl.rlim_max; i++)
(void) close(i);
but that seems wasteful to iterate over rlim_max...
(make that rlim_cur, closing 4 billion descriptors takes too long...)

I'm attaching another diff (against test95 plain), be sure to so a
"make Makefiles" and "make depend" before "make XWin.exe".

It does all the prior stuff and
a) Closes all fds on the fork()'d process
b) Sets environment variable DISPLAY=xxx:yy
c) Replaces %display% with 127.0.0.1:<display>.0 in commands
d) Better syntax error display, gives lineno and expected token in XWin.log
e) Error messages in log when it can't load an icon/etc.
f) Checks WM_NAME property for a match for icons, not just class name
^^ Pretty neat in use, I have my fast Linux machine xterms with
titlebars like "Linux:machinename:$cwd" and Hobbes (Calvin&Hobbes)
icon,
and my slow Sun machine xterms with a CharlieBrown icon!


-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Christopher Faylor
2003-08-07 01:57:19 UTC
Permalink
Post by Earle F. Philhower III
Howdy Christopher, Igor, and Harold...
...
Post by Igor Pechtchanski
1) You can actually call setenv("DISPLAY", value) inside the XWin process,
which will be inherited by XWin's children.
...
Post by Igor Pechtchanski
Post by Harold L Hunt II
The for loop that you have is the way I have seen it done before.
Me too. However, if you can find an API specification for something
which does something similar in the Single Unix Specification, I'd be
...>> getrlimit(RLIMIT_NOFILE, &rl);
Post by Harold L Hunt II
Post by Earle F. Philhower, III
for (i = STDERR_FILENO+1; i < rl.rlim_max; i++)
(void) close(i);
but that seems wasteful to iterate over rlim_max...
(make that rlim_cur, closing 4 billion descriptors takes too long...)
I'm attaching another diff (against test95 plain), be sure to so a
"make Makefiles" and "make depend" before "make XWin.exe".
It does all the prior stuff and
a) Closes all fds on the fork()'d process
It *may* be helpful to call setsid() at this point, after you've closed
the file descriptors.

cgf
Earle F. Philhower III
2003-08-07 02:24:32 UTC
Permalink
Howdy Christopher...
Post by Christopher Faylor
Post by Earle F. Philhower III
a) Closes all fds on the fork()'d process
It *may* be helpful to call setsid() at this point, after you've closed
the file descriptors.
I'm not really up on cygwin's process model, what would the setsid() call
do? I have read the man page and I'm still not sure what's a session ID or
why I'd want a new one...

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Christopher Faylor
2003-08-07 03:00:50 UTC
Permalink
Post by Earle F. Philhower III
Howdy Christopher...
Post by Christopher Faylor
Post by Earle F. Philhower III
a) Closes all fds on the fork()'d process
It *may* be helpful to call setsid() at this point, after you've closed
the file descriptors.
I'm not really up on cygwin's process model, what would the setsid() call
do? I have read the man page and I'm still not sure what's a session ID or
why I'd want a new one...
It would disassociate a tty from any child process. It's often done
after file descriptors have been closed.

I don't know for sure that it will help anything but it may stop the
console windows from popping up -- at least in cygwin 1.5.x.

cgf
Earle F. Philhower III
2003-08-08 00:36:10 UTC
Permalink
Howdy again Christopher...
Post by Christopher Faylor
Post by Earle F. Philhower III
I'm not really up on cygwin's process model, what would the setsid() call
do? I have read the man page and I'm still not sure what's a session ID or
why I'd want a new one...
It would disassociate a tty from any child process. It's often done
after file descriptors have been closed.
I don't know for sure that it will help anything but it may stop the
console windows from popping up -- at least in cygwin 1.5.x.
Thanks, I added the setsid() just after closing all but STDIN/OUT/ERR
and before the execl() and didn't notice any problems, so next time
I put up a patch it'll have this change included. [Of course, I'm
running Cygwin 1.3 and not the 1.5 you're working on...]

I also found a small bug where if you close a window with a shared
icon from the ICONS{} section it deletes the icon even though it
shouldn't. I'm just waiting for more input on the whole
"What should DISPLAY be set to?" question before I clutter up the
mailing list with another patch...

Except for that, the only thing I can think of adding is a 'reread
the prefs file' command to the MENU{} format. Has anyone else
tried the .xwinrc yet?

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Christopher Faylor
2003-08-08 02:58:32 UTC
Permalink
Post by Earle F. Philhower III
Howdy again Christopher...
Post by Christopher Faylor
Post by Earle F. Philhower III
I'm not really up on cygwin's process model, what would the setsid() call
do? I have read the man page and I'm still not sure what's a session ID
or
Post by Earle F. Philhower III
why I'd want a new one...
It would disassociate a tty from any child process. It's often done
after file descriptors have been closed.
I don't know for sure that it will help anything but it may stop the
console windows from popping up -- at least in cygwin 1.5.x.
Thanks, I added the setsid() just after closing all but STDIN/OUT/ERR
and before the execl() and didn't notice any problems, so next time
I put up a patch it'll have this change included. [Of course, I'm
running Cygwin 1.3 and not the 1.5 you're working on...]
...so watch how it will cause cygwin to crash and burn when you port to
1.5.1... :-)

cgf
Harold L Hunt II
2003-08-07 02:40:01 UTC
Permalink
Earle F. Philhower III wrote:

The most recent patch looks pretty good from your description.
Post by Earle F. Philhower III
c) Replaces %display% with 127.0.0.1:<display>.0 in commands
Huh, I was going to say that %display% should be replaced with
"127.0.0.1:0.0", but then I remembered that we know the "0.0", but we
don't know that the user connected via "127.0.0.1". However, should we
just choose to replace display with "127.0.0.1:d.s" where d is display
and s is screen? I know that some users report better performance when
using their actual ip instead of lookback for DISPLAY...

Ugh... what should we do here? Leave it as you did it?

Harold
Ralf Habacker
2003-08-07 08:57:31 UTC
Permalink
Hi all,
Post by Harold L Hunt II
The most recent patch looks pretty good from your description.
Post by Earle F. Philhower III
c) Replaces %display% with 127.0.0.1:<display>.0 in commands
Huh, I was going to say that %display% should be replaced with
"127.0.0.1:0.0", but then I remembered that we know the "0.0", but we
don't know that the user connected via "127.0.0.1". However, should we
just choose to replace display with "127.0.0.1:d.s" where d is display
and s is screen? I know that some users report better performance when
using their actual ip instead of lookback for DISPLAY...
... because the performance of cygwin's tcp implementation is more than twice as
much as the unix domain implementation.
I assume that this is caused by the additional security and emulation stuff
overhead, which is needed to implement unix domain sockets on top of tcp
sockets.

See http://sources.redhat.com/ml/cygwin/2002-01/msg01719.html for further
details.

Ralf
Harold L Hunt II
2003-08-07 12:41:00 UTC
Permalink
Ralf,

If my IP is w.x.y.z vs. my loopback of 127.0.0.1, how is one of these
using unix domain sockets and the other using tcp/ip?

Harold
Post by Ralf Habacker
Hi all,
Post by Harold L Hunt II
The most recent patch looks pretty good from your description.
Post by Earle F. Philhower III
c) Replaces %display% with 127.0.0.1:<display>.0 in commands
Huh, I was going to say that %display% should be replaced with
"127.0.0.1:0.0", but then I remembered that we know the "0.0", but we
don't know that the user connected via "127.0.0.1". However, should we
just choose to replace display with "127.0.0.1:d.s" where d is display
and s is screen? I know that some users report better performance when
using their actual ip instead of lookback for DISPLAY...
... because the performance of cygwin's tcp implementation is more than twice as
much as the unix domain implementation.
I assume that this is caused by the additional security and emulation stuff
overhead, which is needed to implement unix domain sockets on top of tcp
sockets.
See http://sources.redhat.com/ml/cygwin/2002-01/msg01719.html for further
details.
Ralf
Ralf Habacker
2003-08-07 19:20:15 UTC
Permalink
Hi Harold,
Post by Harold L Hunt II
If my IP is w.x.y.z vs. my loopback of 127.0.0.1, how is one of these
using unix domain sockets and the other using tcp/ip?
you're right, the answer is off-topic for this issue. I had read a note about
using DISPLAY=:0, which means using unix domain socket and for that my answer
was target. I only choosed the wrong mail. Sorry for confusing.

Ralf
Earle F. Philhower III
2003-08-07 02:54:29 UTC
Permalink
Howdy Harold...
Post by Harold L Hunt II
Post by Earle F. Philhower III
c) Replaces %display% with 127.0.0.1:<display>.0 in commands
Huh, I was going to say that %display% should be replaced with
"127.0.0.1:0.0", but then I remembered that we know the "0.0", but we
don't know that the user connected via "127.0.0.1". However, should we
just choose to replace display with "127.0.0.1:d.s" where d is display and
s is screen? I know that some users report better performance when using
their actual ip instead of lookback for DISPLAY...
Ugh... what should we do here? Leave it as you did it?
I plead innocence! Actually, 127.0.0.1 is what the clipboard and WM
connect to, so I just left it at that. As for screens, I chose 0 because
while you can have multiple screens per server, what one do you choose
when you do something from a menu? If I choose "xterm" from the taskbar,
which screen does that mean? Seriously, I couldn't think of a good
answer. I don't really have any love for one or the other method,
whatever works is OK by me...

I shudder to imagine how the loopback adapter is slower than an IP
lookup, and double-shudder when you can actually notice the difference
with XWin being so slow updating the screen anyway...

-Earle F. Philhower, III
***@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Sam Edge
2003-08-06 16:56:49 UTC
Permalink
Post by Jack Tanner
1. X should run as a service. There's no reason for it to run as a
user-launched app.
Harold's dealt with this one. An X-server on Windows is not a
background service. It makes no sense whatsoever to have it running
when nobody's logged in. Therefore the StartUp folder is the place for
it or in
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Run, if
and only if the particular user wants to have it start when he logs in
to Windows.
Post by Jack Tanner
2. All X client application on one's machine should have shortcuts
associated with them in the start menu, and these shortcuts should be
created automatically during installation.
No thanks.
a.) If I'm running Cygwin/Xfree86 as a X-terminal to another machine,
I don't use local X client programs anyway.
b.) If I'm running Cygwin/Xfree86 with a manager like openbox or
WindowMaker, they have their own configurable menus for launching
programs which are a more appropriate place for this.
c.) Even if I'm running local clients and using the "-multiwindow"
option, the programs to which I want mouse-click access aren't
necessarily the same as the ones you'd want. I certainly don't want to
clutter up the start menu with /every/ X client on the system. That
would quickly become an unmanageably large menu.
Post by Jack Tanner
3. Exiting X (e.g., by stopping the service) should list all cygwin
processes that were launched under X and prompt the user to terminate
them. For example, an ssh-agent launched from an xterm should be killed
automatically.
This is entirely the wrong way to go about things.

It's the job of your X session manager interacting with the clients on
the X desktop to provide this sort of "Shutting down now. Please save
files. Okay to exit?" functionality, not of the X server. You can then
use the -once switch to make the X server exit cleanly after the last
client - i.e. the session manager - exits.

It /would/ make sense for the -multiwindow window manager to implement
X session-end functionality when the user (Alt-F4/Close) or system
(WM_QUERYENDSESSION) requests X server shutdown. But this should
/only/ happen in -multiwindow mode.

As Harold has pointed out, even without a session manager handling
session-end requests, X clients exit when the server closes down.

Other things like ssh-agent should shut down only when I tell them
too. Just because I'm ending a X session doesn't mean I'm not going to
continue using ssh from a Windows-GUI rxvt or console shell.
Post by Jack Tanner
I know there are ways of approximating these behaviors now; I'm just
suggesting that these be built in.
Absolutely not. The X server should be an X server. If you want a
session manager, install a session manager. (If you don't have one,
write one or convince someone to write one.)

That way you get the functionality you want while I can choose not to
use up disc/memory/CPU resources on my machine on something I don't
want.

Try looking up the term "feature bloat" some time. ;-)

Regards
--
Sam Edge
Continue reading on narkive:
Loading...