Re: Grabbing XFree86.org's xc/ tree using cvsup
Harold L Hunt II wrote: Alexander, Alexander Gottwald wrote: Harold L Hunt II wrote: Another thing to keep in mind is how we want to do development. It has been suggested that we keep the HEAD branch in sync with XFree86.org and that we do our development on another branch. The question here is whether cvsup can preserve a local branch of the code and still be used to sync with XFree86.org. I doubt that this is the case, since cvsup is essentially mirroring the files, not branches/tags/etc. Does this mean that we must manually track XFree86.org and apply their patches after the initial import? My suggestion is to import the current stable release into our CVS. With CVS we can later import the next release and merge all patches we have already commited. Fixing severe bugs is still an issue and might be solved by regulary importing the snapshots of the stable branch and by monitoring the XFree-commit list (I still read every posting on this list and would just pay more attention to security fixes) Mike Harris had a good point that we should grab XFree86's CVS tree with cvsup and use a perl script to change the root for all of the files. Then we have both the current version of all files *and* the history of all of those files. Note that this requires cvsupd to run on the server side ... do XFree86 already run cvsupd? If not, you may find it easier to ask them for a tarball of the CVSROOT to get going, and then something like cvsps (suggested by Mike below) to keep up to date. He suggested using cvsps to generate patch sets. He also suggested doing our development on a branch, keeping HEAD more or less in sync with XFree86.org CVS HEAD, and merge HEAD to our branch whenever required (to get bug fixes, etc.). I doubt that a complete mirror of the XFree86 CVS is a good solution since there is no way (at least I konw of none) to automaticly track changes in the XFree86 repository and commit them to ours too. So importing the whole repository is in my opinion a waste of space since we'd have to import all old revisions from the XFree repository too. I think Mike had a good point that it would be wise to have the history of each file in the tree... what do you think? I think this would be great ; it also allows the possibility of producing security-patched versions of older versions of XFree86, and the version history also provides a kind of documentation of the source David
Re: New package: xwinclip-1.2.0-1
Harold == Harold L Hunt, Harold writes: Harold The xwinclip-1.2.0-1 package has been updated in the Cygwin distribution. The package installs its documentation under /usr/X11R6/share/doc indstead of /usr/X11R6/doc. Ciao Volker
Keyboard focus problem + scrambled icons in wmaker with latest release
Hello, I'm running the latest version of Cygwin, XFree and WindowMaker (from mirrors.rcn.net, but I also tried mirrors.sunsite.dk and mirrors.kernel.org) in my WinXP Pro workstation and I have the following problems: 1) when I move my mouse outside a xterm windows the keyboard focus is lost by that window and is re-taken when I get back to that window with the mouse pointer. It only happens with Cygwin-XFree's xterm, while if I launch, for example, HP-UX's xterm from a HP workstation or Cygwin's rxvt or Nedit it doesn't happen. This started to happen 1/2 weeks ago (consider that I constantly monitor the announce mailing lists of Cygwin and, hence, I make setup.exe run once every one/two days). I saw, from the list, that other people have this problem too. 2) this morning I ran setup and I downloaded the latest modifications to Xwinclip, XFree86-bin, etc. From that point on, some of the icons of wmaker are scrambled, in particular the icons that represents terminals and the icons of the Window Maker Preferences Utility, launching wmaker by hand (i.e. not as I usually do with a script that launces XWin and then wmaker) I get this errors on stderr: TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. I don't know if this is a useful information, but I run XFree in rootless mode. I also tried to uninstall wmaker, to remove from my user's home the configuration files of wmaker (I renamed the ~/GNUstep dir) and to re-install wmaker but things haven't changed. Bye, Danilo Turina
Re: Patch for keyboard handling
Takuma Murakami wrote: I have made a patch to improve keyboard handling. Any comments would be appreciated. The changes are: 1) win.h, winkeybd.c, winwndproc.c - Improve the synchronization of mode key states between XWin and Windows. + /* Stored to get internal mode key states. Must be read-only. */ + static unsigned short *g_winInternalModeKeyStatesPtr = NULL; Shouldn't this be a pointer to constant data? Isn't that: static unsigned short const * g_winInternalModeKeyStatesPtr = NULL; ??? 2) winmultiwindowwndproc.c - Enable mode key synchronization in -multiwindow mode. + g_winInternalModeKeyStatesPtr = (pDeviceInt-key-state); Wow! That is a really good idea. I should have been doing that all along, but I didn't realize that I could access the internal mode-key states. Great idea. 3) winwndproc.c - Make clean termination on logoff or shutdown. Good catch for WM_ENDSESSION. That should have been there all along... 4) winconfig.c - Fix the lacks of KEYUP messages in Japanese environments. The solution was proposed by Kensuke Matsuzaki. Looks good to me. It all depends on if it works for you guys. 5) winwndproc.c - Ignore Windows keyboard auto-repeats so that XWin controls auto-repeats instead of Windows. Okay. I will try to apply this patch tomorrow. Thanks for contributing, Harold
Re: Patch for keyboard handling
+ /* Stored to get internal mode key states. Must be read-only. */ + static unsigned short *g_winInternalModeKeyStatesPtr = NULL; Shouldn't this be a pointer to constant data? Isn't that: static unsigned short const * g_winInternalModeKeyStatesPtr = NULL; ??? Exactly. That's what I wanted to do. Thank you for pointing out. Takuma Murakami ([EMAIL PROTECTED])
Help with cygwin fvwm2 setup
I just downloaded the full cygwin installation as of Friday Oct 31. I did the following just after an install and got many errors: Double-clicked on the cygwin.bat which gave me a bash prompt typed: X which brought up the windows manager typed back in the bash window: export DISPLAY=:0.0 and then the following: fvwm2 -f /usr/X11R6/share/fvwm/system.fvwm2rc-sample-95 and got nothing but a bunch of errors about not being able to find .xpm files. Can someone please tell me where all the .xpm files are and the best way to get fvwm2 fully up and running? Again, this is a full install of cygwin. thanks, taz
Re: Grabbing XFree86.org's xc/ tree using cvsup
On Sun, 2 Nov 2003, Harold L Hunt II wrote: He suggested using cvsps to generate patch sets. He also suggested doing our development on a branch, keeping HEAD more or less in sync with XFree86.org CVS HEAD, and merge HEAD to our branch whenever required (to get bug fixes, etc.). Just a note here. This is what CVS's notion of vendor branches is for. Although I have limited experience with them, I suggest you read up a little here before making this decision. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: xinit: The application has failed to start because cygfreetype-6.dll
On 2003-11-03 00:26, Constantine wrote: Harold wrote: Constantine wrote: Hello, After I have updated my installation today, and when I am running xinit now, I get a Windows window with the message that cygfreetype-6.dll was not found. After I did the following, everything worked again: cd /usr/X11R6/bin/ cp cygfreetype-9.dll cygfreetype-6.dll Constantine, Hmm... I would appreciate it if you could help me to figure out what the real problem is here. The new XFree86-bin-4.3.0-7 package no longer contains cygfreetype-9.dll, as this library is now distributed as part of the freetype2/libfreetype26 package. freetype2 defines the version of the freetype2 library as '6' instead of the '9' that XFree86 was using as the library version. I added a copy of cygfreetype-9.dll to the XFree86-lib-compat package for those that need the old library. However, I want to know what application was failing in your xinit scripts. There should not be an application that requires cygfreetype-9.dll in the default script. Have you modified your script? What program are you launching that requires this DLL? Are you launching emacs? I would like to get any old applications that use cygfreetype-9.dll rebuilt. No, everything should be by default, except for my ~/.xinit file. I just erased that file, ran the installer again (it downloaded only 'libfontconfig1-2.2.0-1.tar.bz2' and 'libfreetype26-2.1.5-1.tar.bz2'), and it seems to work fine. It is very strange, since the setup.ini files from yesterday and today seem to be the same, and I did not selected nor deselected any option neither today nor yesterday. Well, I guess it is the people who make the setup.exe to blame. When I wrote 'that file', I was referring to 'cygfreetype-6.dll', i.e. a copy of 'cygfreetype-9.dll', not to my ~/.xinitrc. In any case, here is my ~/.xinitrc: xhost + 192.168.0.18 ssh [EMAIL PROTECTED] setenv DISPLAY 192.168.0.1:0; startkde Cheers, Constantine. (I am not on the list, so please reply all. )
Regarding Unwanted packages (apache, emacs etc)
Aha! I see. In my naivete I must have managed to select some packages dependant on those two. I should think that selecting the parent package would select the child package only... But I can see where the reverse might be helpful. Thanks! Patricia Patricia C. Vener Come visit my online galleries! vener-art.com ¨Canto que ha sido valiente siempre será canción nueva¨ -- Víctor Jara
Re: Patch for keyboard handling
Takuma Murakami wrote: I have made a patch to improve keyboard handling. Any comments would be appreciated. The changes are: 1) win.h, winkeybd.c, winwndproc.c - Improve the synchronization of mode key states between XWin and Windows. 2) winmultiwindowwndproc.c - Enable mode key synchronization in -multiwindow mode. Actually, now I am a little doubtful that this patch is complete. If I recall correctly, we are merely enqueueing input events into a queue that the mi layer processes later. Checking the mode key states within the X server will only indicate what the mi layer currently knows about the mode key states. The my layer would not know that there are messages in its queue that change the state of the mode keys. I also recall that there is a way to force the mi layer to process all input events (miProcessInputEvents ?) and that this could be called before querying the state of the mode key states in order to get a consistent result. Please respond to this either with a rebuttal or a different patch. I don't think I can commit the existing patch until then. Harold
