Re: One more Xinerama patch for FvwmWharf
On Sat, Aug 18, 2001 at 08:28:54PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. Appliet. BTW, could you please include ChangeLog entries with your patches? BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Can you post a config to demonstrate this? Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. You're using XNest? Usually I don't debug problems with XNest which seems to have a lot of bugs. Did you ever see this with a real X server? BTW2: wouldn't it be wise to add an item 15.5.5.5 to todo-3.0, stating Remove FvwmWharf (It's an FvwmButtons with trivial enhancements)? I'va added it to the list. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Incompatible change to FvwmBacker?
On Wed, Aug 22, 2001 at 09:23:34AM -0700, Michael Han wrote:
On Wed, Aug 22, 2001 at 09:57:18AM -0400, Dan Espen wrote:
One of our users has this:
*FvwmBackerDesk 0 Exec audioplay ${FVWMAUDIO}/kurtsounds/oh.au
*FvwmBackerDesk 1 Exec audioplay ${FVWMAUDIO}/kurtsounds/1.au
Before FVWM 2.4.0, this announced Desk changes but not Page changes.
Now a page change or a desk change is announced.
I seem to recall a problem we discovered in FvwmBacker related to
spurious new-desk/new-page events received by the modules. I don't
know if it was ever resolved adequately.
As far as I know it was, but I don't remember the details.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Incompatible change to FvwmBacker?
[EMAIL PROTECTED] wrote: Did I miss something when I concluded that FvwmBacker can no longer do what it did before? No, if FvwmBacker does what the man page says: *FvwmBackerCommand (Desk d, Page x y) command Specifies the command to execute when the viewport matches the arguments for the desk d, page x coordinate and y coordinate. Any or all of these three numeric arguments can be replaced with an asterisk (*) to indi- cate that any value matches, in this case Desk or Page parts can be skipped. Note these three lines are equivalent: *FvwmBackerCommand (Page * *, Desk *) -solid navy *FvwmBackerCommand () -solid navy *FvwmBackerCommand -solid navy plus this: There is continued support for the now deprecated option: *FvwmBackerDesk d command It is functionally equivalent to using an asterisk for both page coordinates with *FvwmBackerCommand. So *FvwmBackerDesk 0 ... gets translated to *FvwmBackerCommand (Page * *, Desk 0) ... which isn't quite the same thing. There seems to be no way to stop FvwmBacker doing its thing when the page changes and the desk matches. I think we should change the behaviour of FvwmBacker when the Page specifers are not included so that it _doesn't_ do its thing if only the page changes. Similarly if the Desk specifier is not included it _shouldn't_ do its thing when only the desk changes. Then translating *FvwmBackerDesk 0 ... into *FvwmBackerCommand (Desk 0) ... would work in the old way. Cheers, Tim. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS dane: * libs/Bindings.c (MatchBinding): Unify XDisplayKeycodes avoidance.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane01/08/23 09:48:03 Modified files: . : ChangeLog libs : Bindings.c Log message: * libs/Bindings.c (MatchBinding): Unify XDisplayKeycodes avoidance. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: One more Xinerama patch for FvwmWharf
On Thu, 23 Aug 2001, Dominik Vogt wrote: On Sat, Aug 18, 2001 at 08:28:54PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. Appliet. BTW, could you please include ChangeLog entries with your patches? Ok. For this one it is Make FvwmWharf use current Xinerama screen for choosing in which direction to slide panels and for withdrawn position calculation (khm, a bit too long, shame on me...). BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Can you post a config to demonstrate this? Well, that's just AnotherLevel. I append all *FvwmWharf lines in m4-preprocessed form at the end of this mail (long lines are marked with \s). Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. You're using XNest? Usually I don't debug problems with XNest which seems to have a lot of bugs. Did you ever see this with a real X server? Yes. It is the same problem which was 100% reproducible with 2.3.28 under XFree86 3.3.2 with Matrox Millenium II (that was my previous machine). And it is still reproducible under XFree86 4.0.3 on our 4-monitor PC (Matrox G450DualHead + 2 x Millenium II), the same problem on any head. That machine has RedHat 6.2 (kernel 2.2.16) with glibc-2.1.3. U... Actually, I ran fvwm over a 100Mbit Ethernet from another machine, and my oldie was P166MMX; so, maybe there's some timing problem? CUT HERE Style FvwmWharf StaysOnTop,Sticky, WindowListSkip,CirculateSkip, \ ClickToFocus, NoTitle,NoHandles,BorderWidth 0 *FvwmWharfAnimate *FvwmWharfAnimateMain *FvwmWharfGeometry -0+0 *FvwmWharfColumns 1 *FvwmWharfTextureType 255 *FvwmWharfBgColor gray51 *FvwmWharf AfterStep AfterStep.xpm Folder *FvwmWharf Shutdown ShutDown.xpm Quit *FvwmWharf xlock KeysOnChain.xpm FvwmForm XLock *FvwmWharf ~Folder *FvwmWharf xclock nil Swallow xclock xclock -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 -padding 0 *FvwmWharf xbiff nil Swallow xbiff xbiff -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 *FvwmWharf xload nil Swallow xload xload -nolabel -hl black -bg \ #8e8a9e -geometry 48x48-1-1 *FvwmWharf xload nil Exec xterm -ut -T top -e top *FvwmWharf Pager nil Swallow FvwmPager Module FvwmPager 0 0 *FvwmWharf xterm monitor-check.xpm Exec xterm -bg black -geometry \ 80x25 -sl 500 -sb -ls -T 'xterm: [EMAIL PROTECTED]' *FvwmWharf emacs text.xpm Exec emacs *FvwmWharf gimp 3dpaint.xpm Exec gimp *FvwmWharf pine writeletter.xpm Exec xterm -T pine -e pine *FvwmWharf Netscape netscape3.xpm Exec netscape *FvwmWharf Recycler recycler.xpm Restart fvwm2 CUT HERE _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Notification: incoming/767
FVWM Bug Tracking notification new message incoming/767 Message summary for PR#767 From: [EMAIL PROTECTED] Subject: fvwm 2.4.0 on HP-UX breaks xterm etc. Date: Thu, 23 Aug 2001 20:43:35 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Thu Aug 23 20:43:36 2001 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15a60W-0003zV-00 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 20:43:36 -0500 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id UAA20864 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 20:43:35 -0500 (CDT) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15a60V-0003zR-00 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 20:43:35 -0500 To: [EMAIL PROTECTED] Subject: fvwm 2.4.0 on HP-UX breaks xterm etc. Message-Id: [EMAIL PROTECTED] Date: Thu, 23 Aug 2001 20:43:35 -0500 Full_Name: Matthias K. Buelow Version: 2.4.0 CVS_Date: OS: HP-UX 10.20 X_Server: HP-UX 10.20 shipped version Submission from: (NULL) (194.145.150.157) Context: fvwm 2.4.0 on HP-UX 10.20, on a Model 9000 712/60 workstation. Linked against xpm, no imlib, no readline, built with HP's optional ANSI C compiler for 10.20. Single module running is FvwmPager. The problem shows up no matter if fvwm is built with X11R5 or X11R6 headers/libs. fvwm 2.4.0 heavily messes up tty handling in xterm, hpterm and rxvt. The problem does not show up in dtterm (CDE terminal) under fvwm 2.4.0. The problem manifests itself in non-working interrupt keys, however all a bit different in the various terminals and it depends on the shell being used: In xterm (both X11R5 as well as X11R6) with ksh and /bin/sh, SIGINTR doesn't occur at all (intr is bound to ^C, ^C does nothing, doesn't even echo). For all other commands, the first character typed into the command line is echoed before the command's own output. TERM is set to xterm. The problem also shows up after TERM is set to vt100 and xterm was reset. In rxvt with ksh and /bin/sh, SIGINTR doesn't work and ^C is echoed. The first character typed is not echoed before a command's output. TERM is set to xterm. With hpterm, the problem is similar to rxvt. TERM is hpterm. With dtterm, everything works normally. The problem does not show up with csh, in any terminal. The problem _does_ show up after rlogin to a NetBSD machine, with yet another shell (pdksh), so it seems to be some trouble with the X terminal emulator in use. When starting some programs, such as /bin/ed in a defective terminal session, Ctrl+C works all right in that program. It does not work in vi, though, so this seems to be some messed up behaviour with the terminal line discipline regarding canonical mode and cbreak/raw mode (csh is also using canonical mode, ksh is using a combination of canonical and cbreak mode) or whatever. Why I believe this to be an fvwm 2.4.0 problem is because it does not show up in in twm, ctwm, mwm, CDE, xfce and blackbox aswell as fvwm 1.24r (which I have been using mainly until now.) This is a rather serious problem since it effectively disables the use of fvwm 2.4.0 on that particular system (unless you restrict yourself to dtterm.) The problem does not occur on my NetBSD box, which is running the same version of fvwm. More information will be provided on request. I can help debugging this problem, I'll have a look into it this weekend. --mkb -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Notification: incoming/768
FVWM Bug Tracking notification new message incoming/768 Message summary for PR#768 From: [EMAIL PROTECTED] Subject: fvwm_icons.tgz Date: Thu, 23 Aug 2001 22:25:39 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Thu Aug 23 22:25:41 2001 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15a7bJ-000431-00 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 22:25:41 -0500 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id WAA22303 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 22:25:41 -0500 (CDT) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15a7bH-00042x-00 for [EMAIL PROTECTED]; Thu, 23 Aug 2001 22:25:39 -0500 To: [EMAIL PROTECTED] Subject: fvwm_icons.tgz Message-Id: [EMAIL PROTECTED] Date: Thu, 23 Aug 2001 22:25:39 -0500 Full_Name: Pete Fritchman Version: 2.4.0 CVS_Date: OS: X_Server: Submission from: (NULL) (207.29.204.16) It appears that when the fvwm_icons.tgz tarball was rolled, some garbage got mixed in somehow. after a tar xzf you'll see: gzip: stdin: decompression OK, trailing garbage ignored tar: child returned status 2 While this is harmless and all the icons are still extracted, this might make some users think they've done something wrong (ie: downloaded a bad tarball, etc). I maintain the FreeBSD port for fvwm2 and this has confused at least one user so far. If you could re-roll the fvwm_icons.tgz file to get rid of this, that would be great. Thanks for your great work! -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
