FVWM: WindowList in Popup?
I would like to use WindowList as a Popup submenu, but I'm having trouble getting it to work. If I do: AddToMenu foo "Window List" WindowList it works as expected, popping up the window list after I click on the label. I'd prefer that it pop up the list when I hover as Popup does, but when I set: AddToMenu foo "Window List" Popup WindowList I get the label and the Popup arrow, but it does not pop up the Window List. Does anyone know of a way to use the WindowList command as a Popup submenu? Thanks, Mark
Re: FVWM: Alt-Tab and WindowList
On Mon, Feb 15, 2021, at 9:55 AM, Mandar Mitra wrote: > The alternative you suggested won't help me, because I was looking to > address precisely the situation when I have a page "cluttered with many > windows, all atop each other". I'm going to take a low probability shot in the dark. Are you using ClickToFocus, or are you using MouseFocus(default)/FocusFollowsMouse/SloppyFocus? If it is NOT ClickToFocus, are you crossing the "clutter" transitioning the mouse between windows? Each window you cross will briefly have focus, so it will jump to the top of the list and unexpectedly push your "active" windows down. Mark
Re: FVWM: No module "FvwmTaskBar" in Fvwm 2.6.9?
On Wed, Aug 12, 2020, at 6:35 AM, Dr Rainer Woitok wrote: > - and most importantly it automatically hides. > > While I think I could also provide the buttons via module "FvwmButtons" > and could use a separate digital clock application, I did neither find > an "AutoHide" specification for "FvwmIconMan" nor for "FvwmButtons". > > And auto hiding of the taskbar is crucial for my various fullscreen app- > lications running each in a separate desktop page. > > Any suggestions? There is a template for how to autohide something in the faq on the fvwm website, towards the bottom of the list. Mark
Re: FVWM: Document mime type compliance?
On Sun, Jan 5, 2020, at 10:19 PM, Brian wrote: > A while back I added the following to my config. > > AddToMenu DOCMenu "Documents" Title > + MissingSubmenuFunction FuncFVWMMenuDIrectory > + "Documents" Popup /home/brian/Documents > > With the hope that it would pull up a llst of documents in my home > documents directory and then easily select a document > and open it. Well the function does pull up the list of > documents/directories and opens subdirectories and files, but all the > documents open in "vi" and not in the application designated by the > file extension type ie .pdf, .ods, .doc, or .jpg. You didn't include the definition of FuncFVWMMenuDIrectory or the (presumably) script it points at, which is what does the heavy lifting for MissingSubmenuFunction. Speculating wildly, if you are using fvwm_make_directory_menu.sh from the FVWM distribution in FuncFVWMMenuDIrectory, you are always getting vi because that is what fvwm_make_directory_menu.sh puts as the application to run for all non-directory files. If you want different actions based on the extension, you'll need to write a more sophisticated script that is extension aware to use in the place of fvwm_make_directory_menu.sh. Mark
Re: FVWM: Change window decoration mouse button mapping for just one app?
It appears from the manual page that you want: Style ThingIDontWantToClose !Button 2 (or whatever button # you have Close mapped to) Mark On Wed, Dec 11, 2019, at 7:01 AM, Tom Horsley wrote: > I'm trying to train myself to leave one specific app > running instead of clicking on the "close" button > in the window decorations. (There is a bug that > makes startup really slow). > > Can I make the close button binding not do a close > just for one app? (If I really want to close it, I can > use File->Exit). Or even make the close button simply > not be there at all just for one app? > >
FVWM: SnapAttraction ignore?
Is there a window style that can be set which causes all other windows to ignore the first window for the purposes of SnapAttraction? In other words, when I'm moving any other window I want that move to ignore a specific window that it moves near/over rather than snap to it. I tried setting "SnapAttraction 0" on the window I wanted to have ignored, but that didn't work. This, unsurprisingly, has the opposite effect from the one I desire (i.e. when the "SnapAttraction 0 window is in motion, it doesn't snap to any other windows.) Thanks, Mark
Re: FVWM: ResizeMoveMaximize bug or feature? and alternatives
On 2017-12-08 12:20, Thomas Adam wrote: Not a bug. This is fvwm respecting the window's gravity. Fair enough. Does FVWM have a config option to alter gravity? The only thing I saw matching gravity in the man page was UseGravity/IgnoreGravity, which are arguments to MoveByProgramMethod and don't appear to allow setting the gravity direction. Nothing matching a search for cardinal or ordinal directions (North, NorthWest, etc) looked promising either. I would be a very happy person if I could change gravity, as presumably that would also alter the tiling direction for new windows. (I'd prefer bottom to top for the same reasons I want to move the margin of my xterm) On 2017-12-08 12:51, Dominik Vogt wrote: The new position is calculated before cropping the window's size from 100% to a multiple of the character size. That's what I figured was happening, but it's nice to have it confirmed. If you follow up the ResizeMoveMaximize with a "Move -0 -0" it should be fine. That was my fallback plan (which worked as desired). I was hoping there was a way do it with just ResizeMoveMaximize. Mark
