Re: Compiling XWin (modular Xorg)
On Dec 11, 2007 11:49 PM, Yaakov (Cygwin Ports) wrote: Janjaap Bos wrote: The changes I made are all in the patch. Let me know when you have suggestions, and whether you're able to build it. Perhaps Yaakov is willing to check it with his findings. Thank you VERY much. I will try to look into this into the near future, as the server is the only holdup in getting X11R7 finished on Cygwin. Hi all, Have you guys checked out the Xming patches (http://www.straightrunning.com/XmingCode/)? Most of them modify code that is the same as we use and contain many fixes to current problems we are experiencing, such as the 24bpp issue. Also, a lot of AG's fixes he did not commit to either trunk or the cygwin branch. He's also come up with a rather unsavory, yet workable hack to the overloaded function issue. There are a ton of DD improvements to the GLX acceleration code, too. Admittedly, the person who runs that project is still using monolithic as the base and has a rather bizarre way of updating the sources uses modular code, but still, it ought to be worthwhile to check out. Unfortunately, he keeps his latest changes behind a donation paywall, but I'm sure if asked by a well know cygwin-xorg developer, he would be willing to part with them. As for the overloaded function problem, I do recall we had this same issue back in 2002-2003 with shared libXt. You might want to search through the archives on that one for the whole story. It was a real frustrating problem to deal with, but a good solution was found that worked well. I had a thought on packaging. Perhaps we should adopt the Fedora scheme? I mean they seem to have packaged it nicely without having 60+ packages. We would still want our versioned packages for the runtime, but it should help to cut down on the number of packages without having binary compatibility problems. You could then use the current cygwin x11-xorg package names as collection stubs for the individual ones. Just a thought. Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Alan Hourihane wrote: This test version was built from the mainline X.Org trunk code and not the CYGWIN branch. I'll be working on getting whatever changes exist on that branch over into the mainline trunk code next. If the patches are still in CYGWIN then that's the problem. Thanks, Alan. It seems that DPS support is being phased out, so nevermind about that. However, I have noticed another issue which may (or may not) be solved on the branch. It seems that xcursorgen and the default cursor sets were not built and included this time around. Other then that, the new X seems to be working fine. On a side note, once the dust settles and if you have time to look into it, perhaps it would be possible to make static libraries available in addtion to the shared libraries? Just a thought. Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Alexander Gottwald wrote: On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote: I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? DPS has been obsoleted by xorg and is going to be removed from the xorg tree https://bugs.freedesktop.org/show_bug.cgi?id=3080 BTW, xcursorgen and the icon sets are missing in this release. And not to get into an ideological debate over this, but a package including static libs would be nice. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Nicholas Wourms wrote: On 10/28/05, Alexander Gottwald wrote: On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote: I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? DPS has been obsoleted by xorg and is going to be removed from the xorg tree https://bugs.freedesktop.org/show_bug.cgi?id=3080 BTW, xcursorgen and the icon sets are missing in this release. And not to get into an ideological debate over this, but a package including static libs would be nice. Ack. Ignore this one, it was supposed to be deleted. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/27/05, Alan Hourihane wrote: Yep, uploading myself to sourceware now. They'll be in-place in the next hour. Alan, I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: ttmkfdir no longer needed
Harold L Hunt II wrote: It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: That's not what it says, at least it makes no claim to be a full replacement. It mentions only that it is inspired from the original ttmkfdir, but I don't think it in the same class as the latest version (ttmkfdir-3.x) from RedHat. In fact, RedHat still retains and uses it to this day, even in the bleeding-edge Fedora's (which, BTW, are also using xorg-x11 for X11). IIRC, Mike Harris says in specfile that while mkfontscale is adequate for latin font encodings, it doesn't work all that well with unicode and other complex encodings. Since I speak English, I can't confirm nor deny if this is true, but if Mike is still using it for RedHat's TTF's, then I'd have to say there is some truth to it. You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. Any takers? I'll package it if somebody works the kinks out of it. I would *strongly* advise against any action which would work directly in and/or on a user's system's FONTS dir. The first reason is that we can't guarantee the integrity of that link, since it could be broken due to some changes in CYGWIN case flags or inconsistencies in the case interpretation within the cygwin1.dll. Speaking from experience, this has bitten me once before. Secondly, the various utilities you want to use are required to open and read a significant portion of the font data from the font file. Why should this be of concern? Well if our font programs core dump while doing this, there is a possibility of corruption. There's even the possibility of corruption even if the program works as expected. Font corruption isn't always easy to detect, and often will lead people to make false assumptions about why they are getting unexpected or strange output from their fonts. We really don't want to get into the business of messing around with or in end-users' system directories. A better approach would be to copy the fonts to a predetermined Cygwin directory and work on them there. Perhaps a C program, mkttwin32dir, which does as follows (this is very simplistic): 1) Check for the existence of /usr/X11R6/lib/X11/fonts/win32: If yes, then hash the contents of that directory matching *.ttf into a sorted array, a[]. If no, then create the directory. 2) Check for the existence of the System font dir. If yes, goto next step. If no, abort and leave a textfile, README.fail, which contains some info on the reason it failed and to suggest user manually run the contents of the script. 3) Hash the contents of the system font directory for all matching *.ttf into a sorted array, b[]. Iterate the array, b[], converting strings to all-lowercase. Put each resulting string into the corresponding second column of b[], which will be the target's name. If we found a /usr/X11R6/lib/X11/fonts/win32 dir, then compare the contents of the first array, a[], with the contents of the target column of the second array, b[]. Discard from b[] any entries in which a font is in the target dir but not in the system dir. Also, discard any entries which have a match both in the system and the target dir. What is left will be the names fonts of needing copying and their case-converted target names. Obviously, if a[] is empty, then all matches should be copied. 4) For all contents of b[], spawn cp and binary copy the source to the target. Exit with a success return code. Then we could use this program during postinstall to do the necessary work of keeping a user's /usr/X11R6/lib/X11/fonts/win32 dir up to date. Furthermore, a user could set up a monthly cron job to do this automatically, so that the dirs are kept in sync. This program could also be extended
Re: Updated: lesstif-0.93.91-4
Harold L Hunt II wrote: Noted. I am not sure that I can do anything about that. Doesn't seem like it would be worth looking into at the moment. I would gladly accept a tip or patch from anyone. I don't know how, but I think this is my fault. I modified the install script to bzip the manpages, but that should happen *after* the make install portion. And, yes, I did turn on fontconfig support, and I'm not the least bit ashamed to admit it. It was badly needed IMNSHO. For those who want to know, here's a real easy way to make sure your apps get built right: CFLAGS/CXXFLAGS=`pkg-config --cflags xft` LDFLAGS=`pkg-config --libs xft` But most libtool apps will get the depends right anyhow. If someone *really* wanted to get artsy-craftsy, they could make a package-config file for lesstif, which would ensure all the correct libs were used. Cheers, Nicholas
Re: xfree 4.3.0.2 and XftConfig
Ron Stanonik wrote: Recall, after upgrading xfree from 4.2 to 4.3, then libXft and libfontconfig found no fonts. My mistake apparently. I had to run fc-cache (which scans for fonts and builds fonts.cache-1 files). I assumed fonts.cache-1 were just for performance, not strictly required. I was also surprised that installation didn't run fc-cache. It's in the works. I'm working on making fontconfig freetype external packages, so I plan to contribute post-install scripts to do all the font setup. Cheers, Nicholas
Re: Imake.tmpl not found
Harold L Hunt II wrote: Damien, You can just do this: touch /usr/X11R6/lib/X11/config/host.def Our host.def doesn't really have anything in it, so this should work just fine. I will try to release another fix to XFree86-progs tomorrow if an empty host.def takes care of your problem. Harold, Not important now, but in the next release of -progs, can you make creation of /usr/X11R6/lib/X11/config/host.def done via touch in a post-install script? Traditionally, this is the file that should include any local modifications or user-defined routines for Imake. In essence, it is supposed to be a manual override system-wide defines. Unfortunately, I wasn't paying attention this morning when updating, so I subsequently clobbered mine :-/. Also, not related, but aren't supposed to have a symlink /usr/include/X11 - /usr/X11R6/include/X11? I noticed it isn't there, and swear we had it set at one time or another. Cheers, Nicholas
Rxvt new XFree [was Re: 'Wrong' dll names in 4.3.0-1 packages -breaks all 3rd party X apps]
David A. Case wrote: On Fri, Aug 01, 2003, Harold L Hunt II wrote: No. Older X apps will need to be recompiled for 4.3.0. This is a change that needed to happen. In the meantime, you can keep the old DLLs in the same directory and it will allow older X apps to run side by side with new X apps. One of the most common older apps that needs to be recompiled is rxvt. This seems to be a packaging issue: what is the best way for setup to (help) ensure that people upgrading to the new Xfree86 version get a re-compiled rxvt as well? Of course, in principle, rxvt is no different from other X programs that are not updated when Xfree86 is updated, but I think it is very widely used, and hence likely to trip almost everyone up when it stops working after they update the X packages. Well then, Steve's probably the one to talk to regarding this. I believe the problem is that rxvt isn't actually linked to any Cygwin/XFree86 libs, since it uses its own hybrid emulation lib, libW11. I'll let Steve comment on the specifics involved, but I believe that libW11 will need updating to match current libX11 api differences. I wonder if Donald Becker has updated the sources yet? Cheers, Nicholas
Re: [RFC]: Breaking out fontconfig and freetype into seperate packages
Harold L Hunt II wrote: Nicholas, Can you explain to me what fontconfig and freetype2 are, specifically? Freetype2, quoting the homepage [1]: FreeType 2 is a software font engine that is designed to be small, efficient, highly customizable and portable while capable of producing high-quality output (glyph images). ... Note that FreeType2 is a font service and doesn't provide APIs to perform higher-level features, like text layout or graphics processing (e.g. colored text rendering, hollowing, etc..). However, it greatly simplifies these tasks by providing a simple, easy to use and uniform interface to access the content of font files. In other words, freetype2 provides the generic API for reading and preprocessing font files. It also provides the core engine for certain font-related features (such as hinting, anti-aliasing, greater multibyte glyph capabilities). It currently supports: *TrueType fonts (and collections) *Adobe Type 1 fonts *CID-keyed Type 1 fonts *CFF fonts *OpenType fonts (both TrueType and CFF variants) *SFNT-based bitmap fonts *X11 PCF fonts *Windows FNT fonts *BDF fonts (including anti-aliased ones) *PFR fonts *Adobe Type42 fonts (limited support) Freetype1 is an older version of freetype2 and is NOT API source or binary compatible with freetype2. Some applications still depend on it at compile-time, but I don't think XFree86 still does. Most notable is the fact that its library is libttf* as opposed to libfreetype* in freetype2. Fontconfig is a library for configuring and customizing font access. It is the middleware between freetype2 and Xft. But it also provides equivalent interfaces between freetype2 and other applications. From the webpage[2]: Fontconfig can: *discover new fonts when installed automatically, removing a common source of configuration problems. *perform font name substitution, so that appropriate alternative fonts can be selected if fonts are missing. *identify the set of fonts required to completely cover a set of languages. *have GUI configuration tools built as it uses an XML-based configuration file (though with autodiscovery, we believe this need is minimized). *efficiently and quickly find the fonts you need among the set of fonts you have installed, even if you have installed thousands of fonts, while minimizing memory usage. *be used in concert with the X Render Extension and FreeType to implement high quality, anti-aliased and subpixel rendered text on a display. Fontconfig does not: *render the fonts themselves (this is left to FreeType or other rendering mechanisms) *depend on the X Window System in any fashion, so that printer only applications do not have such dependencies. If you are interested, the XFree86 backend (Xft2) is described in detail on the same page. Do they consist of a couple libraries and some executables? How many files are involved in a package that contains them? freetype1, freetype2, fontconfig each consist of some headers, some shared data, some i18n/l10n crap, and a few utility executables. For instance, redhat has the following packages in Shrike(RH9): [Note that the freetype1 stuff is included in the freetype2 packages] freetype 2.1.3-6: - /usr/lib/libfreetype.so.6 /usr/lib/libfreetype.so.6.3.2 /usr/lib/libttf.so.2 /usr/lib/libttf.so.2.3.0 /usr/share/doc/freetype-2.1.3 /usr/share/doc/freetype-2.1.3/ChangeLog /usr/share/doc/freetype-2.1.3/README /usr/share/doc/freetype-2.1.3/README.UNX /usr/share/doc/freetype-2.1.3/announce /usr/share/doc/freetype-2.1.3/docs /usr/share/doc/freetype-2.1.3/docs/BUGS /usr/share/doc/freetype-2.1.3/docs/BUILD /usr/share/doc/freetype-2.1.3/docs/CHANGES /usr/share/doc/freetype-2.1.3/docs/DEBUG.TXT /usr/share/doc/freetype-2.1.3/docs/FTL.txt /usr/share/doc/freetype-2.1.3/docs/GPL.txt /usr/share/doc/freetype-2.1.3/docs/INSTALL /usr/share/doc/freetype-2.1.3/docs/PATENTS /usr/share/doc/freetype-2.1.3/docs/TODO /usr/share/doc/freetype-2.1.3/docs/VERSION.DLL /usr/share/doc/freetype-2.1.3/docs/cache.html /usr/share/doc/freetype-2.1.3/docs/design /usr/share/doc/freetype-2.1.3/docs/design/basic-design.png /usr/share/doc/freetype-2.1.3/docs/design/design-1.html /usr/share/doc/freetype-2.1.3/docs/design/design-2.html /usr/share/doc/freetype-2.1.3/docs/design/design-3.html /usr/share/doc/freetype-2.1.3/docs/design/design-4.html /usr/share/doc/freetype-2.1.3/docs/design/design-5.html /usr/share/doc/freetype-2.1.3/docs/design/design-6.html /usr/share/doc/freetype-2.1.3/docs/design/detailed-design.png /usr/share/doc/freetype-2.1.3/docs/design/hierarchy-example.png /usr/share/doc/freetype-2.1.3/docs/design/index.html /usr/share/doc/freetype-2.1.3/docs/design/library-model.png /usr/share/doc/freetype-2.1.3/docs/design/modules.html /usr/share/doc/freetype-2.1.3/docs/design/simple-model.png /usr/share/doc/freetype-2.1.3/docs/freetype2
Re: XFree86 fonts from 4.2.0 to 4.3.0
Harold L Hunt II wrote: Can anyone think of any changes to the font packages between 4.2.0 and 4.3.0 that would require me to repackage and distribute 4.3.0 font sets? If not, I would really like to just leave the current 4.2.0 fonts in place since it will save most people from downloading between 15 and 50 MB of the same stuff. Of course, the version numbers will look a little funny, but I think most users would be pleased that they didn't have to download the fonts again. Of course, if anyone knows otherwise, please speak up now so I don't make a terrible mistake. I know they added a couple more TTF fonts and a few more OTF fonts (mostly non-latin glyphs tho). You might also want to check the XFree cvsweb as I'm pretty sure they made some changes to the generic bdf fonts as well. Cheers, Nicholas
Re: XFree86-bin,etc 4.3.0-1 broken?
Harold L Hunt II wrote: Andrew, You aren't a -multiwindow guy yet? I don't know about him, but some of us do prefer to have a full window manager to operate in. However, I'm sure there are many who like to have a rootless X, and thus multiwin suits them fine. It would be sorta nice, though, if the window managers could be relinked/bumped to current versions. Thanks Harold for all your hard work, we appreciate it. Cheers, Nicholas
Re: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
Harold L Hunt II wrote: Nicholas, I really don't know what to do here. Perhaps some others know what to do and whether or not this is a good idea. Would it be easier to update to 4.3.0? Have we already made Xt a shared lib in 4.3.0? On a side note, has anyone been seeing signs of when 4.4.0 is going to be released? I noticed that they just tagged 4.3.99.9, so maybe it would be better to wait an release 4.4.0 when it is ready instead. Any thoughts? Hi Harold, Thanks for sharing your thoughts on this. Alexander makes an excellent argument for something I did not entirely considier, a broken import table. So your proposal to move to 4.3+ sounds like a plan to me. Perhaps a strictly testing release of 4.3.99.9 might be in order? If what you say is true, it is highly doubtful that they would be making serious incompatible interface changes so late in the game. Something I forgot to mention was the whole problem with makedpend which, for lack of vision, insists on hardcoding the system include paths (which screws people who have a different version of gcc from the one used to compile X). If anything, this needs to be configurable in a global config file or during runtime it should call the compiler to learn the proper include paths. I was planning on filing a bug report for this, if it hadn't already been fixed upstream. Cheers, Nicholas
[XFree86-4.2.0] Now that we have an improved ld, please make libXta shared library.
Hi Harold, It's been awhile... Anyhow, I've been working on a few packages which use libtool, and thus the reason behind my request. It turns out, using the new libtool, that one has to go to extreme lengths just to get libXt to link in, since the new libtool balks at linking true static archives into shared libraries on Cygwin. As you know, X11's libs are very fussy over link order, thus there exists no simple way of getting the job done (i.e Automake refuses to allow -Wl flags in _la_LIBADD). I've managed to resolve my issue locally by passing -Wl,-L/usr/X11R6/lib -Wl,-lXt -Wl,-lSM -Wl,-lICE -Wl,-lX11 -Wl,--exclude-libs,libXt.a to my projects' _la_LDFLAGS, but this is obviously a kludge. There are many reasons why this is suboptimal, but the number one reason is that there is no way to transmit this information to projects linking against the library. Any linkee will need to know that -lXt should linked in (I'll admit most projects are on the ball and already have -lXt in their build, but not all). Another reason being that it reduces code bloat, which may or may not lead to better performance. However, the primary reason for not building libXt shared is moot and has been for several months now. Compiling with the latest stable binutils cygwin dll will allow an effortless building of libXt.dll. If you doubt me, then `cd /usr/X11R6/lib` and do this: gcc -shared -o ../libXt.dll -Wl,--image-base=0x1000 -Wl,--out-implib,libXt.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive libXt.a -Wl, --no-whole-archive libSM.a libICE.a libX11.a It works like a charm. As we speak, I'm compiling a shared lesstif using libtool-1.5 and a shared libXt. After minor adjustments of the Makefiles to account for cygwin's no undefined in shlibs issue, it seems to be working fine. I really can't see any downside to doing this, since going from static-only - shared breaks nothing (even if it does, then it does so because of badness of the broken package's build). This may seem on the outside like a 4.3.0 type of change, but it really doesn't seem all that harmful. So, hopefully you might consider this in one of your updated test series? Thanks in advance for your consideration. Cheers, Nicholas
Re: Rootless Mode is an Important and Needed Feature
--- Mlarcvaernas [EMAIL PROTECTED] wrote: I think that a Rootless mode for the Xserver right now is one of the most important and crucial features needed. For the Xserver to be used in a way that is convenient for many users, the option to have X applications displayed on the main Windows desktop is pretty important. Of course the current Root mode should also be available as well, since it also has uses. The new rootless mode should be one of the top priorities. Since you are using it in a commericial environment, I suggest you cough up so dough to sponser Harold for a weeks worth of work. Then you'd get your rootless mode. Otherwise, tell the whining users to shut their piehole. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: XFree 4.2.1 + fontconfig-2
--- Alexander Gottwald [EMAIL PROTECTED] Secondly, Cygwin's shared import libraries end in dll.a not .a [which is the suffix reserved for static import libraries]. I really think we ought to differentiate on this. What if I wanted to distribute a shared and static version of my library? Afaik you can either build a X11 library static or shared. imake.rules contains a macro LibraryTargetName which expands to libName.a and is widely used in the Imakefiles. The change the macro to use libName.a for static and libName.dll.a #if Concat(SharedLib,libname) #define LibraryTargetName(libname) Concat3(lib,libname,.dll.a) #else #define LibraryTargetName(libname) Concat3(lib,libname,l.a) #endif But I don't know if this is either valid for imake or if it will break anything. And when you do a shared and a static version, the static version will most likely be name libName.dll.a too. Well that doesn't make any sense because on linux it builds shared libraries with so and static libs with .a. Also, the way it builds it makes it possible in my mind. I make puts shared objects in $BUILDDIR/ and static into $BUILDDIR/unshared/. It shouldn't be too hard to insert the logic necessary to handle archiving the contents properly. Also, ld can automatically generate shared import libraries during linking of the dll, so that might be a possible route to look at. As you know, ld automatically recognizes dll.a suffix and will use that as the shared import library. I'm not trying to harp, but this was causing me trouble earlier this year. There are times when it is handy to link in a static manner, allowing you to ship as few seperate files as necessary. Also, I don't understand the need for keeping import libraries in subdirs. If my original idea doesn't suite you, why not this (if possible): This was not the system install but only the global install in the build tree. I'm sorry, but I don't understand what you mean here... Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: XFree 4.2.1 + fontconfig-2
--- Alan Hourihane [EMAIL PROTECTED] wrote: On Tue, Sep 24, 2002 at 09:32:27 +0200, Alexander Gottwald wrote: On Mon, 23 Sep 2002, Nicholas Wourms wrote: How about a seperate package call X11-compat for this? Just seems like a waste of space for people who don't care. Good idea library name used on *nix: libXfoo.0.0.so actually libXfoo.so.0.0, everything else will also break the library versioning. *for Cygwin: runtime name: - cyg + basename + . + major + . + minor + . + dll [i.e. cygXfoo.0.0.dll] Any minor version bump will break older clients. They will request cygXfoo.0.0.dll but cygXfoo.0.1.dll is installed and is sufficient. if we name it only cygXfoo.0.dll, can the cygwin installer make sure that at least package foo-x.y-1 is installed and not only foo-x.y-0 for all packages requiring the new version? I think in this instance that windows doesn't help us much. I think it should be fine if we had say libXfoo.0.dll installed (which was really v0.0), but then we released Xfoo-0.1.tar.gz which installed another libXfoo.0.dll (which is now v0.1). I.E We only ever report the major version number and forget about the minor one, as in the case of the minor number we are always backwards compatible. Of course, you're correct. I was worried they might make a binary incompatible minor release. However, if this is not the case, then we should be in good shape :-). Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: XFree 4.2.1 + fontconfig-2
--- Alan Hourihane [EMAIL PROTECTED] wrote: On Tue, Sep 24, 2002 at 10:56:54PM +0200, Alexander Gottwald wrote: Nicholas Wourms wrote: final outcome: -- /usr/X11R6/bin/cygXfoo.0.0.dll /usr/X11R6/lib/libXfoo.0.0.dll.a /usr/X11R6/lib/libXfoo.0.dll.a /usr/X11R6/lib/libXfoo.dll.a /usr/X11R6/lib/libXfoo.a Attached a patch which tweaks the makefile to build lib$(NAME)-$(MAJOR).dll lib$(NAME)-$(MAJOR).a lib$(NAME).a - lib$(NAME)-$(MAJOR).a for Xft1 and Xft2 its exports/bin/libXft-1.dll exports/bin/libXft-2.dll exports/lib/libXft-1.a - ../../lib/Xft1/libXft-1.a exports/lib/libXft-2.a - ../../lib/Xft/libXft-2.a exports/lib/libXft.a - libXft-2.a Nice job! For the libXft-1.dll we'll need a hack somewhere to make that libXft.dll for backwards compatibility. Well if I might comment on this and take a stance similar to Chuck's line of reasoning (we were discussing this the other day). First off, it Would Be Nice (tm) to use the prefix that the core distribution uses cyg. Alexander says making that happen is trivial, so why not go with the standard? Secondly, Cygwin's shared import libraries end in dll.a not .a [which is the suffix reserved for static import libraries]. I really think we ought to differentiate on this. What if I wanted to distribute a shared and static version of my library? As you know, ld automatically recognizes dll.a suffix and will use that as the shared import library. I'm not trying to harp, but this was causing me trouble earlier this year. There are times when it is handy to link in a static manner, allowing you to ship as few seperate files as necessary. Also, I don't understand the need for keeping import libraries in subdirs. If my original idea doesn't suite you, why not this (if possible): shared: --- exports/bin/cygXft-1.dll exports/bin/cygXft-2.dll exports/lib/libXft-1.dll.a exports/lib/libXft-2.dll.a exports/lib/libXft-2.dll.a - libXft.dll.a static: --- exports/lib/libXft-1.a exports/lib/libXft-2.a exports/lib/libXft.a - libXft-2.a I'll have a look at Alexander's work to see if I can get it to do this. Again, I appreciate the hard work both of you put into it. Call me crazy, but after some previous threads on the main list, I know how important it is to keep a common naming schema. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: XFree 4.2.1 + fontconfig-2
--- Alan Hourihane [EMAIL PROTECTED] wrote: On Tue, Sep 24, 2002 at 11:24:43PM +0200, Alexander Gottwald wrote: Alan Hourihane wrote: Nice job! For the libXft-1.dll we'll need a hack somewhere to make that libXft.dll for backwards compatibility. in cygwin.cf is BuildXft1Library still set to no and the for Xft2 is still build befor Xft1, so Xft.a links to Xft-1.a after make in lib O.k. I'm doing a build later with all your patches you've submitted to the XFree86 patch list and once I've test built I'll commit everything. Well, if there are no objections, I'm still interested in trying to address the issues laid out in my previous message. My main concern as a package maintainer is the ability to produce shared and static import libraries with the Imake system. It shouldn't be too hard to do, seeing as how this is possible on unix utilizing different suffixes. I'll have a look into the Imake system over the next few days and see what I can come up with. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
RE: X client wrapper for Win apps?
--- Stuart Adamson [EMAIL PROTECTED] wrote: One method is to provide a 'mirror driver' to intercept the all calls from GDI to the display driver (this should be the method used by Netmeeting). But that requires a device driver doesn't it? (i.e. code that runs in kernel mode). Hooking into user32.dll only requires code that runs in user mode - so is a lot easier to get right. As the windwos sample code probably is limited by some licensing issues the driver probably has to be developed without this code - but IANAL. The DDK is a free download (it does say you need VC 5 or 6 to compile drivers - I've never tried with gcc). Now if we could only get the MingW/W32api folks to provide DDK import libraries, headers, and means to build vxd's, we'd be all set :-). Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: New Project (was RE: X client wrapper for Win apps?)
--- Stuart Adamson [EMAIL PROTECTED] wrote: As what we are wanting to do here isn't strictly a cygwin/Xfree86 thing could I suggest we start a new sourceforge project and mailing list for this? A new SF project yes, but this is very much a Cygwin/XFree related issue. It's easier to keep up with things if you don't have to subscribe to tons of lists. I say we keep the discussion going on here. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: New Project (was RE: X client wrapper for Win apps?)
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Please don't use GDI in the name. I ask this because I don't want there to be confusion between the Cygwin/XFree86 NativeGDI engine and any foogdi project. Consider instead something like the following: XShell XExplorer Something more along those lines would help to differentiate your project from Cygwin/XFree86. I don't see why this has to be seperate from the Cygwin/XFree project? It seems to me that they are proposing more of an extension/addon then replacing the server itself. Do you have some objection to what is being proposed? Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: New Project (was RE: X client wrapper for Win apps?)
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Any such development would need to occur in a branch that could eventually be merged back in if it proves stable, useful, well modularized, and actively maintained. If not, I'll just forget that anyone ever talked about doing it in the first place. That's why it needs to move off list, even if it ends up being essentially a feature of Cygwin/XFree86 rather than a seperate program/library. Harold, I don't buy that argument, as I'm sure anyone else who is developing features for Cygwin/XFree isn't directly commiting their changes to HEAD on xfree86.org. Thus, most people would have their own seperate branch from which they would submit changes to be merged into the main branch. I'm sure the fellow working on xwinclip has a local branch that he uses. The point is that for once we are having a lively discussion on this list and I don't see why a new list is necessary. Just makes life harder for everyone. It isn't like this list gets that much volume anyhow. Discussion is *good*, despite your contention that the only thing that should be said is Here's the patch, what do you think? Sometimes planning is necessary and getting input from the community vital to properly implementing a feature. I still don't see why you are so adverse to people talking about haw nice it would be to have x or y, especially when the discussion is serious. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: XFree 4.2.1 + fontconfig-2
Hi Alan, --- Alan Hourihane [EMAIL PROTECTED] wrote: On Wed, Sep 18, 2002 at 11:25:11 -0400, Harold Hunt wrote: Nicholas, I wasn't even aware of XFree86 4.2.1 until you mentioned it. I am not sure if I will build a release of it or not... seems like a lot of trouble for just a few fixes, with non of them Cygwin-specific. 4.2.1 has an important security fix - arguably whether it matters for cygwin based installations though. Yeah, you're probably right. Still I haven't checked but I thought it contained [operational] bug fixes as well? As for building versioned DLLs --- I have no idea. I am not knowledgeable enough about that topic to be able to give you an answer, or even to be able to discuss it. In regards to Xft1 and XFt2, Alan Hourihane and I noticed a problem with both of them being built and one DLL (version 1) wiping out the other DLL (version 2), so we said to hell with it and stopped building Xft1 and went full-on with Xft2. As to whether or not that was a good decision, I can only say that Alan thought it was okay, so it is okay with me :) For this issue, I would revisit it, if someone claimed that there are applications for Cygwin/XFree86 that relied on Xft1. I suspect for the number of applications that will become available for Cygwin/XFree86 they'll now be using Xft2 anyway. But please speakup if this is a problem, I will take another look at fixing it. Well this isn't a problem for me. Since you probably have a close working relationship with Keith, I assume you are more clued-in than me. I made a hasty assumption and my thinking Xft2 was not source compatible with Xft1 apps, so it may not be true. Can you confirm this? I should be releasing QT2 shortly, which uses Xft, but I haven't investigated if it compiles against Xft2 headers/libraries. I think some of the gtk-1 stuff uses Xft1, and someone is working on this. Just to be safe, I'm CC:'ing Steve O. who is working on the Gnome port. I still think, though, that it would be worth the effort to bring Xfree's runtime libraries into sync with the generally accepted Cygwin standard: cyg + library name - lib + ABI Revision + .dll (i.e. cygpopt0.dll) I'm sure this would not only fix the issues now, but might prevent further headaches in the future. However, I know the hell that is Imake, so I'm not going to make a big fuss over this now. Perhaps a suggestion for Cygwin/XFree-4.3.0? So, in summary, there is not likely to be a release effort applied to getting 4.2.1 out the door... unless I suddenly come up on a great amount of time. Also, Alan shipped me the standard X packages last time, which I fed through the Cygwin packaging script, so if he does that this time I'll likely make a 4.2.1 release. There's no bandwidth from me at the moment to cover this, I'm swamped underneath lots and lots of work. Hmm... I guess it wouldn't make too much sense at the moment. Just if Harold was going to release a new test version, that's all. While I have you here, I have a question which Harold said he didn't know. Why was libXaw built as a static library [it's usually shared on linux]? I'm running into some runtime issues with my libXaw3d package [I built it as dll] and I suspect the answer lies in the reasoning behind that question. I was also wondering how you generated the foo-def.cpp? Is there a script that does this or do you just have to go through the entire source? Maybe I'm missing something because I've been spoiled by libtool/ld autogenerating the exports... Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
RE: X client wrapper for Win apps?
--- Harold L Hunt [EMAIL PROTECTED] wrote: Yikes. Didn't your mothers ever tell you guys that you are crazy? C'mon Harold, doesn't the idea seem even a bit compelling? Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: X client wrapper for Win apps?
--- Jehan [EMAIL PROTECTED] wrote: Stuart Adamson wrote: Every Windows draw command is translated into calls to a GDI driver. this driver is either the driver of the graphics card or a printer. The people from wine already have written a driver which exports a GDI interface and maps all calls to X11. Maybe this is a starting point. But xfree86 will also be using this interface to draw to the screen (as will the logon box etc). I can see this becoming rather circular You need to be able to set the GDI context per application. Maybe the way forward is to filter calls to user32.dll (where most of the basic windowing functions end up). By filtering I mean renaming user32.dll to user32-real.dll and writing your own user32.dll which either sends requests to X11 or to user32-real.dll, depending on the process id of the requesting process. Oh nice! I'll then look forward to the new Windows service pack and the number of new posts in the mailing about XFree being broken after the upgrade. So? Your point? It can be fixed and rereleased. You forget that this isn't a CD distro, it's a net distro. But I have a better idea, replace the kernel32.dll with our own that will convert Windows calls into a Linux/BSD/Un*x calls. That way, instead of having Windows window showing in Xfree running in Windows, you'll just have Windows on top of Xfree. We would also have a perfect Unix layer for Windows then, we won't need Cygwin anymore, we would use Linux/BSD/Un*x directly. It will also add to the security/performance/whatever. No, because then you have done what ReactOS is doing. This is different... Oh wait, that's WINE isn't it? ;) No it isn't, because you are still accessing the other Windows dll's for function calls, which is the whole point. Can you run MS Visual Studio in WINE? I think not... Getting rid of Explorer window manager and server, replacing it with X11 is the ultimate goal. You still want to maintain the library compatibility though. We *already* know your position regarding this from the last time it was discussed. You may not be interested, but there are others who are. So, unless you have something to contribute (other then rants and faulty arguments), why not give it a rest? :-P Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: X client wrapper for Win apps?
--- Jehan [EMAIL PROTECTED] wrote: Keith D. Tyler wrote: More over, if you have GDI-fake-X-GDI-real, that would be quite ugly for the speed. Wouldn't running Windows emulation under POSIX emulation under Windows be, at best, just as bad? Yes. That's why I'm saying: - if you want Windows inside X, use Linux+WINE - if you want X inside Windows, use Windows+Cygwin/Xfree but I don't see the point in having Windows inside X inside Windows. The only thing I could understand is that WINE doesn't work with all application yet. But even then, hacking X because WINE doesn't work isn't the best solution (it's far better to fix WINE instead). What about if you use hardware which linux doesn't support (and may never support)? Certain laptops come to mind as well as other things, like scientific intstruments. The point of cygwin isn't just to make X-Windows apps run under Explorer. It's also about providing a posix environment, which is meshed in with Windows itself, that people can use as an alternative to the currently available Windows tools. Explorer is nothing more than a bloated tool that some of us would rather replace. Just because we don't like one part doesn't mean we should throw the baby out with the bath water... I can think of many reasons why Wine on linux will never provide for every situation. The point, I think, is that some of us want to use the other 80% of the documented (and undocumented) Windows API w/o emulation. So what's the big deal? Again, we know your stance, I don't think there is anything you can say that I(we) haven't already heard. Cheers, Nicholas __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: building XFree86 from cvs
--- Guy Harrison [EMAIL PROTECTED] wrote: On Tue, 20 Aug 2002 10:13:50 -0500, Michael Harnois [EMAIL PROTECTED] wrote: Oooh. This is stranger than I thought. Some of those programs do get built correctly, despite the log messages. For instance in config/util, makestrs, revpath, and rman build ... but lndir doesn't. Probably because gcc -o foo yields foo.exe automatically but unfortunately dependencies and so forth won't know that. Your average configure make app can sometimes get away with it - only to fail on the install uninstall (good indication of this problem existing is make invokes the linker even though the last make succeeded). Sadly this is my first forray into the world of Imake so take my advice for this particular problem with a strong pinch of salt. You'd think TOG would get a clue and switch to the autotools... Cheers, Nicholas __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com
Re: Using Cygwin to connect an AIX box. Questions for german, italian, french, spanish [...] users
--- [EMAIL PROTECTED] wrote: Hello, I don't use xkb extension and after each logon to AIX system run xmodmap .xmodmap.cz on my remote machine, where .xmodmap.cz is my keyboard definition file.This needs to by run just once, not for each terminal. Pavel Stephane Poirey [EMAIL PROTECTED]To: [EMAIL PROTECTED] m cc: Sent by: Subject: Using Cygwin to connect an AIX box. Questions for german, italian, french, cygwin-xfree-owner@spanish [...] users cygwin.com 05.08.2002 19:25 Please respond to cygwin-xfree I know that Alt Gr problems were under the spotligth in the past and there is probably no solution since it seems to be an aix related problem, but I wanted to ask people using non-qwerty keyboards what solution do they adopted (if the did'nt give up) ? Use English __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com
Re: Problem with Xdvi using Xfree 86
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Mon, 19 Aug 2002, Bertrand Muquet wrote: Hello I've got a problem running xdvi with Xfree 86 When Xdvi shall display .eps files, it does not work and I get the fwg msg: gs: unknown device:X11 This message is coming from ghostscript. This gs is not compiled with X11 support. Recompile ghostscript to use X11 as output device. Or ask the maintainer of ghostscript if he could provide packages with X11 support. Actually, this is not true. The ghostscript-x11 package contains the X11 gs binary, and installs it in /usr/X11R6/bin. So all he has to do, if it is possible, is to tell Xdvi to use that binary instead. I have no idea how to do that, though. Cheers, Nicholas __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Problem with Xdvi using Xfree 86
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Tue, 20 Aug 2002, Nicholas Wourms wrote: So all he has to do, if it is possible, is to tell Xdvi to use that binary instead. I have no idea how to do that, though. man xdvi -interpreter filename (.interpreter) Use filename as the Ghostscript in terpreter. By default it uses gs. Well I was trying to encourage him to look up the answer himself rather then just give to him. Oh well... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: More xrn build woes
--- [EMAIL PROTECTED] wrote: Hmm. I'm still trying to build xrn. $ xmkmf mv -f Makefile Makefile.bak imake -DUseInstalled -I/usr/X11R6/lib/X11/config In file included from /usr/X11R6/lib/X11/config/Imake.tmpl:1845, from Imakefile.c:9: /tmp/IIf.576279:312: unterminated `#ifdef' conditional imake: Exit code 1. Stop. However: $ cat -n /usr/X11R6/lib/X11/config/Imake.tmpl [snip] 1843XCOMM -- 1844XCOMM start of Imakefile 1845#include INCLUDE_IMAKEFILE [snip] $ cat -n Imakefile [snip] 312#ifdef MOTIF 313TKSED= -e 's/MOTIF//' -e '/XAW/d' -e 's/notify()/Activate()/' \ 314-e 's/unset()/Disarm()/' -e 's/set()/Arm()/' \ 315-e 's/\([*.]\)label:/\1labelString:/' \ 316-e 's/no-op(RingBell/beep(/' \ 317-e 's/\.\([^.]*\)\.baseTranslations/*\1*translations/' \ 318-e 's/baseTranslations/translations/' \ 319-e 's/Down/osfDown/' -e 's/Up/osfUp/' \ 320-e 's/Left/osfLeft/' -e 's/Right/osfRight/' 321#else 322TKSED= -e 's/XAW//' -e '/MOTIF/d' 323#endif [snip] In regard to your issue, it is most likely that the unterminated if statement is happening much earlier, the preprocessor just realizes it at that line. Also, you should probably be using 'xmkmf -a'. Other then that, I really can't think of anything else. You'll just have to go through every statement to make sure it's kosher. Perhaps someone else has an idea... Cheers, Nicholas __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Cygwin problem
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Fri, 16 Aug 2002, Manjunatha Shetty Kondalli wrote: Could you please tell me the solution for following problem? Xlib: connection to mywinhost:0.0 refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Error: Can't open display: mywinhost:0 _Never_ mail me directly when the question belongs to the cygwin-xfree mailinglist. *ROFLMAO*, they can't help it, they're just n00bies! Seriously though, the mcookie application is supposed to allivate this error. Perhaps it should be included in the script. Cheers, Nicholas __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Java in Windows on X
--- Brian Genisio [EMAIL PROTECTED] wrote: Benjamin Riefenstahl wrote: Hi Stuart, Stuart Adamson wrote: I thought it would be neat if there were a way to run a Java app in Windows, and display on an X server. A quick web search on Java, X11 points me to http://sourceforge.net/projects/escher/ . Sounds interesting. so long, benny Yeah, that does sound interesting... It looks more like a Java interface to the X libraries. I can see how this would be extremely useful. Unfortunately, what I am looking for (just peeking for time being), is the existence of a VM that supports this functionality, like the *nix versions do. It would be neat to run the java VM with a flag that used the X protocol instead. Want in one hand, and shit in annother... see which fills up quicker. Well, I can't make any promises, but I've been kicking around the notion of porting the Sun Community Sources version of java to Cygwin/XFree. Currently, my first hurdle is to get OpenMOTIF fully ported, as the jdk won't compile with lesstif. There are some licensing issues regarding that, but I really don't give a damn what the Open Group says. So, once that's done, then comes the hard part. We'll see how far along cygwin's threading capabilities are, as that is probably the most worrisome aspect. Currently, there has been much work done in progressing sysV IPC, so when the time comes it should be ready to roll. Hopefully I can get a useful vm out of it, but it's really just for fun. Anyhow, swing and awt support is just plain dreadful, if not non-existent, in the various gpl'd vms. So, I don't need to be reminded about them, because they are frankly useless. Since I'm not about to write the X11 interface from the ground up, I figure this would be the best bet. Besides, who knows, if this is successful I might submit my build to Sun and see if they'll allow redistribution. Cheers, Nicholas __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
RE: Java in Windows on X
--- John Morrison [EMAIL PROTECTED] wrote: Ooh, if you need anyone to help test! I will! I've been wanting somebody to do this since I started cygwin and Java development! Well I'll see what I can do. Last time I was working on it, I was battling bad arrays and structs which couldn't be autoimported by ld... PITA time :-). I'll let you know, but as I said this is a side project and my plate is fairly full with current cygwin obligations such as QT, bdb, and rpm. Although, when I do get something going, I sure could use a hand, as this is going to require some major munging of the source files to figure out which WIN32 defines should stay and which should go. Cheers, Nicholas __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Troubles using XFree86-Xaw3d-1.5-1
--- Hans Werner Strube [EMAIL PROTECTED] wrote: Some months ago I built xfig with an easily self-compiled static libXaw3d.a. Now after installing XFree86-Xaw3d-1.5-1, I rebuilt xfig. This failed with a plenty of errors indicating multiple entry-point definitions (from Xaw3d and Xt) and auto-import errors (with respect to SME). The X libraries used were -lXpm -lXaw3d -lXmu -lXt -lXext -lX11 . Tentatively I omitted -lXt, which did not work either, resulting in an excessive list of other auto-import errors. Similar errors were reported before under subject Problems with libXaw3d [Was: [ITP] FreeCiv-1.12.0-1 for X Try putting Xaw3d later in the link line, like: -lXpm -lXmu -lXt -lXaw3d -lXext -lX11 Admittedly, I'm having some trouble myself now. Its beginning to look like there was a reason Xaw was compiled statically. I'm trying to track down some of the people who intially worked on this project to ask why they compiled Xaw statically. However, it is interesting to note that there are no problems with compiling Xaw or Xaw3d as dll's on OS/2. I have a suspicion that some of the auto-imported data is being messed up. As I said to Lapo, I'm working on it. If worse comes to worse, I'll just re-release as a static library until I can figure out how to fix the dll. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
RE: QT2 ready for ITP?
--- Ralf Habacker [EMAIL PROTECTED] wrote: What do you wan't more ? The expression is: What more do you want? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
RE: QT2 ready for ITP?
--- Nicholas Wourms [EMAIL PROTECTED] wrote: --- Ralf Habacker [EMAIL PROTECTED] wrote: What do you wan't more ? The expression is: What more do you want? Cheers, Nicholas Arrrggg! I forgot about the Reply-To munging! Sorry, this wasn't intended for the list. __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: /etc/profile.d/00xfree.csh vs. grep
This is more appropriate for the Cygwin/XFree list.
--- Keith Thompson [EMAIL PROTECTED] wrote:
The script /etc/profile.d/00xfree.csh includes the following line:
eval echo ${PATH} | grep -q ${X11PATH}
This is executed before $PATH has been set, resulting in an error
message:
grep: Command not found.
The fix is simple: change grep to /bin/grep.
(00xfree.sh uses /bin/grep.)
--
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]
http://www.ghoti.net/~kst
San Diego Supercomputer Center *
http://www.sdsc.edu/~kst
Schroedinger does Shakespeare: To be *and* not to be
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Re: QT2 ready for ITP?
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 11:14:50AM +0200, Ralf Habacker wrote: Any comments ? Are there any licensing issues with qt? Is the open source license compliant with cygwin's? http://cygwin.com/licensing.html Ghostscript's license [The aladdin license (APFL?)] is much more restrictive than the QPL. Besides when you compile QT, you'll get a screen which shows how the QPL is mutually inclusive of the GPL. So I'd say there are not any issues like there were back in the day with the Rasterman/deIcaza GTK/GNOME vs. Trolltech QT/KDE battles. [Ahh brings back memories...] Cheers, Nicholas P.S. - Corinna already asked this question... ;-) __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: QT2 ready for ITP?
--- Corinna Vinschen [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 10:41:41AM -0400, Chris Faylor wrote: On Wed, Jul 31, 2002 at 11:14:50AM +0200, Ralf Habacker wrote: Any comments ? Are there any licensing issues with qt? Is the open source license compliant with cygwin's? http://cygwin.com/licensing.html Personally I have still problems with the phrase [...] we have released the Qt for Unix/X11 library free of charge I am only porting the Unix/X11 codebase, which is *not* the same as the Win32 codebase. So we are using the code specified in the first part of this sentence. for development of free software for X11. Since this is being ported as an X11 library target for use in Free Software development, I'd say we satisified the second part of this sentence. in the QPL. What bugs me is the word Unix. Cygwin is not Unix but it's... well, some sort of plug in to Windows, isn't it? I hate to say that. Again, I must point out that the core QT/Win32 API is a totally different codebase, at least in terms of hidden code (private). This is why I think that clause is in there, to prevent people from thinking their QT/Win32 API falls under these terms. Cheers, Nicholas P.S. - Many attempts [over 6+ months] have been made to contact Trolltech regarding this, yet no reply is forthcoming. Therefore, we have satisfied the legal obligations, since it was their responsibility to pose any objections, which they have not. __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: QT2 ready for ITP?
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 08:00:59AM -0700, Nicholas Wourms wrote: in the QPL. What bugs me is the word Unix. Cygwin is not Unix but it's... well, some sort of plug in to Windows, isn't it? I hate to say that. Again, I must point out that the core QT/Win32 API is a totally different codebase, at least in terms of hidden code (private). This is why I think that clause is in there, to prevent people from thinking their QT/Win32 API falls under these terms. Well, then, why all of the fuss in cygwin-patches where you were trying to modify windows headers? It doesn't seem like this is an entirely unix port: http://cygwin.com/ml/cygwin-patches/2002-q3/msg00175.html So, while this may have been discussed before, I'm not sure we had all of the details then. Well actually, it would be totally Win32 header free, if it weren't for the fact that Chris January added an original patch to better display current drives in konqueror. As for the dns stuff, that was already present in the Unix/X11 version, which is covered by the QPL/GPL. P.S. - Many attempts [over 6+ months] have been made to contact Trolltech regarding this, yet no reply is forthcoming. Therefore, we have satisfied the legal obligations, since it was their responsibility to pose any objections, which they have not. Well, AFAIK, YANAL and IANAL, so I don't know how you can make Can we please cut out the acronyms? We should be respectful of Ralf and others for whom English is a second[or third, etc.] language. definitive legal pronouncements and I certainly am not going to accept your say so on this. Fine, that is your perogative. I have no doubt that RedHat has a crackshot legal dept., so why not wing the QT/X11 QPL their way and see what they have to say? I'm sure they would be in the position to provide a definitive, authoritative answer to your question. I do understand your concerns, and believe me when I say that the last thing I would want is for RedHat to be sued [since my portfolio consists of a moderate amount of RedHat shares]. So, I will do my best to work with you to resolve this issue. Otherwise, I guess qt will never be a part of Cygwin. Cheers, __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: QT2 ready for ITP?
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 07:51:08AM -0700, Nicholas Wourms wrote: --- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 11:14:50AM +0200, Ralf Habacker wrote: Any comments ? Are there any licensing issues with qt? Is the open source license compliant with cygwin's? http://cygwin.com/licensing.html Ghostscript's license [The aladdin license (APFL?)] is much more restrictive than the QPL. If we are not in compliance with Ghostscript then that is a problem. It is entirely separate from whether qt is compatible with the GPL + Cygwin. If you were aware of issues with ghostcript you should have raised them. Ok, I was mistaken, it turns out they released the GNU version back in April [non-AFPL]. They usually lag behind about 6-8 months with the GNU version, so I was thinking that he used the APFL version. Anyhow, just a false alarm. Besides when you compile QT, you'll get a screen which shows how the QPL is mutually inclusive of the GPL. So, if I show you a screen which says it's exclusive of the GPL, you'll just give up? Since I don't accept the word of every person with a web site out there who thinks they are compliant with the GPL, I don't see why I should accept the words of a screen. Is there an independent corroboration of this anywhere? Check out the suggestion in my reply to your last post. You may or may not like it, but I think it would provide the definitive, independant counsel you need in this matter. Otherwise, I guess I will have to give up, since it is you, not I, who runs this project. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: QT2 ready for ITP?
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Corinna Vinschen wrote: On Wed, Jul 31, 2002 at 10:57:36AM -0700, Nicholas Wourms wrote: --- Christopher Faylor [EMAIL PROTECTED] wrote: Well, AFAIK, YANAL and IANAL, so I don't know how you can make Can we please cut out the acronyms? We should be respectful of Ralf and others for whom English is a second[or third, etc.] language. Why? I'm non-native, too, but actually I'm using acronyms as well. *And* I have this one: http://www.acronymfinder.com/ Corinna Now that you guys mentioned it... what the heck is ITP? Initial Trials Phase? Intent To Package? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Finally on Sylpheed
--- Staf Verhaegen [EMAIL PROTECTED] wrote: Everything De Icaza and Ximian does is open source except one peace of code that is used to connect to an expensive propriety email server. Without this connector thing evolution email client is fully usable and open source as is ximian gnome, red carpet, mono, ... They could have a million things that were opensource and one closed source product but it still wouldn't matter. I'm not against closed source software, all I ask is that you practice what you preach. To him, opensource is(was) a religion, and yet still he refuses to opensource every bit of his software. 'Nuff said. This is way off-topic anyhow. PS: Live would be so much easier when people would just try having fun with computing and not consider it as some kind of religion. Live would be so much easier when people would not try to tell to other people what they should like or should not like. Who's telling people what to like? AFAICT, Jim and I were having an exchange of opinions. What you do with those opinions is entirely up to you. I'm having fun, aren't you? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: problems with XFree
Jehan, As a rule of thumb, packages should *never* modify the /etc/profile script (even if you do back it up). This is a big no-no, as most *nix people would tell you. If you insist on getting into a discussion on why this is, then so be it. Instead, create 2 scripts (a csh and a sh) and drop them into the /etc/profile.d/ directory. This way we play it safe and every one is happy. Also, your scripts should check to see if the path has already been set, if it has, then don't set it again. Remeber, the more entries in the path, the slower Cygwin will operate. Cheers, Nicholas --- Jehan [EMAIL PROTECTED] wrote: 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. Here is an attempt to add the path into /etc/profile using a post-install script. I first try to see if /etc/profile already sets the X path for people who have customized it. So I grep for something of the form PATH=/usr/X11R6/bin If I find such a line then I do nothing. If the line isn't here, I create a new /etc/profile with the lines: if ! echo $PATH | /bin/grep -q /usr/X11R6/bin ; then PATH=$PATH:/usr/X11R6/bin fi at the top of the file, as suggested in the old thread. Just to be safe, the old profile is renamed /etc/profile.old. Jehan #!/bin/bash TMP_PROFILE=/etc/profile.new if ! /bin/grep -q PATH=.*/usr/X11R6/bin /etc/profile; then cat $TMP_PROFILE EOF if ! echo \$PATH | /bin/grep -q /usr/X11R6/bin ; then PATH=\$PATH:/usr/X11R6/bin fi EOF cat /etc/profile $TMP_PROFILE /bin/mv /etc/profile /etc/profile.old /bin/mv $TMP_PROFILE /etc/profile fi __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
[ITP]: Qt-2.3.1
Harold et al., After a brief discussion this morning, Ralf has given me permission to package QT-2.3.1 and release it to the Cygwin community. I would like to have it under the XFree86 dir, since it is a fully native X library. This release has been throughly tested by us over on the KDE-Cygwin project, pretty much all the bugs have been stomped out. Note that QT does *not* require MIT-SHM [that is kde itself]. Furthermore, I fully intend and expect questions regarding Qt be redirected to the kde-cygwin mailinglist. We should probably update the mailing-lists page's policies to reflect this. My intention is not to inundate this list with Qt/Kde related issues. With the your's and the list's permission, I will package it up and provide the links ASAP. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
RE: [ITP]: Qt-2.3.1
--- Harold Hunt [EMAIL PROTECTED] wrote:
Well, remember also that the X11 version is licensed under the GPL,
so it is
fine. They do make some other versions that are not yet licensed
under the
GPL. The native Windows version used to be non-GPL, but I think I
remember
seeing something in the news about this changing a few months ago
or
something.
Harold,
So is this a green light? I'll get started ASAP if it is. I was
thinking that the best bet would be to do like lesstif and put the
qt-2.3.1 tree under:
/usr/X11R6/qt-2.3.1/{bin, include, lib, doc}
What do you think?
Cheers,
Nicholas
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Re: Finally on Sylpheed
--- Jim George [EMAIL PROTECTED] wrote: I say finally but of course the fun is just beginning for me:) I now have sylpheed (the X Mail Client) running under cygwin-X and it's very good, there are some items that could be beefed up/improved upon (and I shall offer whatever help I'm able to) but on the whole very good. So that this isn't one of those mails that just takes up bandwidth... To create it you need glib-1.2.10 and gtk.1.2.10 or above, also libiconv (this is already part of the main setup for cygwin, although you need to specifically select it), and of course you need sylpheed (current release is 0.8.0). You can get glib and gtk at ftp://ftp.gtk.org/pub/gtk/1.2 You can get sylpheed at http://sylpheed.good-day.net You need to make one alteration in the glib package for it to compile. Comment out line 705 of gstrfuncs.c and it will compile flawlessly. Can the lis let me know if there is interest in a X Mail Client for cygwin, in which case I'll investigate becoming a maintainter for the list? Jim, Why don't you wait until Lapo releases the glib/gtk packages. That way you can link to them dynamically. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: [ITP]: Qt-2.3.1
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Ralf, Since KDE on Cygwin might eventually depend on this Qt package, why don't you guys decide together what the best location would be? I really have no idea where to put it, so I'm all for just putting it somewhere and cleaning up the mess later when we learn what we did wrong. The LSB doesn't specify a location for Qt, does it? I thought the decision was that all X stuff should go under X11R6/, but I could have misinterpreted the thread. If not there, based on the LSB, I'd be inclined to stick in /opt, but if Ralf really wants to put it under /usr/lib then I'll do that. Ralf? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Updated: ghostscript-7.05-1 (test release)
--- Harold L Hunt II [EMAIL PROTECTED] wrote: What is going on here Mr. Jack Larsen? We have had four posts of this meesage to [EMAIL PROTECTED] Were you intending to post this to cygwin-apps or somewhere else? Have you put this in release/ or release/XFree86? If it isn't in release/XFree86 then you need to talk to cygwin-apps to get it approved. cygwin-xfree is only in charge of release/XFree86. Harold, Actually this was discussed on Cygwin apps and the maintainers came to the conclusion that, when a package has both XFree and non-XFree components, you should: A)Discuss the non-XFree components on [EMAIL PROTECTED] B)Discuss the XFree components on [EMAIL PROTECTED] C)Only need to seek approval once from the [EMAIL PROTECTED] list. This was done to insure that the volume be kept to a minimum on an already heavily used list ([EMAIL PROTECTED]). So it is fair game to discuss the ghostscript-x11 package on this list. And I do believe Dario did make a test annoucment on here a few weeks back. Here is the hint, in case you forgot: @ ghostscript-x11 sdesc: A Postscript interpreter (GNU version, X11) ldesc: GNU Ghostscript is Postscript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This package contains the X11 build for Cygwin/XFree86. category: Graphics ^[You're right that it should have XFree86] requires: cygwin XFree86-base libpng12 zlib ghostscript-base external-source: ghostscript test: 7.05-1 This does not, however, excuse the quadrupal posting on the sender's part. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
RE: problems with XFree
--- Stuart Adamson [EMAIL PROTECTED] wrote: Granted, the XWin man page is out of date now and could do with an update ... Patches are, as usual, Gratefully Accepted. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Updated: ghostscript-7.05-1 (test release)
Harold, Thanks for the sarcasm, but it was hardly warranted. I was simply restating the facts for those who were not involved. Also, it seems that you missed one of the points of that discussion, which was that all things of XFree nature should be discussed on the XFree list, regardless of whether it was released as a dual mode application or as an X-only application. You seem to have confused the *directory* release/XFree86 with the *category* XFree86. Go back and read my original response and you will see that I was trying to figure out if this package is more of a Cygwin responsibility, rather than a Cygwin/XFree86 responsibility. I was adressing your concerns over which mailing list this should be on, who cares where it is actually located in the release directory. And, according to the mailing lists webpage: cygwin: a high volume ... There are two exceptions ... questions about the Cygwin/XFree86 project (or any X-related questions for cygwin) should go to the cygwin-xfree mailing list (see below)... cygwin-xfree: a list for discussion of all things related to XFree86 on Cygwin (Cygwin/XFree86). If you have questions about how to use, configure, install, build, or develop with Cygwin/XFree86, this is the list for you If I were new and read this page, I think it would be safe to assume that this list *is* the appropriate one for discussing this matter. Considiering hew wanted to offer an extension to the ghostscript-x11 package. Ghostscript is *not* in the XFree86 directory because it is a dual-mode application. Of course, you are still right in pointing out that the ghostscript-x11 package should be in the XFree86 category. However, I was asking where the files were stored, not which category they will be in. If the files are stored in release/, then they are of no concern to me. If the files are stored in release/XFree86/, then they are my responsibility. Ghostscript-x11 is in the same directory as the rest of the ghostscript distribution, which is under /release. Your requirement that all packages that are XFree-related go under /release/XFree86 doesn't make sense. Why should ghostscript be split up and have some parts in /release/ghostscript and others in /release/XFree86/ghostscript? This makes things more complicated then they have to be. Anyhow, your argument that package discussion on this list be limited to packages under /release/XFree86 is contrary to what Chris and others have stated on the other lists and the mailing-list webpage. They claim that any Cygwin/XFree-related discussion should be on this list. His post was regarding cygwin-ghostscript-x11 and cygwin-GSView (x11), which seems to be awefully Cygwin/Xfree-related to me. The next reply I need is from Jack Larsen. Well you're getting my 2 cents on this anyhow :-). Besides, I answered your query as to where ghostscript-x11 was located. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: replies to xfree
--- Dennis Foreman [EMAIL PROTECTED] wrote: Shouldn't replies to a list automatically go to the list? My replies seem to be going to the personal mail of posters. I believe there is a setting in many list servers that prevents the replies from going to the poster. regards, D. J. Foreman website: http://WWW.CS.Binghamton.EDU/~foreman Hi, I usually hit reply to all and forget about it. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Problem with XSendEvent and xterm.
--- Harold L Hunt II [EMAIL PROTECTED] wrote: [SNIP] Hold on a minute here. I am seeing three newsgroup cross-posts in the header for this message. Can someone else verify that this is indeed being cross-posted? Yup, he's cross-posting alright: Newsgroups: comp.windows.x.motif,comp.windows.x,comp.os.linux.x The question is, is he using Gmane or using a mixture? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Problem with XSendEvent and xterm.
--- Nicholas Wourms [EMAIL PROTECTED] wrote: --- Harold L Hunt II [EMAIL PROTECTED] wrote: [SNIP] Hold on a minute here. I am seeing three newsgroup cross-posts in the header for this message. Can someone else verify that this is indeed being cross-posted? Yup, he's cross-posting alright: Newsgroups: comp.windows.x.motif,comp.windows.x,comp.os.linux.x In fact, you can see for yourself at: http://groups.google.com/groups?hl=enlr=ie=UTF-8group=comp.windows.x http://groups.google.com/groups?hl=enlr=ie=UTF-8group=comp.windows.x.motif http://groups.google.com/groups?hl=enlr=ie=UTF-8group=comp.os.linux.x Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: New (Delphi) xlauncher
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Dennis Foreman wrote: At one point in history, (before WW II) the head of the US Patent Office said he wanted to close the office because everything that needed to be invented had already been invented and there was nothing left the world needed. He had obviously not yet heard about the need for penicillin or cardiac by-passes. Harold: What about platforms YOU never heard of or don't use? (I have one. And I may very well be interested in the Xlauncher for it.) Okay, I will start working on that cross-platform registry editor right away! Harold, Who's to say that ReactOS won't have a registry? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Expect Script under X-Windows
--- Thomas Chadwick [EMAIL PROTECTED] wrote: So you're writing a script that very likely will contain a password in cleartext? How secure is that? Keep it on a floppy-disk, and keep that in plastic case in your pocket. It works for me. Then it will be just as secure as your wallet. Now how secure that really is, depends on the individual. Still it is preferable to keeping it on the pc itself. As for Expect, it *WILL NOT* work. This is because Cygnus designed TCL/TK/ITCL/TIX/EXPECT to be mingw like, so that people can use Insight [GUI GDB] without having to fire up an X-windows session. Someday we will have the TCL suite working under both X and native Windows, but that will involve a lot of work. For now, lets just leave it at that. If you *really* want to script, then you should look into some python gui X utilities to do that for you. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: New (Delphi) xlauncher
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Robert Collins wrote: -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 Thank you for pointing out the weakness in that one. You are not welcome. Damnit, I don't care one way or another, because the idea of an Xlauncher is useless for me. However, I do agree that people should worry about it elsewhere. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Gnome
--- Joe W. Guy, Jr. [EMAIL PROTECTED] wrote: Can anyone tell me if/how to install GNOME on cygwin? I have XFree86 running on cygwin, but the only window manager that I have is TWM. Please advise. No GNOME for you, sorry. But you are welcome to install KDE! Check out: http://kde-cygwin.sourceforge.net Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
RE: New xlauncher (was: Re: Success with Java prog in XFree)
--- Tim Thomson [EMAIL PROTECTED] wrote: 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. Until someone provides the runtime libraries as part of the Cygwin dist, I'd have to say yes. Also, Harold seems dead set against these rather bloated cross-platform libraries. I don't know a way to get cross platform support easily without using a library of some kind, and wxWindows seems to be the best, it's been around for ten years, and has a _lot_ of functionality. If you are really serious about this, then follow the directions at: http://cygwin.com/setup.html To package the wxWindows runtime and development libraries for the cygwin platform. If you are *really* serious, once gtk for cygwin is released, you could provide the gtk/X11 version of wxWindows for cygwin as well. I understand your concern at depending on libraries, and I guess compiling a static binary won't satisfy your needs? Aviod the bloat, provide a wxWindows dll to the distribtion. The only other way I can see to do this is to do a complete rewrite of the program per OS, to utilise each systems native framework. There would be very little portable code between each version. Not necessarily. The current maintainer of rxvt has managed to create an awesome terminal client that works in both X and as a native win32 app. He did it by using Donald Becker's libW11, which translates calls to libX11 into win32api calls. Unfortunately, he is running short on time atm and hasn't got much time to improve on the libW11 port to cygwin. Since libW11 is already a part of cygwin, you have met Harold's requirements that it not be dependant on some super-duper-foo-library. Also, it avoids unnecessary memory hogging by an xserver running in rootless mode. If you are curious, check out the source package for rxvt, which contains the libW11 source. Also check out the rxvt README in /usr/doc/Cygwin for infomation on how he did his port and how you can contact him. Writing it as an X app once rootless mode works could be an option, as we would only have to write for an X framework, and not for Win32. This sounds like overkill to me though. I agree, no need for the bloat of an xserver running in rootless mode just to use a startup launcher. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
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? [n1, n2 = additional install types to be provided by external data sources, i.e. one could define Standard Install w/ Cygwin/XFree86 or SSH only Install] As to what goes into #2 is not for me to debate. I've had my fill of flame wars for awhile ;-). However, as more packages are added, I think that we (including me) should help setup become more extensible by defining the classes of installs and providing the chooser only when requested by checkbox #2. Why should this be something we want? A)It makes the whole process much easier for the enduser. B)It better mirrors other installers which the enduser is used to. C)It is much more accessible to people with disabilities. D)It creates a more featureful installer, while preserving the simplicity of the installer. E)It has been marketed and tested by the various linux vendors in the opensource community and so far hasn't met with much disfavor. F)(Hopefully) It will cut down on the number of messages we get from people asking where is package foo or complaing about setup installing too many or too few packages. G)Personally I like to have the robustness of a full setup of tools, while Harold may prefer the simplicity of a minimal X terminal setup. Then there are those who would rather use it simply for SSH. Choice is an important feature of the opensource community, one which we should embrace without creating confusion. I am simply stating an observation and a possible boilerplate for a solution. As to how doable this is and who will do it is another thing. I'll take a crack at it, but I doubt I'd get that far in the next couple of months. So rather than just keep the idea to myself, I decided to share it. Hopefully this might get some useful discussion and possibly spawn more ideas in the process. Cheers, Nicholas P.S. - Please respond in cygwin-apps, as I don't want to cause another off-topic thread to flood cygwin-xfree. ;-) --- Harold Hunt [EMAIL PROTECTED] wrote: Michael, No it is not amazing that the default Cygwin installation does not install XFree86. Just read the Cygwin mailing list archives and notice how often people bitch about how large the default installation is already. The default installation continues to get smaller, rather than larger, as a result of all of this bitching. Now we have reached the point where people bitch about there being too much just about as much as people bitch about there being too little. Thus, we have reached a nice stable point, and we intend to stay there. Harold -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Monday, July 15, 2002 1:38 AM To: Harold Hunt Subject: Re: LibICE.DLL is a BIG problem Amazingly, the default Cygwin install does not install XFree86. It is necessary to choose it. That's why there are so many problems with it being missing. You can see all the trouble people are having by puting LibICE.dll into Google. Michael ___ Harold Hunt wrote: Michael, Because I have never heard of any problems with libICE. You are going to have to provide details, even if those details are only links to the relevant bits of discussions that you have found via Google. Thanks, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Jennings Sent: Monday, July 15, 2002 12:14 AM To: [EMAIL PROTECTED] Subject: LibICE.DLL is a BIG problem There are lots of messages on Google that say people are having a problem with a missing DLL, LibICE.dll. No one has answered that message with a definitive answer. There are FTP and HTTP addresses given that don't lead to the file. I'm trying to install Nedit, and it is asking for this file. Why doesn't Cygwin provide everything necessary, or links, or explanations? Re-installing made no difference. Michael Jennings __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: New xlauncher (was: Re: Success with Java prog in XFree)
--- Rasjid Wilcox [EMAIL PROTECTED] wrote: On Mon, 15 Jul 2002 12:08 am, Ralf Habacker wrote: This is a great idea. I was thinking of using a language/toolkit that I could compile on my Linux box, as it it my main development machine. Delphi isn't too bad, as it (sort of) works under wine. The only problem was the compiled code didn't run under wine very well. It would be cool to be able to use it under linux/unix (hadn't thought of XNest though). What about qt ? It is available for windows and for unix/linux. Just been to the TrollTech website. The windows version of Qt is not fully GPL compatible. See http://www.trolltech.com/developer/download/qt-win-noncomm.html. Based on my interpretation of this discussion, I would say that that would rule out any xlauncher made with Qt for Windows from being distributed by setup.exe. The site also states that it requires MS Visual Studio v6, although my guess is that it could be used with gcc, but would probably take more work. OTOH, wxWindows (http://www.wxwindows.org) is fully GPL compatible. And for those of us that are not C or C++ experts, there is wxPython (http://www.wxpython.org) with an open-source IDE (http://boa-constructor.sourceforge.net/) which is suprisingly useable despite the version number (0.1) - although I'd suggest the CVS version. Rasjid. The last time I checked, building wxWindows import libs was a PITA because their configure script has literally 100+ flags. Why can't they just have --enable-max like apache where it builds everthing that is supported by your platform. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote:
I forgot to check if the batch file already existed or not. Attached is
the corrected script.
Jehan
#!/bin/sh
BATCH_FILE=/usr/X11R6/bin/startxwin.bat
if [ ! -f ${BATCH_FILE} ]; then
# First part of the batch file
cat EOF $BATCH_FILE
@echo off
SET DISPLAY=127.0.0.1:0.0
REM
REM The path in the CYGWIN_ROOT environment variable assignment assume
REM that Cygwin is installed in a directory called 'cygwin' in the root
REM directory of the current drive. You will only need to modify
REM CYGWIN_ROOT if you have installed Cygwin in another directory. For
REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will
need
REM to change \cygwin to \foo\bar\baz\cygwin.
REM
REM This batch file will almost always be run from the same drive (and
REM directory) as the drive that contains Cygwin/XFree86, therefore you
will
REM not need to add a drive letter to CYGWIN_ROOT. For example, you do
REM not need to change \cygwin to c:\cygwin if you are running this
REM batch file from the C drive.
REM
EOF
# Get the DOS path to cygwin
echo SET CYGWIN_ROOT=`cygpath -w /` $BATCH_FILE
# Second part of the batch file
cat EOF $BATCH_FILE
SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%
REM
REM Cleanup after last run.
REM
if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH
attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0
del %CYGWIN_ROOT%\tmp\.X11-unix\X0
:CLEANUP-FINISH
if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix
REM
REM Startup the X Server, the twm window manager, and an xterm.
REM
REM Notice that the window manager and the xterm will wait for
REM the server to finish starting before trying to connect; the
REM error Cannot Open Display: 127.0.0.1:0.0 is not due to the
REM clients attempting to connect before the server has started, rather
REM that error is due to a bug in some versions of cygwin1.dll. Upgrade
REM to the latest cygwin1.dll if you get the Cannot Open Display
error.
REM See the Cygwin/XFree86 FAQ for more information:
REM http://xfree86.cygwin.com/docs/faq/
REM
REM The error Fatal server error: could not open default font 'fixed'
is
REM caused by using a DOS mode mount for the mount that the
Cygwin/XFree86
REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more
REM information:
REM
http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof
REM
REM
REM Use the /B switch only when we can positively confirm that the OS
REM is Windows NT/2000. Do not use the switch in any other case. This
REM should work fine, as it assumes we cannot use /B, except when a
certain
REM criterion is met. A previous version of this batch file assumed
that
REM we could use /B, except when some criterion was met; needless to
say,
REM that didn't work.
REM
if %OS% == Windows_NT goto USE-B-SWITCH
REM Windows 95/98/Me
echo startxwin.bat - Starting on Windows 95/98/Me
REM Startup the X Server.
start XWin
REM Startup an xterm, using bash as the shell.
run xterm -sl 1000 -sb -ms red -fg gray -bg black -e /usr/bin/bash
REM Startup the twm window manager.
run twm
goto END
REM
REM Use the /B switch. This starts the specified process in the
background;
REM in other words, it does not cause a new Command Prompt window to be
REM opened for each 'start' command.
REM
:USE-B-SWITCH
REM Windows NT/2000
echo startxwin.bat - Starting on Windows NT/2000
REM Startup the X Server.
start XWin
REM Startup an xterm, using bash as the shell.
run xterm -sl 1 -sb -ms red -fg gray -bg black -e /usr/bin/bash
REM Startup the twm window manager.
run twm
:END
REM Set a background color to comply with FCC regulations :)
run xsetroot -solid aquamarine4
EOF
# Convert the file to dos format
# and update the permission
u2d $BATCH_FILE
chmod 755 $BATCH_FILE
fi
Jehan,
You still have the chicken-and-the egg issue. How is a user going to
startxwin from a console window if /usr/X11R6/bin is not in their path?
Obviously, if the user installs these packages, they want to be able to
access them. The answer to this is to make 2 scripts that get installed
in the /etc/profile.d directory by the XFree86-base package. One is for
the tcsh/csh users and the other is for the bash/ash/zsh users. In these
two scripts we establish the following:
1)Add /usr/X11R6/bin to the $PATH
2)Resolve the new environmental CYGWIN_X_ROOT by using the method you
specified above.
Then have the various startxwin scripts employ CYGWIN_X_ROOT, but strip
the PATH setting from them. This way you avoid multiple instances of the
XFree directories in your path. So what about the .bat file you say?
Easy, just have it
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: I forgot to attach the X.ico file. It's not the best in the world but I guess it will do (it's the same I sent you with the systray patch a while ago). It is to be installed in /usr/X11R6/bin (or you have to modify the script) Jehan ATTACHMENT part 2 image/x-icon name=X.ico Jehan, If you search the archives, others have already made icons ready for you use :). Meanwhile, I've been thinking about this and looking at the setup.exe code. If no-one minds, I'm going to generate and submit a patch that has setup.exe do all the shortcut stuff. Though your bat file is still useful. I wonder why not just can all the dos stuff by having the batch file call bash which then calls startxwin.sh? One file is *much* easier to maintain then two. Anywho, let me know your thoughts on this.. Cheers, Nicholas P.S. - Robert that goes for you too... __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Charles Wilson [EMAIL PROTECTED] wrote: Better hold off on that patch, Nicholas -- it's opposite of the direction Robert wants to go. Setup should be , itself, as generic as possible, and all actions driven by external data. (granted, I haven't been reading this thread, so I might've missed something...like discussion of the mkshortcut tool in cygutils...) Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: I forgot to attach the X.ico file. It's not the best in the world but I guess it will do (it's the same I sent you with the systray patch a while ago). It is to be installed in /usr/X11R6/bin (or you have to modify the script) Jehan ATTACHMENT part 2 image/x-icon name=X.ico Jehan, If you search the archives, others have already made icons ready for you use :). Meanwhile, I've been thinking about this and looking at the setup.exe code. If no-one minds, I'm going to generate and submit a patch that has setup.exe do all the shortcut stuff. Though your bat file is still useful. I wonder why not just can all the dos stuff by having the batch file call bash which then calls startxwin.sh? One file is *much* easier to maintain then two. Anywho, let me know your thoughts on this.. Cheers, Nicholas P.S. - Robert that goes for you too... 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? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. I wonder why not just can all the dos stuff by having the batch file call bash which then calls startxwin.sh? One file is *much* easier to maintain then two. Anywho, let me know your thoughts on this.. That would be nice I agree. But for what I see on this mailing list, lots of people have problems with startxwin.sh (.xinitrc and .Xautorithy stuff) while very few people complain about startxwin.bat. So until we can have startxwin.sh to work as is for most people, I think it's better to stick with the batch file for now. You are mistaking startx for startxwin.sh. startxwin.sh is basically the same thing as startxwin.bat, but without all the nasty path conversions and soforth. Look again, it has nothing to do with .xinitrc and .Xauthority. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Robert Collins [EMAIL PROTECTED] wrote: -Original Message- From: Nicholas Wourms [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 10:24 AM I mind. Setup should become -more- data driven not less. Excuse me? All I was suggesting is to reword the final setup screen to something like the following: -Create Icon on Desktop for Cygwin Command Prompt -Create Icon on Desktop for Cygwin/XFree86 -Add Icon to Start Menu for Cygwin Command Prompt -Add Icon to Start Menu for Cygwin/XFree86 Then have setup create the shortcuts in the same fasion it does already. Eventually, I'd like to have it gray-out the check boxes for Cygwin/XFree86 if it is not already installed. How is this not data driven? Isn't this what the setup program is for? The last time I checked, most Windows installers handled the shortcut creation. If you need to recompile setup.exe to change it's behaviour, it is not data driven. Most windows installers are driven by an data that drives the dialogs. The 'right' way to do it, is something like the menu's that dpkg uses, they are pure data, and can be interpreted and shown as gui interfaces, or as text menus, or set via the command line. So, here are some options: 1) Implement an interpreter for dpkg's configure menus in setup. 2) Create something new along similar lines. 3) Use a slang interface or something like that in the postinstall script (*). 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. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. I wonder why not just can all the dos stuff by having the batch file call bash which then calls startxwin.sh? One file is *much* easier to maintain then two. Anywho, let me know your thoughts on this.. That would be nice I agree. But for what I see on this mailing list, lots of people have problems with startxwin.sh (.xinitrc and .Xautorithy stuff) while very few people complain about startxwin.bat. So until we can have startxwin.sh to work as is for most people, I think it's better to stick with the batch file for now. You are mistaking startx for startxwin.sh. startxwin.sh is basically the same thing as startxwin.bat, but without all the nasty path conversions and soforth. Look again, it has nothing to do with .xinitrc and .Xauthority. One would think so but no. I have an old .Xauthority from a linux account. If I use this one and run X with startxwin.sh, I get a bunch of Xlib: connection to :0.0 refused by server Xlib: No protocol specified xsetroot: unable to open display ':0.0' for each application I try to run. If I use an empty .Xauthority, then everything works fine. Well, not everything actually but at least I have xterm starting. I don't know what differs between the shell and the batch version of startxwin, but there is definitely something. Jehan Well this is obviously a bug in X and needs to be fixed. I dunno, maybe I'm wrong, but it just seems a bit silly to have two identical scripts for two different situations. I'm of the camp that loves reusable code... Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [packages] gtk+, glib, imlib
--- Lapo Luchini [EMAIL PROTECTED] wrote: Being interested in porting freeciv with gtk+ support... and gtk+ package being not available... I'm investigating it =) Harold states he has not enough time for it ( http://sources.redhat.com/ml/cygwin-xfree/2002-06/msg00302.html ). But has he a partial work or nothing? He has something. Frankly, I think we should let harold release these packages. He's got a firm understanding of the underlying mechanics of how X works. Plus if you commit to maintainership of 1.X, then it is assumed that you will be working on porting 2.X. Are you ready for this responsibility? Steven has a fairly complete Gnome port on his page ( http://homepage.ntlworld.com/steven.obrien2/ ), which has nothing to do with Harold's work. It contains patches for many Gnome programs, including glib-1.2.10, gtk+-1.2.10 and imlib-1.9.14. I was thinking about packaging them as requirements for the freeciv port... has anyone done some work / has more infos / has something to say about? As for freeciv, I will send you a static lib of Xaw3d to see if that will help you better. I would then release free-civ as is. We can worry about why the DLL version of Xaw3d isn't working later. Again, is there any rush to getting it out? Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: [packages] gtk+, glib, imlib
--- Harold L Hunt [EMAIL PROTECTED] wrote: Nicholas, He has something. Frankly, I think we should let harold release these packages. He's got a firm understanding of the underlying mechanics of how X works. Plus if you commit to maintainership of 1.X, then it is assumed that you will be working on porting 2.X. Are you ready for this responsibility? It is not going to happen. I simply do not have time to work on packages other than Cygwin/XFree86 proper. Sure, I have released a few extra packages, but that was just to get the ball rolling on XFree86 category packages. For future reference: I do not intend to assume maintainership of any new packages. However, I reserve the right to post an initial version of packages that compile out of the box, just to get things started. I hope that clears things up, Harold, I'm sorry, I never meant to unload additional work onto you. In previous messages regarding berkley db, you mentioned that you were going to stick to X packages, so I assumed you meant the packages you were already working on for X. Apparently this is not the case, which is OK. I'm glad you cleared things up for everyone. Cheers, __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Using the new cross compilation system - and a request for help
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O ^^ Why is this naming convention being used? That is a relic of B20, we shouldn't use that anymore. Damn those bloody SuSE people for ruining our cross compile system! Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: [Pending Review]: XFree86-Xaw3d-1.5
--- Harold L Hunt [EMAIL PROTECTED] wrote: Nicholas, I'll post this later tonight. Prepare a release announcement to send to both the regular list and cygwin-xfree-announce. I'll let you know when it is posted so you can send the announcements in. Use messages in the archive for cygwin-xfree-announce or cygwin-announce as a template for your announcement. Harold, Fogive me for asking, but when you say regular list, do you mean [EMAIL PROTECTED] or [EMAIL PROTECTED] I'm only asking because when I post a message to [EMAIL PROTECTED], it automatically reposts my message to [EMAIL PROTECTED] Is this not the same for [EMAIL PROTECTED]? Also, wouldn't it make sense just to leverage the existing [EMAIL PROTECTED]? I don't quite understand the necessity for a separate mailing list there. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
[ANNOUNCEMENT] [New Package]: XFree86-Xaw3d-1.5-1
Xaw3d is the 3D version of the MIT Athena widget set for X11. RELEASE NOTES: I have used patches to the SuSE Linux version of this library to fix security and UI bugs. Also, some patches have been added by me to address Cygwin building and to bring this library into the 21st Century. Therefore, most of the bugs in the Official README no longer apply. Given this is the first release, unknown bugs may still exist, so YMMV. Otherwise, enjoy! DESCRIPTION: This is Release 1.5 (14 May, 1998) of a set of 3-D widgets based on the R6.1/R6.3/R6.4 Athena Widget set. The Three-D Athena may be used as a general replacement for the Athena (Xaw) Widget set. In general, you may relink almost any Athena Widget based application with the Three-D Athena Widget set and obtain a three dimensional appearance on some of the widgets. Top and bottom shadow colors, shadow width, top and bottom shadow contrast should be self explanatory, and may be set via the usual and customary methods, e.g. app-defaults, .Xdefaults, programmatically, with editres, etc. The user data resource may be used to hang application specific data on a widget, and is only settable programmatically. You should install Xaw3d if you are using applications which incorporate the MIT Athena widget set and you'd like to incorporate a 3D look into those applications. Xaw3d includes the header files and shared libraries for developing programs that take full advantage of Xaw3d's features. You should install Xaw3d if you are going to develop applications using the Xaw3d widget set. INSTALLATION: To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'XFree86-Xaw3d' from the 'XFree86' category. Cheers, Nicholas *NOTE* that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection, and already up to date. In Japan, use ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ . In Denmark, http://mirrors.sunsite.dk/cygwin/ is already up-to-date. If one of the above doesn't have the latest version of this package you can either wait for the site to be updated or find another mirror. Please send questions or comments to the Cygwin/XFree86 mailing list at: [EMAIL PROTECTED] If you want to subscribe go to: http://cygwin.com/lists.html. I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the XWin server or Cygwin/XFree86 in general. If you want to make a point or ask a question the Cygwin/XFree mailing list is the appropriate place. *** CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO *** To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED]
Re: [ITP] FreeCiv-1.12.0-1 for X (using libXaw)
--- Lapo Luchini [EMAIL PROTECTED] wrote: The following message is copied from message wrongly sent to [EMAIL PROTECTED] Now Nicholas Wourms has ported libXaw3D so maybe I should do a 1.12.0-2 to use it... or maybe two separate binary packages are better? One for libXaw (that is default) and one for libXaw3D? I think one binary package can be sufficient. There is the fact that libXaw3d is less then 1/2 of MB. Just use it, as it looks much nicer then plain old libXaw. Besides, libXaw3d is shared whereas libXaw is not. Maybe I'll do a different binary package using GTK+, as soon as it's ported, as ilbXaw version looks much worse. My first try, it uses libXaw, which is not as good-looking as GTK (but is GTK available as a cygwin package?). I've seen the client crash one time, dunno if it's normal or usual, I'll do more tests. Please notice that when the client hangs the server is still up so the play can continue opening a new client and reconnectiong. This package needs zlib as it includes support for compressed savegames and/or scenarios. This package needs libintl2 as it already includes support for many languages. http://www.lapo.it/tmp/freeciv-1.12.0-1.tar.bz2 2.32Mb http://www.lapo.it/tmp/freeciv-1.12.0-1-src.tar.bz2 3.93Mb @ freeciv sdesc: Freeciv is a multiplayer strategy game ldesc: Freeciv is a free turn-based multiplayer strategy game, in which each player becomes the leader of a civilization, fighting to obtain the ultimate goal: To become the greatest civilization. Players of Civilization II® by Microprose® should feel at home, since one aim of Freeciv is to have compatible rules. Freeciv is maintained by an international team of coders and enthusiasts, and is easily one of the most fun and addictive network games out there! category: Games XFree86 requires: cygwin XFree86-base libintl2 libiconv2 zlib --You'll want to make this XFree86-xserv curr: 1.12.0-1 Looks good, but why not relink against my library? It really does look nicer. :-) Otherwise, you have my vote. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Shared and unshared libraries via the imake system
For any xwin developer: This is not explained in the FAQ or the Contributors guide. Can some explain to me, if it is even possible, exactly how one generates both a shared [.dll and .dll.a] and unshared [.a] library via the imake system? How are the foo-def.cpp files generated? If possible, this should be added to the contributor's guide. I do know how to generate the dll by hand, but I would prefer to know if this can be done automagically by the Imakefile system. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
[Pending Review]: XFree86-Xaw3d-1.5
Greetings All, I have compiled and packaged the 3D Athena Widgets for Cygwin/XFree86 as promised in my previous message. It should be completely functional and ready for use. If they are satisfactory, please upload them to the mirrors. Attached is the README file from the package. I used method #2 for packaging, and the script is included in the source package. Here are the links to the files: http://today.clemson.edu/cygwin/release/XFree86/XFree86-Xaw3d/setup.hint http://today.clemson.edu/cygwin/release/XFree86/XFree86-Xaw3d/XFree86-Xaw3d-1.5-1.tar.bz2 http://today.clemson.edu/cygwin/release/XFree86/XFree86-Xaw3d/XFree86-Xaw3d-1.5-1-src.tar.bz2 Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com XFree86-Xaw3d.README Description: XFree86-Xaw3d.README
Re: Cross Compiling
--- Harold Hunt [EMAIL PROTECTED] wrote: Yup, cross compiling is toroughly broken right now. It will take awhile to get it working properly. I'd appreciate it if anyone that is cross compiling the current XFree86 cvs would send in their host.def, any modification they made to cygwin.cf, etc. and their build command. Harold I did a little research and indeed it is those damn SuSE people who broke the cross compiling system! Take a look at: http://www.xfree86.org/~keithp/xconf2001/cc-imake.pdf and see if that doesn't seem like it fits the current case. Note their desire to modify the imake source file instead of cross.def. This might explain why the build fails when it tries to compile imake. P.S. - Did that CVS command to remove stickiness work for you? __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Using only the X server of Cygwin
--- Charles Wilson [EMAIL PROTECTED] wrote: Hey, Nicholas -- don't squish Rhialto that quickly. He's probably one of our new users who knows nothing about the cygwin project except what he read on slashdot this morning. Sorry, I am still cranky about the refusal to include objc in cygwin/gcc-3.1. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Sat, Jul 06, 2002 at 02:24:13PM +1000, Greg Lane wrote: On Fri, Jul 05, 2002 at 11:57:55PM -0400, Christopher Faylor [EMAIL PROTECTED] wrote: On Sat, Jul 06, 2002 at 01:17:13PM +1000, Greg Lane wrote: Then I have tried pointing my font path to it (with xset fp= ...) from a number of sources 1) remote machine running freebsd 2) from cygwin x-server on the same machine 3) from XWinPro on the machine Can you send what, exactly, you are typing? xset fp=...? cgf xset fp= ... where ... depended on where I was on the network at the time: 1) xset fp= tcp/192.168.96.2:7100 xset fp= tcp/hostname.xxx.xxx:7100 2) xset fp= tcp/localhost:7100 xset fp= tcp/127.0.0.1:7100 xset fp= tcp/:7100 3) same as 2) Thanks. I'd never used the 'xset fp=' command before. Unfortunately, now that I've tried running things, the best I can do is confirm that it core dumps for me, too. It probably wouldn't be terrifically hard to track down with a debugging version of xfs, running under gdb but that would require building xfs, which I'm not set up to do. Maybe someone who has the sources on their machine could give this a try... Chris + Greg, Check your e-mail, I just e-mailed both you and greg an xfs.exe with debugging symbols. As for what version I'm running, it is the vanilla version that comes via setup.exe, a.k.a XFree86-4.2.0 on Cygwin 1.3.13-cygdaemon(special development branch). Also, you might want to check your /var/log/fs-errors, incase xfs output anything interesting there. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Greg Lane [EMAIL PROTECTED] wrote: I have cc'ed this to Nicholas since I'd like to know what version of X he was running... On Sat, Jul 06, 2002 at 12:45:58AM -0400, Christopher Faylor [EMAIL PROTECTED] wrote: Thanks. I'd never used the 'xset fp=' command before. Unfortunately, now that I've tried running things, the best I can do is confirm that it core dumps for me, too. It probably wouldn't be terrifically hard to track down with a debugging version of xfs, running under gdb but that would require building xfs, which I'm not set up to do. Maybe someone who has the sources on their machine could give this a try... cgf I had hoped it wouldn't come to that!! Can I just ask what Windows system you tried it on and what version of cygwin X you have? Earlier Nicholas said he had it running on Windows Me, but did not say what version of X he was running. I will try and build a debugging version of xfs myself but that will have to wait until the end of the week as i have to go to a conference tomorrow. Hopefully some kind soul will have already done this by then, else I'll have to learn how to build X in cygwin! Is there a simple way to backdate X with binary packages to see if this is an introduced problem? Ok, It's stack dumping on me too, now. I had forgot that my startx script was unsetting the fontpath and setting its own (I was getting TrueType fonts going earlier last month). Now, when it looks for tcp/localhost:7100, it just crashes. I'm running it as xfs -daemon, and it appears to be running in the background fine. But as soon as I startx, boom! Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Greg Lane [EMAIL PROTECTED] wrote: On Sat, Jul 06, 2002 at 05:01:52AM -0700, Nicholas Wourms [EMAIL PROTECTED] wrote: Chris + Greg, Check your e-mail, I just e-mailed both you and greg an xfs.exe with debugging symbols. As for what version I'm running, it is the vanilla version that comes via setup.exe, a.k.a XFree86-4.2.0 on Cygwin 1.3.13-cygdaemon(special development branch). Also, you might want to check your /var/log/fs-errors, incase xfs output anything interesting there. Cheers, Nicholas G'day Nicholas, One of the first things I did was check /var/log/fs-errors only to find nothing there, however I don't know about you, but the executable you sent works just fine for me! (So the debugging symbols are for nought, but making the executable was not in vain!!) Excellent, I discovered the same thing. My previous report was for the original executable! As for logging, that is quite irritating, someone ought to look into that... I tried it on my laptop with XP, and on Win98 running under VMWare on FreeBSD. Worked fine on both. Super! So I don't know what that portends. Can you give me a quick primer on building just xfs from source? Then I can build my own and see if that works. Possibly there might be a difference in the compilation process when you are running 1.3.13-cygdaemon compared to my standard 1.3.12. I know nothing about the build environment for the binary packages, but it might be interesting to see how it compiled on my machine rather than on yours to maybe narrow down the problem. I had a quick look and it looks to me like the only option via setup.exe if I want to make xfs is to download the full source for X. Is the source a special tree for cygwin or could I copy over the source I already have from the ports tree on my FreeBSD box? Is it then as simple as going to an xfs sub-directory and typing make? Well, unfortunately I tried building just xfs directory of the XFree source tree, but that doesn't work. You'll have to follow the detailed instructions harold provides in the cygwin contributors guide: http://xfree86.cygwin.com/docs/cg/cygwin-xfree-cg.html You can follow the debugging directions if you want a debug build. You might want to set your cvs sticky tag to the xf-4_2-branch for the checkout if you run into problems with HEAD. If you do go this route, be sure to unset the sticky tag in the /xc/programs/Xserver/hw/xwin directory. This way you'll get the latest Cygwin/XFree updates while keeping the rest of the distribution stable. At least I know now that xfs can be made to work!! That means I will be able to implement some of the things our local users need. Just need to work out exactly why it sometimes fails. Please feel free to contribute! Patches are welcome! Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Nicholas Wourms [EMAIL PROTECTED] wrote: [SNIP] I had a quick look and it looks to me like the only option via setup.exe if I want to make xfs is to download the full source for X. Is the source a special tree for cygwin or could I copy over the source I already have from the ports tree on my FreeBSD box? Is it then as simple as going to an xfs sub-directory and typing make? Well, unfortunately I tried building just xfs directory of the XFree source tree, but that doesn't work. You'll have to follow the detailed instructions harold provides in the cygwin contributors guide: http://xfree86.cygwin.com/docs/cg/cygwin-xfree-cg.html You can follow the debugging directions if you want a debug build. You might want to set your cvs sticky tag to the xf-4_2-branch for the checkout if you run into problems with HEAD. If you do go this route, be sure to unset the sticky tag in the /xc/programs/Xserver/hw/xwin directory. This way you'll get the latest Cygwin/XFree updates while keeping the rest of the distribution stable. The more I think about, the more it doesn't add up. I am, by far, not doing a standard build. Infact, I'm not building on cygwin at all... Here are some interesting facts about my build worth noting: 1)It was done via a cross-compiler on a linux box 2)I was using gcc built from the mingw_cygwin_gcc_3.1 branch of the gcc cvs tree as of 06/22 3)I was using the latest binutils built from the binutils cvs sources as of 06/22 I wonder if this has anything to do with it??? Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: CVS Sticky Tags
--- Harold Hunt [EMAIL PROTECTED] wrote: Nicholas, You might want to set your cvs sticky tag to the xf-4_2-branch for the checkout if you run into problems with HEAD. If you do go this route, be sure to unset the sticky tag in the /xc/programs/Xserver/hw/xwin directory. This way you'll get the latest Cygwin/XFree updates while keeping the rest of the distribution stable. Okay, lets say I check out the xf-4_2-branch. What command to I run, and in what directory, to unset the sticky tag for teh hw/xwin directory? Harold, 1)cd xc/programs/Xserver/hw/xwin 2)cvs -z4 update -dPA The -A resets(unsets) the sticky tag and merges all changes from HEAD as well as downloading any new files or directories (-dP). Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Sat, Jul 06, 2002 at 05:01:52AM -0700, Nicholas Wourms wrote: Check your e-mail, I just e-mailed both you and greg an xfs.exe with debugging symbols. As for what version I'm running, it is the vanilla version that comes via setup.exe, a.k.a XFree86-4.2.0 on Cygwin 1.3.13-cygdaemon(special development branch). Also, you might want to check your /var/log/fs-errors, incase xfs output anything interesting there. I am not sure how I gave you the impression that *I* wanted to track this down. I was suggesting that someone with sources on their machine would be the correct person to do so. I am not an XFree86 expert by any means. I was just trying to help with obvious stuff before someone more experienced took over. Well, I don't have a WinXP machine, so I wouldn't be the best person either. I assumed, based on the content of your previous letter that you were interested in helping figure out this problem. Since you have a WinXP machine with gdb, I assumed you want to have a look into it. At the very least, you could report what you get from the backtrace, should you not desire to delve into the code. So I was trying to be helpful by fufilling what I thought you were requesting. Obviously I was mistaken. Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
RE: Use Tcp.h?
Harold, We had this discussion in the past, and yes I *have* read the cygwin-xfree contributor's guide and followed your directions WORD-FOR-WORD, except for removing the NO_TCP_H and defining font building. I checked out the Xfree tree with the 4.2.0 sticky tag. I then updated the xwin drivers directory by unsetting the sticky tag. Also, I did mention cross-compiling, just not as direct as you may have wanted. Also, I will confess that I am using the cygwin-mingw-gcc-3_1-branch branch of the gcc cvs sources for my compiler plus the latest binutils. I encourage you to do the same, as we a revving up to have gcc-3.1 replace the current gcc any day now. FWIW, I am sorry for not mentioning these factors previously... This is a clean build from a lndir'ed dir. I do *know* how to build outside of the tree! Give me a little credit, plus I was comparing the amount of warnings before and after I toggled NO_TCP_H. Building X on cygwin is just way too slow for me. Anyhow, if you recall, you posted a log of your cross-compile awhile back. It turns out that in the log, the crosscompiler was never found, so all I got was a log full of i686-pc-cygwin-gcc not found messages (not very useful). My point is that you should revisit your directions, as they do not cover how to get X to build fonts when cross-compiling. As it stands, X is trying to use the foreign bdfto* and mkfondir utilities. Also, the XFree people have broken crosscompiling according to your method in HEAD as opposed to the 4.2.0 branch. You might want to investigate this as well. --- Harold Hunt [EMAIL PROTECTED] wrote: Nicholas, Judging from you log file, I don't think you did a clean rebuild. I don't see the same warnings that you do for Xserver/os/connection.c. I see in Xserver/include/os.h a prototype for CloseDownFileDescriptor that is only processed when LBX *is* defined, while in Xserver/os/connection.c there is a prototype for CloseDownFileDescriptor that is only processed when LBX is *not* defined. The warning you are getting can only happen if LBX is both defined and undefined... so my suspicion is that your build tree is tainted. (Don't tell me that you're building in the source tree either... I don't want to hear any of it... see the Contributor's Guide for simple instructions on how to build out of the source tree with lndir.) What is this `i686-pc-cygwin-gcc' business about? Are you cross compiling? Shame on you for not disclosing this information if you are... it is really vital to knowing how to fix a problem. For now, whether you are cross compiling or not, ensure me that you have done a completely clean build from a freshly lndir'd tree. Harold __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: xfs (font server) crashes under cygwin. Anyone got it to work?
--- Greg Lane [EMAIL PROTECTED] wrote: On Thu, Jul 04, 2002 at 11:12:58PM -0400, Christopher Faylor [EMAIL PROTECTED] wrote: On Fri, Jul 05, 2002 at 12:54:38PM +1000, Greg Lane wrote: The rules say to post here, although would there be any point asking on the main cygwin list to get a broader coverage and try and find someone who has it running? Not unless you want to be redirected back here by a number of people. Fair enough!! Well then, has anyone on this list had xfs running properly under cygwin? I just tried it yesterday on WindowsME, it works for me. You probably will want to check to see if XP is running any services on the same port. Also, it may have something to do with your security, but don't ask me about the whole NT security deal, as I have no experience dealing with it. It seems like a big headache to me, more hassle then good... Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
RE: Use Tcp.h?
--- Harold Hunt [EMAIL PROTECTED] wrote: Nicholas, We had this discussion in the past, and yes I *have* read the cygwin-xfree contributor's guide and followed your directions WORD-FOR-WORD, except for removing the NO_TCP_H and defining font building. You could not possibly have followed the Contributor's Guide (CG) instructions word-for-word because your build log doesn't have a header (see below), it just jumps right into the clean step. In the CG the build step says: make World BOOTSTRAPCFLAGS=-D__CYGWIN__ -Ulinux -DCrossCompiling=1 IMAKE_DEFINES=-D__CYGWIN__ -Ulinux World.log 21 That causes the header information to show up in the build log... are you running something other than 'make World'? No, I am following the directions. Ok, my mistake again, I had been capturing the output from my terminal aplication, not piping it. Apparently the terminal application screwed up and chopped off the top. Anyhow, I think we are missing the whole point of this thread, what were *YOUR* findings. You didn't make it clear whether making the modifications to that one source file and removing DNO_TCP_H worked... I think we got caught up in my deviance from the contributor's guide. Again, I'm sorry for not sticking to it exactly. So what were your findings from your build? What is your conclusion? On a side note, I find it hard enough to remember all the builds/flags/compilers/etc that I'm using. I don't have any space in my brain to store state information for other developers. You have to feed me some details everytime you ask a question, else you can assume that I've forgotten those details. OK, next time I'll be better. Anyhow, if you recall, you posted a log of your cross-compile awhile back. It turns out that in the log, the crosscompiler was never found, so all I got was a log full of i686-pc-cygwin-gcc not found messages (not very useful). I remember that I posted a broken build log because I forgot to set my path before running the build. I thought about posting a new log but I didn't because no one seemed to complain much. Don't worry about it now... My point is that you should revisit your directions, as they do not cover how to get X to build fonts when cross-compiling. As it stands, X is trying to use the foreign bdfto* and mkfondir utilities. Also, the XFree people have broken crosscompiling according to your method in HEAD as opposed to the 4.2.0 branch. You might want to investigate this as well. Oh, I know that the XFree86 folks are doing some stupid things with respect to expecting certain XFree86 utilities to already be installed at build time. I bitched about this to the devel list at XFree86 and you know what? I didn't get a single reply. Not even a ``go away, you are annoying''. Apparently no one else on the project things that you should be able to bootstrap on a machine that has never had XFree86 installed. Hopefully they fix this before the next release. I see that my font building complaint is currently being addressed, thanks very much. :-) However, are you aware that the CVS HEAD isn't even building period with regards to your cross directions? It fails in the initial stages, because it seems that some of the macros you have defined in your host.def are no longer valid. If you do not believe me, try it yourself. It seems that they have mucked around with the cross building configuration files and rules files. We better get on them about that, too. I believe that some stupid SuSE developer is responsible for the whole mess... Cheers, Nicholas P.S. - When you get a chance, you should read those other posts I made, especially regarding the conflicting files in lesstif and XFree86-prog... __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: FW: xc/lib/fontconfig/fonts.conf depends on existing fonts installation
Harold, On ~ line 66158 of my build log, you'll notice this: LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t tech14.bdf | gzip tech14.pcf.gz /bin/sh: ../../../exports/bin/bdftopcf: No such file or directory LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t techB14.bdf | gzip techB14.pcf.gz /bin/sh: ../../../exports/bin/bdftopcf: No such file or directory LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t term14.bdf | gzip term14.pcf.gz /bin/sh: ../../../exports/bin/bdftopcf: No such file or directory LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t termB14.bdf | gzip termB14.pcf.gz /bin/sh: ../../../exports/bin/bdftopcf: No such file or directory LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/mkfontdir -x bdf . /bin/sh: ../../../exports/bin/mkfontdir: No such file or directory make[5]: *** [fonts.dir] Error 127 make[5]: Target `all' not remade because of errors. Let's assume I have followed the directions exactly (because this is what has happened in the past when I followed them exactly). When cross-compiling, why is make World trying to use the foreign utilities to build the fonts? Shouldn't it be using the utilities under /usr/X11R6/bin? I don't know if this relates to your comments below, but it is very annoying. --- Harold Hunt [EMAIL PROTECTED] wrote: Alan, Hmm... as usual I misspoke... I was bitching about the ``findfonts'' script which runs on the installed fonts rather than on fonts being built. I'll have to look into the font build utility problem. I hate it when I get confused. Anyway, here is what I wrote to the XFree86 devel list. Harold -Original Message- From: Harold Hunt Sent: Saturday, April 13, 2002 7:44 PM To: xf-devel Subject: xc/lib/fontconfig/fonts.conf depends on existing fonts installation I don't understand why xc/lib/fontconfig/fonts.conf runs the script xc/lib/fontconfig/findfonts which looks at the *currently installed fonts*. That doesn't make any sense to me. Shouldn't you be able to build XFree86 on a machine that doesn't have any fonts installed, or for that matter, any piece of XFree86 installed? The problem that I'm running into on Cygwin is that even if /usr/X11R6/lib/X11/fonts exits but /usr/share/fonts doesn't exist then the findfonts script fails because 'find' cannot find that directory. I'm not certain that this is a Cygwin only problem, but it is the only platform that I am building on. I propose that one of two things be done: 1) Do not execute the scripts that do things for *installed* fonts, as this makes no sense. 2) Or, change the findfonts script to silently fail if either of the fonts directories cannot be found, thus removing a non-error error from build logs. Please CC me, as I am not currently subscribed to the devel list. A snippet of my build log follows. Harold Hunt make[1]: Leaving directory `/home/Administrator/x-devel/build/std/lib/fontconfig /fc-list' rm -f fonts.conf sh ./setfontdirs find: /usr/share/fonts: No such file or directory ed: not found make: *** [fonts.conf] Error 127 __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
RE: Use Tcp.h?
--- Harold L Hunt [EMAIL PROTECTED] wrote: Nicholas, Anyhow, I think we are missing the whole point of this thread, what were *YOUR* findings. I forgot to draw attention to what I found, but I did post your build snippet with warnings and my build snippet that didn't have warnings for the same file. My overall results were that I got no new errors or warnings. I did a 'make install' and ran the server with local clients as well as with a -query to a KDE machine with no problems. Again, I'm sorry for not sticking to it exactly. So what were your findings from your build? What is your conclusion? The conclusion is that we might as well remove -DNO_TCP_H and the #if !defined(__CYGWIN__) from whatever file I said it was in. (Note that -DNO_TCP_H was present in the initial version of cygwin.cf... so it is just a define that has not been noticed as uneeded until now.) Well there is no point in keeping stale defines around, is there? Obviously you were curious, otherwise you wouldn't have invested so much time. :-) On a side note, I find it hard enough to remember all the builds/flags/compilers/etc that I'm using. I don't have any space in my brain to store state information for other developers. You have to feed me some details everytime you ask a question, else you can assume that I've forgotten those details. OK, next time I'll be better. Appreciated. However, are you aware that the CVS HEAD isn't even building period with regards to your cross directions? It fails in the initial stages, because it seems that some of the macros you have defined in your host.def are no longer valid. If you do not believe me, try it yourself. It seems that they have mucked around with the cross building configuration files and rules files. We better get on them about that, too. I believe that some stupid SuSE developer is responsible for the whole mess... Oh, I believe you. But like I said in another post (which hadn't been written when you wrote this), I'll have to do a substantial amount of work to my Linux machine to be able to do a cross compile of Cygwin/XFree86. P.S. - When you get a chance, you should read those other posts I made, especially regarding the conflicting files in lesstif and XFree86-prog... I have, you cleared things up for me. No big deal right now, but *if* you have some spare time this weekend maybe you could give that hdd install a try... Not that I know all the facts, but surely a hdd install takes less then 10 hours? I read them, but you're going to have to do more than just suggest what to do with the host.def files. I hope you realize that your simple, ``should we remove -DNO_TCP_H'', question has cost me about 5 hours already in looking at source files, doing build tests and writing detailed correspondence to the mailing list. I take it that you feel this wasn't worth it? I'm sorry then, I was just trying to be helpful. Now you are asking about Lesstif's host.def and our host.def and all I can see is that our host.def is empty so I can't see what problems it will cause for us not to do anything with the host.def files. Furthermore, I don't see how you could even fix this with pre-remove and postinstall scripts. I mean, how are you going to determine which host.def file is installed, how are you going to determine if you need to remove the currently installed host.def file (maybe package Z's host.def file was already overwritten by another package installation), and how are you going to determine which host.def to install in place of the one that are you are removing? Not to mention what sort of naming/storage convention are you going to use to identify the original host.def files that come with each package? So yeah, I read your post and I saw that it raised more questions than it answered, so I forgot about it. I'm leaving this one up to you, or somebody else, to figure out. You have to remember, as I've said time and time again, I'm a horrible X user and I'm even a horrible X developer. You see, I don't have years of experience with hundreds of X programs and with hundreds of X libraries. I only have experience with X Server implementation and in that I only have experience with X Server development for Cygwin. I just don't have enough experience to solve questions about host.def files easily. I've never heard you say these remarks regarding your X skills, I just assumed... Well, the point is this. Move your host.def file to some temporary location. Then get a project that uses Imakefiles and run xmkmf in it's source directory. You'll see that xmkmf requires a host.def, empty or not, to proceed with making the makefile. I simply proposed a possible solution, I didn't expect you to deal with it instantly. It is just something that you should be aware of as a potential gotcha. I'm still thinking about how best
Re: Server Test Series - Test62 available
Nope, It is shipped with I.E. 2.0. Only in win95oemsr2 a.k.a. Win95b did I.E. 3.0 start shipping. Cheers, Nicholas --- Sylvain Petreolle [EMAIL PROTECTED] wrote: If you have *Windows 95*, you must have Internet Explorer 3.0 or greater installed to use Cygwin/XFree86, as this installs a new version of comctl32.dll that contains _TrackMouseEvent Isn't Windows 95a shipped with Internet Explorer 3.0 ? ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
host.def in lesstif conflicts with host.def in XFree86-prog
Harold, As you well may know, the /usr/X11R6/lib/X11/config/host.def is needed for running the xmkmf command. The issue is that this file is being installed by both the lesstif and XFree86-prog packages. The problem is, when you uninstall lesstif, the XFree86-prog version host.def is not restored. Worse yet, the lesstif host.def is completely removed. This is not good, but the issue will become worse in the future now that setup.exe is getting closer to implimenting dependancy/conflict functions. I suggest making postinstall and preremove (/etc/preremove/*.sh) scripts for both packages to handle this potential issue. Just a thought... Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: [ANNOUNCEMENT] xwinclip Test 06
2) xwinclip.c - Add a UnicodeSupport function to check if we have Unicode support or not. Currently this is done by just checking if we are on an NT-based platform or not. (Harold Hunt) Harold, I found this on MSDN, and wonder if it might be of use for Unicode support on 95/98/ME for Xwinclip. The API for this layer is described at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win9x/unilayer_4wj7.asp The actual redistributable can be downloaded at: http://www.microsoft.com/downloads/release.asp?releaseid=30039 The actual lib is is in the platform SDK. Any thoughts on this? Cheers, Nicholas __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Spanning desktop across multiple X servers...
--- Tim Thomson [EMAIL PROTECTED] wrote: Hi there, I think x2x is what you are after. Looks like the xservers need to support the XTEST extension. Does the cygwin-xfree server support this? Not sure where you'd find it, there is a description here: http://packages.debian.org/stable/x11/x2x.html There are packages of this for other systems, but I'm not sure where it originated. Tim, It was designed by DEC (Digital) back in '97 and can still be found at: ftp://ftp.digital.com/pub/Digital/SRC/x2x/ Dunno if it still works, but it's worth a try ;-). Cheers, Nicholas __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re[2]: Spanning desktop across multiple X servers...
Thomas, You are very welcome! Now that we've helped you, perhaps you want to volunteer to submit and maintain this as a package for the main distribution of Cygwin? It's real easy, just follow the instructions at: http://cygwin.com/setup.html When you're ready, just submit the information to this list rather than cygwin-apps. If you have any questions about packaging, feel free to ask. Cheers, Nicholas --- Thomas Chadwick [EMAIL PROTECTED] wrote: Thank you, thank you, thank you! Grabbed the src from DEC, built it in a jiffy, and voila! It is EXACTLY what I was looking for. FYI - I did some additional poking around and found this, which describes making x2x more secure: http://www.cs.washington.edu/homes/klee/misc/x2x.html From: Nicholas Wourms [EMAIL PROTECTED] To: Tim Thomson [EMAIL PROTECTED], cygwin-xfree Mailing List [EMAIL PROTECTED] Subject: Re: Spanning desktop across multiple X servers... Date: Fri, 21 Jun 2002 04:19:47 -0700 (PDT) --- Tim Thomson [EMAIL PROTECTED] wrote: Hi there, I think x2x is what you are after. Looks like the xservers need to support the XTEST extension. Does the cygwin-xfree server support this? Not sure where you'd find it, there is a description here: http://packages.debian.org/stable/x11/x2x.html There are packages of this for other systems, but I'm not sure where it originated. Tim, It was designed by DEC (Digital) back in '97 and can still be found at: ftp://ftp.digital.com/pub/Digital/SRC/x2x/ Dunno if it still works, but it's worth a try ;-). Cheers, Nicholas __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: broken lndir so cant build tree
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Jun 17, 2002 at 06:25:49AM -0700, Nicholas Wourms wrote: I can confirm this with the the latest snapshot of cygwin on WindowsME. I'll run an strace later and see what the problem is. Was this ever posted? I never saw it, if so. cgf Chris, It works now, thanks to your excellent skills in repairing that bad Pierre patch ;-). Cheers, Nicholas __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
RE: [ANNOUNCEMENT] Server Test 58
--- Harold Hunt [EMAIL PROTECTED] wrote: Chris was referring to the fact that, in addition to placing the test release stand-alone files (e.g., XWin-Test58.exe.bz2) on my msu.edu site and distributing them via the sources.redhat.com network, I have also been placing a modified XFree86-xserv-4.2.0-?.tar.bz2 for Cygwin's setup.exe in cygwin/xfree/release/XFree86/XFree86-xserv/. Chris was saying that instead of telling users to point setup.exe to that other directory I could just put the test package in the normal directory and mark it as 'test' in setup.hint. Hope that clears things up, Harold, Implementing the test-release in setup.exe is real easy. Take, for example, the setup.hint of GDB: sdesc: The GNU Debugger category: Devel requires: cygwin termcap test: 20020411-1 curr: 20010428-3 That's all there is to it :-). FWIW, I think CGF's suggestion is a good one, as it makes it much easier to deal with... Cheers, Nicholas __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Possible bug of the M$ windows manager ? or, XFree bug ?
People, For the love of God, bzip2 is there for a reason, please use it. Some of us have high mail volume and low mailbox quotas. Thanks, Nicholas --- Harold L Hunt [EMAIL PROTECTED] wrote: Philippe, Did you hide the mouse cursor when you took the screenshots? There's not a mouse cursor anywhere in any of those screenshots... I need to see that Cygwin/XFree86 is indeed hiding/unhiding the mouse cursor correctly. Harold Philippe Bastiani [EMAIL PROTECTED] said: Hi, Sorry for the delay of my reply... As you can see it, WindowsXP enlightens the system buttons when the mouse pointer is on those. Line n°2 of the png file: the mouse pointer is on the 'close' button. Line n°3 of the png file: the mouse ponter is on the 'shrink' button, - Message d'origine - De : Harold Hunt [EMAIL PROTECTED] À : Philippe Bastiani [EMAIL PROTECTED]; cygx [EMAIL PROTECTED] Envoyé : mardi 14 mai 2002 04:12 Objet : RE: Possible bug of the M$ windows manager ? or, XFree bug ? Philippe, You're the first person to complain and you're going to have to give a heck of a lot more details than that if I'm ever going to look into it. Screenshots. I want screenshots. You'll need at least four: two that show a working window, and two that show Cygwin/XFree86's behavior. Make them PNGs, not JPGs, as I want to be able to look at them. You can copy a screenshot to the clipboard of the current window in Windows XP with Alt+PrintScreen. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Philippe Bastiani Sent: Monday, May 13, 2002 6:18 PM To: Cygwin Subject: Possible bug of the M$ windows manager ? or, XFree bug ? Hi, On Windows XP, the buttons of the titles bar of XFree86 screen seem non standard ! Normally, the drawing of the system buttons should be modified when the mouse pointer is on these! Philippe Bastiani __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
logos (was RE: AmiWM Port)
Harold, Sorry to rehash an old discussion, but I just discovered this thread when you mentioned it. I followed it through to conclusion, but it stopped as quickly as it started. Whatever happened to this discussion? Any chance of a new logo being adopted? I personally dislike the current cygwin logo, too. It's a bit bland if you ask me. Maybe it needs the redhat touch, but the logo that was attached to that message rocked. Any chance of adopting it? Cheers, Nicholas --- Harold Hunt [EMAIL PROTECTED] wrote: Chris, Hmm... when did you drop the message size limit to 100 KB? This messages from 2002/04/06 has a roughly 200 KB attachment: http://cygwin.com/ml/cygwin-xfree/2002-04/msg00081.html I looked back at the mailing list archives over the last 5 months or so and I see no legitimate messages without attachments that were larger than 50 KB. I therefore request that the message size limit be dropped to 50 KB. Thanks, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor Sent: Sunday, June 02, 2002 9:36 PM To: [EMAIL PROTECTED] Subject: Re: AmiWM Port Should lower the message size limit here? I think it's currently 100K. cgf On Sun, Jun 02, 2002 at 05:40:04PM -0400, Harold Hunt wrote: Don't send 57 KB (or whatever) attachments to the Cygwin/XFree86 mailing list. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
