uxterm from xterm-185-2 not working and Unicode related craches from xterm

2004-03-23 Thread Dr. Volker Zell
Hi list

When running uxterm from xterm-185-2 I get

12:47 PM [126] uxterm
xterm:  bad command line option -u8

usage:  xterm [-/+132] [-C] [-Sccn] [-T string] [-/+ah] [-/+ai] [-/+aw]
[-b number] [-/+bc] [-bcf milliseconds] [-bcn milliseconds] [-bd color]
[-/+bdc] [-bg color] [-bw number] [-/+cb] [-cc classrange] [-class string]
[-/+cm] [-/+cn] [-cr color] [-/+cu] [-/+dc] [-display displayname]
[-e command args ...] [-fa pattern] [-fb fontname] [-/+fbb] [-/+fbx]
[-fd pattern] [-fg color] [-fi fontname] [-fn fontname] [-fs size]
[-fx fontname] [#geom] [%geom] [-geometry geom] [-hc color] [-help]
[-/+hold] [-iconic] [-/+ie] [-/+im] [-into windowId] [-/+j] [-/+k8] [-/+l]
[-leftbar] [-lf filename] [-/+ls] [-/+mb] [-mc milliseconds] [-/+mesg]
[-ms color] [-n string] [-name string] [-nb number] [-/+nul] [-/+pc]
[-/+pob] [-rightbar] [-/+rv] [-/+rvc] [-/+rw] [-/+s] [-/+samename] [-/+sb]
[-/+sf] [-/+si] [-/+sk] [-sl number] [-/+sm] [-/+sp] [-/+t] [-ti termid]
[-title string] [-tm string] [-tn name] [-/+ulc] [-/+ut] [-/+vb] [-version]
[-/+wf] [-xrm resourcestring] [-ziconbeep percent]

Type xterm -help for a full description.

This used to work before decoupling xterm from XFree86-bin.

Additionally before, I could use the following command line to display
Unicode characters in an xterm with the sample text file at
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

[EMAIL PROTECTED] /tmp
12:46 PM [93] LC_CTYPE=en_GB.UTF-8 xterm -fn 
'-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1' -sb

Now it crashes :-((

(gdb) bt
#0  0x6fd08e84 in cygX11-6!XFreeFont () from /usr/X11R6/bin/cygX11-6.dll
#1  0x6fd08418 in cygX11-6!XLoadQueryFont () from /usr/X11R6/bin/cygX11-6.dll
#2  0x0041329a in ?? ()
#3  0x0a0472f8 in ?? ()
#4  0x0a054e5c in ?? ()


Any hints ? Can anybody confirm ?

This looks the same like the bt from my already reported crash with xfontsel:

(gdb) bt
#0  0x6fd08e84 in cygX11-6!XFreeFont () from /usr/X11R6/bin/cygX11-6.dll
#1  0x6fd08418 in cygX11-6!XLoadQueryFont () from /usr/X11R6/bin/cygX11-6.dll
#2  0x00403299 in ?? ()
#3  0x0a043680 in ?? ()
#4  0x0a05ff88 in ?? ()
(gdb)

Ciao
  Volker



Re: uxterm from xterm-185-2 not working and Unicode related craches from xterm

2004-03-23 Thread Thomas Dickey
On Tue, 23 Mar 2004, Dr. Volker Zell wrote:

 Hi list

 When running uxterm from xterm-185-2 I get

 12:47 PM [126] uxterm
 xterm:  bad command line option -u8

The imake configuration normally enables this code; the configure normally
does not.  There was some discussion last week about choosing appropriate
options for the configure script (which appears to be the basis for the
new package), and it was noted that the --enable-wide-chars option was not
yet being used.  That's needed to compile-in support for -u8.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


Re: XWin 4.3.0-50 crashes with -multiwindow

2004-03-23 Thread fabrizio . ge
Harold and all,
I built XWin from source and debugged with gdb, and in that way I was able
to track down the bug. It is due to my visual being 24bpp. It does not occur
if it is changed to 16bpp. 32bpp is not available, but I am confident everything
would work in that case.

Here is what happens:
- winScaleXBitmapToWindows is called. The pixmap passed has height 42, width
48 and bitsPerPixel 24
- effXBPP is 24, xStride is 144 (48*(24/8))
- iconData is allocated as an array of 144*42 bytes
- then, miGetImage is called. Here the line

linelength = PixmapBytePad(w, depth);

is executed with w=48 and depth=24. As a result, linelength is 192 (48*4),
not 144 (48*3).
- in the following for cycle, pDst (initialized as iconData) is incremented
by linelength(=192) each time. Soon the pointer overflows the allocated
bounds, causing the crash.

It seems that handling of 24-bit display is broken. Maybe winScaleXBitmapToWindows
should use PixmapBytePad to calculate xStride, but I'm only guessing as
I'm not an expert.

Regards,
Fabrizio

I then compiled VICE (http://www.viceteam.org) and launched the program
x64 with option -display in order to make it use my Cygwin X server. If
the
server is launched with -multiwindow, it crashes



__
ADSL Senza Canone 640Kbps:
attivala entro il 31 marzo e avrai GRATIS il costo di adesione,
quello di attivazione e il modem per tutto il 2004.
E per i primi 3 mesi navighi a 1,5 euro l'ora! Affrettati!
http://point.tiscali.it/adsl/prodotti/senzacanone/





XWin -clipboard Bug

2004-03-23 Thread Andreas_Vogler
Hi, 
i want to report a bug to the -clipboard Option:

I Startet the Xserver with: -emulate3buttons -multiwindow -clipboard

The Xsession is startet via putty xtunnel or also with exporting Display 
diekt.

From the Xwin.log:

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 4.3.0.59
Contact: [EMAIL PROTECTED]

The Problem is when starting vim -g

When Selecting something in the vim -g (Marking for copying)
it could be copied to windows but only once. Every next marking will copy 
to another xwinows the new next, but to windows the old text is copied.
When Marking another text in another xwindows or copying somthing from 
windows, let the Marikng work in the vi -g again for the next time, but 
ony one time again

In the Xwinlog it apears: 
winInitMultiWindowWM - XOpenDisplay () returned and successfully opened 
the display.
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened 
the display.
winClipboardProc - XOpenDisplay () returned and successfully opened the 
display.
winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
winClipboardFlushXEvents - SelectionNotify - XConvertSelection () failed, 
aborting: 1
winClipboardFlushXEvents - SelectionNotify - XConvertSelection () failed, 
aborting: 1



The error is reproduceable on linux, sun,aix


I Hope my Report helps.


See you
Andreas


Russian Keymap

2004-03-23 Thread David Snopek

Hi,

I am trying to get gtypist working under cygwin so I can learn to type
better in Russian.  I have a US keyboard that should be maped to Russian
the same way MS Windows does (not sure if this is the only way).  I can
get xterm to show cyrillic characters properly using -fn.  But nothing I
try can get the keymap right.  Doing setxkbmap ru will cause xterm to
show nothing on keypress and gtypist will show '^' characters.

Thank you,
  - #1044;#1072;#1074;#1080;#1076;.

PS: I am not on the list, so remember to CC: me!!


Cjdsop

2004-03-23 Thread roman coons
word-processors  zaslow  welshy  wdence  tortech

The reason I'm telling you this is because Ciális, something even better
than Viagrá is now the answer.
Pls go here:
http://wppk.g.we3s45.com/se/
0nly 1.75 per d0se
Worldwide avaliable



No more:  h.eq.erpices.com/a.html
I'd like you to come right over, a man phoned an undertaker,  and 
supervise the burial of my poor, departed wife.Your wife! gasped the
undertaker, Didn't I bury her two years ago?You don't understand, said
the man,  You see I married again.Oh, said the undertaker,
Congratulations!
A local bar was so sure that its bartender was the strongest man around
that they offered a standing $1,000 bet. The bartender would squeeze a lemon
until all the juice ran into a glass, and hand the lemon to a patron. Anyone
who could squeeze one more drop of juice out would win the money. Many
people had tried over time (weightlifters, longshoremen, etc.) but nobody
could do it. One day a scrawny little man wearing thick glasses and a
polyester suit came in and said in a tiny, squeaky voice, I'd like to try
the bet. After the laughter had died down, the bartender said okay, grabbed
a lemon, and squeezed away. Then he handed the wrinkled remains of the rind
to the little man. But the crowd's laughter turned to total silence as the
man clenched his fist around the lemon and six drops fell into the glass. As
the crowd cheered, the bartender paid the $1,000, and asked the little man,
What do you do for a living? Are you a lumberjack, a weightlifter, or
what? The man replied, I work for the IRS.
mbjmr0ukumisa87qho 



Re: Russian Keymap

2004-03-23 Thread Alexander Gottwald
On Tue, 23 Mar 2004, David Snopek wrote:

 
 Hi,
 
 I am trying to get gtypist working under cygwin so I can learn to type
 better in Russian.  I have a US keyboard that should be maped to Russian
 the same way MS Windows does (not sure if this is the only way).  I can
 get xterm to show cyrillic characters properly using -fn.  But nothing I
 try can get the keymap right.  Doing setxkbmap ru will cause xterm to
 show nothing on keypress and gtypist will show '^' characters.

what does xev report on keypress?

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723


Re: uxterm from xterm-185-2 not working and Unicode related craches from xterm

2004-03-23 Thread Harold L Hunt II
I'm preparing xterm-185-3 right now using --enable-wide-chars.

It wasn't clear to me if I should do this the first time around, so I 
figured I would just enable it later if it turned out to be needed and 
worked on Cygwin.  Looks like that is the case.  :)

Harold

Thomas Dickey wrote:

On Tue, 23 Mar 2004, Dr. Volker Zell wrote:


Hi list

When running uxterm from xterm-185-2 I get

12:47 PM [126] uxterm
xterm:  bad command line option -u8


The imake configuration normally enables this code; the configure normally
does not.  There was some discussion last week about choosing appropriate
options for the configure script (which appears to be the basis for the
new package), and it was noted that the --enable-wide-chars option was not
yet being used.  That's needed to compile-in support for -u8.


Re: Russian Keymap

2004-03-23 Thread David Snopek

Alexander Gottwald said:
 On Tue, 23 Mar 2004, David Snopek wrote:


 Hi,

 I am trying to get gtypist working under cygwin so I can learn to type
 better in Russian.  I have a US keyboard that should be maped to Russian
 the same way MS Windows does (not sure if this is the only way).  I can
 get xterm to show cyrillic characters properly using -fn.  But nothing I
 try can get the keymap right.  Doing setxkbmap ru will cause xterm to
 show nothing on keypress and gtypist will show '^' characters.

 what does xev report on keypress?

KeyPress event, serial 17, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 6207984, (442,250), root:(512,367),
state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES,
XLookupString gives 0 bytes:  

KeyRelease event, serial 22, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 6208109, (442,250), root:(512,367),
state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES,
XLookupString gives 0 bytes:  

So it knows when I press #1072; that its the cyrillic a but the
XLookupString returns  as the represention?

Thank you.
  -- David Snopek

Satellite Computing Solutions, LLC


Re: Russian Keymap

2004-03-23 Thread Alexander Gottwald
David Snopek wrote:

 KeyPress event, serial 17, synthetic NO, window 0xc1,
 root 0x3a, subw 0x0, time 6207984, (442,250), root:(512,367),
 state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES,
 XLookupString gives 0 bytes:  

 KeyRelease event, serial 22, synthetic NO, window 0xc1,
 root 0x3a, subw 0x0, time 6208109, (442,250), root:(512,367),
 state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES,
 XLookupString gives 0 bytes:  

 So it knows when I press #1072; that its the cyrillic a but the
 XLookupString returns  as the represention?

This worked for me (running linux):
(taken from http://koi8.pp.ru/frame.html?/xwin.html)

$ export LANG=ru_RU.KOI8-R
$ xev

KeyPress event, serial 27, synthetic NO, window 0x2c1,
root 0x48, subw 0x2c2, time 2609951, (41,46), root:(46,890),
state 0x0, keycode 38 (keysym 0x6c6, Cyrillic_ef), same_screen YES,
XLookupString gives 1 bytes:  Æ

KeyRelease event, serial 27, synthetic NO, window 0x2c1,
root 0x48, subw 0x2c2, time 2610073, (41,46), root:(46,890),
state 0x0, keycode 38 (keysym 0x6c6, Cyrillic_ef), same_screen YES,
XLookupString gives 1 bytes:  Æ

Please report if it works.

bye
ago

NP: Lights Of Euphoria - True Life (God Module Remix)
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723


Re: Remote KDE with Cygwin X

2004-03-23 Thread Harold L Hunt II
Peter,

How are you starting Cygwin/X?  It sounds like you are using startx, 
startxwin.sh, or startxwin.bat, all of which will start the server in 
multi-window mode which will crash if you try to run KDE remotely 
because both multi-window mode and KDE will be trying to run window 
managers at the same time when you can only run one at a time.

Please send in /tmp/XWin.log from one of these attempts so we can figure 
out the command line being passed to XWin.exe.

Harold

Peter Graf wrote:

Hello

I want to report a strange problem I have since yesterday
since I upgraded Cygwin X base to 4.3.0-9. I upgraded my 
entire cygwin installation to the version available yesterday.

I have a WinXP laptop and a linux server that has no monitor.
I have had this setup for over a year now, Cygwin X always 
worked perfectly for it, I have also not changed the KDE
on the server lately.

I run KDE remotely on my laptop when I use the Linux server by
- starting XWin.exe with one xterm inside on the laptop
- ssh'ing to the server: ssh -X -l user server
- starting KDE on the server: kde
After yesterday's upgrade I now have the strange effect
that launching and running the KDE hangs at various stages unless
I select some text from the initial xterm window with the mouse.
Like: KDE is running, I want to start Konqueror and click on it's
Icon, nothing happens, once I bring the xterm window, which I used
for ssh'ing to the server and starting the kde from, into the 
foreground and highlight some text in it with the mouse,
konqueror appears.

I only detected the workaround, because KDE hung during launch
and I wanted to highlight and copy/paste the messages from the
xterm window to a mail I wanted to send to this group.
All of a sudden the launch proceeded then hung again, .
I somehow have the feeling the problem has something to do
with the clipboard, I do not know enough to really say :-(.
Maybe this post helps somebody figuring out the problem.
I can live with my workaround so far.
Greetings,

Peter   

--
--
Peter Graf, http://mission.base.com


Re: Cygwin Tk for X?

2004-03-23 Thread Jeffrey C Honig
Harold L Hunt II huntharo at msu dot edu wrote:

 Jeffrey C Honig wrote:
 
  Is it just because no-one has taken the time to build it?
 
 Yes, that is sort of it.  In other words, people are open to the idea
 of adding an X11 version of Tk, but it needs to be done in a way that
 allows both the X11 and Win32 versions to be installed at the same
 time. This sort of splitting, renaming, and script foo will take about
 60 hours.  So, it isn't just that people are lazy, it is that it will
 take a significant amount of time to complete all of the tasks, test
 it, and fix errors in the packaging scheme.  I've thought about doing
 this at times, but I haven't got time for it at the moment.

I do not have that kind of time either.  Is it a project we can outline
and have people work on a bit at a time?

Thanks.

Jeff

-- 
Jeffrey C. Honig [EMAIL PROTECTED]
http://www.honig.net/jch
GnuPG ID:14E29E13 http://www.honig.net/jch/key.shtml


Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)

2004-03-23 Thread Earle F. Philhower III
Howdy Fabrizio, Harold.

Thanks for the good debug Fabrizio!  The 24bpp icon handling was
something I never could test: I couldn't find any apps that had
24bpp icons, all I found were 1- 15-, 16-, or 32-bit ones.
I was assuming the X server always used a packed format, but
PixmapBytePad() looks to be the proper way of handling this.
(Can I ask how you knew?  I did a Google on the macro and didn't
come up with anything of interest, I only found stuff in the
header files themselves...)
Harold, the xStride calc looks great, but by removing the conversion
of 15-bpp modes into effective 16-bpp modes will break 15bpp icon
handling.  15-bpp modes are handled exactly the same as 16bpp modes,
except they are not bit-packed (there's 1 extra unused bit every
pixel) so you can't do (bpp/8).
To fix it we can reinstate the if()...
   if (pixmap-drawable.bitsPerPixel == 15)
 effXBPP = 16;
   else
 effXBPP = pixmap-drawable.bitsPerPixel;
   if (pixmap-drawable.depth == 15)
 effXDepth = 16;
   else
 effXDepth = pixmap-drawable.depth;
Or get rid of the effX* variables completely, but modify (~line 218)
 if (effxdepth==16) into
into
 if (xdepth==16 || xdepth==15)
and modify all of the X image ptr walking
 ptr += posX * (effXBPP / 8);
into
 ptr += (xbpp==15)?(posX * (16/8):(posX * (xbpp/ 8));
If you'd like I can do it, just let me know which one would be
more appealing!  Personally I find the effX variables make the routine
a bit more readable, but that's kind of expected since I put them
there in the first place...


At 07:49 PM 3/23/2004 -0500, you wrote:
Fabrizio,

It looks like your conclusions are correct.

I have included your suggested change in XFree86-xserv-4.3.0-60.  Please 
test this on a 24 bit depth system.  It seems to work okay on 32 bit depth 
systems.

I checked the change into CVS as well.  I think that Earle should probably 
take a look at it to verify that it is likely correct since there are 
several calculations to correct the depth and bpp values, which may be 
made redundant by just using PixmapBytePad instead; but the function 
confuses me too much to understand it quickly.

Harold

wrote:

Harold and all,
I built XWin from source and debugged with gdb, and in that way I was able
to track down the bug. It is due to my visual being 24bpp. It does not occur
if it is changed to 16bpp. 32bpp is not available, but I am confident 
everything
would work in that case.
Here is what happens:
- winScaleXBitmapToWindows is called. The pixmap passed has height 42, width
48 and bitsPerPixel 24
- effXBPP is 24, xStride is 144 (48*(24/8))
- iconData is allocated as an array of 144*42 bytes
- then, miGetImage is called. Here the line
linelength = PixmapBytePad(w, depth);
is executed with w=48 and depth=24. As a result, linelength is 192 (48*4),
not 144 (48*3).
- in the following for cycle, pDst (initialized as iconData) is incremented
by linelength(=192) each time. Soon the pointer overflows the allocated
bounds, causing the crash.
It seems that handling of 24-bit display is broken. Maybe 
winScaleXBitmapToWindows
should use PixmapBytePad to calculate xStride, but I'm only guessing as
I'm not an expert.
Regards,
Fabrizio
-Earle F. Philhower, III
 [EMAIL PROTECTED]
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com



Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)

2004-03-23 Thread Harold L Hunt II
Earle,

Earle F. Philhower III wrote:

Howdy Fabrizio, Harold.

Thanks for the good debug Fabrizio!  The 24bpp icon handling was
something I never could test: I couldn't find any apps that had
24bpp icons, all I found were 1- 15-, 16-, or 32-bit ones.
I was assuming the X server always used a packed format, but
PixmapBytePad() looks to be the proper way of handling this.
(Can I ask how you knew?  I did a Google on the macro and didn't
come up with anything of interest, I only found stuff in the
header files themselves...)
Harold, the xStride calc looks great
Glad that you think it is correct.  I was worried that it might break 
something.

but by removing the conversion
of 15-bpp modes into effective 16-bpp modes will break 15bpp icon
handling.  15-bpp modes are handled exactly the same as 16bpp modes,
except they are not bit-packed (there's 1 extra unused bit every
pixel) so you can't do (bpp/8).
Upon closer inspection I think you'll see that the logic of the 
statements is unchanged.  I was working on adding an additional case for 
24-bpp and reworked the if/else pairs to more a set default/override 
default it needed structure.  Looked cleaner to me, so I left it :)

Let me know if you still think it is changed or not after another 
inspection.

Harold


Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)

2004-03-23 Thread Earle F. Philhower III
Howdy Harold...
At 10:17 PM 3/23/2004 -0500, you wrote:
Upon closer inspection I think you'll see that the logic of the statements 
is unchanged.  I was working on adding an additional case for 24-bpp and 
reworked the if/else pairs to more a set default/override default it 
needed structure.  Looked cleaner to me, so I left it :)
Let me know if you still think it is changed or not after another inspection.
D'oh, I did just a CVS diff and I latched on to the unconditional
assignments.  I just did a cvs update and it looks fine, no changes
needed.
-Earle F. Philhower, III
 [EMAIL PROTECTED]
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com


Re: Changes to multiwindow mode and always-on-top (ping Takuma)

2004-03-23 Thread Earle F. Philhower III
Hi Takuma,

  At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
  You give me a good insight to improve Z order handling.
  I believe we can approach to better solutions.  The attached
  is my latest code which should fix all problems on restacking
  and a-o-t windows without using fAlwaysOnTop flag.  Could you
  try and review this?
After 48 hours of continuous running in a mixed environment of both
X and Windows apps I haven't noticed any problems at all, and I've seen
from the logfile that the fRestacking flag has captured and killed
some recursive restacks as expected from looking at your code.
The only glitch I have seen, and this is NOT new, is that when the
Win32 Z order changes because of a right-click system menu or a
click-and-drag to move a window, the X window is only restacked
at the end of the menu or move operation.
I don't see any reason to not commit your changes to CVS as soon
as possible!
-Earle F. Philhower, III
 [EMAIL PROTECTED]
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com


Possible clipboard hang fix in the works

2004-03-23 Thread Harold L Hunt II
I was just talking to 'jst' in irc.freenode.net about the periodic 
hanging caused by the clipboard integration manager.

I took a peek at the source code again (it is tough to understand and 
tough to not cause infinite loops, that's why I look at it about once 
every 3 months) and realized that I left in something that never realy 
intended to leave in: a blocking call that waits for an X application to 
send clipboard data.

The part I am referring to is that we call XPeekIfEvent to wait for a 
SelectionNotify event to be sent back to our clipboard manager.  If an X 
application is misbehaved or if something goes wrong, then that message 
will never come.  The problem with XPeekIfEvent is that it does not 
allow for a timeout value to be specified, so it blocks forever if the 
event never comes.

Upon a cursory inspection it should be almost trivial to replace the 
call to XPeekIfEvent with a simple loop that does the same thing but has 
a timeout value that prevents it from blocking indefinitely.

Course... that means we probably can't use select... so I'll have to 
look at how XPeekIfEvent works and write something similar to it.

In any case, I might have a fix for this problem later this week or as 
early as Wednesday.

Harold


Re: Possible clipboard hang fix in the works

2004-03-23 Thread Christopher Faylor
On Wed, Mar 24, 2004 at 01:02:28AM -0500, Harold L Hunt II wrote:
Upon a cursory inspection it should be almost trivial to replace the 
call to XPeekIfEvent with a simple loop that does the same thing but has 
a timeout value that prevents it from blocking indefinitely.

Why can't you use select()?  select() takes a timeout value.

cgf


Re: Russian Keymap

2004-03-23 Thread Roman Belenov
David Snopek [EMAIL PROTECTED] writes:

 So it knows when I press #1072; that its the cyrillic a but the
 XLookupString returns  as the represention?

Probably it's a locale issue (try setting LANG environment variable to ru
before starting xterm).

