Re: FVWM: Quoting of style name with quotes - do I need them?
On Wed, Jan 22, 2014 at 4:14 PM, Oleksandr Gavenko wrote:
> The only thing that surprise me that fvwm-mode doesn't released to any of
> Emacs package repositories:
>
> (setq package-archives '(("ELPA" . "http://tromey.com/elpa/";)
>("gnu" . "http://elpa.gnu.org/packages/";)
>("marmalade" .
> "http://marmalade-repo.org/packages/";)
>("melpa" . "http://melpa.milkbox.net/packages/";)
> ))
>
I just submitted fvwm-mode to melpa. Should be there soon.
--
Thanks,
Jonathan Kotta
Hofstadter's Law:
It always takes longer than you expect, even
when you take into account Hofstadter's Law.
Re: FVWM: Paging behavior changed from fvwm version 2.5.26 to 2.5.28
On Tue, Jun 22, 2010 at 1:54 AM, halfdog wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thanks for your tips, Jaimos and Thomas, I did not know that the fvwm packages > work across various ubuntu versions and that there is no additional > ubuntu-magic > compiled in. I had just to add the libreadline5 before the old dpkg could be > installed. The result was, that the same problem was also reproducible with > 2.5.26 on lucid. > > I dug a little deeper to find the differences in the jaunty/lucid setups. It > seems that xserver modules cause this strange behavior. With these changes, > the > paging on lucid works like before: > > Section "ServerFlags" > Option "AutoAddDevices" "false" > EndSection > > Section "InputDevice" > Identifier "GenericMouse" > Driver "mouse" > Option "Protocol" "auto" > Option "SendCoreEvents" "true" > EndSection > > > It seems, that the xserver on lucid automatically adds evdev mouse/keyboard, > that interfere with the paging behavior. By blocking the autodevices and > creating an old-style mouse, the setup works as expected. > > Thanks, > hd > > - -- > http://www.halfdog.net/ > PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkwgXgMACgkQxFmThv7tq+5msQCggBBBXueRwGOCFJ+9sU10evHH > flgAoIPkhc25WpRFEE1RrIhS9FNUVhOj > =1VwU > -END PGP SIGNATURE- > > It probably doesn't have anything to do with your problem directly, but maybe I should mention that I too had trouble going from Ubuntu 9.04 to 9.10 (and later). I have a mechanism in Fvwm to automatically flip focus when switching pages or closing windows. While this autofocusing itself had no trouble, it had some bad interactions with a couple of special case windows whose focusing I want to work differently. AFAIK, this was caused by changes to X, because I tried several different versions of Fvwm and Ubuntu and only changing the OS would cause the problem. I fixed it by modifying my Fvwm config. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: window buttons and button-focus
On Mon, Mar 29, 2010 at 4:04 AM, Thomas Adam wrote: > On 29 March 2010 09:47, JUNG, Christian wrote: >> I've tried to use a function like that: >> >> DestroyFunc CloseWindow >> AddToFunc CloseWindow >> + C Close >> >> Mouse 1 2 A Function CloseWindow >> >> But this does not work exactly the way I would like to. >> >> I do not know if this is maybe a bug, but shouldn't the >> function be triggered only if the mouse pointer is over >> the button and the mouse key depressed? On buttons (e.g. >> FvwmForms) this works as I'd like. >> >> Does anyone has a solution for this? > > The pointer is grabbed at the time the function is invoked, and as > such the action would apply regardless. FVWM has no way of knowing > where the mouse is to correctly invoke the function as you're wanting > it. > > -- Thomas Adam > > You can cancel the action by pressing escape before releasing the mouse button. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: sticky pidgin
On Sat, Feb 27, 2010 at 5:50 PM, Thomas Adam wrote: > On Fri, Aug 28, 2009 at 07:06:05PM -0500, Jonathan Kotta wrote: >> I have the style 'Style "Buddy List" Sticky' to make Pidgin's buddy >> list window sticky. It used to work, but it hasn't for many months (I >> rarely restart, so it doesn't bother me much, but today it did). I >> can reproduce this with a minimal config (e.g. just the above Style >> command). So I started an FvwmEvent to run the following function on >> add_window events: > > [ Coming back to this rather later than I planned to...] > > What's the status of this, Jonathan? Does it still happen? Can you verify > this using the CVS version of FVWM with the same version of pidgin you > mentioned? > > -- Thomas Adam > > -- > "It was the cruelest game I've ever played and it's played inside my head." > -- "Hush The Warmth", Gorky's Zygotic Mynci. > Sorry for not reporting back earlier. I installed Pidgin 2.6.5 and the problem went away (still on FVWM 2.5.28). I just installed Fvwm 2010-03-03 snapshot and there's no problem. The version with the problem was 2.5.5 from Ubuntu. I don't really feel like downgrading it. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: x2x and x2vnc
On Fri, Jan 15, 2010 at 4:46 AM, Craig <4gq7nrk...@sneakemail.com> wrote: > On Fri, 15 Jan 2010 10:27:38 +, "Thomas Adam" > said: >> 2010/1/15 Craig <4gq7nrk...@sneakemail.com>: >> > Sometimes, if a window is at the edge of the screen, it prevents x2x >> > from moving control to another other computer. Same problem with x2vnc. >> > >> > I tried adding these lines to my config, yet the problem still occurs. >> > >> > EdgeThickness 0 >> > Style x2x* Sticky, StaysOnTop >> > Style x2vnc* Sticky, StaysOnTop >> > >> > This problem does not occur until some time after fvwm is restarted, and >> > I have yet to determine exactly when it does. >> >> What makes you think this has anything to do with FVWM, out of interest? >> >> -- Thomas Adam > > I have used x2x and x2vnc with the desktop environments xfce and lxde > with no problems. Only when I replaced opebox with fvwm within lxde did > the problems begin. > > I have noticed one way to cause the problem is to press CTRL-S in > firefox, that pops up a "Save as" dialog window. The problem continues > until I restart fvwm. > > -- > Craig > > x2x works much better for me when I use the -resurface option. , | -resurface | | Ugly hack to work-around window manager ugliness. The | -north, -south, -east and -west modes actually put a small | window on the side of the "from" display. This option | causes this window to resurface itself if another window | ever obscures it. This option can cause really nasty | behavior if another application tries to do the same thing. | Useful for login scripts. ` -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Autofocus on matlab windows
On Wed, Nov 25, 2009 at 12:08 PM, wrote: > math...@iup.physik.uni-bremen.de writes: > >> Dear all, I use fvwm under debian : >> >> fvwm -V >> fvwm 2.5.28 (from cvs) compiled on Aug 17 2009 at 22:43:46 >> with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, >> Bidi text, Xinerama, XRender, XCursor, XFT, NLS >> >> I haevily use matlab and have the very annoying feature, >> that every time a figure (coming in an own window) is adressed >> this window gets the focus. >> I already searched the web and found three solutions, none of which worked: > > This appears to be a very old issue, check here: > > http://www.mail-archive.com/fvwm-work...@lists.math.uh.edu/msg00373.html > > I don't know if this was ever resolved but you might want to check > with Matlab. > > IIRC, Matlab uses Java in some places. I have the following in my config for some misbehaving Java apps: # java apps think they should handle focusing, but do a terrible job # this lets FVWM control focusing Style sun-awt-X11-* Lenience # same with Wine Style Wine Lenience You may want to verify that the figure windows match with FvwmIdent. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Resize br
On Sat, Nov 21, 2009 at 5:37 PM, Thomas Adam wrote: > 2009/11/21 Jonathan Kotta : >> First, it seems like the "units" are not always consistent for a given >> window. For pixel-based windows, it seems to work OK, in the sense I >> can apply the binds an equal number of times, and I don't make the >> window too small, I get back to exactly the same size. For >> character-based windows (terminals), they usually get smaller, more so >> in the y direction. Example: an xterm starts at 211x76, after -5c,-5c >> it's 189x72, and after +5c,+5c it's 210x75. > > Yes, this is always intentional, AFAIK. > >From the man page: With a ’c’ suffix the unit defined by the client application (hence the c) is used. So you can say Resize 80c 24c to make a terminal window just big enough for 80x24 characters. So it makes it sound like for a given window, the unit doesn't change. Is the method of finding the unit inherently unreliable? This problem happens with different applications, so it seems to me like it's not (completely) an application problem. >> The second problem is when resizing an OpenOffice window, it moves >> *both* the top left and bottom right corners. > > This is likely due to the window not having a WindowGravity of NorthWest. Indeed, it's not. Is there any way to change that? I tried MoveByProgramMethod because it's the only thing in the man page with a mention of "gravity", but it didn't change anything. > > -- Thomas Adam > -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
FVWM: Resize br
I have the following bindings: # these resize the window by moving the SW corner by 5 "units" at a time Mouse 4 T N Resize br w+5c w+5c Mouse 5 T N Resize br w-5c w-5c They let me resize by rolling the mouse wheel on the titlebar. My intention is that they are inverses of each other. I have two problems with them. First, it seems like the "units" are not always consistent for a given window. For pixel-based windows, it seems to work OK, in the sense I can apply the binds an equal number of times, and I don't make the window too small, I get back to exactly the same size. For character-based windows (terminals), they usually get smaller, more so in the y direction. Example: an xterm starts at 211x76, after -5c,-5c it's 189x72, and after +5c,+5c it's 210x75. The second problem is when resizing an OpenOffice window, it moves *both* the top left and bottom right corners. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Tutorial
On Thu, Sep 17, 2009 at 7:00 AM, Michael Kirsch wrote: > On Wed, Sep 16, 2009 at 08:51:22PM +0100, Thomas Adam wrote: >> 2009/9/16 Michael Kirsch : >> > I was wondering if you know of a good fvwm tutorial somewhere online, >> > I can't seem to really find anything useful. >> >> There's this but it's old now and needs a lot of updating to bring it >> inline with current development: >> >> http://www.zensites.net/fvwm/guide/ >> >> -- Thomas Adam > > I'm still not too worried about fvwmrc, but about how to get rid of GNOME and > Metacity while it's running (I have Fedora 11). > > > It sounds like you want to run Fvwm instead of Gnome, rather than within Gnome. You should make a ~/.xinitrc script (it's just a shell script) and add a line to run fvwm. It is important to make fvwm block execution of the script, i.e. don't do it with "fvwm &". Then you can start fvwm by running "startx" at the linux console. If you symlink ~/.xinitrc to ~/.xsession, your display manager (e.g. kdm, gdm) should run that if you choose "alternate session" or something similar. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: again (semi-transparent) pseudo-cursors
On Fri, Sep 4, 2009 at 12:23 PM, Thomas Adam wrote: > 2009/9/4 Lucio Chiappetti : >> However until I do not click again to terminate the move, any keyboard >> action (e.g. to advance slides) is inhibited. > > Obviously -- the pointer is grabbed at the point for the duration of > that function. > >> Is dynamic changement of icon supported by fvwm ? > > Depends; you can reissue CursorStyle commands and Style commands as > often as you like. > > -- Thomas Adam > > Not exactly what you are looking for, but have a look at gromit. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
FVWM: sticky pidgin
I have the style 'Style "Buddy List" Sticky' to make Pidgin's buddy list window sticky. It used to work, but it hasn't for many months (I rarely restart, so it doesn't bother me much, but today it did). I can reproduce this with a minimal config (e.g. just the above Style command). So I started an FvwmEvent to run the following function on add_window events: DestroyFunc Stickify AddToFunc Stickify + I Schedule 25 WindowId $0 Stick True With a schedule delay of 10 it never works, and with 30 it always works, with the probability of success increasing fairly smoothly for delays in between (these numbers assume that pidgin is in the disk cache). So there's some sort of race condition going on. Any ideas? I hate using FvwmEvent to set styles. BTW, I set other styles, and all but Sticky get applied: Style "Buddy List" \ FixedPosition, FixedSize, \ CirculateSkip, WindowListSkip, \ Sticky, !Iconifiable, \ NeverFocus $ fvwm --version fvwm 2.5.27 compiled on May 3 2009 at 17:52:18 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Xinerama, XRender, XCursor, XFT, NLS $ /usr/bin/pidgin --version Pidgin 2.5.5 -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Conditionally selecting windows on another page.
On Mon, Aug 17, 2009 at 12:48 PM, Thomas Adam wrote: > 2009/8/16 : >> >> Hi.. >> >> I've written a function to swap the windowson one screen with the >> windows on another screen in a xinerama setup. It works, but its not >> ideal >> >> DestroyFunc SwapScreens >> AddToFunc SwapScreens >> + I All (CurrentPage) MoveToPage 9 0 >> + I GotoPage 9 0 >> + I All (CurrentPage) PipeRead "$[HOME]/.fvwm/MoveToScreenAndWarp.sh $[w.x]" >> + I GotoPage 0 0 >> + I All (CurrentPage, AnyScreen) PipeRead >> "$[HOME]/.fvwm/MoveToScreenAndWarp.sh $[w.x]" >> + I GotoPage 9 0 >> + I All (CurrentPage, AnyScreen) MoveToPage 0 0 >> + I GotoPage 0 0 >> >> So I move windows to page (9,0) as a holding place. What I'd like to do >> is reference the windows on page 9 0 instead of having to goto that >> page. Will reduce flicker of the goto's and make it appear more >> seamless. Is this possible with a regular function? > > Yes, but you can't do it they way you'd like. I would just mark those > windows you're going to put on page 9 0 with a State, then you can do: > > All (State n) MoveToScreen > > Read up on the "State" command/style option. > >> Something like: >> >> + I All (Page 9 0, AnyScreen) MoveToPage 0 0 > > No, this isn't possible. > > -- Thomas Adam > > I thought this was a neat idea for a function, so I implemented it. SetEnv SWAP_SCREENS_STATE 3 DestroyFunc SwapScreens AddToFunc SwapScreens + I SetEnv old_pointer_x $[pointer.x] + I SetEnv old_pointer_y $[pointer.y] + I All State $[SWAP_SCREENS_STATE] off + I WindowId root $[LEFT_SCREEN] WarpToWindow 50 50 + I All (CurrentPage) State $[SWAP_SCREENS_STATE] on + I All (State $[SWAP_SCREENS_STATE]) MoveToScreen $[RIGHT_SCREEN] + I All (CurrentPage, AnyScreen, !State $[SWAP_SCREENS_STATE]) \ MoveToScreen $[LEFT_SCREEN] + I WindowId root WarpToWindow $[old_pointer_x]p $[old_pointer_y]p + I UnSetEnv old_pointer_x + I UnSetEnv old_pointer_y Key Up A 4C SwapScreens -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Show window content on "Move"
On Thu, Jul 30, 2009 at 2:51 PM, Harold Pimentel wrote: > Hi all, > > Can someone show me a key binding that will show the window content while I > "move" it, not just the outline? I also want the key binding to allow me to > hold the click button on my mouse down while i hold meta, and as soon as i > let go of the click button, it releases the window. > > I basically want to emulate Gnome behavior. > > Currently I have: > > Mouse 1 WTSFI1357924680 M Move > > Which does none of these. > > > Thanks, > > Harold > > > > > You need to bind to a function with Move as the "move action" or "immediate action". DestroyFunc MyMove AddToFunc MyMove + M Move Mouse 1 W M MyMove I use this function for a binding similar to yours: DestroyFunc MoveOrMaximize AddToFunc MoveOrMaximize + I Raise + M Move + D ThisWindow (Iconic) Maximize True + D TestRc (NoMatch) Maximize 100 100 + D Iconify False -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
FVWM: MoveToScreen changes to current page
MoveToScreen seems to always move the window to the current page. I can't move a window from one screen to another without putting it on the current page (and desk). This is with an empty config file. $ fvwm -V fvwm 2.5.27 compiled on Mar 9 2009 at 10:06:25 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Xinerama, XRender, XCursor, XFT, NLS -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Fvwm and pulseaudio
On 12/2/08, Dan Espen <[EMAIL PROTECTED]> wrote: > > I'm hoping someone on this list has encountered this. > > Recent distros are now defaulting to using pulseaudio. > > I just installed FC9 and I find sound works under Gnome but > not under Fvwm. I can see Gnome starts up a pulseaudio process > but launching that process from the command line under Fvwm doesn't > make sound start working. > > I start Fvwm from a .xinitrc file. > > Does anyone know what the command is to correctly start the > pulseaudio process for a user? > > > In my InitFunction, I have Exec pulseaudio --kill ; pulseaudio -D There is no reason why it couldn't be in ~/.xinitrc though. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: FvwmPager and Xinerama mode
I have a big pager across the top of my screen(s) and a little pager in the upper right corner. The big pager gets auto-hidden, that's why it's slightly off the screen. I use the DesktopScale parameter to set the size. LEFT_SCREEN and RIGHT_SCREEN are host-dependent variables. *DesktopPager: Geometry [EMAIL PROTECTED] *DesktopMiniPager: Geometry [EMAIL PROTECTED] On 10/29/08, Hans Voss <[EMAIL PROTECTED]> wrote: > It's been a while since I used Xinerma mode with FVWM. (My new laptop > (or ubuntu) doesn't properly manage it). > > I believe I just put two Pagers on screen (one on each screen) using a > seperate pager specification. > > > On Wed, Oct 29, 2008 at 09:38, Harald Dunkel <[EMAIL PROTECTED]> wrote: > > Hi folks, > > > > Maybe a stupid question (hopefully not): > > > > On a Xinerama display FvwmPager just shows the global screens. > > AFAICS it does not recognize (or care about) Xinerama at all. > > Thats fine with me. But using > > > >*FvwmPagerGeometry x90-0-0 > > > > the pager window is put into the bottom right corner of the > > top left screen instead of the global screen. This is > > different to other XWindow applications. "xterm -geometry -0-0" > > works as expected on the global screen. > > > > How can I tell FvwmPager to be put on the bottom right corner > > of the global display (independent of the screen size and > > the number of screens, of course)? > > > > > > Regards > > > > Harri > > > > > > > > > > > -- > > Met vriendelijke groeten / With kind regards > Hans Voss > --- > * Infrastructure Architect > * Open Source, Networking and Security > * General Open Sourcerer > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > * My blog: http://jazzterdaily.blogspot.com - Tech and other news that > caught my attention. > * Google Reader: My shared News feed: > > https://www.google.com/reader/public/atom/user/02723796534474865919/state/com.google/broadcast > * Linked In page: http://www.linkedin.com/in/hansvoss > * google talk enabled > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Pick multiple windows in one function
On 10/8/08, Tom Alsberg <[EMAIL PROTECTED]> wrote: > Hello, people. > > A little question - I have long not touched my FVWM configuration or kept > myself updated with development/list, and now only done some basic research > by looking at parts that seemed relevant in the man page and searching the > mailing list, so I may be missing the answer somewhere: > > I want to add a function that arranges a set of windows I pick in some > predetermined positions. For one window I can just put a function with > something like "+ I Pick Move 42p 365p" in it, which when executed will let > me choose a window to place at that position. > However by nature of the way Pick works (checking for a window context > first), if I put more than one such line in a function, I only get to pick > one window and all Move commands will operate on it. How can I make the > function "forget" the window context after picking so that another window > can be picked, or somehow combine several such functions in one? > > Suggestions appreciated, > -- Tom > > -- > Tom Alsberg - certified insane, complete illiterate. > Homepage: http://www.cs.huji.ac.il/~alsbergt/ > * An idea is not responsible for the people who believe in it. > > I think this is what you want. I find it very useful. # this will let you keep picking windows until you click on root or hit ESC DestroyFunc PickAgain AddToFunc PickAgain + I Pick $* + I PipeRead "test $[func.context] = r && echo 'PickAgain $*'" -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: How to use use the xvkbd(Virtual Keyboard for X Window System) with touchscree
On 10/3/08, qingping XI <[EMAIL PROTECTED]> wrote: > Hi all, > > The xvkbd send the key message to the focused window. > > There are three windows: > WIN_A: The window I want to input through xvkbd. > WIN_B: The window of xvkbd. > WIN_C: The window I do not want to input. > > I focus the WIN_A, after that a tip a key, and xvkbd can send the key > to the WIN_A. > But after that, the WIN_B(xvkbd) is the focused window. > > If I want to input another key, I must focus the WIN_A again manually. > > How can I config the xvkbd(WIN_B), when I tip a key, then the > WIN_A(not WIN_B or WIN_C) can focused again automatic. > > Thanks a lot. > > -- > Regards! > >XI Qingping > > I assume you want xvkbd to never have keyboard focus. Try this: Style xvkbd NeverFocus I installed xvkbd to see if it happens for me, and xvkbd never gets the keyboard focus, even without the above Style definition. I use ClickToFocus as my main focus policy. -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: PlaceAgain Anim Warp
You could use the $[pointer.wx] and $[pointer.wy] variables. I'm not sure if there's a cleaner way. It's kind of messy when the pointer wasn't inside the window in the first place. DestroyFunc PlaceAgainAnimAndWarp AddToFunc PlaceAgainAnimAndWarp + I SetEnv tmpx $[pointer.wx] + I SetEnv tmpy $[pointer.wy] + I PlaceAgain Anim + I WarpToWindow $[tmpx]p $[tmpy]p + I UnSetEnv tmpx + I UnSetEnv tmpy On 3/17/08, Tim Connors <[EMAIL PROTECTED]> wrote: > > In the style of AnimatedMove x y [Warp], I wish to be able to bind CMS F3 > in my case to Placeagain Anim, to move the window to a more convenient > location, but have the cursor follow that window. > > I can almost fake it with: > > AddToFunc "PlaceAgainAnimAndWarp" "I" PlaceAgain Anim > + "I" WarpToWindow 20 20 > Key F3 A CMS PlaceAgainAnimAndWarp > > But, I'd rather the mouse didn't deviate from the original location in the > window at all. > > Any thoughts? > > -- > > Tim Connors > > > -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: FVWM: Add button 8 on title bar, press to "always on top" or cancel
On 3/6/08, Thomas Adam <[EMAIL PROTECTED]> wrote: > I often get asked why I don't use Current in place of ThisWindow. The > answer is simple: I use this function from FvwmEvent, where it's not > guaranteed the window in question will have focus. > > It's a really popular question at the moment; I've probably answered > it about six times this month. > > I remember being confused about this when I started using FVWM. Perhaps "Current" should be aliased to something like "Focused" or "FocusedWindow"? -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
FVWM: antialiased fonts
I recently switched distros and I've lost antialiased fonts in fvwm. In my previous distro, I had to enable them manually. I think I added stuff to /etc/fonts/local.conf, but I can't remember for sure because I didn't write it down (stupid). Anyway, I know that I'm using xft fonts in FVWM, and I know that antialiasing is working in other apps. Here's what I've tried so far: added antialias stuff to /etc/fonts/local.conf: true made a ~/.fonts.conf (with same stuff as above) tried antialias=true in FVWM font specification I appologize for not searching the archives, but they haven't been working for me for the past few days (searches fail, links are broken, etc.). Thanks, jpkotta
