Re: FVWM: backing windows off currentpage
> So how can I prevent the windows from being unmapped? If there > is no solution in X, is there a way in FVWM that I can trigger > a mapping without forcing a virtual page change? You can't, in general, even in principle. Unless your graphics card happens to have more memory than is needed to support the resolution and color-depth of your monitor, mapped == displayed.
Re: FVWM: Alarm/calendar applications that work well in fvwm?
> >> ... I want a reminder, say, seven days before and then > >> a repeating reminder until I tell the reminder program > >> I have done what it's reminding me about. > > > > iCal can do this. Mark an entry as a TODO, and it will > > keep coming back every day until checked off as done. > > POSIX, or MacOSX-specific? Certainly not MacOSX-specific, since I'm running it on Red Hat 9 Linux here at the office and I also run it on FreeBSD at home. I have no idea what, if anything, POSIX may have to say about the matter. There may be more than one calendar application claiming the same name. This one was written in Tcl/Tk by Sanjay Ghemawat <[EMAIL PROTECTED]> and was somewhat of an orphan as long ago as Red Hat 6.2 (which is where I first found it). BTW the FVWM list (and I think most other open-source help lists) prefers to keep discussions on the list, so that others who may have the same question, currently or when searching the archives in the future, can also find the answer.
Re: FVWM: I want to send in a question about something, and the mail registration system completely weirds me out.
> I'm behind a corporate Exchange Server which seems to have > changed recently to converting everything it sees to HTML. > > How embarrassing. I'm also behind a corporate Exchange Server, which I access using fetchmail (via ssl/imap) for incoming and nail (via smtp) for outgoing. It does not currently convert anything, but I seem to recall having had a similar problem a few years ago, following an "upgrade". It can be fixed, provided the server administrators are sufficiently motivated, but I have no clue what they had to do to get it to behave itself.
Re: FVWM: Alarm/calendar applications that work well in fvwm?
> > BTW the FVWM list (and I think most other open-source help > > lists) prefers to keep discussions on the list, so that others > > who may have the same question, currently or when searching > > the archives in the future, can also find the answer. > > Sorry, auto-typed the "N" response to Pine's "Reply to all?" > ... Don't suppose you know a way to make it by default reply to > the list when it's there, and to the sender only if it's not? I have no clue if it's possible to configure Pine that way, but maybe someone else on the list will know. (My experience with Pine consists of maybe half a day several years ago, just long enough to figure out that I prefer a POSIX-compliant mail client, such as nail :)
Re: FVWM: Alarm/calendar applications that work well in fvwm?
> I can't get tcl/tk(/c) ical to compile & run anymore ... [This is getting OT for FVWM, but I'm not aware of a support list for Sanjay Ghemawat's ical.] Which OS/version are you using? It works for me on Red Hat 9, RHEL4 (with a bit of tweaking), and FreeBSD 6.1. I haven't tried it on FreeBSD 7.0 yet.
Re: FVWM: Starting applications iconified.
> Is there a more efficient way to associate the StartIconic > style with a single Exec command? Dunno about StartIconic, but some apps (e.g. xterm) will accept a -iconic switch on the command line to start iconified.
Re: FVWM: Dragging not recognized anymore?
> Recently fvwm stoped recognizing dragging with the mouse most > of the time ... behaving as if I just clicked mouse instead of > holding the button pressed while moving it. > > Any ideas who is responsible for this and how to troubleshoot? ... > > It seems that selecting text shows same problem ... My first guess would be a worn-out switch in the mouse itself. Does it still behave the same way with a different one?
Re: FVWM: Off topic: Weather applet
> http://xoap.weather.com/weather/local//GMXX0109?dayf=5&unit=m). > However, since a while I can't get the current weather only the > forecast for 5 days ... I know nothing at all about xoap, but that "dayf=5" in the URL sure looks like a request for a 5-day forecast. Maybe visit the site with a browser, and see what kind of URLs are involved in retrieving current conditions?
Re: FVWM: Always place window inside desktop
> > Hello, is there a way to tell FVWM to always place windows > > inside the desktop, at least when the window size is less > > than the desktop size. > > Surely you mean s/less/greater/ here? I read the inquiry as requesting that, as long as the window (including decorations) will fit entirely within the desktop -- i.e. it is smaller than the desktop -- it should be placed entirely within the desktop, and not with parts of the decorations extending outside of the desktop and therefore invisible. I have the same complaint in 2.4.16, although to a much lesser degree: one of the windows belonging to one particular application invariably is placed something like 2 or 3 pixels too far up and to the right. I think the application is trying to put that window exactly in the upper right corner, but about half the thickness of the frame always ends up offscreen. > > Sometimes they are placed so that the titlebar is not visible, > > because it is above the visible desktop ...
Re: FVWM: Ban area for window placement
> > ... if I do a 'xwd -root |convert xwd:- png:screen.png' I get a > > 3040x1200 screen.png where the top right looks scrambled (see > > http://www.der-frank.org/tmp/sscreen.jpg [48kB]). However, xdpyinfo > > states, that I have "number of screens:1". Confusing. >^^^ > > That seems to be the problem. X.org does not tell fvwm the proper > geometry. How is this wrong? I thought the whole point of Xinerama was to combine two or more actual screens into a single virtual screen. Of course, if two screens of different height are joined left-right -- or different width joined top-bottom -- there's going to be a rectangle of the virtual screen that does not exist on either actual screen, hence the original question of how to tell FVWM to block out that area.
Re: FVWM: keys don't repeat
> >> I'm using fvwm 2.4.20 and when I hold down a key (whether > >> in an xterm or an rxvt) it doesn't repeat. > > > > in the xterm or rxvt type: > > > > xset r on > > > > If that works, put it in your .xinitrc. > > It works, thanks! > > Where in .xinitrc should I put "xset r on"? With my .xinitrc > like this... > #=== > exec /usr/bin/fvwm > xset r on > #=== > ...the "xset r on" doesn't seem to have an effect. > Nor does it work if I reverse the order of those two lines. It certainly won't do anything *after* the exec, because the exec says "replace the running shell with /usr/bin/fvwm" (so the rest of the script does not get executed at all). If it doesn't work when run in .xinitrc ahead of fvwm, I suppose you could try putting it in an InitFunction (or SessionInitFunction -- see the fvwm manpage for the difference) in your .fvwm2rc.
Re: FVWM: keys don't repeat
> ... "xset r on" doesn't work before "exec /usr/bin/fvwm" > either. Nor does it work if I put in in InitFunction *or* > SessionInitFunction, e.g. > > AddToFunc InitFunction >+ I xset r on >+ I exec xsetroot -mod 1 2 -fg cornflowerblue -bg sienna > > or > > AddToFunc SessionInitFunction > + I Nop > + I xset r on I suppose you could try StartFunction as Thomas Adam suggested, but I can't think of any reason why that would work when InitFunction or SessionInitFunction didn't. Another possibility is to put it in your shell's startup file (e.g. .bashrc or .cshrc), which will cause it to be run whenever you start up an xterm or rxvt that is running a shell, but in that case it should be inside a conditional so that it is not run if DISPLAY is not set (i.e. if the shell is *not* running in an xterm, rxvt, etc).
Re: FVWM: Some fvwm functions quitting after a bit
> From: chris_hons...@gmx.de > On Tuesday, 18. August 2009, Thomas Adam wrote: > > There's various reports of people complaining that with recent > > Xorgs, the keyboard mapping happens to "quickly", with FVWM > > realising a keyboard layout of "US" initially, but then the > > XServer changing it from under its feet -- effectively making > > any bindings void until FVWM is restarted (when it gets the > > correct keyboard layout). > > ;-) I know this very well. > I have written a patch that remaps the keybindings. But > as Thomas said, it's pretty ugly and I should not post it > anywhere. So I will not do. But if someone really wants > it - mail me and don't tell anybody ;) It sounds as if FVWM is more the victim than the cause of the problem. Does either of you have the expertise and inclination to write a patch _for Xorg_ that would keep it from initially reporting an incorrect keyboard layout?
Re: FVWM: initialmapcommand with restart
> The way I understand your request, you are asking for Fvwm > to un-minimize windows on a restart. That's the impression I got, also. > Fvwm is supposed to restore windows to their previous state > and position on a restart. Doing anything else is a bug. Perhaps the OP needs to put a command in RestartFunction to DeIconify all windows?
FVWM: raising an icon via the window list
Once in a while I lose track of an icon. I can find the window in the window list, but clicking it there -- with any of the 3 mouse buttons and with or without Ctrl, Alt, or Shift -- raises the window _and_ deiconifies it. Ordinarily this is what I want, but when I'm trying to track down a lost icon I really want to raise and warp to the icon while leaving the window iconified. How would I go about programming one of the mouse buttons to do this, without changing the behavior of the other buttons as would happen if I redefined WindowListFunc? FVWM version 2.4.16 compiled on Aug 12 2003 at 11:32:21 with support for: ReadLine, XPM, GNOME WM hints, Shape, SM, Xinerama
FVWM: colorsets not working as expected
I suspect there is something about colorsets that I don't understand. I am using fvwm 2.5.30 with Ubuntu 12.04. My ~/.fvwm/.fvwm2rc reads the stock Ubuntu system.fvwm2rc and then makes some adjustments. For the most part this works, but when I try to create a colorset 37 (which seems to be not otherwise defined or used), and then define a new xterm menu item using it, the window opened by the new item gets default colors instead of those defined by my "Colorset 37" directive. It does not seem to matter whether I define the new colorset before, or after, reading system.fvwm2rc -- it does not work either way. However, if I use one of the already-defined colorsets in the new menu item -- leaving the item definition otherwise identical -- I do get that colorset's colors; so it seems that the colorset references in the new menu item at least are correctly formatted. This is what I have in ~/.fvwm/.fvwm2rc -- the commented AddToMenu MenuFvwmShells being the one that results in default colors if I uncomment it and instead comment the one following it. --8<---cut here---start->8--- Read /etc/X11/fvwm/system.fvwm2rc Colorset 37 fg white, bg 80/00/00, Plain, NoShape *FvwmButtons: Geometry 200x90-0-54 *FvwmIconMan: ManagerGeometry 2x0-210-54 AddToMenu MenuFvwmUtilities "Calendar%menu/clock.xpm%" Exec exec ical AddToMenu MenuFvwmUtilities "Monitor Setup" Exec exec gnome-display-properties AddToMenu MenuFvwmWebBrowsers "Firefox" Exec exec firefox #AddToMenu MenuFvwmShells "&Unlogged $[gt.default]%menu/terminal-remote.xpm%" Exec export SCRIPT_LOGFILE=/dev/null && exec xterm -fg $[fg.cs37] -bg $[bg.cs37] AddToMenu MenuFvwmShells "&Unlogged $[gt.default]%menu/terminal-remote.xpm%" Exec export SCRIPT_LOGFILE=/dev/null && exec xterm -fg $[fg.cs32] -bg $[bg.cs32] Style * IconBox -210 0 -0 -154, IconGrid 1 1, IconFill right bottom # redefine without font changes DestroyFunc FuncFvwmRunInXterm AddToFunc FuncFvwmRunInXterm + I exec xterm -fg $[fg.cs34] -bg $[bg.cs34] -T "$0" -n "$0" -e $1 # initial apps Exec exec xterm -fg $[fg.cs30] -bg $[bg.cs30] Exec sh -c "sleep 1 && exec ical -iconic" # wait a while for screen to get set up before enabling Xinerama support # (else Buttons, IconMan, and the initial apps land on the wrong screen) FuncFvwmRestartModule FvwmCommandS PipeRead '( ( sleep 3 ; FvwmCommand "Xinerama True" ) & ) 1>&2' --8<---cut here---end--->8--- At over 170KB the system.fvwm2rc is too large to post in its entirety, but these excerpts show its Colorset definitions and the definition of MenuFvwmShells --8<---cut here---start->8--- Colorset 0 fg black, bg rgb:70/a0/a0 Colorset 1 VGradient 40 2 rgb:88/7b/66 1 rgb:66/5c/4c 1 rgb:88/7b/66, \ bg AliceBlue, fg gray80, fgAlpha 85, NoShape Colorset 2 VGradient 40 2 rgb:cc/b8/9a 1 rgb:99/8a/7b 1 rgb:cc/b8/9a, \ bg AliceBlue, fg white, NoShape Colorset 3 fg black, bg rgb:88/7b/66, Plain, NoShape Colorset 4 fg black, bg rgb:cc/B8/9a, Plain, NoShape Colorset 5 fg white, HGradient 40 rgb:51/6c/90 rgb:3f/54/70, bg Linen, NoShape Colorset 6 fg white, bg rgb:63/84/b0, Plain, NoShape Colorset 7 fg grey45, bg grey45, Plain, NoShape Colorset 10 fg black, bg rgb:80/A0/A0, Plain, NoShape Colorset 11 fg black, bg white, Plain, NoShape Colorset 12 fg black, bg rgb:80/A0/A0, \ VGradient 20 rgb:80/A0/A0 rgb:C0/F0/F0, NoShape Colorset 13 fg black, bg rgb:70/8C/8C, hi black, sh gray40, \ Plain, NoShape Colorset 14 fg black, bg rgb:80/A0/A0, Plain, NoShape Colorset 15 fg black, bg rgb:C0/F0/F0, Plain, NoShape Colorset 16 fg black, bg rgb:F0/F0/C0, Plain, NoShape Colorset 17 fg black, bg rgb:80/A0/A0, Plain, NoShape Colorset 18 fg black, bg rgb:A0/C8/C8, Plain, NoShape Colorset 19 fg white, bg rgb:60/78/78, Plain, NoShape Colorset 20 fg black, bg rgb:88/AA/AA, Plain, NoShape Colorset 21 fg black, bg bisque, Plain, NoShape Colorset 22 fg white, bg rgb:00/30/60, Plain, NoShape Colorset 30 fg white, bg rgb:00/00/50, Plain, NoShape Colorset 31 fg white, bg rgb:00/50/50, Plain, NoShape Colorset 32 fg white, bg rgb:50/00/00, Plain, NoShape Colorset 33 fg white, bg rgb:00/50/00, Plain, NoShape Colorset 34 fg rgb:FF/FF/E8, bg rgb:30/48/48, Plain, NoShape Colorset 35 fg black, bg rgb:80/A0/80, Plain, NoShape Colorset 36 fg black, bg rgb:A0/C8/A0, Plain, NoShape --8<---cut here---end--->8--- --8<---cut here---start->8--- DestroyMenu MenuFvwmShells AddToMenu MenuFvwmShells "$[gt.Terminals]" Title + "&Xterm $[gt.default]%menu/terminal.xpm%" Exec exec xterm -fg $[fg.cs30] -bg $[bg.cs30] + "Xterm/r&oot $[gt.default]%menu/terminal-special.xpm%" Exec exec xterm -fg $[fg.cs31] -bg $[bg.cs31] -e su -l + "&Rxvt$[gt.default]%menu/terminal.xpm%" Exec exec rxvt -fg $[fg.cs30] -bg $[bg.cs30] + "&Eterm $[gt.default]%menu/terminal.xpm%" Exec exec Eterm + "