-- 
With regards, Roman.



Re: launching a remote webbrowser with cygwin

2004-03-23 Thread Igor Pechtchanski
Wrong list.  All questions about X on Cygwin should be directed to
cygwin-xfree at cygwin dot com.  Redirecting...
Igor

On Tue, 23 Mar 2004, Chris Bullock wrote:

 This is my first post to cygwin and I would like to say, great product.

 Background:
 With all the recent Microsoft virii and code leaks we are slowly blocking
 Windows based pcs from accessing the Internet.  What we are doing is placing
 a box running a Linux terminal server client beside every Windows box that
 needs to access the Internet.  This is beginning to get very cumbersome and a
 huge headache.

 What I desire.  I wish to load a very small portion of Cygwin on each Windows
 box.  When the user clicks the icon it would then connect to the Linux
 Terminal Server and launch $browser of choice.  First off is this possible?
 and if so can someone point me on how to make this happen.  I do not want to
 have to run the entire terminal client.  Currently, what we have tested is
 from the cygwin prompt we run 'X --query $LTSP:1' but this gives us the
 entire terminal server and all I want the users to do is access a webbrowser.

 Regards,
 Chris

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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


Re: license for X-startup-scripts package

2004-03-23 Thread Christopher Faylor
We have a mailing list for cygwin-x.  Redirecting there.

On Tue, Mar 23, 2004 at 03:02:23PM -0500, Dick Repasky wrote:
I'm looking for the license under which the X-startup-scripts package is 
released.  The file named COPYING is 1 byte long in 
usr/X11R6/share/doc/X-startup-scripts-1.0.2/COPYING, and in the source 
tarball 
X-startup-scripts-1.0.2-1-src.tar.bz2:X-startup-scripts-1.0.2.tar.bz2:COPYING.

I haven't been able to figure out where CVS is for the package, but I 
assume that the copying file is one-byte there, too.

Thanks,

Dick

-

Dick Repasky
Bioinformatics Support
UITS Cubicle 101.08
Indiana University
USA

[EMAIL PROTECTED]