Your message to nylug-talk has been rejected
Your mail to 'nylug-talk' with the subject Congratulations Has been rejected because Post by non-member to a members-only list If you would like to post messages to this list, please confirm that you are sending messages from a subscribed email address, or visit http://herzl.nylug.org/mailman/listinfo/nylug-talk to subscribe to the list. -- 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: Problems building snap-20020826
On 05 Sep 2002 03:25:49 +0200, Mattias Andersson wrote: On 26 Aug 2002 11:28:23 -0500 Jason L Tibbitts III [EMAIL PROTECTED] wrote: BTW, the machine I'm building on runs Red Hat 7.1, and has XFree86 4.0.3 installed. I know it's old but I expect that others would run into the same issue. I had similar problems first. If you look in the first part you semms to be missing a few Gnome packages e.g. GDK. If you search for these in www.rpmfind.net you will find them. Test with rpm -q gnome-core or gdk. You don't need gnome or gtk to build fvwm. The problem was different and was fixed in cvs as you may see on ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/ and since there are no more automatical Problems building snap messages. Regards, Mikhael. -- 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 olicha: * Fixed FvwmTaskBar i18n font loading
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/09/05 06:26:50 Modified files: . : Tag: branch-2_4 ChangeLog NEWS modules: Tag: branch-2_4 ChangeLog modules/FvwmTaskBar: Tag: branch-2_4 FvwmTaskBar.c Goodies.c Log message: * Fixed FvwmTaskBar i18n font loading -- 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/920
FVWM Bug Tracking notification new message incoming/920 Message summary for PR#920 From: [EMAIL PROTECTED] Subject: *FvwmPager: BalloonBack is ignored Date: Thu, 05 Sep 2002 15:12:58 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Thu Sep 05 15:12:58 2002 Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17n2zq-0005px-00 for [EMAIL PROTECTED]; Thu, 05 Sep 2002 15:12:58 -0500 Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by util2.math.uh.edu with esmtp (Exim 4.10) id 17n2zq-0003d3-00 for [EMAIL PROTECTED]; Thu, 05 Sep 2002 15:12:58 -0500 Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17n2zq-0005pt-00 for [EMAIL PROTECTED]; Thu, 05 Sep 2002 15:12:58 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: *FvwmPager: BalloonBack is ignored Message-Id: [EMAIL PROTECTED] Date: Thu, 05 Sep 2002 15:12:58 -0500 Full_Name: Robert Withrow Version: 2.4.9 CVS_Date: OS: FreeBSD 4.6.2-RELEASE X_Server: XFree86 4.2.0 Submission from: (NULL) (47.234.0.52) The following directive: *FvwmPager: BalloonBack yellow Seems to be ignored in this version of FVWM; the balloon backgrounds are always black. It worked as expected in 2.3.32. -- 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 domivogt: * Several stacking order fixes with transients.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/05 15:57:01 Modified files: . : ChangeLog fvwm : stack.c stack.h Log message: * Several stacking order fixes with transients. -- 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 domivogt: * Preliminary version of recursive transient raising/lowering.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/05 15:59:44 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 bindings.c stack.c libs : Tag: branch-2_4 fvwmlib.h modules: Tag: branch-2_4 ChangeLog modules/FvwmTaskBar: Tag: branch-2_4 FvwmTaskBar.c Goodies.c Log message: * Preliminary version of recursive transient raising/lowering. * Several stacking order fixes with transients. -- 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: Notification: incoming/920
On Thu, Sep 05, 2002 at 03:12:58PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/920 Full_Name: Robert Withrow Version: 2.4.9 CVS_Date: OS: FreeBSD 4.6.2-RELEASE X_Server: XFree86 4.2.0 Submission from: (NULL) (47.234.0.52) The following directive: *FvwmPager: BalloonBack yellow Seems to be ignored in this version of FVWM; the balloon backgrounds are always black. It worked as expected in 2.3.32. The problem is already know and fixed in the source repository. The 2.4.10 version that is going be released until the end of next week will fix that. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 domivogt: * Copied stacing order patch from stable branch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/05 17:42:27 Modified files: . : ChangeLog NEWS fvwm : stack.c Log message: * Copied stacing order patch from stable branch. -- 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 domivogt: * Cleaned up stacking order patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/05 17:42:55 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 stack.c Log message: * Cleaned up stacking order patch. -- 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: FVWM: Re: 2.5.x questions (Was: i can't run fvwm 2.4)
I tried the above. Make install works fine but if you make -k install-strip then the problem occurs. Dont know if this is the same thing, but is the make -k install-strip to remove the dedebug symbol tables? I just change -g -O2 in configure to -O3. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Re: 2.5.x questions (Was: i can't run fvwm 2.4)
On 04 Sep 2002 22:07:19 -0700, elliot sowadsky wrote: I tried the above. Make install works fine but if you make -k install-strip then the problem occurs. Hmm, I can't reproduce this problem. /usr/bin/install -c -s ... exits with error, but does install a script with +x permissions for me. Anyway, eventually we'll switch to autoconf-2.53 when creating releases and make install-strip will work well even without -k parameter. Dont know if this is the same thing, but is the make -k install-strip to remove the dedebug symbol tables? I just change -g -O2 in configure to -O3. Yes, more or less the same effect may be done by: env CFLAGS=-O3 ./configure or (before make install): make CFLAGS=-O3 Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Non iso8995-1 fonts and the TaskBar
On Mon, Aug 12, 2002 at 06:29:28PM +0100, John Latham wrote: FvwmTaskBar crashes, quietly without any trace, in 2.4.6 as shipped by Red Hat 7.3 (multi-byte is enabled) and also in 2.4.8 when compiled with multibyte option, but not otherwise. The task bar just refused to appear, and left no error message not even a core dump. Don't ask me how I figured out this was with the setting that caused the problem *FvwmTaskBarFont -*helvetica-medium-r-*-*-12-*-*-*-*-*-*-* and changing it to the following makes it work okay: *FvwmTaskBarFont -*helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-1 I assume it was picking up some font encoding that FvwmTaskBar cannot handle -- does that make sense? There is a bug in the taskbar, if the SelFont is not found the taskbar exit (the default font is not tried!). This will be fixed in the next stable release. Any way if you use: -*-*helvetica-medium-r-*-*-12-*-*-*-*-*-*-* ^^ I think that the taskbar will work as you want (no locale change and this is better than enforcing the charset). I still do not understand why with -*helvetica-medium-r-*-*-12-*-*-*-*-*-*-* the font loading procedure fails (as xlsfont show me some fonts, but xlsfont do not use the i18n procedure for querying font). But I do not think that it is fvwm fault. Maybe a * count issue. This behaviour was still happening after I changed to POSIX locale (see previous message): it seems you need BOTH the posix locale and the iso8859-1 to make it work in 2.4, if multi-byte is emabled. Similarly, FvwmPager was using the wrong font until I put the iso8859-1 spec on that too. At least it wasn't crashing! Use -*-*helvetica-medium-r-*-*-12-*-*-*-*-*-*-* All this seems to work fine on 2.5.2, no need for locale change or iso8859-1 specification. This all makes me think I could do with learning a *bit* more about X fonts and their relationships to locales. Can anyone suggest a good (implies short...) summary on the matter? man XCreateFontSet and the xlfd and i18nFramework documents in the X doc directory (something like /usr/X11R6/lib/X11/doc). Maybe you will not find this docs good. Regards, Olivier -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Motif-like windowed menus
Some motif windows (in Motif-based gVim or NEdit) can be put inside windows by clicking on dashed line on top of the menu. Is there any way to do so with menus in Fvwm2 ? -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Motif-like windowed menus
Rastislav Galia [EMAIL PROTECTED] writes: Some motif windows (in Motif-based gVim or NEdit) can be put inside windows by clicking on dashed line on top of the menu. Is there any way to do so with menus in Fvwm2 ? Pin up menus are available in the Fvwm 2.5.x beta series. A 2.5.x release might be OK for personal use but should not be widely deployed. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: i can't run fvwm 2.4
Date: Tue, 03 Sep 2002 11:27:37 -0600 From: Gregg Dameron [EMAIL PROTECTED] To: fvwm@fvwm.org John Latham wrote: I've just noticed that the one I thought might be the most helpful, ResizeHintOverride actually is already there in 2.4 -- for some reason I thought it was only in 2.5. (I am hoping this will help combat the quite common but appalling 1x1, modal, nonresizable dialog ``feature'') If a solution to the 1x1 presents itself, please post it. We've been fighting this one in 2.4.7 (and prior to that, under fvwm95 for many years). It seems to happen more frequently if the CPU is under load. Gregg Dameron Success -- I just managed it!!! I have in the last day or so started to build up a set of togglable java bug work arounds to put on the menu in AnotherLevelUp. This allows the user to switch them on/off at will in a persistent way (i.e. next start/restart has them on/off as you last left them). This reduces the risk of unforseen side effects, if they were enabled for everyone all the time, and allows users to experiment and report back what works, how and when. So far I have implemented 3, and 2 of them certainly seem to help, at least with blackdown's jdk1.3. I have yet to see any effect from the first one below. For now I am calling them: 1) BugOpts ModalityIsEvil 2) Style AWTdialog ResizeHintOverride 3) FvwmEvent AWT add_window Deiconify 1) is one of the recommended Java 1.3 `fixes', but I have not yet seen it have any effect (but have not really given it a good try). 2) I have just managed to successfully use this against a 1x1 modal dialog -- I was able to stretch it out and the real contents appeared!! We're celebrating here! (BTW, it was the tip of the day dialog for Together 6.) 3) I have successfully used this to get around the non-reappearing dialog and (app) windows: viz a dialog is created and mapped, user dismisses it, then later it is reshown, but is remapped iconified. Particularly devastating if you do not have transient windows appearing in task vars or as icons, etc.. This fix deiconifies all AWTdialog and AWTapp windows when they are mapped, and it seems to work so far. I can post the toggle mechanism that AnotherLevelUp uses, if you wish, but attached are the guts of the work arounds so far, as hopefully self evident functions. Best wishes, John Latham DestroyFunc ToggleJAVAModalityIsEvilOn AddToFunc ToggleJAVAModalityIsEvilOn + I BugOpts ModalityIsEvil DestroyFunc ToggleJAVAModalityIsEvilOff AddToFunc ToggleJAVAModalityIsEvilOff + I FvwmForm RestartAfterChanges DestroyFunc ToggleJAVAAWTdialogResizeHintOverrideOn AddToFunc ToggleJAVAAWTdialogResizeHintOverrideOn + I Style AWTdialog ResizeHintOverride + I Recapture DestroyFunc ToggleJAVAAWTdialogResizeHintOverrideOff AddToFunc ToggleJAVAAWTdialogResizeHintOverrideOff + I Style AWTdialog NoResizeOverride + I Recapture DestroyFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOn AddToFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOn + I *JAVAFvwmEvent: Cmd Function + I *JAVAFvwmEvent: PassID + I *JAVAFvwmEvent: add_window DeIconfiyGivenWindowIfAWT + I Module FvwmEvent JAVAFvwmEvent DestroyFunc DeIconfiyGivenWindowIfAWT AddToFunc DeIconfiyGivenWindowIfAWT + I WindowId $0 (AWTapp) Iconify off + I WindowId $0 (AWTdialog) Iconify off DestroyFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOff AddToFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOff + I KillModule FvwmEvent JAVAFvwmEvent + I DestroyModuleConfig JAVAFvwmEvent* *RestartAfterChangesWarpPointer *RestartAfterChangesFontfixed *RestartAfterChangesButtonFont *helvetica*medium-r*12* *RestartAfterChangesInputFont fixed *RestartAfterChangesFore#FF *RestartAfterChangesBack#E64080 *RestartAfterChangesItemFore#FF *RestartAfterChangesItemBack#19007F *RestartAfterChangesLine left *RestartAfterChangesText The changes you have made will not apply until you *RestartAfterChangesLine left *RestartAfterChangesText next restart Fvwm2. *RestartAfterChangesLine expand *RestartAfterChangesLine left *RestartAfterChangesText If you want to make more changes first, *RestartAfterChangesLine left *RestartAfterChangesText you may ignore this form until you are ready, *RestartAfterChangesLine left *RestartAfterChangesText or make it go away for now. *RestartAfterChangesLine expand *RestartAfterChangesLine expand *RestartAfterChangesLine expand *RestartAfterChangesButton quit I want to Restart now ^M *RestartAfterChangesCommand Function ReallyRestartWithoutRandomPreferences *RestartAfterChangesButton quit Go away - I will Restart later ^C *RestartAfterChangesCommand Nop Style RestartAfterChanges StaysOnTop,Sticky AddToFunc ReallyRestartWithoutRandomPreferences # AnotherLevelUp has lots of stuff here, but the main thing is: + I Restart -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list,
Re: FVWM: Non iso8995-1 fonts and the TaskBar
From: Olivier Chapuis [EMAIL PROTECTED]
To: fvwm@fvwm.org
On Mon, Aug 12, 2002 at 06:29:28PM +0100, John Latham wrote:
FvwmTaskBar crashes, quietly without any trace, in 2.4.6 as shipped by Red
Hat
7.3 (multi-byte is enabled) and also in 2.4.8 when compiled with multibyte
option, but not otherwise.
There is a bug in the taskbar, if the SelFont is not found the taskbar
exit (the default font is not tried!). This will be fixed in the next
stable release. Any way if you use:
-*-*helvetica-medium-r-*-*-12-*-*-*-*-*-*-*
^^
I think that the taskbar will work as you want (no locale change and this
is better than enforcing the charset).
Indeed, you are right -- it works, thanks. I must admit that I have not
fiddled with the fonts in AnotherLevelUp since it was Red Hat's AnotherLevel,
but I have previously noticed the `missing *' and believed it not to be a
problem. Which it isn't, apart from in FVWM 2.4!
I still do not understand why with
-*helvetica-medium-r-*-*-12-*-*-*-*-*-*-*
the font loading procedure fails (as xlsfont show me some fonts, but
xlsfont do not use the i18n procedure for querying font).
But I do not think that it is fvwm fault. Maybe a * count issue.
I think you are saying it should not cause a problem, as stars are supposed to
match hyphens too. Which is what I believed to be true. The `missing -*' does
not cause a problem in FVWM 2.2.4 nor 2.5.{2,3}, just in 2.4.{6,8}. So,
perhaps FVWM 2.4 is querying fonts in a slightly different way?
Use -*-*helvetica-medium-r-*-*-12-*-*-*-*-*-*-*
I will thanks, -- I prefer your fix to mine. This might have other
consequences as Red Hat's AnotherLevel had (and so ALU currently still has):
define(`BASIC_FONT',`*helvetica')
and then later on things like:
*FvwmTaskBarFont -BASIC_FONT-medium-r-*-*-FONT_SIZE-*-*-*-*-*-*-*
and (now updated to use Style *)
Style * Font BASIC_FONT-bold-r-*-120-*
etc., so I need to be a bit careful.
All this seems to work fine on 2.5.2, no need for locale change or iso8859-1
specification.
This all makes me think I could do with learning a *bit* more about X fonts
and their relationships to locales. Can anyone suggest a good (implies
short...) summary on the matter?
man XCreateFontSet and the xlfd and i18nFramework documents in the X doc
directory (something like /usr/X11R6/lib/X11/doc). Maybe you will not
find this docs good.
I shall try these, thanks.
Regards, Olivier
Best wishes, John Latham
--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Motif-like windowed menus
Date: Thu, 05 Sep 2002 11:26:05 -0400 From: Dan Espen [EMAIL PROTECTED] Rastislav Galia [EMAIL PROTECTED] writes: Some motif windows (in Motif-based gVim or NEdit) can be put inside windows by clicking on dashed line on top of the menu. Is there any way to do so with menus in Fvwm2 ? Pin up menus are available in the Fvwm 2.5.x beta series. A 2.5.x release might be OK for personal use but should not be widely deployed. -- Dan Espen E-mail: [EMAIL PROTECTED] Hi. This morning I spotted another place where 2.5.x is being referred to as alpha -- in the NEWS files. Best wishes, John Latham $ grep alpha release fvwm-snap-20020904/NEWS Changes in alpha release 2.5.4 (not released yet) Changes in alpha release 2.5.3 (25-Aug-2002) Changes in alpha release 2.5.2 (24-Jun-2002) Changes in alpha release 2.5.1 (26-Apr-2002) Changes in alpha release 2.5.0 (27-Jan-2002) Changes in alpha release 2.3.5 (July 1999) Changes in alpha release 2.3.4 (June 1999) Changes in alpha release 2.3.3 (June 1999) Changes in alpha release 2.3.2 (May 1999) Changes in alpha release 2.3.1 (April 1999) Changes in alpha release 2.3.0 (February 1999) -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: transparent parts of xpm icons
Does fvwm2 allow to create a simple framing window around each individual icon in a similar way as MWM does ? Hitting the .xpm icons with transparent portions is sometimes a tricky task. /Rastjo -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: transparent parts of xpm icons
Rastislav Galia [EMAIL PROTECTED] writes: Does fvwm2 allow to create a simple framing window around each individual icon in a similar way as MWM does ? Hitting the .xpm icons with transparent portions is sometimes a tricky task. I answered your question yesterday in comp.windows.x.apps. Here is the same answer again: Nope. I've heard that .png icons with newer releases of XFree86 allow for you to click on the transparent parts. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
Date: Tue, 3 Sep 2002 11:58:18 +0200 From: Dominik Vogt fvwm@fvwm.org On Thu, Aug 29, 2002 at 07:55:51PM +0100, John Latham wrote: This is probably one for Dominic... You may recall a few weeks ago you fixed a bug in the menus when they have a HGradient -- certain menu items left `up' after scanning over them? It works much better now in 2.5.3, thanks very much, but I have noticed one little imperfection that I didn't notice before. Say you put the pointer on a menu item which causes a sub-menu to pop up. Then move the pointer up one place. The sub-menu is cleared away, however, it also wipes off the bottom edge of the 3D `up' relief of the item at the new pointer position (i.e. what was the top of the 3D relief of the previous position). This `absent bottom' feature is disabled if there is a NOP between the two items. Could you try with my latest patch? I couldn't reproduce this myself (probably because of SaveUnders or something). Bye Dominik ^_^ ^_^ I tried yesterday's snapshot this morning. Good news: I think the cosmetic menu problem has gone, thanks. Possible bad news -- maybe you are aware of these, but just in case: 1) Menus do not stay up like they used to. With Mouse 1 R A Menu StartMenu Nop a single click on the root window used to make the menu stay up. Now, it appears and disappears as soon as you let go of the mouse. And AddToMenu XXX + blah blah PopUp SubMenuYYY used to make SubMenuYYY stay up if you clicked on the item in XXX. (This was with PopupAsRootMenu style.) 2) I was able to get a maximize button to become `stuck', in the sense that every thing I clicked would be toggle maximised -- not even just the window that the button belonged to! Clicking on the root window would make it look like everything was normal, but as soon as the mouse was even moved the original ``sticky button'' would display it's ActiveDown mini-icon again. Even killing the program which the sticky button window belonged to (via another console) did not resolve the problem: the skeleton of it remained on the screen. Only killing X could stop it. I was able to invoke this feature twice, but did not spend a long time working out exactly what magic sequence was needed. I think it involves the window being resized by itself, and/or moved by itself prior to clicking the button. Would you like me to try to find a more definitive sequence of events, or is somebody already onto this bug? Best wishes, John Latham -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On 05 Sep 2002 18:55:26 +0100, John Latham wrote: Possible bad news -- maybe you are aware of these, but just in case: 1)Menus do not stay up like they used to. With Mouse 1 R A Menu StartMenu Nop a single click on the root window used to make the menu stay up. Now, it appears and disappears as soon as you let go of the mouse. And AddToMenu XXX + blah blah PopUp SubMenuYYY used to make SubMenuYYY stay up if you clicked on the item in XXX. (This was with PopupAsRootMenu style.) If you use the cvs or daily snapshots regularly you should subscribe to the fvwm-workers list to be up to date with what happens. You would see that this problem was reported and answered, but not fixed. You would also see the Dominik's request not to use the today's cvs because it will crash. 2)I was able to get a maximize button to become `stuck', in the sense that every thing I clicked would be toggle maximised -- not even just the window that the button belonged to! Clicking on the root window would make it look like everything was normal, but as soon as the mouse was even moved the original ``sticky button'' would display it's ActiveDown mini-icon again. Even killing the program which the sticky button window belonged to (via another console) did not resolve the problem: the skeleton of it remained on the screen. Only killing X could stop it. I was able to invoke this feature twice, but did not spend a long time working out exactly what magic sequence was needed. I think it involves the window being resized by itself, and/or moved by itself prior to clicking the button. Would you like me to try to find a more definitive sequence of events, or is somebody already onto this bug? This problem is not known. I don't quite understand what every thing I clicked would be toggle maximised means. Please post all ButtonStyle and other related lines. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
Date: Thu, 5 Sep 2002 20:07:22 +0100 From: John Latham [EMAIL PROTECTED] ... I suspect that one of the steps needed to invoke the feature is to ask this application to move itself: I have bound the right mouse button to act as a `grab and move' function for this application (because it has lots of little windows). ... I did not make it clear, sorry: the binding I speak of is a PerlTk binding, not an FVWM binding. So as far as FVWM is concerned, I presume, the PerlTk application is asking to be moved, quite a lot of move requests in fact, as I drag the mouse. (I hope this is Red Herring.) Best wishes, John Latham -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On Thu, Sep 05, 2002 at 06:31:34PM +, Mikhael Goikhman wrote: 2) I was able to get a maximize button to become `stuck', in the sense that every thing I clicked would be toggle maximised -- not even just the window that the button belonged to! Clicking on the root window would make it look like everything was normal, but as soon as the mouse was even moved the original ``sticky button'' would display it's ActiveDown mini-icon again. Even killing the program which the sticky button window belonged to (via another console) did not resolve the problem: the skeleton of it remained on the screen. Only killing X could stop it. I was able to invoke this feature twice, but did not spend a long time working out exactly what magic sequence was needed. I think it involves the window being resized by itself, and/or moved by itself prior to clicking the button. Would you like me to try to find a more definitive sequence of events, or is somebody already onto this bug? This problem is not known. I don't quite understand what every thing I clicked would be toggle maximised means. Please post all ButtonStyle and other related lines. It's known to me and also caused by the event handling rewrite. If you are curious, press the maximize/shade/whatever button on a window, move the pointer out of the button and release it. Regardless of where you click now the action on the window button is triggered. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On 05 Sep 2002 23:20:14 +0200, Dominik Vogt wrote: On Thu, Sep 05, 2002 at 06:31:34PM +, Mikhael Goikhman wrote: 2) I was able to get a maximize button to become `stuck', in the sense that every thing I clicked would be toggle maximised -- not even just the window that the button belonged to! Clicking on the root window would make it look like everything was normal, but as soon as the mouse was even moved the original ``sticky button'' would display it's ActiveDown mini-icon again. Even killing the program which the sticky button window belonged to (via another console) did not resolve the problem: the skeleton of it remained on the screen. Only killing X could stop it. I was able to invoke this feature twice, but did not spend a long time working out exactly what magic sequence was needed. I think it involves the window being resized by itself, and/or moved by itself prior to clicking the button. Would you like me to try to find a more definitive sequence of events, or is somebody already onto this bug? This problem is not known. I don't quite understand what every thing I clicked would be toggle maximised means. Please post all ButtonStyle and other related lines. It's known to me and also caused by the event handling rewrite. If you are curious, press the maximize/shade/whatever button on a window, move the pointer out of the button and release it. Regardless of where you click now the action on the window button is triggered. Ok, I wondered whether this may be caused by my InactiveUp/InactiveDown enhancement. If a complex functions is bound (like in my case), nothing bad happens, but, yes, if some command is bound a very bad thing happens. A possible workaround for this may be to bind ComplexMaximize instead of Maximize: AddToFunc ComplexMaximize + C Maximize #+ H Nop # this cancels Maximize after some timeout Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: latest snapshot problems
On 05 Sep 2002 20:07:22 +0100, John Latham wrote: You would also see the Dominik's request not to use the today's cvs because it will crash. Actually today it only failes to compile, crashes are promised later. ;) Imagine a new feature (which might even be useful!) called ``PointerIsAMagicWand'' which when set would be given a function and would then apply that function to every window you clicked on. (I don't know how you could turn it off!) Anyway, the behaviour I was getting was as though I had asked for PointerIsAMagicWand Maximise 100 97 The button I originally pressed was bound to Maximise 100 97. This feature is easy to implement in 2.5.1+: # repeat command until escape is pressed or root window selected DestroyFunc RepeatUntilCanceled AddToFunc RepeatUntilCanceled + I Pick $* + I Cond (Error) Break + I RepeatUntilCanceled $* RepeatUntilCanceled Maximize 100 0 RepeatUntilCanceled UnshadeAndIconify But Pick is broken for some time now, so _currently_ RepeatUntilCanceled does nothing. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Changing titlebar buttons based on window state?
I have the following defined in my .fvwm2rc : Mouse 0 1 A Menu Window-Ops2 Close Mouse 0 2 A Close Mouse 0 4 A Maximize Mouse 0 6 A Iconify # lightning bolt - system menu ButtonStyle 1 8 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # x - Close ButtonStyle 2 17 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # downward triangle - minimize ButtonStyle 6 4 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # large square - maximize ButtonStyle 4 5 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # small square - restore #ButtonStyle 4 5 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] (swiped straight from the website and sample files, obviously) What I want to do is use the small square for button 4 if the window is fullscreen and the large square if it's neither fullscreen nor iconified. I feel certain this is in the man pages somewhere, but I've yet to come across it. I have no idea how to approach this. I'd still like to work on (which may or may not be doable) : * How to make windows resizable by dragging on the borders, in addition to the corner handles (and disabling moving via borders) * How to make a window truly maximize, rather than stop a few pixels short of fullscreen; a nice touch would be to make it _really_ maximize, with no border showing and no movement possible while maximized * How to either get FvwmTaskBar to swallow FvwmPager, or remove the border from FvwmPager (there is also some difficulty in getting focus to return to a window after using the pager) * How to remove the biff applet and clock from FvwmTaskBar * How to remove the title and geometry info from the WindowList menu but still have it pop up centered on the screen * How to prevent the menu selection from automatically following the mouse pointer and vice-versa * How to get vector buttons to appear in a different color than the titlebar * How to make the handles thicker than the border ...but I'll work on these personal preferences as time allows. :) Thanks for any advice on my first (real) question. Any input on the subsequent wish list is appreciated (particularly if something is known not possible). -- +-+ | Len Philpothttp://philpot.org/ | | [EMAIL PROTECTED] [EMAIL PROTECTED] (alt) | +-+ -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
