RE: cygpath hangs from postinstall scripts when called like $(cygpath -S) but not otherwise
On Sat, 2003-10-04 at 14:19, Alan Miles wrote: All, I concur - I have a couple of private packages that I build, and then use a local copy of upset to create the setup.ini file. My packages are ** NOT ** XFree86 related, and I have the same type of $(cygpath -S) call in my postinstall scripts. They also freeze up this latest setup.exe, the 2.340.2.5 release of setup.exe everything worked properly. This is intruiging: these reports where already coming in before I pushed out the current release. (Which I did because I was finally tired of the 'setup hangs' reports due to the bad graph traversal code.) Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Setup bug --- probably already reported and fixed, of course[Scanned]
On Sat, 2003-08-02 at 01:30, Harold L Hunt II wrote: FYI --- In further testing, archive.progeny.com is the mirror that has not been updated yet. Selecting only archive.progeny.com gives me the warning about setup.ini being older than when I last installed Cygwin. Selecting only mirrors.rcn.net does not give such a warning and correctly indicates that the XFree86-bin tarball is roughly 10500 KiB and downloads it and all other tarballs with no problems. Thus, this does not so far appear to be entirely my fault. When you updated the X tarballs, did you bump the version number for the tarballs? (i.e. did they have -unique- file names compared to the existing tarballs?) Cheers, Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: problems with XFree
On Thu, 2002-07-25 at 11:20, Harold Hunt wrote: Jehan, Excellent summarization of the thread regarding how we can add /usr/X11R6/bin to the path. Looks like we had Dave Cook and Robert Collins discussing the best way to do things but then the thread died. I don't really think that I know how to implement the best solution here, so I will just have to leave this up to others. I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob
Re: /etc/profile package maintainer (Was: problems with XFree)
On Thu, 2002-07-25 at 20:14, David Starks-Browning wrote: On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. Thanks for the offer David... John Marshall has already volunteered off-list though (after a few questions to ascertain the work it entails.) I don't care who maintains it - I'm going to work on the basis of it being John until I'm told otherwise :}. Rob
RE: /etc/profile package maintainer (Was: problems with XFree)
On Thu, 2002-07-25 at 20:40, Morrison, John wrote: From: Robert Collins [mailto:[EMAIL PROTECTED]] On Thu, 2002-07-25 at 20:14, David Starks-Browning wrote: On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. Sorry David, I should have ack'd this publically. Thanks for the offer David... John Marshall has already volunteered I think you mean me ;) John M, well I got most of it right :}. Yes, I did mean you. Sorry - I will drink more coffee now :}. Rob
Re: [ITP]: Qt-2.3.1
On Thu, 2002-07-25 at 22:45, Corinna Vinschen wrote: Are you sure that we don't get licensing issues here? AFAIK, Qt is (roughly) only free when running on a free OS. Basically we're still running on Windows... http://www.trolltech.com/developer/licensing/ Summary, 2.2 and later is QPL and GPL. They may not like it, or they may like it. Who knows. But... they can't stop it. Rob
Re: X via SSH (was: New (Delphi) xlauncher)
=== - Original Message - From: Nick THOMPSON [EMAIL PROTECTED] To: cygwin-xfree Mailing List [EMAIL PROTECTED] Sent: Tuesday, July 23, 2002 9:22 PM Subject: X via SSH (was: New (Delphi) xlauncher) What I could do with is a mode that allows an X session to be setup through an SSH tunnel. So I need an SSH client that DOESN'T give me a shell, but supports an X11 tunnel, prompts me for the SSH passwd and runs a single command (the remote ~/.xinitrc say, and pipes the output to a local file). Even better if I can select from a list of hosts at startup. Does this xlauncher support that? Currently, I'm using putty, but it asks for the passwd in a shell window which you have to keep open. Any other ideas? man ssh-agent. Rob
RE: New (Delphi) xlauncher
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms Sent: Tuesday, 23 July 2002 1:36 AM Harold, Who's to say that ReactOS won't have a registry? 1) ReactOS has a registry, and an editor. 2) ReactOS is targeting binary compatability with NT, so it's about as cross platform as installing a mandrake rpm on a redhat machine :}. Rob
RE: Problems with MSVC6.0
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Juan José Andrés Gutiérrez Sent: Wednesday, 17 July 2002 9:55 PM As I can use these DLL in a program written with Visual C++? 1) Dlls are not libs. Conversion is not guaranteed. 2) These .dll's use a different C runtime than Visual C/C++ does, so you can't use them with each other. 3) Why not just use g++? Rob
RE: Problems with MSVC6.0
-Original Message- From: Juan José Andrés Gutiérrez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 17 July 2002 10:04 PM To: Robert Collins Subject: Re: Problems with MSVC6.0 I need to use Visual C++ 6.0 because I'm making an ActiveX. False. G++ can produce ActiveX objects, the COM interface is supported - but you will need to research this quite a bit to do it. I need to make a function that controls X-Window objects. Is posible use this dll in a Visual C++ project? Which part of 'can not use them with each other' did you not understand? Rob
RE: Problems with MSVC6.0
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Juan José Andrés Gutiérrez Sent: Wednesday, 17 July 2002 11:51 PM To: Robert Collins Cc: [EMAIL PROTECTED] Subject: Re: Problems with MSVC6.0 I need a explanation, please. If I load the DLL in my program dynamically instead of using a library (lib) will worked? or on the contrary it will happen the same. One last time: If you use VC6, it will not work. If you use g++ it will work. Rob
RE: Installation Classes for setup.exe [was RE: LibICE.DLL is a BIG problem]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms Sent: Tuesday, 16 July 2002 3:04 AM To: cygx Cc: [EMAIL PROTECTED] Subject: Installation Classes for setup.exe [was RE: LibICE.DLL is a BIG problem] Hi, Instead of bitching, all people have to do is click once on the default option and it will switch to install. This installs everything except the test packages. If only people would try to figure it out a little before complaining. Although, I suppose eventually we'll have to get setup to give people the option of: 1)Minimal Install (currently default) 2)Standard Install 3)Full Install (currently (install) n1) [Install Type n1] n2) [Install Type n2] [CHECK BOX 1] Install experimental packages? [CHECK BOX 2] Customize package selection? Funnily enough: this http://sources.redhat.com/ml/cygwin-apps/2002-03/msg00228.html may be very similar to what you are talking about. Rob
Re: New xlauncher (was: Re: Success with Java prog in XFree)
- Original Message - From: Tim Thomson [EMAIL PROTECTED] To: Rasjid Wilcox [EMAIL PROTECTED] Cc: cygwin-xfree Mailing List [EMAIL PROTECTED] I have been playing with wxWindows with C++. Why not just code to the Win32 API? It's not that hard, not for a trivial launcher. wxWindows is a pretty big dependency to have, and the reason your programs are so big is most likely due to static linking instead of using the shared library... Rob
Re: New xlauncher (was: Re: Success with Java prog in XFree)
- Original Message - From: Tim Thomson [EMAIL PROTECTED] To: cygx [EMAIL PROTECTED] Sent: Monday, July 15, 2002 3:39 PM Subject: RE: New xlauncher (was: Re: Success with Java prog in XFree) On Mon, 2002-07-15 at 16:33, Harold Hunt wrote: For future reference, the xlauncher-style program is on my list of things to do. I want it done in straight C or C++ interfacing the GDI manually. I don't want dependencies on cumbersome libraries, and I don't want any non-free compiler languages involved. This xlauncher will remain on my to-do list until it is written to the above specs, regardless of whether or not someone comes up with a really slick xlauncher that depends on super-duper-library-foo. I don't care about super-duper-library-foo, I just want to be able to spend a small amount of time in order to contribute to a program with an arguably small scope. So wxWindows is also out? I was hoping for a cross platform xlauncher, as it would also be useful under a linux/*nix system using Xnest. I don't know what Harold will say - although I can guess :}. What we do over in cygwin-apps when someone offers to provide maintain foo, that depends on library bar which is not in the distribution, is to say Maintain bar - making it a .dll if appropriate, packaging it and so forth. THEN, and only then, offer foo as a package. In short, I don't see any particular problem with wxWindows per se, as long as you make it easy for other folk to build and link and run against it natively. This would involve at a minimum a shared library and a -devel package with a static build and the headers. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harold L Hunt Sent: Saturday, 13 July 2002 6:38 AM To: [EMAIL PROTECTED] Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: Okay, if you are so smart, explain to me how I can put a drive letter into a batch file that is expected to work on computers where Cygwin could be installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly could not put ``c'' as the drive, nor could I put ``d'' as the drive. So, what do you suggest? I missed this the first time around. What you need is a small sed script in your postinstall script. The sed script can replace some symbol with the output from 'cygpath -w /usr/X11/'. As for linefeed issues, AFAIK windows will process bat files with unix format, but you could always use d2u in your script. Additionally you need to make your package depend on the tools you use in your script. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: Jehan [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 8:18 AM To: Robert Collins Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Robert Collins wrote: Nope, it's also generated from mount information. Cygwin could be z:\bar\foo\bar and it would still be correct. Is there a way then for a program to add (after asking the user) to create a shortcut on the desktop/start menu? Is there also way to get the information about the installing for all users or just me? Jehan Yes to the first, it's a tool in cygutils - Chuck answered the same question here less than a week ago. No to the second, that's not exported anywhere by setup. Perhaps it should be. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Thomas Chadwick I hate to jump into the middle of a religious argument (which this is turning out to be) but it seems to me that a plausible solution would be to urge the maintainers of the cygwin setup program to define a CYGWIN_ROOT environment variable for us. Cygwin setup is already putting stuff in the registry, isn't it, so why not this? No. Use `mount -w /` in your postinstall shell script. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms Sent: Sunday, 14 July 2002 10:29 AM Chuck, For crying out loud, 95% of the installers out there create shortcuts for the user in the startmenu and on the desktop. Why is this such a bad thing for setup.exe to do? What does external data have to do with the price of potatos? Seriously, I'm proposing a simple solution which is the norm for most installers. Where have I gone astray? Because simple solutions often increase coupling, wheres a more thought out solution decreases coupling. Also, I know you are subscribed to cygwin-apps, and I just posted there just a couple of days ago about wanting to remove the hardcoded stuff from setup.exe. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: Nicholas Wourms [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 10:57 AM To: Jehan Bing ... No he isn't. There are two ways that someone will interface with Cygwin, via Console or via X11. The other apps you mention are Console apps, therefore you can't expect them to have shortcuts. However X is much more than an Application, it is an interface. Therefore, one can argue that it deserves setup.exe making it a shortcut just as much as setup.exe making the console a shortcut. Lastly, something you will not disagree with, ALOT of people want to use just X and not the console, especially for doing XDMCP. This is even more reason why setup.exe should make the shortcut. The above is an argument for the creation of the shortcut, not for setup.exe creating it. Rob
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms Sent: Sunday, 14 July 2002 11:09 AM Robert, I'll have none of this debian talk. You know full well that I am working very hard to get rpm-4.1 ready for inclusion into the distribution. At that point, Chuck and I will start figuring out ways to interface it with setup. Also, we will be figuring out how to best transition setup to use rpms. The point of this is that all this talk is a long way off. I'm not going to invent a new interface when others already exist. The fact of the matter is, that for right now, setup is well suited to perform the task at hand, which is to support all of the future X users. Like it or not, there is enough of them to warrant a separate mailing list. Lets temporarily let setup do this now and then we'll replace it when something better comes along. Nicholas, no consensus has been reached for using the rpm database as the backend. If rpm has a similar system to the one I referenced, substitute rpm for dpkg in my previous comments. I *did not* suggest that we use dpkg as a backend for this particular thing either - I pointed out the best practice pattern to address the issue we are facing. Lets stick to that topic, shall we? For now, try listening, not taking the conversation off on tangents. I happen to have put quite a bit of effort into the Cygwin Xfree86 project in the past, and continue to make various contributions as and when it's appropriate. I strongly resent your implying that I might dislike the presence of the cygwin-xfree86 community - which I am a member of! The simple fact is, I disagree with your proposal, and you have made no convincing arguments to change my mind. What you are suggesting is not what 'most' windows installers do, it is not flexible, it is a step backwards in approach, and a proper solution is not that hard to do! Rob
Re: Weird X start problem
Whats your SHELL variable? Rob
Re: Incorrect version in packages names
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 08, 2002 4:16 PM and in setup.ini : @ kdelibs-2 Get rid of this. I suspect that it is confusing setup.exe. It should certainly do the right thing without it. Doh!. Good catch Chris. Yes, foo-bar is allowable as a package name, foo-2 is not. I'll see what I can do for a future setup.exe release to address this, but don't expect anything soon. It'll require altering the installed.db database format, which results in a non-backwards compatible local environment. Rob
Re: Incorrect version in packages names
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] upset would probably do the right thing with the above but I really don't see any reason to use it, regardless. I don't see any reason why a user would need to know that these are kdelibs-2 when it is pretty obvious from the version number. One possibility is if the version number reflects the ABI, not the software release. This is actually quite likely with libtool packages. Anyway, it's low priority however one approaches it. Rob
Re: [PATCH] -scrollbars option
Why not just run the patch through d2u? Rob - Original Message - From: Harold Hunt [EMAIL PROTECTED] To: cygx [EMAIL PROTECTED] Sent: Monday, July 08, 2002 2:59 PM Subject: RE: [PATCH] -scrollbars option Jehan, That is an excellent patch! I was just thinking that we should add this sort of functionality. Yes, I was reading the ./ posts too :) However, there are a bunch of ^M's showing up in the patch file for winwndproc.c starting at about line 496 (in the patch file). Could you clean that up and resubmit? Thanks for the great work, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jehan Sent: Sunday, July 07, 2002 11:27 PM To: [EMAIL PROTECTED] Subject: [PATCH] -scrollbars option Hello, Since I've seen a couple complaints about not being able to resize the windows in this mailing list and on slashdot, I've decided to implement it. So here it is. With this option, when in windowed mode, you can resize the window (if you use decoration) and have a virtual screen bigger than your desktop (so now you can have a real 1024x768 screen on your 1024x768 monitor without having to go fullscreen, or you can have a 1600x1200 on your 320x200 monitor :) ). Harold, I left a comment in wincreatewnd.c (line 263 for me). At this place, you map the client area coords to fullscreen but you never use them. So either I missed something and I'm sorry for bothering you, or this is some left over from some old code that can be removed. Also, I didn't change the Primary FB since it's deprecated and you said in the contributor's guide that the Development of the Primary FB engine has ceased. Jehan
RE: RENDER extension in Server test 59
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Alkov Sent: Friday, 21 June 2002 3:20 AM Also, specific kudos for the recent mousewheel fix for cygwin setup We fixed it? Ah, mmm, ok!. Thanks for the feedback. Rob
RE: Cut down xfree server for XDMCP only
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Thomson Sent: Saturday, 15 June 2002 8:54 PM Hmmm, I first installed cygwin-xfree before it was incorporated into the setup.exe system, but have now used the setup.exe to install on another system as well. I found that it was very hard to reduce the size of the install, as many things depend on many others. Yes. The X install is relatively heavy. I was thinking that you can do the following: Setup your own setup.ini. In that include a package (say XFree86-XDMCP-minimal) for your cut-down X install, minus all the cygwin infrastructure. DON'T include anything with a name the same as cygwin's setup.ini. Include dependency listings that your package has on cygwin packages - should any exist (i.e. various font packages may be useful). Anything that your can't separate out usefully enough, include the content in your package' tarball, OR ask Harold if he is able to split the package out a little. Then tell your users to run setup.exe, add your mirror site to the mirrors list, and to select an official cygwin mirror as well. That should be much smaller, and Perhaps we could check if cygwin is already installed, and refuse to install if it is. We could also have warnings saying not to install both at the same time. This would mean we could use the standard binary and libraries, just repackaged. That would help. I suspect you'll still get folk installing cygwin on top, but at least a one-way check helps a lot. Cheers, Rob
RE: How to start messing around with creating a rootless mode...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stuart Adamson Sent: Thursday, 13 June 2002 10:11 PM It does seem like this might get a bit complex (we would have to hold the hwnd of each window in the windows private and use that to decide what needs updating and when). Yes, but the X infrastructure for this is excellent. I had it mostly working, but looking crap due to the decorations, and not choosing which windows to show on the taskbar terribly cluefully. Alan has various patches from me. Unfortunately, my personal time completely dried up without much warning a couple of months ago, and I haven't gotten back to that. The windows message loop will need to do some demux'ing as well. Hmm, could do, but didn't seem to need it. Rob
RE: How to start messing around with creating a rootless mode...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alan Hourihane Sent: Thursday, 13 June 2002 11:04 PM To: [EMAIL PROTECTED] Subject: Re: How to start messing around with creating a rootless mode... On Thu, Jun 13, 2002 at 10:57:44PM +1000, Robert Collins wrote: Yes, but the X infrastructure for this is excellent. I had it mostly working, but looking crap due to the decorations, and not choosing which windows to show on the taskbar terribly cluefully. Alan has various patches from me. Unfortunately, my personal time completely dried up without much warning a couple of months ago, and I haven't gotten back to that. Unfortunately I didn't get the full set of patches which really did the rootless modes. If you want to create a full diff - I'm sure someone will look at them. I'll see what I can do shortly. Rob
RE: How to start messing around with creating a rootless mode...
Enjoy. YMWV, as this is against somewhat old sourceforge CVS. I'm also not sure what quality I left it in :}. At a minimum it should provide food for thought. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harold Hunt Sent: Thursday, 13 June 2002 11:53 PM To: [EMAIL PROTECTED] Subject: RE: How to start messing around with creating a rootless mode... Robert, I totally forgot that you had worked on a rootless mode. I'd definitely be interested in seeing the patches. Thanks, Harold rootless.patch.bz2 Description: Binary data
RE: KDE 2.2.2 beta1 released
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephan H. Schug Sent: Saturday, 25 May 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: KDE 2.2.2 beta1 released Nicholas Wourms schrieb: I hate to chime in with a me too, but I have been experiencing the same issue. I contacted Robert Collins about the issue and he said he would look into why setup is doing that. Haven't heard from him yet though... Setup is doing what? Rob
RE: KDE 2.2.2 beta1 released
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ralf Habacker Sent: Wednesday, 29 May 2002 8:12 PM To: Cygwin-Xfree Subject: RE: KDE 2.2.2 beta1 released Nicholas Wourms schrieb: I hate to chime in with a me too, but I have been experiencing the same issue. I contacted Robert Collins about the issue and he said he would look into why setup is doing that. Haven't heard from him yet though... Setup is doing what? They mean the bug with the GNU long name extension, which results in failed kdebase installation, we have spoken about and for which I have submitted a patch. Do you have applied this patch into cvs ? As of now, yes. Rob
RE: error downloading XFree86-base-4.2.0-1.tar.bz2
46 bytes sounds about right. Rob -Original Message- From: Kostas Adaos [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:29 PM To: [EMAIL PROTECTED] Subject: error downloading XFree86-base-4.2.0-1.tar.bz2 when I download the XFree86-base-4.2.0-1.tar.bz2 through the cygwin setup an error occurs (the file is only 46 bytes). The installation is not proceeding after that. Is there a soluttion?
RE: KDE 2.2.2 beta1 released
I haven't had time to test yet. Hopefully I will this weekend... Rob -Original Message- From: Nicholas Wourms [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:50 PM To: Jonathan Fosburgh Cc: Ralf Habacker; Cygwin-Xfree Subject: Re: KDE 2.2.2 beta1 released Hi, I hate to chime in with a me too, but I have been experiencing the same issue. I contacted Robert Collins about the issue and he said he would look into why setup is doing that. Haven't heard from him yet though... Cheers, Nicholas --- Jonathan Fosburgh [EMAIL PROTECTED] wrote: On Fri, 17 May 2002 09:39:23 +0200 Ralf Habacker [EMAIL PROTECTED] wrote: Hi all, today the KDE 2.2.2 beta 1 is released. For further details see http://cygwin.kde.org/kde2.php Have fun ! Ralf Habacker I had this problem with the installer for 2.2.1 as well, but I was hoping it would be fixed in this one. During the installation of kdebase, I will get about half way through, and then get booged down in a series of error messages that read: warning: deleting d:\cygwin/opt/kde2/share/doc/HTML/en/kdeprint/cupsserverconfig _serverencryptionconfig_servercertificate_blurb.png so I can make a directory there. After hitting OK, I get another one that reads: warning: moving directory /opt/kde2/share/doc/HTML/en/kdeprint/cupsserverconfig_servere ncryptionconfig_servercertificate_blurb.png out of the way. At least for 2.2.1, installing manually by extracting the archive on the command line works. And, sure enough, I have multiple copies of a directory with that name. Will proceed with manual installation for 2.2.2. -- ** Jonathan Fosburgh |Certified AIX Administrator Software Systems Spec. III |ICQ: 32742908 Communications and Computer Services|MSN: [EMAIL PROTECTED] UT MD Anderson Cancer Center|Jabber: [EMAIL PROTECTED] Houston, TX |Yahoo: jefosburgh ** __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
RE: Re[5]: setup.exe and inuse files for X
One thing I'm not clear on - are both calls -required-? -Original Message- From: Pavel Tsekov [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 8:52 PM To: Robert Collins Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re[5]: setup.exe and inuse files for X Ok, I've tested it on my WinXP Home on NTFS, FAT and FAT32. The following snippet removes the file no matter the filesystem (the Get/SetFileAttributes is required for FAT/FAT32 only): HANDLE hFile; DWORD dwAttr = GetFileAttributes (test.dat); SetFileAttributes (test.dat, dwAttr ~FILE_ATTRIBUTE_READONLY); hFile = CreateFile (test.dat, DELETE, 0, NULL, OPEN_EXISTING, FILE_FLAG_DELETE_ON_CLOSE, NULL); CloseHandle (hFile); RC Does this work on FAT too? PT I don't know - its not clear from the documentation. Someone has to PT test it on FAT. However this combined with an an call to PT SetFileAttributes () before it should be sufficient.
RE: Repackaging of WindowMaker and openbox needed ?
-Original Message- From: Ton van Overbeek [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 6:39 PM By the way, what is the best place to discuss X packaging issues, this list (cygwin-xfree) or cygwin-apps ? Yes. I'd suggest that any non-trivial discussions take place on cygwin-apps, optionally copied to cygwin-xfree. Any xfree-only discussions, don't need to be on cygwin-apps. Rob
RE: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or
general topic. Anyway
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 10, 2002 5:36 AM
Robert Collins wrote:
In short, I don't like the idea of making key_t 32 bits.
I have taken deeper into ftok and have some questions:
The current implementation (excuse the indenting):
key_t
ftok (const char *path, int id)
{
struct stat statbuf;
if (stat (path, statbuf))
return (key_t) -1;
/* dev_t is short
* ino_t is long
* and we need 8 bits for the id
*/
return ((long long) statbuf.st_dev (5*8)) | (statbuf.st_ino (8)
) | (id 0x00ff);
}
1. Why do you use st_dev explicity. Isn't ftok() only for
files ? From the ftok documentation: The ftok() function
returns a key based on path and id that is usable in
subsequent calls to msgget(), semget() and shmget(). The path
argument must be the pathname of an existing file that the
process is able to stat().
So st_dev seems to make no sense for me and could be removed.
Possibly. If the file can be stat'd - and devices can - we should check
it, no?
2. Does st_ino creates uniq inodes rsp. hash values ? If so,
why not (CASE1) adding an ascii representation of id to the
path and calling hash_path_name() (the function which creates
statbuf.st_ino) or (CASE2), using id as hash value for
hash_path_name() like the following code.
hashs collide. key_t's can not collide under any circumstance, and must
be deterministic (i.e. not dependent on currently issued keys).
How do you suggest that you avoid hash collisions?
Rob
RE: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages
Randall, theres nothing in X or Cygwin that could cause a CPU to disappear on you. Rob
RE: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 2:09 PM Actaully, I think the long delay was the copy-on-reboot stage of the cygwin upgrade. I vaguely remember something about XFree needing to update a LOT of in use files, so setup puts those files in the copy-on-reboot list. Fonts? Anyway, copying hundreds of files, one at a time, can take a while... X appears to have a lot of read only files, which setup fails (don't know why) to delete, so falls back to copy-on-reboot replacement. Rob
RE: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages
-Original Message- From: Randall R Schulz [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 2:41 PM To: Charles Wilson Cc: [EMAIL PROTECTED] Subject: Re: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages Charles, Wouldn't that copy-on-reboot processing wait until I logged in the first time? It happens before the GUI comes up. Rob
RE: MIT shared memory extension
-Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 7:41 AM What about using a new type respective casts for cygdaemon. This would not break key_t compatibility and allows to migrate single application to cygdaemon, while others works with cygipc (at least for a limited time) ? At the moment key_t's are generated locally without the cygserver. This means that in theory a cygipc linked app will still work with the new key_t code after recompiling (I think we do need to remove ftok from cygipc at that point though). If we have a list of key_t's, then it must be global, so cygserver will have to be running. I think that that is bad. Also at the moment, we know that the same file will generate the same key_t every time. (because it's inode based). If we walk a list, then we'll have to walk the entire list *and store the file name the key was generated from* to see if it's been handed out already. Lastly we don't have an existing list of key_t's, that was a list of shm areas you are referring to, and they can share the key_t values. (the shmid is the index in that list). In short, I don't like the idea of making key_t 32 bits. Rob
RE: MIT shared memory extension
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 10:20 AM the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. cygdaemon provides ipc and shm, but the shm is incomplete. Someone want to fund it? (only half kidding). As for it being turned on, you need to patch newlib (for the new key_t definition) and cygwin (to export the functions) and then rebuild cygwin. Rob
RE: MIT shared memory extension
-Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 8:55 PM To: Robert Collins; Charles Wilson Cc: [EMAIL PROTECTED] Subject: RE: MIT shared memory extension the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. cygdaemon provides ipc and shm, but the shm is incomplete. Someone want to fund it? (only half kidding). Can you explain this a little bit more ? I've got very little spare time at the moment. To devote more to Cygwin, I'd need to allocate consulting time from my employer, and my employer will want money to do that. I will eventually get it done on my own time however. As for it being turned on, you need to patch newlib (for the new key_t definition) Could this perhaps not be patched in the cvs or are there compatibility issues against it ? The definition of key_t in newlib is a 32bit int, for cygdaemon it needs to be 64 bit to store the inode and the index cleanly. Redefining that will break every cygipc linked application when they are rebuilt, until cygipc is rebuilt against the new source. However rebuilding cygipc will break every already linked app. So until the cygdaemon shm code is complete, Chuck and I figured that it was not worth putting everyone through the agony of a backwards incompatible ABI change. and cygwin (to export the functions) all shm* symbols ? Index: cygwin.din === RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v retrieving revision 1.44 diff -u -p -r1.44 cygwin.din --- cygwin.din 2002/02/25 17:47:46 1.44 +++ cygwin.din 2002/03/03 21:52:10 @@ -1246,3 +1246,8 @@ acltotext _acltotext = acltotext aclfromtext _aclfromtext = aclfromtext +ftok +shmat +shmctl +shmdt +shmget Rob
RE: setup.exe and inuse files for X
-Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 1:44 AM To: CygWin Apps; Cygwin-Xfree Subject: Re: setup.exe and inuse files for X On Wed, May 01, 2002 at 04:58:36PM +1000, Robert Collins wrote: I think I've got a handle on this... looks like read only (-r--r--r--) files don't delete properly, so setup fails to overwrite them. Patches gratefully accepted, it's going in the TODO for now. I recall having sent a patch for this a few months ago to the cygwin-apps list... Yes. And I had implemented similar code. (Including the SetFileAttributes call). I'm not sure why it is still failing to do what it should. Rob
setup.exe and inuse files for X
I think I've got a handle on this... looks like read only (-r--r--r--) files don't delete properly, so setup fails to overwrite them. Patches gratefully accepted, it's going in the TODO for now. Rob
RE: upset stumper [cgf, Robert Collins, please comment]
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 12:25 AM To: Robert Collins; cygx Subject: RE: upset stumper [cgf, Robert Collins, please comment] Robert, I forgot to reply last night that I had hand-fixed the setup.ini file and setup.exe ran fine after that. Cool. Rob
RE: A small contribution
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 12:31 AM To: [EMAIL PROTECTED] Cc: Luke at work Subject: A small contribution I read through the contributors guide, but couldn't find any mention of how to contribute a binary port of a utility. So after considerable hunting around the web site, trying to find out how to make such a contribution, I found the above vaguely-likely address. Have a look at http://www.cygwin.com/setup.html. Cheers, Rob
RE: build.sh
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 28, 2002 2:33 PM I've been thinking that maybe a Makefile version of this might be more useful, as it would prevent the rebuilding of packages that haven't had their XFree86 package updated. Makes sense to me. Rob
RE: xfree86 install makes wininit not working
-Original Message- From: Ilya Goldin [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 3:52 AM When I restarted, Win2K (which is what I'm running here, with all the latest patches), got stuck at the end of its second ... Having read the list since, I surmise that the WININIT.INI There is no WININIT.INI on NT. There is an equivalent on-boot process however. P.S. I guess the other burning question is why did setup.exe decide that it couldn't overwrite the Xfree files even though Xfree wasn't in use? Send in your /var/logs/setup.log.full and /var/logs/setup.log and I'll see what I can tell you. Rob
RE: xfree86 install makes wininit not working
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 21, 2002 1:15 PM To: [EMAIL PROTECTED] Subject: Re: xfree86 install makes wininit not working On Sun, Apr 21, 2002 at 12:59:26PM +1000, Robert Collins wrote: What's your prognosis on this? Is this a problem that is specific to Sylvain's machine or is this going to be a problem because Cygwin/XFree86 has over 4000 files in the font directories? I haven't come to a root cause yet. Have you actually duplicated the problem, Robert? Maybe I've missed something but I don't think I've seen an indication that this isn't just a Wine problem. The user reported the problem as being under Windows ME. Rob
open-file replacements with win9x
We've got a problem folks: From MSDN === To rename or delete a file on Windows 95/98/Me Check for the existence of the WININIT.INI file in the Windows directory. If WININIT.INI exists, open it and add new entries to the existing [rename] section. If the file does not exist, create the file and create a [rename] section. Add lines of the following format to the [rename] section: DestinationFileName=SourceFileName Both DestinationFileName and SourceFileName must be short file names. To delete a file, use NUL as the value for DestinationFileName. === Note that both files must be shortnames. I had _assumed_ that the OS would preserve the attached long file name. But (as the list records show)... I had not been able to test it to see that this was indeed the behaviour we would get. If anyone with a 16 bit windows box out there has the time to do some test cases and see if my assumption was wrong, or if the current reported case was a fluke that went wrong, that would be great. As to _why_ 600 odd files needed replacing, I've yet to look closely at that aspect. Rob
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 6:56 AM In a related question that has to do with my laziness, I need a way to tarball a CVS tree without including the CVS directories. I'm sure this can be done with a simple script, but I'm a programmer not a script writer. Anyone want to point me to an existing script that does this, or write one for me? Grab the -src for one of the packages that Chuck or I maintain - say libxslt. There is a tar command in the .sh that filters out various directories... I'm sure you can adapt it easily. Rob
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 8:48 AM I didn't quite gather from the earlier discussions whether we can have a source package seperate from any binary packages. i.e., could we have XFree86-full-src without an associated binary package? Or would we have to make XFree86-base-src the package that contained the full source archive. Hmm. Yes. I think this would work. That might be the best solution. In fact, it may be a nice trend setter. I think setup.exe needs a little work before doing this, but it's a good direction. (i.e. setup.exe should have a view to only show src packages, and a view to only show binaries - to avoid confusing folk). (Think apt-get source vs apt-get install). Rob
RE: xfree86 install makes wininit not working
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 12:47 PM To: [EMAIL PROTECTED] Cc: Robert Collins Subject: RE: xfree86 install makes wininit not working Robert, Cygwin's setup.exe doesn't use wininit.ini, does it? I'm going to guess that the answer is something along the lines of no way in hell, but I figure I had better check with you. It does, via the proscribed windows API to perform copy-on-reboot for in-use files in win95. Windows is meant to perform the copies before loading the GUI, and then remove the ini entries after it does that. If I could get some details - the /var/log/setup.log and setup.log.full, and the machine layout (where windows cygwin etc are), and a copy of the ineffective wininit.ini, I will see what I can figure out. As to why this happened, I assume that the user was running X at the same time as installing it via setup.exe. Rob
RE: xfree86 install makes wininit not working
I realised the ini file was present in Sylvain's email. Sylvain - do the .NEW files exist? Are the paths correct? ROb
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 12:59 PM Also, setup must do the following (even without new 'views' and whatnot) Setup should already do that, why not make a test setup.ini and see what happens :]. It's all data driven and there is no requirement for -src packages to follow the same name as the base. Rob
RE: [ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 3:30 PM Dependencies work for installing. The behavior I noticed when uninstalling is that dependencies are ignored. I'm guessing that setup.exe was designed that way because there isn't really a good way to handle dependencies when uninstalling. Yeah. On uninstalling we need some user interaction, and the chooser isn't quite there to do that cleanly (yet). Rob
clipping questions
In the span functions, if pGc-CompositeClip has (nbox = REGION_NUM_RECTS (pRegion)) == 0, what does that indicate? Should we skip rendering the span? Grab 1 rect and hope we can read it? Something else? Rob
RE: makeNativeRgn
-Original Message- From: Alan Hourihane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 5:44 PM To: [EMAIL PROTECTED] Subject: Re: makeNativeRgn On Wed, Apr 10, 2002 at 03:35:06PM +1000, Robert Collins wrote: There's more that can be done, like moving the clipboard selection before the spans iteration, but the biggest improvement I've achieved so far is making native Rgn's for the FILLTILED routine. I'll make a patch for this once I clean a little other code in winfillsp.c up. The background rendering is instantaneous with this for me. O.k. I'll hang off applying that other patch until you've done the above. Can you send the patch as an attachment. At my end windows nicely put in the good old =20 and =3D expansions into the last email. Will do. Rob
RE: drawables
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 3:11 PM I hope that clarifies things. This may actually be documented in the Porting Layer Definition, but I don't remember for sure. Yes it is sortof - some frameworks have defined mechanisms for RTTI, and I hate to guess wrong... Sounds like you are making good progress. Keep it up and I hope to see what you have soon, So do I :}. As soon as I get the mouse going again I think I'll send the patch in. Rob
Just a note - nativegdi engine
I've made serious progress, but I'm having trouble with two things.
1) The mouse - I'm not getting any WM_MOUSEMOVE messages to the app
windows. Anyone seen this before?
2) I've broken fillspans for DRAWABLE_WINDOWs. I can fix it by drawing
into the root window hdc always,
but that's defeating the purpose - all we gain is the pretty task bar
entries :[.
2) I'm working on, I suspect it's a coordinate translation thing. I get
lovely background stipple but not (AFAICT solid fills).
Anyway, the reason for the email:
Harold:
I thought you might like to see the little todo: I've added.
Creating a single combined clipping region using CombineRgn will allow
you to move the for (iX= ..)loop from within the while (nbox--) loop,
thus saving multiple selectClipRgn+deleteObject + bitblt calls, which
may make the native engine quite a bit faster. I *will* do this
optimisation here and elsewhere, but only after I get the fills working
for 'native' windows first.
Rob
/* TODO: create a single commbined clipping region */
nbox = REGION_NUM_RECTS (pClip);
pbox = REGION_RECTS (pClip);
while (nbox--)
{
hrgn = CreateRectRgn (pbox-x1, pbox-y1, pbox-x2,
pbox-y2);
SelectClipRgn (pGCPriv-hdcMem, hrgn);
DeleteObject (hrgn);
hrgn = NULL;
for (iX = fullX1; iX fullX2; iX +=
pStipple-drawable.width)
{
int width;
if ((iX + pStipple-drawable.width) fullX2)
width = fullX2 - iX;
else
width = pStipple-drawable.width;
BitBlt (pGCPriv-hdcMem,
iX, fullY1,
width, 1,
hdcStipple,
0,
fullY1 % pStipple-drawable.height,
g_copyROP[pGC-alu]);
}
pbox++;
}
RE: info: single install xfree86 + minimal cygwin?
-Original Message- From: Ian Burrell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 9:49 AM Is it possible to have multiple packages in a subdirectory and setup.hint file? Or does each package needs its own directory? Each package needs it's own directory. For a hierarchy, I was thinking: base, devel, doc, fonts, and progs (for the optional servers). I'm not clear not the hierarchy there - that reads like a list to me. You've got two clauses you can independently use to make a hierarchy and package dependencies - category:(i.e. the devel tarball belongs in XFree86 and in Devel) and requires: (i.e. the server package requires the fonts and the programs and ...) There are a couple of refinements that can be made to the repackaging. First, the 75dpi fonts make up the bulk (10MB) of the fonts package and aren't strictly required. They could be made their own package. The miscellaneous fonts could be folded into the base package so there is only one required package. Second, move the man3 man pages into the devel package. Also, move the .a files in /usr/X11R6/lib into devel. That reduces the base package by a couple MB. Those refinements can be made at any point - there's no need to have it perfect on first release. Setup.exe is quite capable of handling files moving from one package to another now. Rob
RE: info: single install xfree86 + minimal cygwin?
-Original Message- From: Ian Burrell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 10:57 AM That is a list of subdirectories. But it won't work since the each package needs its own subdirectory. A better hiearchy would use the components from the package names. Hopefully, multiple levels of subdirectories will work. xfree: base: ... xvfb: xfree-xvfb-4.2.0.tar.bz2 As a directory layout, that should be fine. Those refinements can be made at any point - there's no need to have it perfect on first release. Setup.exe is quite capable of handling files moving from one package to another now. They were simple changes to the script I wrote to repackage the distributed archives. I'll try to write proper setup.hint files for all the packages. Cool. Rob
RE: info: single install xfree86 + minimal cygwin?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 11:23 AM Now, this works, and upset/setup are happy (every binary package has a src package) but it is hackish, ugly, and a pain to maintain. Is there a better solution? (Or can we discard the psuedo-src packages without repurcussion? Won't upset be upset by the bin without src problem?) Setup won't be. It won't allow the src box to be ticked unless it knows of a src package details. Rob
RE: info: single install xfree86 + minimal cygwin?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 12:19 PM I don't think it's that big a deal to require cygwin packages to follow a parseable naming scheme; ours is pretty lenient...when it fails, it's not a terrible imposition to either change a '-' to a '_', or swap some digits and alphabetics within a -- word. And package file names are not directly used by humans 99% of the time. That's what setup + cygcheck + upset are for. Rob
makeNativeRgn
Alan,
this may be of use to you: It's the region optimisation I mentioned
before. It seems a little faster to me, which indicates that some
(most?) of the calls have mulitple clip regions.
There's a little extra stuff for the rootless mode in win.h, but it
won't hurt to have that committed - if you're willing.
There is also some rootless stuff (the #if 1-else-end and #if
0-else-end's) in winsetsp and winfillsp, and that stuff should NOT go
into CVS, but I didn't want to corrupt the patch by hand removing. You
should be able to do it easily in your sandbox... (it's only 2-3 lines
to delete).
Index: win.h
===
RCS file: /cvsroot/xoncygwin/xc/programs/Xserver/hw/xwin/win.h,v
retrieving revision 1.1.1.1.2.2
diff -u -p -r1.1.1.1.2.2 win.h
--- win.h 5 Feb 2002 18:47:39 - 1.1.1.1.2.2
+++ win.h 10 Apr 2002 02:39:46 -
@@ -268,7 +268,8 @@ typedef Bool (*winHotKeyAltTabPtr)(Scree
typedef struct
{
- DWORDdwDummy;
+ HWND hwnd;
+ HDC hdc;
} winPrivWinRec, *winPrivWinPtr;
typedef struct
@@ -414,6 +415,7 @@ extern miPointerScreenFuncRec g_winPoint
extern DWORD g_dwEvents;
extern int g_fdMessageQueue;
extern int g_iScreenPrivateIndex;
+extern int g_iWindowPrivateIndex;
extern int g_iCmapPrivateIndex;
extern int g_iGCPrivateIndex;
extern int g_iPixmapPrivateIndex;
@@ -553,6 +555,8 @@ winBlockHandler (int nScreen,
RegionPtr
winPixmapToRegionNativeGDI (PixmapPtr pPix);
+HRGN
+makeNativeRgn (RegionPtr const pRegion);
/*
Index: winclip.c
===
RCS file: /cvsroot/xoncygwin/xc/programs/Xserver/hw/xwin/winclip.c,v
retrieving revision 1.1.1.1.2.1
diff -u -p -r1.1.1.1.2.1 winclip.c
--- winclip.c 7 Feb 2002 21:34:19 - 1.1.1.1.2.1
+++ winclip.c 10 Apr 2002 02:39:46 -
@@ -248,3 +248,33 @@ winPixmapToRegionNativeGDI (PixmapPtr pP
#endif
return(pReg);
}
+
+HRGN
+makeNativeRgn (RegionPtr const pRegion)
+{
+ BoxPtr pbox;
+ int nbox;
+ HRGN rv;
+ nbox = REGION_NUM_RECTS (pRegion);
+ pbox = REGION_RECTS (pRegion);
+ rv = CreateRectRgn (pbox-x1, pbox-y1, pbox-x2, pbox-y2);
+ --nbox;
+ ++pbox;
+ while (nbox--)
+{
+ int combinerv;
+ HRGN tempRgn;
+ tempRgn = CreateRectRgn (pbox-x1, pbox-y1, pbox-x2, pbox-y2);
+ combinerv = CombineRgn (rv, rv, tempRgn, RGN_OR);
+ if (combinerv == ERROR)
+ {
+ ErrorF (makeNativeRgn: Failed to create native region %u\n,
GetLastError());
+ DeleteObject (rv);
+ return NULL;
+ }
+ DeleteObject (tempRgn);
+ ++pbox;
+}
+ return rv;
+}
+
Index: winsetsp.c
===
RCS file: /cvsroot/xoncygwin/xc/programs/Xserver/hw/xwin/winsetsp.c,v
retrieving revision 1.1.1.1.2.8
diff -u -p -r1.1.1.1.2.8 winsetsp.c
--- winsetsp.c 19 Feb 2002 20:31:25 - 1.1.1.1.2.8
+++ winsetsp.c 10 Apr 2002 02:39:46 -
@@ -27,6 +27,7 @@
*
* Authors:Harold L Hunt II
* Alan Hourihane [EMAIL PROTECTED]
+ * Robert Collins [EMAIL PROTECTED]
*/
/* $XFree86: xc/programs/Xserver/hw/xwin/winsetsp.c,v 1.6 2001/10/22
15:21:12 alanh Exp $ */
@@ -48,8 +49,6 @@ winSetSpansNativeGDI (DrawablePtr pDrawa
HBITMAP hbmpOrig = NULL;
BITMAPINFO bmi;
HRGN hrgn;
- int n;
- BoxPtr pbox;
/* Branch on the drawable type */
switch (pDrawable-type)
@@ -67,8 +66,6 @@ winSetSpansNativeGDI (DrawablePtr pDrawa
while (iSpans--)
{
- n = REGION_NUM_RECTS (pGC-pCompositeClip);
- pbox = REGION_RECTS (pGC-pCompositeClip);
ZeroMemory (bmi, sizeof (BITMAPINFO));
bmi.bmiHeader.biSize = sizeof (BITMAPINFOHEADER);
@@ -85,14 +82,14 @@ winSetSpansNativeGDI (DrawablePtr pDrawa
bmi.bmiColors[1].rgbGreen = 255;
bmi.bmiColors[1].rgbRed = 255;
}
-
- while (n--)
+
+ hrgn = makeNativeRgn (pGC-pCompositeClip);
+ if (hrgn)
{
- hrgn = CreateRectRgn (pbox-x1, pbox-y1, pbox-x2,
pbox-y2);
SelectClipRgn (pGCPriv-hdcMem, hrgn);
DeleteObject (hrgn);
hrgn = NULL;
-
+
StretchDIBits (pGCPriv-hdcMem,
pPoints-x, pPoints-y,
*piWidths, 1,
@@ -102,7 +99,6 @@ winSetSpansNativeGDI (DrawablePtrpDrawa
(BITMAPINFO *) bmi,
DIB_RGB_COLORS,
g_copyROP[pGC-alu]);
- pbox++;
}
pSrcs += PixmapBytePad (*piWidths, pDrawable-depth
rootless mode
I've been thinking about rootless mode. Here's my current thoughts: 1) We create a real win32 window for each X window. 2) We use SetWindowLong to store the X window pointer in the WIN32 struct, so that when a message arrives to that windowclass's WindowProc, we can lookup the X window the message belongs to. 3) We use WindowPrivates to store the WIN32 related window HANDLE and other gunk. I don't know how we go about telling X it's rootless - Alan, I'm hoping you can jump in here and say 'do X, Y and Z'. Anyway, whilst I won't have time to be a significant contributor, I hope to have a proof-of-concept patch against the Native GDI engine shortly. Rob
RE: rootless mode
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 7:01 AM To: Robert Collins; Ian Burrell Cc: [EMAIL PROTECTED] Subject: RE: rootless mode Rob, One Win32 window per top-level X windows isn't an optimization... it's just necessary. A top-level window is like a Windows window with a blue border... any other window could be a button or a scrollbar, etc. We certainly don't want to create a Win32 window for each of those (just picture an X window with a bounding Win32 window and a Win32 window for each button it has... won't work). Actually Win32 uses CreateWindow to create all the buttons and scrollbars you see in (say) outlook or wordpad. Based on that I see little or no reason it shouldn't work. However, I imagine that only top-level windows will need to show on the task bar. Anyway, my first goal is simply proof of concept - the native engine rendering into each window based on picking up the pWin from GetWindowLong. What is a good way to detect top-lvel X windows given a WindowPtr (so I can test this rather than being stubborn :}). The top level windows I'm creating have no win32 decoration - no close button etc. That's a window manager consideration and one of the pdfs you've gather documents a good way to handle that. Rob
drawables
For rootless, I'd ideally be able to go from a pdrawable to a pWin. Is there a reliable way to do this? Some scenarios where this makes sense: 1) Anything passed a pDrawable + a pGC - if it's a window we want a HDC for that window. 2) Clipping. If we are drawing a window we need a win32 clipping context so that we don't overwrite other onscreen windows that happen to be in front of us. (At the moment we draw onto the win32 screen DC, because I can't go from pDrawable to pWin in the setspans/fillspans routines. BTW, I have rootless mode happily drawing all the windows, with a win32 window on the task bar. I'm deliberatly not writing a 'internal window manager' at this point. So we're nearly at my proof-of-concept target. Rob
Native GDI
Just a question: how does X cope with region invalidate - say with the Xnest engine? I'm wondering how the native GDI engine will handle having regions invalidated by win32 apps in front of it, without an off-screen buffer. Rob
Building from CVS
Hi, I tried to build from CVS on http://sourceforge.net/projects/xoncygwin using the instructions from http://xfree86.cygwin.com/docs/cg/prog-build-native.html. I've attached the bzip2'd log file from a standard build.. The summary is that it's failing to build the server binaries. All the .o compilations are showing a warning on alloca redefinition, but not actual errors are shown. Any thoughts? Rob World.log.bz2 Description: World.log.bz2
RE: Building from CVS
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 06, 2002 10:49 PM To: Robert Collins; [EMAIL PROTECTED] Subject: RE: Building from CVS Rob, We forgot to tell you that you have to pull the windows-1-branch, which has that fix. Thanks Harold, I assume it also has the GDI engine improvements, which is what I intend to have a quick eyeball at? Rob
RE: Building from CVS
Harold... We're getting places. Found this this time round: make[5]: *** No rule to make target `winrop.o', needed by `libXwin.a' I forgot to re-run the recursive link maker after updating the tag. I'm starting another run now - thanks for the help so far. Rob -Original Message- From: Harold L Hunt [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 07, 2002 5:46 AM To: Robert Collins; [EMAIL PROTECTED] Subject: RE: Building from CVS That is correct. Harold Robert Collins [EMAIL PROTECTED] said: -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 06, 2002 10:49 PM To: Robert Collins; [EMAIL PROTECTED] Subject: RE: Building from CVS Rob, We forgot to tell you that you have to pull the windows-1-branch, which has that fix. Thanks Harold, I assume it also has the GDI engine improvements, which is what I intend to have a quick eyeball at? Rob
X11/Xlib.h not found?
Does the build recipe expect the X11 headers to be installed? The following is a sample error (there are many similar ones) indicating that X11/Xlib.h is not found, and I not thate /usr/X11R6/include is in the include path. I don't have X currently installed. If it needs those headers, and installing them is a safe bet, then I'm happy to do that. It does seem strange to me that it looks at system headers though.. Rob rm -f wincutpaste.o gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith-I. -I../../../../expor ts/include/X11 -I../../../../include/fonts -I../../../../programs/Xserve r/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/ shadow -I../../../../programs/Xserver/miext/layer -I../../../../program s/Xserver/include -I../../../../programs/Xserver/os -I../../../../in clude/extensions -I../../../../exports/include/X11 -I../../../../program s/Xserver/render -I../../../../programs/Xserver/randr -I../../../.. -I../../../ ../exports/include -I/usr/X11R6/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LO CALE -D_X86_ -D__STDC__ -DNO_TCP_H -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURC E=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_ALLOCA -DSHAPE -DXINPU T -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DRENDER -DR ANDR -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFr ee86Server -DXF86VIDMODE -DXvMCExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDE BUG -DFUNCPROTO=15 -DNARROWPROTO -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -D XvExtension -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DX_BYTE_ORDER=X_L ITTLE_ENDIAN -DDDXTIME -DFD_SETSIZE=256 -DDDXOSINIT -DDDXOSVERRORF -DDDXOSFATALE RROR -DHAS_MMAP -UXFree86LOADER -UXF86DRI wincutpaste.c wincutpaste.c:50: X11/Xlib.h: No such file or directory make[5]: *** [wincutpaste.o] Error 1
RE: missing telnet, solution
-Original Message- From: mstucky5 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 10:10 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: missing telnet, solution This whole thread got me thinking about possible ways to avoid this xxx is missing problem... I thought that I'd throw an idea out for discussion... Would it make sense to have setup install a dummy script for some of the common utilities and then overwrite that script with the actual utility if it is selected from the gui as it should be? In debian, there is a package that will do this - I think it that when a binary is not found it queries dpkg to see if a package that can provide it exists. Anyway, I think that an _automated_ approach to this could be quite useful, but not a manual one. (I realise that you didn't imply either, I'm simply getting there first :}). Rob
RE: And we have a xfree cygwin package.. (What are they called?)
-Original Message- From: Andrew Markebo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 4:17 PM | Or, were you planning on keeping the separate .tgz files around too? separate .tgz? I The executable tgz's of the xfree package? I am considering giving it a try using them instead.. small ptoblem might be version numbering, can I put version numbers in the hints file? (the dist tgz files today is automagically built by xfree makefile(?) and therefore I don't want to change their name, to get it as easy as possible) Yes, the version number for a file can be explicitly given, but if your files are non-versioned, you will have mirror site headaches when updates within an Xfree official release are done. Versioning the tarballs takes only a couple of seconds - and can be scripted. Rob
RE: And we have a xfree cygwin package.. (What are they called?)
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 3:40 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: And we have a xfree cygwin package.. (What are they called?) On Tue, Mar 19, 2002 at 11:27:18PM -0500, Harold Hunt wrote: Okay, I mirrored the files: http://www.msu.edu/~huntharo/xbase/xbase-4.2.0-1.tar.bz2 http://www.msu.edu/~huntharo/xbase/setup.hint http://www.msu.edu/~huntharo/xbase/md5.sum .. I assume that these are just for people to play with but that will require a little bit of customization of local setup.ini's if you want to do anything useful. Harold... If I can be so bold, can I suggest that you add a setup.ini to the collection of files - just include the setup.hint contents (see http://www.cygwin.com/setup.html for the setup.ini format. This will let folk grab the X install via setup.exe with NO customisation of local files - all they have to do is run setup.exe, click on Add in the mirror screen and put http://www.msu.edu/~huntharo/xbase in as the URL. Then setup.exe will merge the main setup.exe and the xbase one into one seamless view. If you are going to have http://www.msu.edu/~huntharo/xbase and http://www.msu.edu/~huntharo/xclient and http://www.msu.edu/~huntharo/... (while testing) then put the setup.ini at http://www.msu.edu/~huntharo and include the path in the install: rule. Rob
RE: Installation on CD-Rom, Copying a whole installation
-Original Message- From: Andrew Markebo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 6:44 PM First thoughts, do a package with all required tgz's and then do packages with the fonts not required.. docs.. Hmm what more is needed?? ;-) Here's the easiest way to get started: * 1 package (and one setup.hint) per binary tarball. * make sure that each package lists all it's dependencies. * edit the install script you've got, to remove any tarball extraction stuff, and put it in a new tarball called 'X11-install' or something as a postinstall script, and make sure that the server/client packages depend on that. That should do it. Oh, explicitly list the source for all the packages as the same source tarball (if that's what exists for X). Cheers, Rob
RE: DDraw Blt vs BltFast
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 4:46 AM To: cygx Subject: RE: DDraw Blt vs BltFast Ralf, Those are some very interesting results. I especially like the ones where Cygwin is 10 to 1000 times slower than Linux :) Oh well... I can't bitch anymore for fear of obligating myself to contribute to Cygwin proper. Lol! Seriously though, I'm quite excited by what Ralf has been working on, and the cygserver is in HEAD now, so cygwin 1.11 will have it, and Ralf's patches don't need to be against a development branch. Rob
RE: DDraw Blt vs BltFast
-Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 5:06 AM To: Cygwin-Xfree Subject: Re: DDraw Blt vs BltFast On Tue, Mar 12, 2002 at 09:30:05AM +0100, Ralf Habacker wrote: I have done some analysing work with this and with the cygwin daemon (cygserver transport classes) there may be a way in the future to implement unix domain sockets with named pipes which speed up unix domain sockets up to 250 MB/s, as I have measured with a quick an dirty sample Fine. But how do you implement them on 9x/Me? Perhaps the same way I implemented FIFO's, but easier as the semantics seem less complex to me. Anyway, sure we don't need to have bot NT and 9x all at the same time... Rob
RE: DDraw Blt vs BltFast
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 12:52 PM To: [EMAIL PROTECTED] Subject: Re: DDraw Blt vs BltFast On Tue, Mar 12, 2002 at 06:06:16PM -0500, Harold Hunt wrote: Fine. But how do you implement them on 9x/Me? Perhaps the same way I implemented FIFO's, but easier as the semantics seem less complex to me. Anyway, sure we don't need to have bot NT and 9x all at the same time... Sounds logical to me. There is no reason to limit the performance on Windows NT/2000/XP just because there would need to be a seperate routine for Windows 95/98/Me. I'm glad it sounds logical. Cygwin already has lots of code that is NT specific, e.g., CYGWIN=ntsec. I agree. I got the impression from Corinna's email that what Ralf was suggesting needed a 9x equivalent to be seriously considered. I'm not 100% sure why I got that impression though Rob
RE: ORBit install
-Original Message- From: O'BRIEN,STEVE (HP-UnitedKingdom,ex1) The problem library in gnome-vfs, where there appears to be problems with thread mutexes, although I really have not been able to debug this at all. Hi, I'm the cygwin pthread maintainer. What seems to be the problem? Rob
Re: DirectDrawCreate
- Original Message - From: Harold Hunt [EMAIL PROTECTED] Have a look at autoload.c in the cygwin sources or the setup.exe sources. It provides a symbol to link to for the linker, but doesn't resolve the .dll until runtime. Well, that's okay too, but w32api shouldn't be doing things that break perfectly legitimate calls to Win32 functions. Of course. Autoload.c uses w32api too, so if w32api gets broken, so will setup.exe and cygwin1.dll :}. Rob
Re: XFree86 4.2.0
=== - Original Message - From: Tzafrir Cohen [EMAIL PROTECTED] Further separations can probably made (separate fonts packages, separate documentation packages, etc. Think of all the choices that the install script gives youon what to install). I'm talking about getting *something* up easily and quickly. It can of course change as time goes by. Harolds point about new documentation being required is very important - and IMO minimising the effort needed to setup (no pun intended) the new packages will free up time for doco work, thus hastening the transition. Rob
Re: Cygwin XFree web page looks odd in Mozilla
- Original Message - From: Harold Hunt [EMAIL PROTECTED] I'm kind of surprised that there were errors at all, as I usually run the validator after submitting. Cool. I was surprised too, but I didn't look further than the surface of the issue. I've already made lots of changes to get the page to look as well as it does in Mozilla... I'm going to wait for 1.0 before I make more drastic Mozilla-specific changes. Don't worry, I'm not holding my breath... I have been watching Mozilla since March 2000, when 1.0 was going to be released, any day now. :) Lol. And then some more. Rob
Re: Cygwin XFree web page looks odd in Mozilla
=== - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 17, 2002 3:03 PM Subject: Cygwin XFree web page looks odd in Mozilla Anyone else noticing that the XFree86 web page looks odd in Mozilla? Maybe it's because I'm using the latest snapshot but the Project Overview is showing up under the left bar. It fails validation - usually a sign of some HTML oddity somewhere (just click on the HTML4 icon). Rob
