Re: FVWM: sticky windows on given display
On Wed, Apr 06, 2022 at 09:47:58AM +0200, Martin Cermak wrote: > there's one manual step I'd like to automate with fvwm: I'd like > to make all windows that are created or moved to given physical > display - sticky. > > For now I've partially automated that based on the window name, > but I'd love to base this on the display where the window is > shown rather than on the window name. > > Is there a reasonable way of doing this? How? You can make a wrapper move function and use that instead of the move command: addtofunc moveandstick + i move $* + i all ... stick on Replace the "..." with a condition that matches all windows that are supposed to become sticky. Then replace all "move" calls in the config with "moveandstick". Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: sticky windows on given display
On Wed, Apr 06, 2022 at 02:13:38PM -0500, Brian A wrote: > Hi, I'd love to do the same with gkrellm, except I'd also like it to > always remain on top also. Right now it often ends up hidden under my > right panel, since I like to place it in the lower right. Today, each > time I start FVWM, I have to manually click on the gkrellm window and > then set it to "StaysOnTop". There must be a way to specify in > .fvwm/config Start Function area the "StaysOnTop" parameter? > right now the line is > + I Test (Init) Schedule 8000 Exec gkrellm > > is it as easy as > > + I Test (Init) Schedule 8000 Exec gkrellm StaysOnTop Style ... staysontop Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: debugging strange behaviour
On Fri, Mar 11, 2022 at 12:39:03PM +, Nacho wrote: > [fvwm][CMD_InfoStore]: <> Bad arguments given. Double check the uses in your config file to find the reason for the message. In general the message means that the infostore command was called with fewer than two arguments, or the assigned value is an empty string. This is a bit clumsy, but it's how the command works. > But as it doesn't say which were the arguments in the first place or at which > line in the config file the error happens, it's hard to locate the problem. Add echo commands that print the call and the arguments before each infostore command. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: (sd-pam) process not killed on Quit
On Mon, Feb 21, 2022 at 09:33:21AM -0300, Hernán Gustavo Solari wrote: > I am an old fan of fvwm (I started with the old twm decades ago). > I run fvwm2 without a desktop-manager. The xsession launched by > lightdm on a Debian 5.10.84-1 system. > > Problem: an authentication module (sd-pam) is lauched at login for > every user. It should be killed on exit. But it is not. It is very > noticeable since at shutdown the machine spends 2 minutes trying to > stop the job (it indicates systemd --user is waiting for a job to > stop). That sounds like a systemd problem. You should investigate why the module does not stop and ask the systemd folks for help. > (I have a second debian system in another machine that is not showing > the problem so far) > > The (sd-pam) job is not responding to the SIGTERM signal. But when it > receives the SIGUP signal quits!! > > I added an exit option > + "KillAll and roughQuit" Exec /usr/bin/killall -s 1 -u ME > > Sending a SIGUP instead of SIGTERM is odd, but it works fine. > What is the fvwm Quit function actually doing? That depends on the actual function. How does it look like? > Does it send a SIGTERM to every job as I imagine? Fvwm doesn't have a built in "quit" function. If there is one, it's either in your private config or came with the desktop environment or some other setup. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm focus change causes vim to leave insert mode
On Tue, Jul 27, 2021 at 12:28:42PM -0400, John Sellens wrote: > Why did I think this was fvwm related? I think xterm only gets these events > with a suitably modern window manager. The windowmanager cannot intercept these events, but the exact sequence of events depends on how windows are managed internally. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm focus change causes vim to leave insert mode
On Thu, Jul 22, 2021 at 03:34:56PM -0400, John Sellens wrote: > When I have the vim editor open in an xterm window, in insert mode, > and move my mouse (and focus) into another window, the vim in the > original window receives some sort of escape sequence that causes > it to leave insert mode and beep. > I can't figure out what's happening or why, or how to prevent it. > > Anyone have any hints? Try to attach the "xev" program to the xterm. It creates an awful lot of output, but that should contain some indication of what's happening. You can also post the relevant part of the output to the list. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Interview fvwm developers
On Wed, Jul 07, 2021 at 09:43:10PM +0100, Thomas Adam wrote: > On Mon, Jun 28, 2021 at 06:53:05PM +0200, Keywan Tonekaboni wrote: > > I'm looking for an interview with one of the developers of the early > > days. If you could help me, how to contact Robert Nation, Chuck Hines or > > somebody else, that would be great. > > How far back is "early days"? I am sure Dan Espen and Dominik Vogt would > qualify! > They're still lurking round these parts somewhere, I do hope! Sure I am. :) > As for Robert Nation, I contacted him a few years ago via LinkedIn. Chuck > hasn't been seen on this list in several years, AFAIK. Since 2005 I haven't talked to Rob and Chuck. The resulting discussion is on our history page. https://www.fvwm.org/Wiki/FvwmHistory/ > I am sure those who qualify will see this email and reply in due course. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mouse
On Mon, Mar 15, 2021 at 01:38:56PM +0100, Klaus Altmann wrote: > how can I change the size, shape, or color of the mouse pointer? i mean this > little black arrow which is to tiny for my eyes... I have this in $HOME/.Xresources: Xcursor.size: 64 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Move windows to a new desk preserving pages
On Mon, Mar 01, 2021 at 01:40:17PM +, Ethan Raynor wrote: > hi Dominik, > > On Mon, Mar 1, 2021 at 9:45 AM Dominik Vogt wrote: > > What is the actual use case for this? > > i quite often find myself wanting to move windows between desks to > suit my workflow. what i would like is the ability to move windows as > they are on desk X to screen Y without them losing which page they are > on. so for example when i do this: > > all (desk 2) movetoscreen > > this does move all the windows on desk2 to the current screen but i > would ideally like those windows on desk2 to also keep the page they > are on. currently the above command moves all windows on desk 2 to the > current page on the screen i run it from - i don't want this. Can you please be more precise? You're mixing the terms page, desk and screen which are all differet things. Could you give an example of the workflow? It's hard for me to imagine what you're actually doig that could require to move all windows from oe desktop (page?) to another. Why is it not good enough to make the windows on desk 1 sticky? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Move windows to a new desk preserving pages
On Mon, Mar 01, 2021 at 12:31:19AM +, Ethan Raynor wrote: > I'm trying to understand how I can move all windows from desk X to > desk Y without losing where the windows on desk X are in terms of > their pages. > > I know I can do something like: > > All (Desk 1) MoveToDesk 2 > > But all this does is take every window on desk 1 (regardless of page) > and move those windows to desk 2. > > How can I essentially "mirror" the windows on desk 1 so they are in > the same position/page on desk 2? Fvwm allows windows to be present on a single desk or on all desk, but not a selection of desks. The closest you can have is to make windows on desk 1 visible on all desks: all (desk 1) stickacrossdesks on -- What is the actual use case for this? It would be possible to mark these windows with a flag (can't remember the syntax now) and write a hand tailored function that shows the windows when weitching to desk 1 and 2, but not on other desks. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Get the current content of root window
On Thu, Feb 18, 2021 at 09:31:06PM +0100, Klaus Ethgen wrote: > Am Do den 18. Feb 2021 um 18:57 schrieb Dominik Vogt: > > They tell the X server to do it, mostly by doing alpha blending, I > > think. X offers no reliable way to get any screen contents other > > than what you can see. Doing that on the client is also really > > too slow. > > Do you know, how? Not exactly, I was never interested in these pointless and mostly unusable visual effects. > From my knowledge, it only work with using another window manager than > fvwm. Yeah, we've never implemented stuff like that because of the reasons above. Looking "modern" instead of being usable and configurable has never been in the focus of development. There were some experiments in applications with transparent background before alpha blending was implemented in X, but this was unreliable and irritating. The only slightly helpful use of transparency I know of is for moving windows, but if that really is an issue, fvwm has wire frame window movement. Doesn't look fancy though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Get the current content of root window
On Thu, Feb 18, 2021 at 02:00:44PM +0100, Klaus Ethgen wrote: > Hi Dominik, > > Am Do den 18. Feb 2021 um 12:36 schrieb Dominik Vogt: > > On Wed, Feb 17, 2021 at 06:48:45PM +0100, Klaus Ethgen wrote: > > > seting the background (root window) to some image is easy. But is there > > > any way to get the image content on fvwm root window back to an image? > > > > As far as I know the X protocol offers no way to retrieve the > > background pixmap of any window. > > Sad. How are window manager working when they provide transparency? How > does ETerm does it? (however, it doesn't work here) They tell the X server to do it, mostly by doing alpha blending, I think. X offers no reliable way to get any screen contents other than what you can see. Doing that on the client is also really too slow. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Get the current content of root window
On Wed, Feb 17, 2021 at 06:48:45PM +0100, Klaus Ethgen wrote: > seting the background (root window) to some image is easy. But is there > any way to get the image content on fvwm root window back to an image? As far as I know the X protocol offers no way to retrieve the background pixmap of any window. The best approximation is to remove all windows from the current desk and then make a screenshot. For example, from FvwmConsole: all stick off all movetodesk 1 *But* if there is some background image, how did it get there? There should be some readable image file somewhere on the system. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Alt-Tab and WindowList
On Mon, Feb 15, 2021 at 09:25:44PM +0530, Mandar Mitra wrote: > Dominik Vogt wrote (Sun, Feb 14, 2021 at 12:05:26PM +0100): > I have no idea what I'm doing wrong, but something does seem to > be messing with window focus. For a while, the list is nicely > maintained in MRU order, then suddenly, a window that I haven't > focused for a while jumps up to the middle of the list. The focus order is implemented as a doubly linked list. Windows can not just "jump" around in the list. The list only ever modified in two places in the code: 1) When a window gets focus it's pulled from it's current position and put at the beginning of the list. 2) When a new window is opend, it starts at the end of the list. So, if windows appear at the top of the list which you do not expect, watch closely for reasons why unexpected windows get focus, even for a short while. (For example with MouseFocus if you move the pointer across small visible pieces of other windows.) > Sometimes > its Emacs, sometimes its zathura (a pdf viewer). I copy pasted the > destroyfunc and addtofunc that you provided above into > FvwmConsole, but neither FvwmConsole itself, nor .xsession-errors > had anything to report while the list was being re-ordered, > apparently randomly. Maybe you could try to figure out some reproducable instructions to make that happen (preferrably with a minimal config). It's of course not impossible that there might be a bug in the code, that is highly unlikely, because the focus order is on of the most used pieces of code in fvwm, and if there were list inconsistencies, fvwm would have crashed 20 years ago. > 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 bet this has something to do with your problem. -- Have you tried using multiple pages? For example, I use six (2x3) pages. Each has a keyboard shortcut assigned to it. Shells and editors are on page (0 0), browsers are on (1 0), text processors + xpdf are on page (0 1) and so on. This makes it really easy to find windows and keeps the desktop usable. -- #// paging (like on the console) Key F1 A M GotoPage 0 0 Key F2 A M GotoPage 1 0 Key F3 A M GotoPage 2 0 Key 1 A M GotoPage 0 1 Key 2 A M GotoPage 1 1 Key 3 A M GotoPage 2 1 # Menu to move windows around # (inconsistent with abouce bindongs; menus cannot use function keys) Key p TSIWF CM Menu PutOnPageMenu AddToMenu PutOnPageMenu + "Put on page" Title + "&1: page (0 0)" MoveToPage 0 0 + "&2: page (1 0)" MoveToPage 1 0 + "&3: page (2 0)" MoveToPage 2 0 + ": page (0 1)" MoveToPage 0 1 + ": page (1 1)" MoveToPage 1 1 + ": page (2 1)" MoveToPage 2 1 # Start programs on specific pages Style Gnumeric StartsOnPage 1 1, SkipMapping Style Firefox* StartsOnPage 0 1, SkipMapping, MaxWindowSize 99 97 Style Firefox* fixedpposition Style Firefox* NoTransientPPosition, NoFuncHint Style Emacs StartsOnPage 0 0, SkipMapping -- > For now, I've just disabled SelectOnRelease, and use the Fvwm > assigned number to quickly jump to the window I want. This saves > me from having to keep typing Tab to get where I want in the list. > I suppose it'll just take a little while for muscle memory to > reset itself to this usage pattern. Why not simply assign letters to your programs? E.g. -- Key tab A M Menu GotoWindowMenu AddToMenu GotoWindowMenu + "Go to window" Title + "" Prev (emacs) RaiseAndWarp + "" Prev (ipe) RaiseAndWarp + "" Prev (zathura) RaiseAndWarp ... -- Much more intuitive than numbers that change all the time. > Idle curiosity: do you use ipe too? Nice to discover such > commonalities in an unrelated list. No, sorry that I fooled you; i just instlled it to see what it's doing. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Trouble with transient windows
On Sun, Feb 14, 2021 at 11:31:01AM +0100, Dominik Vogt wrote: > For me, this works well: > > Style * GrabFocusTransient > Style ipe !FPGrabFocusTransient > Style * !RaiseTransient, !LowerTransient, !StackTransientParent P.S.: There's also the nuclear option to prevent some window from ever being focused: Style NeverFocus But that would only work if Ipe windows had distinguishable names. At the moment, all its windows have the class "ipe", resource "ipe", and some of the transients have also the name "ipe". So, Style ipe neverfocus would affect all Ipe windows because it matches class and resource, and that's not what you want. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Trouble with transient windows
On Sun, Feb 14, 2021 at 01:07:03PM +0530, Mandar Mitra wrote: > At the moment, the only thing that I want is that transients > should never get focus. Side note: You *really* don't want this. It would render many applications unusable (file dialogs etc.). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Alt-Tab and WindowList
On Sat, Feb 13, 2021 at 08:37:12PM +0530, Mandar Mitra wrote: > I have Alt-Tab bound as follows: > > Key Tab A M WindowList (CurrentPage) > CurrentAtEnd,IconifiedAtEnd,...,SelectOnRelease Alt_L > > I'd like windows to be listed in most recently used order, and > there are a number of fvwm related Web pages that state that is > what "normally" happens, but what I'm observing is the following. > > As long as I'm switching back and forth between Window A and > Window B, things work well. I also have some other windows (all > pdf viewers displaying different files) on the same page. If I > take a look at one of them, I would expect A, B and the focused > pdf viewer window to occupy the top 3 slots, but that's not what > happens. Either A or B is positioned way down in the list. Try running just WindowList (currentpage) from FvwmConsole and see if that works as expected. The ordering of that list entirely depends on the order in which windows are focused. If that results in a weird ordering, then something messes with window focus. In that case, try if this helps: destroyfunc EWMHActivateWindowFunc addtofunc EWMHActivateWindowFunc + I echo Ignoring EWMHActivateWindowFunc $[w.id] $[w.name] And watch the console output for the debug messages. -- However, I recommend to ditch Alt-Tab and the windowlist command completely. It's just unintuitive, failed design: You always need to be aware of the order in which windows have had focus. Instead I use Key Left A M DirectionOrThis West Key Right A M DirectionOrThis East Key UpA M DirectionOrThis North Key Down A M DirectionOrThis South Key Home A M DirectionOrThis FromPointer Center Key Minus A M DirectionOrThis Center I.e., pressing Alt- selects the next window in the given direction from the currently focused window. Sometimes it requires a couple of key presses to get the right window, but you get immediate visual feedback, and it's very easy to use. You don't have to keep track of some "hidden" state. The selection algorithms prefers closer windows of windows that are farther away, and windows in the exact direction over windows that are a couple of degrees off. Play with it to get a feeling for it. It works pretty well if the current page is not cluttered with many windows, all atop each other. Alt-Minus gives you the window closest to the current one, and Alt-Home the one that's closest to the pointer. Both bindings help with stacked windows, but I hardly ever use them. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Trouble with transient windows
On Sat, Feb 13, 2021 at 08:22:16PM +0530, Mandar Mitra wrote: > Ipe sometimes pops up a little window (only borders, no titlebar > or buttons) that says "Waiting for external editor" (meaning > emacs), and grabs focus. 1) Please provide instructions how to make this happen. 2) What are the focus related options in the config file? (All of them) > I have to manually focus emacs before I can type anything. When > I quit emacs, the above window goes away. > I would like the transient windows to not affect focus at all. I > looked at the manual page for the FPGrabFocusTransient, > FPGrabFocusTransient, FPReleaseFocusTransient, and similar > options, but I couldn't figure out what I need to do to get the Thanks to the "extended window manager hints" specification applications can force focus on certain windows without leaving that to the window manager. Ipe sends an "activation" message on the transient windows to the window manager, and the default reaction to that is to raise and focus the window. For me, this works well: Style * GrabFocusTransient Style ipe !FPGrabFocusTransient Style * !RaiseTransient, !LowerTransient, !StackTransientParent destroyfunc EWMHActivateWindowFunc addtofunc EWMHActivateWindowFunc + I echo Ignoring EWMHActivateWindowFunc $[w.id] $[w.name] But that will also prevent automatic focusing of file dialogs etc. (which is perfectly fine for me). Alas, Ipe gives several of these windows the name "ipe" (and all its windows have the class and resource "ipe"), so unfortunately "style ipe ..." applies not only to the transients in question but to all its windows. -- If you really want EWMH to focus windows automatically and throw unexpected windows in your face, revealing the passwords you were typing in a shell etc., you'd have to hand write an EWMHActivateWindowFunc that does nothing for ipe windows (using conditional execution syntax) but works normally for others. -- To figure out the window names, use Style * DecorateTransient Or run the FvwmIdent module on the window in question. (E.g. open FvwmConsole, type "FvwmIdent", then pick a window.) -- (A bug report to Ipe to ask them to name all their windows properly would be in order, but not fix the problem anythime soon, I guess.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> I also see fvwm2 being used for quite a while even as fvwm3 matures.
Can we please stop calling the project "fvwm2" or "fvwm3". We've
renamed it to "fvwm" ages ago.
> Creating two packages that live side by side is a far greater
> challenge than initially anticipated. First there are a lot of other
> binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> conflict,
Do these not get the --program-suffix? If not, that should be
fixed.
> and though the --program-{prefix,suffix,transform-name} can
> rename the binaries, this isn't the only conflict. The manpages for
> all the common modules conflict and so does the translations/locales.
> And none of these are affected by the --program-foo options.
All right, but if these problems had been *reported* and not just
silently dealt with in the distribution, they would have been
fixed immediately back when the change from fvwm2 to fvwm was
done.
> I was thinking of maybe some fvwm-common package that would host the
> manpages
Applying the --program-suffix to the man page names should be
trivial to do in the Automakefiles.
> and locales,
I don't know much about locales, but are they not installed in
/usr/share/fvwm?
> but even this isn't doable since there is
> already differences in the modules in fvwm2 and fvwm3, mostly it is
> the modules that are available, but FvwmPager has already received
> some changes in options for the RandR per monitor setup.
Is is acceptable to have man pages named
FvwmModule in addition to the default names?
If all else fails, the manpages could be put in separate packages.
> Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> only one of those can be installed at a time.
I don't like this naming scheme that suggest the version number is
part of the project name. Is naming them "fvwm", "fvwm-2",
"fvwm-1" not an option?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 01:27:19PM +0100, Thomas Adam wrote: > It's a tricky one. Right now, things have not diverged because I haven't > implemented those changes. I'd always viewed Fvwm3 as being a departure from > Fvwm2 -- and hence any association with it at the moment as being equivalent > is just because it's lacking any breaking changes. It's also an easier > transition for any one wishing to try Fvwm3 who's previously used Fvwm2. > > That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to > be separate from Fvwm2 over time, in that I'm not expecting to maintain > compatibility, and I wouldn't therefore want to mislead users with a false > version number. > > There may well be some overlap with Fvwm2 in terms of unchanged file names > (fvwm-config springs to mind), although I think for the most part Fvwm2 and > Fvwm3 can co-exist. I'll try and make the distinction better in future > releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3 > to coexist. The exact same reasoning led to the "fvwm2" project, and it caused a whole lot of useless work to eventually clean up and rename it to fvwm again. The autotools can take care of having two versions installed in parallel (--program-suffix configure option). Distributors know how to use these options. And as far as I understand, nobody is going to maintain the 2.x version anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > installed. Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? Renaming the project because of a new major version was already a mistake for fvwm-2.0.0. No reason to repeat it now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: React to event "KeyPress Control_L, KeyRelease Control_L"
On Sat, Apr 11, 2020 at 04:37:40PM +0200, Dr Rainer Woitok wrote: > is there a way in Fvwm to bind some command to just pressing and immedi- > ately releasing the Ctrl-key without pressing any other key? No, binding things to modifier key does not work. I've tried to implement that many years ago, but the X interface is just not suited for this kind of binding. To trap key press and release events it's necessary to redirect all keyboard input to fvwm. > Holding down Ctrl any pressing A should NOT trigger this command. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: COVID-19: Hope everyone's well
On Sat, Mar 21, 2020 at 03:20:06PM +, Thomas Adam wrote: > Just emailing to check that everyone's OK and not suffering too much at the > moment. I know different countries are largely doing the same things as one > another -- and I'm working from home for the foreseeable. I'm fine, working from home for the forseeable future. Things are a bit strange in Germany. Hopefully people hav understood the severity of the current situation now. Keep well and fit everybody, as we now say in Germany. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwmorg/fvwm3] msgpack as fvwm <-> modules <-> bindings communicator (#31)
On Sun, Feb 23, 2020 at 07:37:22PM -0500, Dan Espen wrote: > Thomas Adam writes: > > > FVWM was written before any formal message parsing libraries existed. > > Currently, the communication protocol that FVWM uses is a packed structure > > which is shoved down a pipe, which the receiving end has registered > > interest in by locking on to various > > messages which are sent. > > > > Other libraries exist to abstract away this message construction, such as > > msgpack which allows for other binary data to be considered (rather than > > packing unsigned longs down a pipe, which is how FVWM does this currently). > > > > Another benefit is that other languages have native msgpack bindings, which > > would allow for agnostic FVWM APIs to be created to allow scripting in any > > language. This is similar to how neovim does things, for example. Please don't forget a way to just send text from a shell script without having to link with some library. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Changing mouse cursor size
On Sun, Feb 16, 2020 at 09:23:45AM +0100, Dr. Nikolaus Klepp wrote: > Anno domini 2020 Sun, 16 Feb 00:18:54 + > Thomas Adam scripsit: > > > > On Sun, Feb 16, 2020 at 12:57:20AM +0100, Dominik Vogt wrote: > > > Debian based distros seem to have some kind of scalable "cursor > > > themes". Has anybody (i) tried to use them with fvwm and (ii) > > > managed to actually define a custom scaling factor without using > > > some config dialog from the distro? > > > > however on my > > laptop(s) which have 4K screens (which X11 hates until you mess about with > > all > > manner of DPI settings, and even then the various X widget libraries have no > > clue about scaling), I set the following in my ~/.Xdefaults file: > > > > Xcursor.theme: cursor-theme > > Xcursor.size: 90 > > And you'll need to add these for GTK2 to ~/.gtkrc-2.0: > > gtk-cursor-theme-name="cursor-theme" > gtk-cursor-theme-size=90 Ah, great, thanks! No chance to find this simple solution by duckduckgoing. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
FVWM: Changing mouse cursor size
Debian based distros seem to have some kind of scalable "cursor themes". Has anybody (i) tried to use them with fvwm and (ii) managed to actually define a custom scaling factor without using some config dialog from the distro? (Other suggestions to get larger cursors welcome.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Perform action, one in a time - at every open window at all desks and workspaces.
On Fri, Feb 07, 2020 at 05:30:43PM +0100, Peter Holm wrote: > I often restart fvwm. With tons of windows open. So that no windows > are open - cant be the reason. Okay. > I have written in this thread espcially about that - and maybe found a > way out of it. > But the message is stalled . So I have to wait until it been moderated. You're sending each message twice to the list, so one of them is stalled because it's a duplicate. > And I prefere to not use fvwm-event in this case - out of several > reasons. I have the thumbnail-function executed every time i switch > desktop. > > I just want a helper function that I runs only when needed. Well, as written before, "All" executes an action for each window. If that does not do what you expect, it's because the called function does not do what you expect. Try it out in FvwmConsole, for example with ThisWindow Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Perform action, one in a time - at every open window at all desks and workspaces.
Please don't top-post on this list and leave the relevant portions of the discussion intant when replying to a message. On Fri, Feb 07, 2020 at 04:10:49PM +0100, Peter Holm wrote: > I am not sure if the All command is the solution. I suppose the > actual viewport (if that is the correct term here) should be at the > actual desk and page before the function thumbnail_minicons executes. > > Am I wrong.? "All" (without further conditions) does what the name suggests: It executes the action for each and every existing window at the time when its called. E.g. All MoveToDesk moves all windows to the current desk. > 2020-02-07 11:56 GMT+01:00, Peter Holm : > > No go with > > AddtoFunc StartFunction > > + I All Thumbnail_MiniIcons The problem with that approach is that the function is executed in the StartFunction, before any window is created. If it's really necessary to execute a function for a new window, the FvwnEvent module can be used. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Perform action, one in a time - at every open window at all desks and workspaces.
On Fri, Feb 07, 2020 at 11:56:32AM +0100, Peter Holm wrote: > No go with > AddtoFunc StartFunction > + I All Thumbnail_MiniIcons Of course not. "All" works only on existing windows. Perhaps you can elaborate on what you want to accomplish? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Document mime type compliance?
On Mon, Jan 06, 2020 at 04:04:49PM -0600, Brian wrote: > > Thanks for replying. The following is the functions called, so not the > one you reference. > > #Function FvwmMenuDirectory > DestroyFunc FuncFvwmMenuDirectory > AddToFunction FuncFvwmMenuDirectory > + I PipeRead '/usr/bin/fvwm-menu-directory --title "%d" --dir "$0"' > > Which as I said makes a Documents directory directly in the main menu > and then displays the files and directories as if they were a submenu of > "Documents". > > The trouble I run into is that every file clicked on opens in vi, > directories open the next level down directory, and what I need is for > the files to open according to the mime type with the proper > application. > > Dominik, > The man page suggest that you and Mikhael originally wrote this little > script. Is there a config I've forgotten so that files will properly > open by mime type? It is really just a showcase for generating menus on the fly. Any additional logic like opening files needs to be done outside fvwm. It was never intended to integrate a general file handler into fvwm. > For example I see in the man for fvwm-menu-directory a --exec-app > [command] which maybe means I need to include the app to run on a file, > but would that work for each mime type? Maybe there is another > FvwmFunction which needs to be referenced to add mime type calls? > Maybe I'm using the wrong function even? Looking at the --help output, I imagine that the option --exec-file=xdg-open should do what you want. (xdg-open starts the application defined by the mime type with the given file; don't ask me about syntax details.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: how to escape F1?
On Fri, Mar 08, 2019 at 10:59:44AM +0100, Harald Dunkel wrote: > Hi Thomas, > > On 3/8/19 9:53 AM, Thomas Adam wrote: > > Key F1 A A -- > > > > Apparently thats a misunderstanding. Sorry for my bad English. > > I would like fvwm to *ignore all key bindings for one keypress* > to forward it directly to the app with input focus. X11 does not have a way to override all grabs for just a couple of keystrokes. If a grab is present, it's always active. (Unless the application grabs the keyboard, but that is not what you're looking for.) So the only way to do that is to put all key bindings in some file or function, e.g. bind_keys and to unbind them in another one unbind_keys then "read unbind_keys" when necessary and restore them with "read bind_keys" later. You'll probably be unhappy with the performance of this approach if you have mora than just a few bindings. (Don't forget to put a binding that reactivates the other bindings into unbind_keys.) > Some kind of > "escape" key entered before the actual key. > > For example, I have > > Key F1 A N Switch-Iconic > Key F2 ... > : > > in my .fvwmrc. > > Assuming the window "xyz" has input focus: If I press and release > some [magic_escape_key], followed by [F1], then "xyz" should *not* > be changed to an icon, but [F1] should be sent to "xyz" instead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Canceling window placement via user-defined key
On Sun, Dec 30, 2018 at 10:23:39AM -0700, Glenn Golden wrote: > Dominik Vogt [2018-12-30 01:11:13 +0100]: > > On Sat, Dec 29, 2018 at 04:29:00PM -0700, Glenn Golden wrote: > > > Anyway, the idiom I'm seeking to implement is this: > > > > > > 1. Tap Control_R with pointer inside a window to begin 'Move' > > > operation > > > 2. Use arrow keys to reposition the window > > > 3. Tap Control_R to terminate the 'Move' operation > > > > All the keyboard shortcuts for moving and resizing windows, > > dragging the viewport and execution of complex functions are hard > > coded in libs/Target.c. I.e. this won't work without changing the > > sources. > > > > I'm not quite understanding what you mean, can you explain a little more? > > The above already does work, by just binding Control_R to 'Move', except that > the Move operation has to be terminated by 'Space' or 'Return'. Do you mean > that the definition of the terminating key events (i.e. Space or Return) is > hardwired to those particular two keys in Target.c? Exactly. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Canceling window placement via user-defined key
On Sat, Dec 29, 2018 at 04:29:00PM -0700, Glenn Golden wrote: > Anyway, the idiom I'm seeking to implement is this: > > 1. Tap Control_R with pointer inside a window to begin 'Move' operation > 2. Use arrow keys to reposition the window > 3. Tap Control_R to terminate the 'Move' operation All the keyboard shortcuts for moving and resizing windows, dragging the viewport and execution of complex functions are hard coded in libs/Target.c. I.e. this won't work without changing the sources. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: rare behavour with mouse buttons
On Wed, Aug 29, 2018 at 02:39:30PM -0600, Jaimos Skriletz wrote: > On Wed, Aug 29, 2018 at 2:35 PM bruce m beach wrote: > > > > Hello > > > > > > Mouse 1 2 NMaximize true 0 33 > > Mouse 3 2 NMaximize true 0 100 > > > > Mouse 1 4 NMaximize true 27 0 > > Mouse 3 4 NMaximize true 100 0 > > > > Mouse 0 6 A Iconify > > > > Now what happens is that these mouse clicks totally stop working. > > No response whatever. A few minutes later everything is okay. > > > > The N requires that no modifier is being pushed. If any modifier is > being pushed, the bindings won't work. Note that numlock is a > modifier. This might be relevant. This is one of the most asked > questions in the FAQ > > http://www.fvwm.org/documentation/faq/#a-few-minutes-after-fvwm-is-started-my-keyboard-and-mouse-bindings-stop-working--what-can-i-do > > Anyways, making N and A (for any modifiers) should make it work no > matter what modifier you are holding down. And IgnoreModifiers L2 is a good idea too. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Tue, Aug 28, 2018 at 05:40:02PM +0200, Stefan Blachmann wrote: > Well, I think this points to an off-by-one bug in Firefox's SessionStore.jsm > > A quick peek into the source made me stumble over this: > > Bottom and right coordinates are calculated there this way: bottom = > top + height > this will result in an off-by-1 bottom coordinate... > ...shouldn't it be bottom = top + height - 1 ? > > Please look at the restoreDimensions() function, line 4137+ > in particular lines 4165 and 4180 > > (Link: > https://hg.mozilla.org/mozilla-central/file/190b827aaa2b/browser/components/sessionstore/SessionStore.jsm > ) > > What do you think? > Do you think a bug report at Mozilla is justified? I don't see any problem with that logic. The "bottom" coordinate is not used as the name suggests. Unless aHeight is larger than the screen height wehn the function is called, its value is used unchanged in the aWindow.resizeTo() call. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Tue, Aug 28, 2018 at 03:22:54AM +0200, hw wrote: > Dominik Vogt writes: > > > On Mon, Aug 27, 2018 at 10:36:58PM +0200, hw wrote: > >> Dominik Vogt writes: > >> > >> > On Sun, Aug 26, 2018 at 09:30:14PM +0200, hw wrote: > >> > >> > [...] > >> >> IIUC, I explicitly told the window manager to ignore what the program > >> >> tries to do about the placement of the windows it creates, and yet the > >> >> window manager still allows the program to do (part of) what it wants > >> >> rather than what I told the window manager to do about the window > >> >> placement. > >> >> > >> >> So either the window manager is ignoring what I'm telling it to do, or > >> >> the program is able to override the window manager, or both. > >> > > >> > That's exactly what I wrote. The window manager cannot know that > >> > the application lies about the user's wish. The situation is > >> > impossible to detect. > >> > >> I don't understand: The window manager does not need to detect lies when > >> I tell it not to allow a program to move its windows and not to allow it > >> to create them at a particular position. It only needs to enforce thes > >> policies, and the placement policy. > >> > >> In this case, fvwm appears to be enforcing the creation and movement > >> policies correctly and the placement policy only partially. > > > > Then please enlighten us with the output of > > > > bugopts explainwindowplacement on > > > > so we can see what's going on. Fvwm just does what it's told, we > > haven't coded a glass ball inside it. > > Thanks to your other post, I finally got this: > > > , > | [fvwm][__explain_placement]: placed new window 0x1400010 'Mozilla Firefox': > | initial size 1280x2161 > | desk 0 (current desk) > | current page > | screen: current screen: 0 0 3840x2160 (current screen) > | position 0 0, placed by fvwm (normal placement) > | placement method: MinOverlapPercent > | > | [fvwm][__explain_placement]: placed new window 0x1400032 'Mozilla Firefox': > | initial size 1280x2161 > | desk 0 (current desk) > | current page > | screen: current screen: 0 0 3840x2160 (current screen) > | position 0 0, placed by fvwm (ignored program specified position) > | placement method: MinOverlapPercent ... > Oh, ok, there is actually four windows, not three. I forgot about the > fourth one because I didn't get to see it. A fourth window must somehow > have been created after Firefox said it had crashed a Tab and I was > missing a window after that. The problem is that the windows are created larger than your screen. The window height is 2161 pixels but the screen is only 2160 pixels. MinOverlapPercent never places any part outside of the screen. In this case, the algorithm fails and windows are placed at 0 0. The message could be improved a bit in that case; I've obviously missed that case when writing that output. Never happened to me. If you reduce window heigt by a pixel, that should work fine. Personally I'm happy with Style SeaMonkey MaxWindowSize 99 97 which limits the size of Seamonkey windows to 99% of the screen width and 97% of its height. You may want to try that too (or even 100%). > BTW, I'm seeing > > > , > | [fvwm][style_parse_and_set_window_style]: <> Bad style option: > gnomeignorehints > ` > > > in the log file. Why is this a bad option? The style doesn't exist anymore. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Tue, Aug 28, 2018 at 02:51:58AM +0200, hw wrote:
> Dominik Vogt writes:
> >> Or does the module create its own output that needs to be
> >> redirected when the module is being started?
> >
> > What module?
>
> FvwmConsole
We're talking about fvwm output, not module output.
Personally, I start the X server with the zsh function
mystartx () {
setopt localoptions
setopt multios
/usr/bin/startx > /dev/fd/1 > ~/.X.err 2>&1
}
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Tue, Aug 28, 2018 at 02:49:05AM +0200, hw wrote: > Viktor Griph writes: > > > Den mån 27 aug. 2018 00:27hw skrev: > > > >> With Firefox, I think using FixedPPosition, !UsePPosition fix it as > >> well, but the problem is that for some reason, fvwm does not place the > >> windows according to the placement policy. > > > > As you describe it it sounds as if Firefox maps the new window before > > restroing the size of the window, so Fvwm will do it's placement logic > > based on whatever sixe firefix has put on the windows when they are > > displayed, > > What does it mean to "map" a window? Does fvwm not know the size of a > window before placing it? That totally depends on what the application does with its window. Most create their windows with the finaly size, others come up with some default and resize them later. > > and once placed, Firefox rezises the windows to the old > > size. > > As far as I can see, the windows created by Firefox are each 1/3 the > width of the display and full height of the display when they become > visible. Apparently, they are not being resized --- unless I can not > see that happening. Fvwm does its best to make only the final size visible. One cannot tell what's happening by looking at the screen. > > (It should be obvious from the ExplainWindowPlacement option if > > that's the case.) > > If I could only get that to work ... :) Instead of spending time on complaining, spend your time on making that work. It's your machine after all. > > You can also try to use the "PlaceAgain" comman on the Firefox windows > > once they are all restored and see if they pace as you expect then. If > > so, you might be able to do some magic with FvwmEvent to trigger a > > PlaceAgain automatically on Firefox windows, but I'm not certain it is > > possible, or how to configure the module to do it. > > Interestingly, this option does nothing to the windows of Firefox, and > they remain on top of each other. It replaces other windows as > expected, though. > > Oh, and when I manually move the Firefox window which is on top and > replace it then, it is being moved to the top left corner of the display > so it ends up on top of the other two windows! > > How come? There must be some bug with fvwm that it can not correctly > place the windows of Firestorm. Just give us the debug output. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Mon, Aug 27, 2018 at 10:43:59PM +0200, hw wrote: > > If you use a .xinitrc you can have the WM output directed where ever > > you like otherwise the distro will pick a place. > > I tried that by redirecting the output of fvwm into a file from within > .xinitrc. The file was created buy remained empty. > > Hm, do I need to redirect fvwms stdderr, too? Of course. > Or does the module create its own output that needs to be > redirected when the module is being started? What module? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Mon, Aug 27, 2018 at 10:36:58PM +0200, hw wrote: > Dominik Vogt writes: > > > On Sun, Aug 26, 2018 at 09:30:14PM +0200, hw wrote: > > > [...] > >> IIUC, I explicitly told the window manager to ignore what the program > >> tries to do about the placement of the windows it creates, and yet the > >> window manager still allows the program to do (part of) what it wants > >> rather than what I told the window manager to do about the window > >> placement. > >> > >> So either the window manager is ignoring what I'm telling it to do, or > >> the program is able to override the window manager, or both. > > > > That's exactly what I wrote. The window manager cannot know that > > the application lies about the user's wish. The situation is > > impossible to detect. > > I don't understand: The window manager does not need to detect lies when > I tell it not to allow a program to move its windows and not to allow it > to create them at a particular position. It only needs to enforce thes > policies, and the placement policy. > > In this case, fvwm appears to be enforcing the creation and movement > policies correctly and the placement policy only partially. Then please enlighten us with the output of bugopts explainwindowplacement on so we can see what's going on. Fvwm just does what it's told, we haven't coded a glass ball inside it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Sun, Aug 26, 2018 at 11:23:56PM +0200, hw wrote: > Dominik Vogt writes: > >> What could be causing this? Is Firefox somehow claiming the entire > >> screen because it tries to place the windows itself, making fvwm figure > >> there is no good place to put them? Without FixedPPosition, the windows > >> are still being placed on top of each other. > >> > >> I??ll resort to TileManualPlacement for now because it??s easier to place > >> the windows where I want them as they are created than it is to move > >> them once they??re all there. > >> > >> > There's also the option > >> > > >> > bugopts explainwindowplacement on > >> > > >> > Which will print a detailed report to the console when new windows > >> > are placed. > >> > >> You mean the FvwmConsole module? Nothing is printed there when I enable > >> this and place any window. > > > > No, in the output of the X server, wherever that goes. > > After trying to get systemd to create log files, it apparently goes into > /var/log/Xorg.0.log (where it might have gone to before). Alas, no > output is added to the log file when I use this option and create > windows. > > Do I need to set compile time options for fvwm to make this work? No. > It seems it must be "true" rather than "on", but that doesn't seem to > give any output, either. No. "true", "on" or "1" all work the same. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Sun, Aug 26, 2018 at 09:30:14PM +0200, hw wrote: > Dominik Vogt writes: > > > On Fri, Aug 24, 2018 at 10:58:51PM +0200, hw wrote: > >> Stefan Blachmann writes: > >> > I was annoyed and looked into that. > >> > session[re]store.js is a *horrible* mess of code, and to understand > >> > its workings, I just disabled the screen bounds check where > >> > sessionrestore creates the windows from the data in the > >> > sessionrestore.js file and wrote a script that just corrects the > >> > coordinates in the sessionrestore.js file, so that Firefox restores as > >> > it should. > >> > So I could just run the firepox script, after that run FF, it should > >> > restore the windows where they originally were. > >> > > >> > The script might be outdated for new FF versions, as the > >> > sessionrestore code was changed again in the meantime, introducing > >> > again random placement of restored windows. > >> > But reading it might give you some insight of the workings in the > >> > sessionrestore.js files. > >> > > >> > It is on github together with a small intro, here: > >> > https://github.com/kernschmelze/firepox > >> > >> Thanks! I think it must not be possible at all for a program that > >> creates windows to override the very window manager that manages the > >> windows. > > > > It actually is possible. Sort of. If the application claims that > > a requested position is "user specified" instead of "program > > specified", the window manager has no way of knowing that the user > > did not ask for it. Nowadays many programs abuse this hint to > > override the window manager - in clear violation of the > > communication rules set in the ICCCM2 standard. > > That's not overriding the window manager, it's overriding what the user > wants. > > IIUC, I explicitly told the window manager to ignore what the program > tries to do about the placement of the windows it creates, and yet the > window manager still allows the program to do (part of) what it wants > rather than what I told the window manager to do about the window > placement. > > So either the window manager is ignoring what I'm telling it to do, or > the program is able to override the window manager, or both. That's exactly what I wrote. The window manager cannot know that the application lies about the user's wish. The situation is impossible to detect. > Either way, what I??m telling the computer to do is being overridden, and > that is not acceptable. Yeah. These applications are annyoing me as much as they are annoying you. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Sat, Aug 25, 2018 at 11:20:37AM +0200, Stefan Blachmann wrote: > On 8/24/18, hw wrote: > > > But that doesn??t work either, the windows are placed on top of each > > other again. With !UsePPosition alone, I get the windows placed as I > > want it, but it means Firefox is moving them rather than that fvwm > > places them. > > Yes, FF creates its windows with the size given in sessionrestore.js, > *then* moves, retitles and paints them. If that is the case, styles may not match the newly created windows. Could you provide some list of events that are generated in relation to the output of bugopts explainwindowplacement ? Maybe we could "preview" events that rename a window that is just being created. But I'd need some kind of test case for that. Ideally just a simple application that does the same thing that Firefox does in a reliable way. > On 8/25/18, Dominik Vogt wrote: > > It actually is possible. Sort of. If the application claims that > > a requested position is "user specified" instead of "program > > specified", the window manager has no way of knowing that the user > > did not ask for it. Nowadays many programs abuse this hint to > > override the window manager - in clear violation of the > > communication rules set in the ICCCM2 standard. > > Well, Firefox is correct if it says "user specified" position, as > *you* probably were the one who originally specified it by moving the > window. No. The windows may have been placed automatically by the window manager, and still the application claims the position is "user specified". It's just a lame excuse that I've read many times. Unless the user explicitly selected an option "restore window position" or similar, the position is program specified. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Fri, Aug 24, 2018 at 10:58:51PM +0200, hw wrote: > Stefan Blachmann writes: > > I was annoyed and looked into that. > > session[re]store.js is a *horrible* mess of code, and to understand > > its workings, I just disabled the screen bounds check where > > sessionrestore creates the windows from the data in the > > sessionrestore.js file and wrote a script that just corrects the > > coordinates in the sessionrestore.js file, so that Firefox restores as > > it should. > > So I could just run the firepox script, after that run FF, it should > > restore the windows where they originally were. > > > > The script might be outdated for new FF versions, as the > > sessionrestore code was changed again in the meantime, introducing > > again random placement of restored windows. > > But reading it might give you some insight of the workings in the > > sessionrestore.js files. > > > > It is on github together with a small intro, here: > > https://github.com/kernschmelze/firepox > > Thanks! I think it must not be possible at all for a program that > creates windows to override the very window manager that manages the > windows. It actually is possible. Sort of. If the application claims that a requested position is "user specified" instead of "program specified", the window manager has no way of knowing that the user did not ask for it. Nowadays many programs abuse this hint to override the window manager - in clear violation of the communication rules set in the ICCCM2 standard. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Fri, Aug 24, 2018 at 10:41:45PM +0200, hw wrote: > Dominik Vogt writes: > > > On Thu, Aug 23, 2018 at 07:10:47PM +0200, hw wrote: > >> Hi! > >> > >> Fvwms manpage says: > >> > >> > >>Placement policy options and window stacking > >> !UsePPosition instructs fvwm to ignore the program > >> specified position (PPosition hint) when adding new > >> windows. Using PPosition is required for some > >> applications, but if you do not have one of those it's a > >> real headache. Many programs set PPosition to something > >> obnoxious like 0,0 (upper left corner). Note: > >> !UsePPosition is equivalent to the deprecated option > >> !UsePPosition > >> > >> > >> Is "!UsePPosition" deprecated? > > > > No, it just means that styles nowadays are all negated with a '!' > > in front of them and the old names with "No..", "Dont..." etc. > > shouldn't be used anymore. There's a type though; the manpge > > should state that "NoPPosition" is deprecated. > > Should make a bug report? > > >> Some years ago, I had found out that I need to use "FixedPPosition" for > >> Seamonkey to prevent it from creating windows at unreachable places, > >> i. e. way off screen on desktop pages that didn't even exist. So I??m > >> using this option for Firefox now. > >> > >> What option(s) can I use to prevent windows being created by Firestorm > >> at unreachable places and yet have them placed according to the > >> placement policy? > > > > Well, the full array of options to get shitty applications under > > control is: > > > > Style ... fixedpposition, fixedusposition > > Style ... fixedpsize, fixedussize > > style ... gnomeignorehints, EWMHIgnoreStackingOrderHints > > style ... EWMHIgnoreStrutHints, EWMHPlacementIgnoreWorkingArea > > style ... EWMHIgnoreStateHints > > > > (The fixedus... styles make it impossible for the user to move or > > resize the window too. If they re the only way to make the > > application behave, one could make a script that waits for a few > > seconds or until the windows appear and then remove the style.) > > Thanks! Alas, these options don??t have the desired effect with Firefox. > > What has an effect is TileManualPlacement (with FixedPPosition): With > TileManualPlacement, I get to place the windows manually when Firefox > starts. What I want is MinOverlapPlacement, or > MinOverlapPercentPlacement. When I use either, the Firefox windows are > placed on top of each other. Are you sure that the styles match? If windows would be created without a name first, the style does not match, and firefox could do with them what it wants. > I was wondering if something is going on that prevents fvwm from > noticing for the placement that there are windows already there when > Firefox suddenly creates its three because it is creating them too fast > or somehow not entirely. Yet getting to do manual placement when > TileManualPlacement is used would indicate that fvwm does realise that > these windows are being created. > > The manual placement fvwm falls back to, when TileManualPlacement is > used, would indicate that fvwm can not find a smart location for these > windows. You mean as a command or as a style? > What could be causing this? Is Firefox somehow claiming the entire > screen because it tries to place the windows itself, making fvwm figure > there is no good place to put them? Without FixedPPosition, the windows > are still being placed on top of each other. > > I??ll resort to TileManualPlacement for now because it??s easier to place > the windows where I want them as they are created than it is to move > them once they??re all there. > > > There's also the option > > > > bugopts explainwindowplacement on > > > > Which will print a detailed report to the console when new windows > > are placed. > > You mean the FvwmConsole module? Nothing is printed there when I enable > this and place any window. No, in the output of the X server, wherever that goes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: deprecated? placing firestorm windows?
On Thu, Aug 23, 2018 at 07:10:47PM +0200, hw wrote: > Hi! > > Fvwms manpage says: > > >Placement policy options and window stacking > !UsePPosition instructs fvwm to ignore the program > specified position (PPosition hint) when adding new > windows. Using PPosition is required for some > applications, but if you do not have one of those it's a > real headache. Many programs set PPosition to something > obnoxious like 0,0 (upper left corner). Note: > !UsePPosition is equivalent to the deprecated option > !UsePPosition > > > Is "!UsePPosition" deprecated? No, it just means that styles nowadays are all negated with a '!' in front of them and the old names with "No..", "Dont..." etc. shouldn't be used anymore. There's a type though; the manpge should state that "NoPPosition" is deprecated. > Some years ago, I had found out that I need to use "FixedPPosition" for > Seamonkey to prevent it from creating windows at unreachable places, > i. e. way off screen on desktop pages that didn't even exist. So I??m > using this option for Firefox now. > > What option(s) can I use to prevent windows being created by Firestorm > at unreachable places and yet have them placed according to the > placement policy? Well, the full array of options to get shitty applications under control is: Style ... fixedpposition, fixedusposition Style ... fixedpsize, fixedussize style ... gnomeignorehints, EWMHIgnoreStackingOrderHints style ... EWMHIgnoreStrutHints, EWMHPlacementIgnoreWorkingArea style ... EWMHIgnoreStateHints (The fixedus... styles make it impossible for the user to move or resize the window too. If they re the only way to make the application behave, one could make a script that waits for a few seconds or until the windows appear and then remove the style.) There's also the option bugopts explainwindowplacement on Which will print a detailed report to the console when new windows are placed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FakeClick
On Mon, Jun 25, 2018 at 10:28:29PM +0100, Klaus Ethgen wrote: > Am Mo den 25. Jun 2018 um 21:29 schrieb Dominik Vogt: > > Don't use FakeClick, it's a failed experiment I once made. It's > > virtually imposible to get the clicks in the right ubwindow, and > > even if you manage to do that, the application will probably > > ignore it. > > Any other idea how to do it? > > I have to use `pass -c ...` and a paste thousand times per day. I need > to get that done with a key function to not get carpal syndrome by > changing to the mouse every time. Shift-Insert should often work. Or bind a middle button click to a key (somewhere in the X config). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Request to increase 1024 char/line limit in read.c
On Mon, Mar 05, 2018 at 11:57:27AM +, Thomas Adam wrote: > Hi, > > On Mon, Mar 05, 2018 at 04:38:08AM +0100, Stefan Blachmann wrote: > > Hi fvwm-workers, > > > > the 1024 char limit in the read line buffer in fvwm/read.c has become too > > small. > > This caused a breakage in my MissingSubmenuFunction menu generator > > after after addition of programs + update; the Popup did not display. > > > > Could the buffer be extended to, say, 4096 chars? > > We'd be chasing stack limits if we do this. > > I'd much rather see that fgets() loop replaced with fparseln() instead, which > would also solve this problem indefinitely. The reson for commnd line limitation is mostly the size limit of pipes (pipereas command and module communication). In the past we used the largest value that every system guaranteed to support (256) and then increased that to 1024 at some time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]
On Fri, Mar 02, 2018 at 08:33:20PM +, Thomas Adam wrote: > On Tue, Feb 13, 2018 at 11:19:41PM +0100, Dominik Vogt wrote: > > On Mon, Feb 12, 2018 at 02:14:57PM +, Thomas Adam wrote: > > > Well, this is good news! Apologies for bouncing this between fvwm@ and > > > fvwm-workers@. > > > > > > If no one objects, I'll go ahead an start making the relevant changes? > > > > Good. With the extra clauses gone, things get easier - go ahead. > > So, I've started this here: > > https://github.com/fvwmorg/fvwm/commit/7274b020a4dfec4adcc5317f557605b006bce085.diff > > However, we're not out of the woods yet, as there's the following > complications: > > libs/Picture.c: > libs/PictureBase.c: > > /* > * Copyright 1996, Romano Giannetti. No guarantees or warantees or anything > * are provided or implied in any way whatsoever. Use this program at your > * own risk. Permission to use this program for any purpose is given, > * as long as the copyright is kept intact. > * > * Romano Giannetti - Dipartimento di Ingegneria dell'Informazione > *via Diotisalvi, 2 PISA > * mailto:rom...@iet.unipi.it > * http://www.iet.unipi.it/~romano > * > */ > > modules/FvwmBacker/FvwmBacker.c: > modules/FvwmBacker/FvwmBacker.h: > > /* Copyright 1994, Mike Finger (mfin...@mermaid.micro.umn.edu or > * mike_fin...@atk.com) > */ > /* Robert Nation and Nobutaka Suzuki */ > > modules/FvwmIdent/FvwmIdent.c: > > /* Copyright 1994, Robert Nation and Nobutaka Suzuki. */ > > > So I need to track down these additional people as well before I can remove > the full clause. I think in all these cases it is enough to move the copyright notice to the COPYING file (it also has a copyright section). After all, the copyright does not go away if the copyright notice is removed. Rob's clauses were problematic because they specifically required to be kept intact. When that work is done, I'll backport the patches to the old stable branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM:
On Wed, Feb 28, 2018 at 06:42:09AM +1030, Viktor Griph wrote: > 2018-02-28 6:14 GMT+10:30 Michelle Konzack <linux4miche...@tamay-dogan.net>: > > ...but I found this file is guilty: > > > > [ ~/.fvwm/Functions.d/AutoHide.conf ]--- > > DestroyFunc autohide > > AddToFunc autohide > > + I ThisWindow ($0) Deschedule $[w.id] > > + I ThisWindow ($0) ThisWindow (Shaded) WindowShade off > > + I TestRc (!Match) All ($0, !Shaded autohide\_hide $1 $2) > > That's the line giving the warning. You are trying to use > autohide\_hide $1 $2 as a condition without commas. > Try to change it to > + I TestRc (!Match) All ($0, !Shaded) autohide\_hide $1 $2 > > I'm not sure why you need to escape _ in the above code. If it doesn't > work still, try to remove the escape as well. Also, it's probably a good idea to put the $0 in double quotes. You'll get a similar warning if $0 contains spaces. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM:
On Tue, Feb 27, 2018 at 07:45:50PM +0100, Dominik Vogt wrote: > That leaves the "comma" warning. If you can't find it by looking > at your files, try adding more "echo" commands to narrow it down > to a specific place. It's probably in a style or a window > circulation command (Next, All, etc.). Maybe this grep helps: > > grep "[[(].*," ~/.fvwm/* Or rather $ grep "[[(][^]),]*[[:space::]" ~/.fvwm/* or if it's not in a module line: $ grep "^[^*].*[[(][^]),]*[[:space:]]" .fvwm2rc Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM:
On Tue, Feb 27, 2018 at 05:51:52PM +0200, Michelle Konzack wrote: > Am 2018-02-27 hackte Dominik Vogt in die Tasten: > > Is the file that defines the root menu in this list? Have you > > double checked the menu name and the binding? Is there any > > problem with numlock or the other sticky modifier keys? > > I have currently NO root menu, I just saw, that there is a non-visible > character in the filename which prevented my "tdfvwm-daemon" to read the > config file like > > PipeRead `tdfvwm-daemon Menus.d` Is the "no root menu" issue solved then? That leaves the "comma" warning. If you can't find it by looking at your files, try adding more "echo" commands to narrow it down to a specific place. It's probably in a style or a window circulation command (Next, All, etc.). Maybe this grep helps: grep "[[(].*," ~/.fvwm/* Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM:
On Tue, Feb 27, 2018 at 02:51:09PM +0200, Michelle Konzack wrote:
> > ~/.fvwm/config
>
> This is what I have
So the correct file is read.
> Reading /home/michelle.konzack/.fvwm/Functions.d/AutoHide.conf...
...
> Reading /home/michelle.konzack/.fvwm/start.d/xloadimage.conf...
Is the file that defines the root menu in this list? Have you
double checked the menu name and the binding? Is there any
problem with numlock or the other sticky modifier keys?
> /bin/sh: 1: Syntax error: "(" unexpected
^^^
You need to debug the cause of this error message. To me it looks
like /bin/sh is trying to execute an fvwm configuration file as a
shell script. Possibly unrelated.
> FvwmIconMan: Show only focused to: 0
> FvwmIconMan: Bad line: *FvwmTaskbarIconsTipstrue
> FvwmIconMan: What is this: true?
> FvwmIconMan: Bad line: *FvwmTaskbarIconsTipsOffset 3 2
> FvwmIconMan: Unknown option: *FvwmTaskbarIconsTipsOffset
> FvwmIconMan: Bad line: *FvwmTaskbarIconsSelectButtons flat Green Yellow
> FvwmIconMan: Unknown option: *FvwmTaskbarIconsSelectButtons
> The "FvwmIconMan" will be another mail... because it seems, FVWM is
> removing the ": " behind "*FvwmTaskbarIcons" which produce the error but
> it is not with all options.
That's something else. If you cannot figure this out yourself and
write a message to the list, please include the FvwmIconMan config
and the line from FvwmButtons that starts it.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Causing "firefox" to start in particular desktop page
On Tue, Feb 27, 2018 at 02:33:19PM +0100, Dominik Vogt wrote: > If the debug output looks good, Firefox has probably moved its own > window to a different page. There is a number of styles to > prevent applications moving their own windows. Try > > Style ... fixedpposition > > first. P.S.: I have this in my config: Style Firefox* StartsOnPage 0 1, SkipMapping, MaxWindowSize 99 97 Style Firefox* fixedpposition Style Firefox* NoTransientPPosition, NoFuncHint (But I've not been using Firefox for ages.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Causing "firefox" to start in particular desktop page
On Tue, Feb 27, 2018 at 01:44:47PM +0100, Dr Rainer Woitok wrote: > Greetings, > > since a few days I'm trying to set up "fvwm" in such a way that a "fire- > fox" window is always opened in page "0 0 1" rather than in page "0 0 0" > from where I'm issuing the "firefox" command. From the manual page and > the FAQ I took the suggestion to use > >Style Firefox* StartsOnPage 0 0 1, SkipMapping >Style * RecaptureHonorsStartsOnPage, CaptureHonorsStartsOnPage > > and added this to my configuration file using all four variations of > "Firefox*", "*Firefox", "*Firefox*", and "Firefox", but it simply didn't > work here. ^ First, double check that you've got the correct style name. If there is any doubt, use FvwmIdent on the Firefox window. If the style seems to be fine, add some odd style to the same line and see it taht works - to make sure the style is actually applied. If it's not a problem with the style name, you can add the line bugopts explainwindowplacement on to the config file. With that, fvwm prints a detailed message explaining where new windows are placed and why. In case you need help reading that output, feel free to post it to the list. If the debug output looks good, Firefox has probably moved its own window to a different page. There is a number of styles to prevent applications moving their own windows. Try Style ... fixedpposition first. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to disable keys on keyboard if xmodmap does not more work?
On Tue, Feb 27, 2018 at 10:22:57AM +0200, Michelle Konzack wrote: > I have on my ThinkPad near the 4 arrow keys to other keys (Pg Back, > Pg Fwd) and xmodmap does not more work under Debian Stretch. > > The problem is, if I am in Firefox and my webmail that I have hit > already many times the "pg back" button and then my whole EMail I > wrote is gone. > > Does someone know, how to disable this two buttons? >... > > and as I sayed, xmodmap does not work, nor my deadkeys for many estonian > special caracters. Does it work if you run xmodmap from a shell when fvwm is running? I've had a similar problem: Although xmodmap is called from .xinitrc, the keyboard layout is reset to the default after that. The only solution I could find was to run xmodmap with a delay so that it would run some seconds after fvwm startup. This is the line from ~/.xinitrc: ( sleep 4; xset s off; setxkbmap -option terminate:ctrl_alt_bksp; xmodmap ~/.Xmodmap; ) & -- It's really not an fvwm issue, but it is possible to "disable" keys everywhere or just for certain windows with bindings. For example, I've disabled ctrl-q and alt-q in some programs with Key (Gnumeric) q TSIFW M Nop Key (Sea*onkey*) q TSIFW C Nop etc. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM:
On Tue, Feb 27, 2018 at 12:50:03PM +0200, Michelle Konzack wrote: > I have checked since several years where this error is coming from, but > failed, becasue I have no MULTIPLE CONDITIONS > > [fvwm][CreateConditionMask]: <> Use comma instead of > whitespace to separate conditions > > This errors appear, if I move with the mouse from one window to another > without clicking on it. > > I was thinking, this can be only in the styles like >... Nothing of that has any conditions. It must be somewhere else. > I had my own RootMenu which was not more working and now it show all the > time "Builtin Menu" which I do not want. > > So, if fvwm loads stuff trom elsewhere, than I am right, that my config > has no errors, because the errors are also there, if I have no styles > and whatelese configured... > > How it is possibel, to DISABLE the WHOLE default stuff? Fvwm has a very small builtin configuraion that includes the builtin menu and some very basic bindings and styles. The last command of the default configuration reads the file ConfigFvwmDefaults that is installed along with the binaries. After that, it tries to find the user configuration file, picking the first one in this list: ~/.fvwm/config /usr/local/share/fvwm/config (depending on the configure prefix) ~/.fvwm/.fvwm2rc ~/.fvwm2rc /usr/local/share/fvwm/.fvwm2rc ... (some more obscure file locations) If it still uses the builtin menu, then either your config file does no do what you think it does. Are there any error messages during startup about missing or inaccessible files; have any files been moved or renamed? Or it uses a different file than it should. Check the above list carefully. Hm, if someone really installed a system wide /usr/local/share/fvwm/config, that would *always* be read instead of the user's ~/.fvwm/.fvwm2rc. > There are several things which I have never configured and can not get > rid of it, because I do not know, where it come from and what it is... Well, since you seem to have quite a few unexpected problems at the moment, there is probably a problem with which configuration files are used. Try to figure out which ones are executed and which ones are not. You can temporarily put an echo command at the top and bottom of all the files: echo BEGIN ... echo END Also, make sure that all "read" commands actually find the filed they are supposed to read. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [SOLVED] Re: FVWM: Jumping cursor
On Tue, Feb 27, 2018 at 12:32:49PM +0200, Michelle Konzack wrote: > Am DATE hackte AUTHOR in die Tasten: Thomas Adam > > On Tue, Feb 27, 2018 at 10:13:50AM +0200, Michelle Konzack wrote: > >> Good morning, > >> > >> can someone tell me the option, which prevent a jumping cursor in > >> the > >> middle of an application window? > > > > http://fvwmforums.org/wiki/Tips/FocusStealing/ > > OK, the cursor does not more jump, but now I get with every > click in an application tonns of error message like: > > DestroyFunc EWMHActivateWindowFunc Create a new function with that name that does nothing. addtofunc EWMHActivateWindowFunc i nop > [fvwm][__execute_function]: <> No such command > 'EWMHActivateWindowFunc' > which is not, what I expected... Well, you should expect that, if you destroy functions that are in use. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]
On Mon, Feb 12, 2018 at 02:14:57PM +, Thomas Adam wrote: > Well, this is good news! Apologies for bouncing this between fvwm@ and > fvwm-workers@. > > If no one objects, I'll go ahead an start making the relevant changes? Good. With the extra clauses gone, things get easier - go ahead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Placement of QT5 app
On Fri, Sep 29, 2017 at 09:39:05AM -0400, Tom Horsley wrote: > On Fri, 29 Sep 2017 14:00:10 +0100 > Dominik Vogt wrote: > > > These two styles are meant exactly for this situation. One of > > them should work unless the program guesses the border width and > > title height wrong. Is it 10x1 pixels? > > I'm fairly certain the program doesn't make the slightest > attempt to guess anything at all about decorations, the shift > on each start is exactly the window decoration dimension. And you have really tried out both styles (separately) and made sure that they are applied to the window, and both do not work? What output do you get when the window starts if you use BugOpts DebugCRMotionMethod on If you don't mind trying some debug code and recompiling the sources: In events.c there's an "#if 0" at line 1026: #if 0 fprintf(stderr, "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " ... If you make that "#if 1", fvwm will print all configure requests generated for the window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Placement of QT5 app
On Fri, Sep 29, 2017 at 08:38:01AM -0400, Tom Horsley wrote: > On Fri, 29 Sep 2017 01:30:08 +0100 > Dominik Vogt wrote: > > On Thu, Sep 28, 2017 at 07:18:08PM -0400, Tom Horsley wrote: > > > I see calibre windows gradually drift up and left > > > every time I start calibre because the code is > > > trying to save its geometry and getting it wrong. > > > > Try either > > > > Style ... UseGravity > > > > or > > > > Style ... IgnoreGravity > > > > where "..." is a style name matching the offending window only. > > Yea, I tried all that stuff, but apparently the way calibre > is written, it waits for the initial window to be drawn, > then moves and resizes itself programatically. So even giving > it an explicit geometry does no good :-). These two styles are meant exactly for this situation. One of them should work unless the program guesses the border width and title height wrong. Is it 10x1 pixels? (Please don't CC me.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Placement of QT5 app
On Thu, Sep 28, 2017 at 07:18:08PM -0400, Tom Horsley wrote: > I see calibre windows gradually drift up and left > every time I start calibre because the code is > trying to save its geometry and getting it wrong. Try either Style ... UseGravity or Style ... IgnoreGravity where "..." is a style name matching the offending window only. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Is this fvwm or X or what?
On Fri, Sep 01, 2017 at 08:26:22AM -0400, Tom Horsley wrote: > I have a Kensington trackball, which means I can click a mouse > button without touching the ball, and there is absolutely > no mouse movement when I click. > > When I do such a mouse click on the window decoration "close" > button, I see the button animation as it appears to be > depressed and spring back up which makes me believe > it did indeed see both the press and release events. > > But fairly often, the window will just sit there, not > closing till I finally touch the trackball and cause > some mouse movement event, then the window finally pops > out of existence. > > Clearly this is the worlds most unimportant problem, but > I just got curious about it, so I thought I'd ask if > anyone knows something that would cause this. It's either a hardware problem (trackball broken) or the X server is doing something strange (not deliver the button release event unless there is some mouse motion). I've seen thing like this before, caused by both. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Stopping to use Github / Don't push to Github(!!)
On Sat, Jun 10, 2017 at 07:41:24PM +0100, Thomas Adam wrote: > On Wed, Apr 12, 2017 at 08:47:15PM +0100, Dominik Vogt wrote: > > I don't see how this is fixable without either removing all of > > Rob's code or changing Github's terms and conditions. I see no > > problems between D.4 and D.5 and the GPL though. > > Gitlab might be an option, but that would require me to set the infrastructure > up there again -- something I'm not willing to do at all. Frankly, we lose > more than we gain. I'm not crazy about switching either. > The other option we have is contacting Rob Nation and asking him if he's happy > for his terms to change. I would be *amazed* if there's much of any of his > original code left to such an extent where his original copyright notice even > means anything, not to mention, it was written such a long time ago as well. > > I can certainly try and contact him. Good idea, please do. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwmorg/fvwm] Fedora 26 fvwm-menu-desktop not working (#42)
On Mon, Jun 05, 2017 at 07:28:00PM -0400, Dan Espen wrote: > pyaazkaparatha <notificati...@github.com> writes: > > > It still gives error. > > > > bash-4.4$ fvwm-menu-desktop File "/usr/bin/fvwm-menu-desktop", line 146 > > print str(err) # will print something like "option -a not > > recognized" ^ SyntaxError: invalid syntax > > > > This is with python3 > > > > fvwm 2.6.7 compiled on Apr 11 2017 at 14:20:21 > > fvwm-menu-desktop doesn't work with Python 3. > That's a known issue here. > > I can't give you a time line right now on the fix. > I might do the work but other issues stand in the way. > Dominik, any updates? I really don't know what to do about Github, other than dumpint it. :-( Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Sometimes windows remain after the process has died.
On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote: > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote: > >> Sometimes when a process stops the window will remain open until some > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm > >> will remove the window. > > > > That is not possible unless either > > ... > > The process do not appear in 'ps fax' and the script outputs [Done] on > all the jobs that were run in the background in the shell, so this is > not the case. > > > 2) the X server has a bug, > > This does seem to be the case. The user and myself both tested this > running an xsession with only an xterm. We could not reproduce it with > only running an xterm. > > I decided to test another window manager, openbox in this case, and > was able to reproduce the issue in openbox. So it seems to be some bug > with how the xserver but may require a window manager to trigger it. I wonder what that trigger could be. If the window can be moved, fvwm is communicating with the X server in both directions, so if a destroy event was pending it should have been delivered to fvwm before any mouse motion events. Maybe the X server itself has destroyed the window internally but not yet sent the event for some reason, and does so only when some request for that window is issued. (Moving the fvwm window does not move the client window directly but the frame.) If you type "xsync" in FvwmConsole, does that kill the window? (This forces all pending requests and events to be delivered in both directions.) My guess is that it doesn't, i.e. no event is pending. > In all cases trying to get any info from the xserver closes the > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo > will close all the windows that were left open when running that > command. Does it also kill the window to request information from a different (non-zombie) window? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Sometimes windows remain after the process has died.
On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> Sometimes when a process stops the window will remain open until some
> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> will remove the window.
That is not possible unless either
1) the process is not really dead,
2) the X server has a bug,
3) fvwm does not destroy the frame after the window has gone.
I've spent lots of time to get rid of any cases of #3, and what
you describe does not sound like "empty frame remains".
> The following script was provided by the user which launches and
> closes a large number of xterms. When running this script some of the
> xterm windows will remain even though the process is no longer
> running.
>
> On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre <vinc...@vinc17.net> wrote:
> > Simpler test case:
> >
> >
> > #!/bin/sh
> >
> > n=${1:-200}
> > n=$((n+0))
> >
> > for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
> >
> > wait
> >
That's how I've tested that the frame always gets removed.
> After this script ends a few windows remain and can be moved,
> iconified, shaded, resized. But if you run FvwmIdent something is
> triggered which removes all the affected windows.
>
> I was not able to reproduce this on my main machine (though rarely I
> would have a window stick around for a second or two before it was
> removed, most weren't even drawn), but I was able to reproduce this
> with the default config on both the debian 2.6.7-3 package and the
> master branch from git inside a virtual machine.
Maybe it's a problem with the X server in a virtual machine? I
don't have such a setup to test that, but it doesn't happen on a
plain X server with or without config and neither in Xnest for me.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Stopping to use Github / Don't push to Github(!!)
On Wed, Apr 12, 2017 at 09:24:45AM +0100, Thomas Adam wrote: > On Wed, Apr 12, 2017 at 09:48:30AM +0200, Christoph Fritz wrote: > > On Thu, 2017-03-09 at 13:55 +0100, Dominik Vogt wrote: > > > There is a discussion about Github's new terms of service which may > > > not be compatible with the Gpl: > > > https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm > > > > > > I didn't have time to read the new terms yet, but it is possible > > > that we need to remove all fvwm repositories from Github. The > > > most important thing right now is to *not* *push* *anything* to > > > Github until we've decided about this issue, because by continuing > > > to use Github, the new terms of service are automatically accepted. > > > > out of curiosity: Are there any updates on this? > > Storm in a tea cup, really: > > http://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft No that's not correct. D.7 conflicts with this: /* * This module is all original code * by Rob Nation * Copyright 1993, Robert Nation * You may use this code for any purpose, as long as the original * copyright remains in the source code and all documentation */ D.7 To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; ... I don't see how this is fixable without either removing all of Rob's code or changing Github's terms and conditions. I see no problems between D.4 and D.5 and the GPL though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Stopping to use Github / Don't push to Github(!!)
There is a discussion about Github's new terms of service which may not be compatible with the Gpl: https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm I didn't have time to read the new terms yet, but it is possible that we need to remove all fvwm repositories from Github. The most important thing right now is to *not* *push* *anything* to Github until we've decided about this issue, because by continuing to use Github, the new terms of service are automatically accepted. Ciao Dominik ^_^ ^_^
[fvwmorg/fvwm] d89af5: Fix "--" bindings.
Branch: refs/heads/fvwm2-stable Home: https://github.com/fvwmorg/fvwm Commit: d89af5d26a27e52ba86e529fbde02a26533c2d84 https://github.com/fvwmorg/fvwm/commit/d89af5d26a27e52ba86e529fbde02a26533c2d84 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/bindings.c Log Message: --- Fix "--" bindings. Commit: b7dfb7bad58c51470615b6479ab2d3a70f387e10 https://github.com/fvwmorg/fvwm/commit/b7dfb7bad58c51470615b6479ab2d3a70f387e10 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M ChangeLog Log Message: --- ChangeLog. Commit: 65007a8f70e09eadb4e20d1fb3d083f268c3df9b https://github.com/fvwmorg/fvwm/commit/65007a8f70e09eadb4e20d1fb3d083f268c3df9b Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/47e634b66324...65007a8f70e0
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 03:10:48PM -0500, Chris Siebenmann wrote: > > > If you click on the link, it's supposed to print something like: > > > > > > link > > > http://gtk.org > > > In a configuration with a Mouse 1 binding that includes the Window > > > context (so W or A), the link can't be activated by clicking mouse-1 > > > and link.py prints nothing. You can however get it to print something > > > by clicking on the link and then hitting Return to activate the link > > > through the keyboard. > > > > Okay, this is reproduceable. I know nothing about python or Gtk+, > > so this may be easy, but here, when you click on the window, xev > > prints no ButtonPress or ButtonRelease events at all neither with > > nor without the binding. Is there a way so that the program > > prints all events it sees? > > I don't know if there's a way to get GTK to do that, but I can > use the blunt hammer of xtrace here: > https://xtrace.alioth.debian.org/ > > Based on this, the link.py script is seeing LeaveNotify and EnterNotify > events before the ButtonPress event. The initial numbers here are > relative time since program start in seconds, and I left the program > idle for several seconds to make sure things would stand out (and indeed > they do): > > 5.042 000:>:0206: Event LeaveNotify(8) detail=Ancestor(0x00) > mode=Grab(0x01) flags=same-screen time=0x05ee50ba root=0x026d > event=0x0063 child=None(0x) root-x=702 root-y=319 event-x=128 > event-y=102 state=Button1 > > [link.py wakes up and wakes a ton of requests and RENDER-Requests] > > 5.043 000:>:0235: Event UnmapNotify(18) event=0x00600043 > window=0x00600043 from-configure=false(0x00) > 5.045 000:>:0235: Event VisibilityNotify(15) window=0x0063 > state=Unobscured(0x00) > 5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=117 > width=38 height=1 count=0x0004 > 5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=118 > width=40 height=1 count=0x0003 > 5.046 000:>:0235: Event Expose(12) window=0x0063 x=143 y=119 > width=42 height=33 count=0x0002 > 5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=152 > width=40 height=1 count=0x0001 > 5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=153 > width=38 height=1 count=0x > 5.046 000:>:0235: Event EnterNotify(7) detail=Ancestor(0x00) > mode=Ungrab(0x02) flags=same-screen time=0x05ee50bd root=0x026d > event=0x0063 child=None(0x) root-x=702 root-y=319 event-x=128 > event-y=102 state=Button1 > 5.046 000:>:0235: Event ButtonPress(4) button=left button(0x01) > time=0x05ee50ba root=0x026d event=0x0063 child=None(0x) > root-x=702 root-y=319 event-x=128 event-y=102 state=0 same-screen=true(0x01) > > (Some of those expose events are presumably because of the various > requests and render requests it issued immediately after the LeaveNotify.) > > In looking at this carefully, I did notice another anomaly in link.py's > behavior (which you may have also noticed). When I initially move the > mouse pointer over the actual link, it turns from a plain pointer into > a hand-pointer, presumably to signal that this is a clickable link, and > the program also pops up a tooltip for the link destination. When I > click on the link and nothing happens, this immediately changes back to > the regular pointer; in fact, this change happens on the button press > (which I can see if I click down and hold). This doesn't happen with > working clicks, where a button-press leaves the cursor unchanged. > > I wonder if GTK is (mis-)processing the LeaveNotify here as 'the mouse > pointer is leaving the link', instead of 'mouse has been grabbed from me'. That's just what I think. The program seems to believe it has lost focus and stops processing button events. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote: > On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote: > > (Let me know if you want more detail somewhere here and I can rerun > > my gdb tracing and/or add printfs appropriately.) > > > > Fortunately there is a simple reproduction program mentioned in the > > Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151 > > that comes from the Ubuntu compiz bug report. For convenience, I've > > put it up as its own (shorter) URL: > > https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py > > and my fvwmrc: > > https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5 > > > > If you have the Python GTK bindings (so that link.py runs at all), it > > puts up a label box with an underlined link. > > No idea, but the window with the "link" appears. > > > If you click on the link, it's supposed to print something like: > > > > link > > http://gtk.org > > In a configuration with a Mouse 1 binding that includes the Window > > context (so W or A), the link can't be activated by clicking mouse-1 > > and link.py prints nothing. You can however get it to print something > > by clicking on the link and then hitting Return to activate the link > > through the keyboard. > > Okay, this is reproduceable. I know nothing about python or Gtk+, > so this may be easy, but here, when you click on the window, xev > prints no ButtonPress or ButtonRelease events at all neither with > nor without the binding. Is there a way so that the program > prints all events it sees? > > The "A" context bindings actually do cause grabbing the button > with any modifiers globally (in order to cut down the total number > of grabs, I think). It's just a global mask of buttons to grab > globally, and most applications don't care about it. There may be > some change in the sequence of events the application gets, or > maybe the timestamps, but its hard to say without actually seeing > the events. There's another strange symptom that seems to point to a button handling problem in the library, as it occurs even without such a "trigger" binding. Without a "mouse 3 a ..." binding: * Move the pointer over "link". The test gets highlighted in white. * Push button 3. The text gets a dark grey background, and a popup menu opens. * Hit the "Escape" key to close the popup. The text background is light grey now. * Do not move the pointer now; otherwise the problem goes away. * Clicking with button 3 again does nothing. Pressing the "Return" key still works. It seems the library gets confused about the window's state. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 08:45:36PM +0100, Dominik Vogt wrote: > On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote: > > On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote: > > > (Let me know if you want more detail somewhere here and I can rerun > > > my gdb tracing and/or add printfs appropriately.) > > > > > > Fortunately there is a simple reproduction program mentioned in the > > > Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151 > > > that comes from the Ubuntu compiz bug report. For convenience, I've > > > put it up as its own (shorter) URL: > > > https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py > > > and my fvwmrc: > > > https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5 > > > > > > If you have the Python GTK bindings (so that link.py runs at all), it > > > puts up a label box with an underlined link. > > > > No idea, but the window with the "link" appears. > > > > > If you click on the link, it's supposed to print something like: > > > > > > link > > > http://gtk.org > > > In a configuration with a Mouse 1 binding that includes the Window > > > context (so W or A), the link can't be activated by clicking mouse-1 > > > and link.py prints nothing. You can however get it to print something > > > by clicking on the link and then hitting Return to activate the link > > > through the keyboard. > > > > Okay, this is reproduceable. I know nothing about python or Gtk+, > > so this may be easy, but here, when you click on the window, xev > > prints no ButtonPress or ButtonRelease events at all neither with > > nor without the binding. Is there a way so that the program > > prints all events it sees? > > > > The "A" context bindings actually do cause grabbing the button > > with any modifiers globally (in order to cut down the total number > > of grabs, I think). It's just a global mask of buttons to grab > > globally, and most applications don't care about it. There may be > > some change in the sequence of events the application gets, or > > maybe the timestamps, but its hard to say without actually seeing > > the events. > > There's another strange symptom that seems to point to a button > handling problem in the library, as it occurs even without such a > "trigger" binding. Without a "mouse 3 a ..." binding: > > * Move the pointer over "link". The test gets highlighted in > white. > * Push button 3. The text gets a dark grey background, and a > popup menu opens. > * Hit the "Escape" key to close the popup. The text background > is light grey now. > * Do not move the pointer now; otherwise the problem goes away. > * Clicking with button 3 again does nothing. Pressing the > "Return" key still works. > > It seems the library gets confused about the window's state. Note: This bug is present even in the complete absence of a window manager, when the program runs on a plain, unmanaged X screen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote: > (Let me know if you want more detail somewhere here and I can rerun > my gdb tracing and/or add printfs appropriately.) > > Fortunately there is a simple reproduction program mentioned in the > Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151 > that comes from the Ubuntu compiz bug report. For convenience, I've > put it up as its own (shorter) URL: > https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py > and my fvwmrc: > https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5 > > If you have the Python GTK bindings (so that link.py runs at all), it > puts up a label box with an underlined link. No idea, but the window with the "link" appears. > If you click on the link, it's supposed to print something like: > > link > http://gtk.org > In a configuration with a Mouse 1 binding that includes the Window > context (so W or A), the link can't be activated by clicking mouse-1 > and link.py prints nothing. You can however get it to print something > by clicking on the link and then hitting Return to activate the link > through the keyboard. Okay, this is reproduceable. I know nothing about python or Gtk+, so this may be easy, but here, when you click on the window, xev prints no ButtonPress or ButtonRelease events at all neither with nor without the binding. Is there a way so that the program prints all events it sees? The "A" context bindings actually do cause grabbing the button with any modifiers globally (in order to cut down the total number of grabs, I think). It's just a global mask of buttons to grab globally, and most applications don't care about it. There may be some change in the sequence of events the application gets, or maybe the timestamps, but its hard to say without actually seeing the events. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 07:02:55PM +0100, Dominik Vogt wrote: > On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote: > > > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote: > > > > > > > > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5 > > > > > > file (from the URL) *except* either: > > > > > > > > > > > > Mouse 1 A MS Iconify > > > > > > or > > > > > > Mouse 1 A M Raise > > > > > > Try > > > > > > mouse 1 tsifw ... > > > > > > instead. Limit the context a binding applies to to what is > > > needed. It's inefficient and interferes with other programs' > > > bindings. Or do you really iconify windows by clicking on the > > > root window? > > > > I've now tested and the problem happens with just: > > > > Mouse 1 W MS Iconify > > > > ... which is about the minimal binding, since I really do want to > > iconify windows with meta-shift-1 anywhere inside them. > > Referring to the other message, I disagree with the analysis > there. Fvwm grabs only the modifier combinations on windows that > it needs, i.e. the ones that are present in the binding. See > libs/Bindings.c:GrabWindowButton(). Unless you have you have > something like > > IgnoreModifiers MS > > The only other reason fvwm grabs a button is for focus handling in > focus.c:__focus_grab_one_button(). The only possible reason I > could think of is that the application does not accept focus so > that grab never gets removed. Have you tried > > Style * Lenience > > as Dan suggested? > > For further debugging, does the problem go away with > > style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick > > Unless I have a simple test application and a configuration that > exhibits that behaviour I cannot do much about it. Would you be > able to fvwm in Xnest and debug through > events.c:__handle_bpress_on_managed() to see what actually > happens? By the way, have you tried to get the application developers' opinion? From the xev output is seems that the button events are reported to the program, so why doesn't it react to them? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote: > > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote: > > > > > > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5 > > > > > file (from the URL) *except* either: > > > > > > > > > > Mouse 1 A MS Iconify > > > > > or > > > > > Mouse 1 A M Raise > > > > Try > > > > mouse 1 tsifw ... > > > > instead. Limit the context a binding applies to to what is > > needed. It's inefficient and interferes with other programs' > > bindings. Or do you really iconify windows by clicking on the > > root window? > > I've now tested and the problem happens with just: > > Mouse 1 W MS Iconify > > ... which is about the minimal binding, since I really do want to > iconify windows with meta-shift-1 anywhere inside them. Referring to the other message, I disagree with the analysis there. Fvwm grabs only the modifier combinations on windows that it needs, i.e. the ones that are present in the binding. See libs/Bindings.c:GrabWindowButton(). Unless you have you have something like IgnoreModifiers MS The only other reason fvwm grabs a button is for focus handling in focus.c:__focus_grab_one_button(). The only possible reason I could think of is that the application does not accept focus so that grab never gets removed. Have you tried Style * Lenience as Dan suggested? For further debugging, does the problem go away with style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick Unless I have a simple test application and a configuration that exhibits that behaviour I cannot do much about it. Would you be able to fvwm in Xnest and debug through events.c:__handle_bpress_on_managed() to see what actually happens? > > > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence > > > > > in xev > > > > Forget about these; that's just how X works. > > Is it possible that some part of GTK+ doesn't like this sequence > of events and ignores ButtonPress/ButtonRelease as a result? No. > It is relatively striking to me how correlated things are here. These events are generated as a side effect of button presses by design of the X protocol. An application that cannot deal with them is broken. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm 2.6.x title vs icon title bug
On Thu, Mar 02, 2017 at 12:00:08AM +0700, ?? wrote: > On 01.03.2017 23:38, Dominik Vogt wrote: > >On Wed, Mar 01, 2017 at 04:20:29PM +0100, Dominik Vogt wrote: > >>On Sat, Feb 18, 2017 at 11:35:48AM +0700, ?? wrote: > >>>With both fvwm 2.6.5 and latest 2.6.7 I experience a bug when icon > >>>of the window of some apps keeps a previously set title. For > >>>example: > >>>- Normal window has title AND icon title "title", which is correct > >>>according to FvwmIdent, > >>>- After Iconify, icon title appears as some default name of the > >>>application, or "title". > >>>- Deiconifying it again, and making app change title to "title > >>>(new)". Both title and icon title are correct and shown as "title > >>>(new)" according to FvwmIdent. > >>>- Iconifying it again, and icon is named "title" (if there was some > >>>default app name, it changes to this previously set name). > >>>- Deiconifying it again, and making app change title to "new title". > >>>Again, both title and icon title is correct per FvwmIdent. > >>>- Iconifying it again, and I see icon name set to "title (new)". > >>> > >>>This issue happens only with some apps. Namely, I think all FOX > >>>toolkit apps are affected (for me they are Xfe, Xfw, Adie). > >>> > >>>On forums http://fvwmforums.org/phpBB3/viewtopic.php?f=6=3204 I > >>>was directed to mailing list thread > >>>http://www.mail-archive.com/fvwm-workers@fvwm.org/msg03213.html, > >>>which gave me an idea that setting IconTitleFormat to %i and > >>>TitleFormat to %n separately may work. Indeed this worked and solved > >>>my issue I described. > >> > >>I'm working on the problem. > > > >Can you please try the fix on the master branch in Git? > > > > I removed temporaries related to this issue from my .fvwm2rc and > tested a patch with 2.6.7. I can say the issue is gone fully. I will > notify if there will be regressions related to this. Good. I'll push the patch onto the stable branch. One thing I'm not quite sure about; before that patch that added TitleFormat and IconTitleFormat in 2008, what did fvwm show as the icon title? Was it the icon name or the window title? Now it's the icon name, but was it the same before that patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] bc685f: Fix updating window and icon titles.
Branch: refs/heads/fvwm2-stable Home: https://github.com/fvwmorg/fvwm Commit: bc685fd15f2f2f1064347f0ae1cfc19560ef9de4 https://github.com/fvwmorg/fvwm/commit/bc685fd15f2f2f1064347f0ae1cfc19560ef9de4 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Commit: af8c4580b9d7f54798ebd251eda3bf232a63f1f6 https://github.com/fvwmorg/fvwm/commit/af8c4580b9d7f54798ebd251eda3bf232a63f1f6 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M ChangeLog Log Message: --- ChageLog. Commit: 47e634b66324df8fb9acd235fefa40b7be76fee5 https://github.com/fvwmorg/fvwm/commit/47e634b66324df8fb9acd235fefa40b7be76fee5 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/b57836af68bc...47e634b66324
Re: FVWM: '--' key action has stopped working in the master
On Mon, Feb 27, 2017 at 04:35:31AM +0200, Alexander Gromnitsky wrote: > So I have > > Key F4 A M Close > > in .fvwm2rc for closing any window on Alt-F4. But I want the xterm app > to be exempt from such a treatment. > > W/ fvwm-2.6.5, this configuration has been working flawlessly for me: > > $ cat ~/.fvwm/.fvwm2rc > Key F4 A M Close > Key (XTerm) F4 A M -- > > $ grep allowSendEvents ~/.Xdefaults > XTerm*allowSendEvents: true > > Today I've built fvwm from the master branch & have noticed that the > above trick doesn't work any more--the xterm window gets closed when I > press Alt-F4. > > What could be the culprit? A bug in a patch from 2013: By accident the variable that indicated a "--" action was evaluated before being set. I've pushed a fix to the branch "dv/devel". Can you please try that and see if it solves your problem? It does for me. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] 5df54f: Fix "--" bindings.
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 5df54fcf24d2488f4ba82acd92412df85d2a60b3 https://github.com/fvwmorg/fvwm/commit/5df54fcf24d2488f4ba82acd92412df85d2a60b3 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/bindings.c Log Message: --- Fix "--" bindings. Commit: f6c69f52e643f3d6a8b7cc3643c3962c875b4f1d https://github.com/fvwmorg/fvwm/commit/f6c69f52e643f3d6a8b7cc3643c3962c875b4f1d Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/ffe942d66cdb...f6c69f52e643
Re: FvwmIconMan still sometimes triggers Hint Warnings
On Wed, Mar 01, 2017 at 07:18:11AM -0700, Jaimos Skriletz wrote:
> On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
> >> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
> >> <jaimosskril...@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > FvwmIconMan still reports Hint warnings even with the patchs applied.
> >>
> >> I wrote this small patch that has FvwmIconMan wait until the window
> >> has resized to set the window hints. This is in the lines of Dominik
> >> Vogt's patch, but waits until FvwmIconMan has fully resized to run
> >> fix_manager_size() to set the window hints. My tests here no longer
> >> seem to tiger the warnings like it still sometimes did.
> >>
> >> As an additional thought, talking to Thomas Adam about the patch in
> >> #fvwm, he mentioned that the issue is more FVWM being overly cautious
> >> and the fix should be in how fvwm handles size hint warnings over
> >> working with FvwmIconMan to avoid triggering them.
> >>
> >
> > So, if it's not possible to completely fix FvwmIconMan in a decent
> > way, what do we do with the warning? I'd rather not disable it,
> > but the number of false positives is too high. One could make a
> > style that disables the warning for a certain class of windows,
> > but that would probably be used as "style * ...", disabling the
> > warning for everything. :-/
> >
>
> FvwmIconMan isn't the only application that triggers these warnings,
> but using it in a situation where it grows/shrinks is a very regular
> way to cause the warnings and it fills up .xsession-error with mostly
> warnings. Other applications I use only trigger these warnings rarely,
> and in each case the application appears to work fine so yet more
> false positives. But FvwmIconMan is the only one that regularly
> resizes itself triggering the warning a lot.
Of course. Flooding the log was not the intention of the patch.
> I had two ideas on this, one is use a BugOpts option that can turn on
> these warnings for a user who wants to debug things, but they are off
> by default. This is basically your style idea and the affect will be
> almost everywhere these warnings will not appear and thus may miss out
> on programs that actually need to be reported.
Yes, but defaulting to "off" makes the warning effectively useless.
> Another is maybe don't have fvwm jump to conclusions that there is a
> warning.
Let me rephrase that: Fvwm informs the user about something that
might not be possible to clean up. In such a situation the user
would see that the window did not get resized as intended and has
no clue why. At least, fvwm has told her that something strange
was going on.
> What if there was some timer that fvwm gave the application
> to fix itself before reporting a warning, and then the warning is not
> just that the window had this inconstant state which seems to give
> false positives, but it has been inconsistent for a set amount of time
> without fixing itself.
Too complex stuff for such a simple situation. Maybe one could
peek the event queue for an event that fixes the windows's size
and not complain if such an event is already pending? Another
option is to generate only a limited number of these warning for
each window.
Does the attached patch improve the situation?
> Anyways, for those of us who use FvwmIconMan as a growing/shrinking
> standalone module, this patch drastically reduces the amount of
> warnings, but I agree it really doesn't seem like the way to deal with
> this issue to make applications have to add these waits to deal with
> resizing both the window and the size hints.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From 8f74a2e6f1f0e059e9d1e073bace15a33dd2c016 Mon Sep 17 00:00:00 2001
From: Dominik Vogt <dominik.v...@gmx.de>
Date: Wed, 1 Mar 2017 17:24:13 +0100
Subject: [PATCH] Try to fix FvwmIconMan warnings.
---
fvwm/events.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index 980ccab..a7d41d0 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -3627,6 +3627,10 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
break;
}
case XA_WM_NORMAL_HINTS:
+ {
+ int do_check;
+ XEvent dummy;
+
/* just mark wm normal hints as changed and look them up when
* the next ConfigureRequest w/ x, y, width or height set
* arrives. */
@@ -3641,8 +3645,11 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
* Note that SET_HAS_NEW_WM_NORMAL_HINTS being set here to
* true is still valid.
*/
- GetWindowSizeHintsWithCheck(fw, 1);
+ do_check = !FCheckTypedWindowEvent(
+ dpy, FW_W(fw), ConfigureRequest, );
+ GetWindowSizeHintsWithCheck(fw, do_check);
break;
+ }
default:
if (te->xproperty.atom == _XA_WM_PROTOCOLS)
{
--
1.7.10.4
[fvwmorg/fvwm] 3bad8f: Add "J" function actions (late immediate).
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c https://github.com/fvwmorg/fvwm/commit/3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M doc/commands/AddToFunc.xml M fvwm/functions.c Log Message: --- Add "J" function actions (late immediate). This works like "I" but is executed later (once), when the user starts interacting with the function, e.g. on the first button release or if the pointer moves (and the function uses "M"). This can be used to write an "escalating" close function that runs on the first button release: AddToFunc CloseOrDestroy + J Close + D Destroy Run "Close" immediately (but not right when the button is pressed) and follow up with a Destroy in case of a double click. Compared to the normal "+ C Close" this avoids the double click delay before the action is triggered. Commit: ffe942d66cdb1a24d761d9e89c1a4dab49f2400c https://github.com/fvwmorg/fvwm/commit/ffe942d66cdb1a24d761d9e89c1a4dab49f2400c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Compare: https://github.com/fvwmorg/fvwm/compare/fa8125cec830...ffe942d66cdb
[fvwmorg/fvwm] 3bad8f: Add "J" function actions (late immediate).
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c https://github.com/fvwmorg/fvwm/commit/3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M doc/commands/AddToFunc.xml M fvwm/functions.c Log Message: --- Add "J" function actions (late immediate). This works like "I" but is executed later (once), when the user starts interacting with the function, e.g. on the first button release or if the pointer moves (and the function uses "M"). This can be used to write an "escalating" close function that runs on the first button release: AddToFunc CloseOrDestroy + J Close + D Destroy Run "Close" immediately (but not right when the button is pressed) and follow up with a Destroy in case of a double click. Compared to the normal "+ C Close" this avoids the double click delay before the action is triggered. Commit: ffe942d66cdb1a24d761d9e89c1a4dab49f2400c https://github.com/fvwmorg/fvwm/commit/ffe942d66cdb1a24d761d9e89c1a4dab49f2400c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Commit: 3ecfb3d3080a34507840d427d7ae32d0dd847f39 https://github.com/fvwmorg/fvwm/commit/3ecfb3d3080a34507840d427d7ae32d0dd847f39 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: A fvwm/ChangeLog A libs/ChangeLog Log Message: --- ChangeLog. Compare: https://github.com/fvwmorg/fvwm/compare/5c75103c1224...3ecfb3d3080a
Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration
On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote: > > > > If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5 > > > file (from the URL) *except* either: > > > > > > Mouse 1 A MS Iconify > > > or > > > Mouse 1 A M Raise Try mouse 1 tsifw ... instead. Limit the context a binding applies to to what is needed. It's inefficient and interferes with other programs' bindings. Or do you really iconify windows by clicking on the root window? > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence > > > in xev Forget about these; that's just how X works. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmIconMan still sometimes triggers Hint Warnings
On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
> <jaimosskril...@gmail.com> wrote:
> > Hello,
> >
> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>
> I wrote this small patch that has FvwmIconMan wait until the window
> has resized to set the window hints. This is in the lines of Dominik
> Vogt's patch, but waits until FvwmIconMan has fully resized to run
> fix_manager_size() to set the window hints. My tests here no longer
> seem to tiger the warnings like it still sometimes did.
>
> As an additional thought, talking to Thomas Adam about the patch in
> #fvwm, he mentioned that the issue is more FVWM being overly cautious
> and the fix should be in how fvwm handles size hint warnings over
> working with FvwmIconMan to avoid triggering them.
>
> I don't know enough about the issue to say which is more appropriate,
> but here is a patch that stops the warnings from being triggered in my
> tests.
Changing window geometry and hints has inherent race conditions by
design of the X protocol, unless every change is synchronized with
the server, and even then it's impossible to avoid some
inconsistencies. For example, there is no way to change the
window size and the requested min/max size in one atomic action.
Even more, there are lots of applications that set invalid hints
or in an ambigouos way. The window manager has to guess the
apllication's intention in such cases. A while ago I've started
adding more warnings to Fvwm in order to better identify such
situations, but this specific one has too many false positives.
Patching the application to wait for something happening is
definitely the wrong approach, not just because it is inefficient
but because there is no guarantee that the window manager ever
honours such requests.
So, if it's not possible to completely fix FvwmIconMan in a decent
way, what do we do with the warning? I'd rather not disable it,
but the number of false positives is too high. One could make a
style that disables the warning for a certain class of windows,
but that would probably be used as "style * ...", disabling the
warning for everything. :-/
> From 227d7ea2597ec3fec304c53934fcc41773ab7e89 Mon Sep 17 00:00:00 2001
> From: Jaimos Skriletz <jaimosskril...@gmail.com>
> Date: Tue, 28 Feb 2017 17:43:12 -0700
> Subject: [PATCH 1/1] Wait until FvwmIconMan is resized to set window HINTS
>
> ---
> modules/FvwmIconMan/xmanager.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/modules/FvwmIconMan/xmanager.c b/modules/FvwmIconMan/xmanager.c
> index 58eaaedc..b4efe890 100644
> --- a/modules/FvwmIconMan/xmanager.c
> +++ b/modules/FvwmIconMan/xmanager.c
> @@ -439,6 +439,16 @@ static void resize_window(WinManager *man)
> }
> MyXUngrabServer(theDisplay);
>}
> +
> + // Wait until the window has resised to fix the HINTS.
> + // counter is used to break an infinte loop.
> + XWindowAttributes attribs;
> + int counter = 2;
> + while ( counter && (attribs.width != man->geometry.width ||
> + attribs.height != man->geometry.height)) {
> +XGetWindowAttributes(theDisplay, man->theWindow, );
> +counter--;
> + }
>fix_manager_size(man, man->geometry.width, man->geometry.height);
> }
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Menu hot keys with accented characters
On Sun, Jan 08, 2017 at 11:13:52AM -0700, Jaimos Skriletz wrote:
> On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
> >> Here is an old (minor) bug that is lurking in the Debian BTS.
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
> >>
> >> The bug is that when assigning non ASCII keys as hot keys in a Menu,
> >> the underline underlines the non ASCII character and the one after it.
> >
> > Hotkeys must be printable 7 bit Ascii characters, which is
> > probably not documented. The reason for this is that the hotkey
> > is specified as a substring from the item label (e.g. "á") instead
> > of a key name ("aacute"). X has no real way to convert a string
> > into a key name or vice versa, so hotkeys work only for keys where
> > both representations are the same.
> >
>
> If keybindings for non 7 bit ASCII keys don't work, documentation
> could be useful. Though this has been around for a long time and not
> many seem to mention it so it probably isn't a big deal in the overall
> picture.
This may be a real issue for automatic hotkeys in languages other
than English. Words beginning with non-latin letters like Ü, Á
etc. are not uncommon in European languages.
> > I can reproduce the drawing bug. Maybe we should simply disable
> > hotkeys completely for anything not 7 bit ASCII.
> >
>
> Disabling the keys since they aren't working anyways and giving a
> warning may be useful for those who try to use non ASCII characters.
> Such a warning should only trigger when items are added to the menu,
> not each time the menu pops up.
Yes, a warning if it's a manual hotkey, at least. Not sure what
to do about automatic ones. It may be confusing to get no hotkey
without a warning (and without iconv we can't reliably look past
the first letter). On the other hand the user has probably not
asked for warnings regarding automatic hotkeys.
> At least this way if anyone tries to use non-ASCII characters they are
> correctly informed that they do not work and this can move to a
> feature request to add support for these keys.
I *could* implement the table I mentioned (there are several
version floating around the net) to get non-Ascii hotkeys working,
but then we might as well leave hotkeys as they are in fvwm-2.x
and rewrite the hotkey syntax to allow specifying key names for
fvwm-3.x. E.g. "&(aacute)" or something like that, or even
ábc use "á" as hotkey if iconv support is compiled in
(using a built-in table), otherwise no automatic
hotkey. Maybe rather use b as the hotkey as there's
no guarantee the keyboard has a key for á?
&ábcif iconv support is compiled in; automatic hotkeys
work; use built-in table
&(aacute) string representation of a keysym (XStringToKeysym)
&(12345)numeric representation of a keysym
Too stupid that X has no way to convert keysyms into printable
strings and vice versa.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Menu hot keys with accented characters
On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
> Here is an old (minor) bug that is lurking in the Debian BTS.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
>
> The bug is that when assigning non ASCII keys as hot keys in a Menu,
> the underline underlines the non ASCII character and the one after it.
Hotkeys must be printable 7 bit Ascii characters, which is
probably not documented. The reason for this is that the hotkey
is specified as a substring from the item label (e.g. "á") instead
of a key name ("aacute"). X has no real way to convert a string
into a key name or vice versa, so hotkeys work only for keys where
both representations are the same.
A solution for this would be to hard code a unicode-to-keysym
table inside fvwm and also requires iconv support. :-/
> Here is a simple test
>
> DestroyMenu TestMenu
> AddToMenu TestMenu "Test" Title
> + "T&êst" Echo Test
> + "&ñice one" Echo Nice One
> + "Th&ááát" Echo Thaaat
> + " One" Echo This
>
> Then open the menu.
I can reproduce the drawing bug. Maybe we should simply disable
hotkeys completely for anything not 7 bit ASCII.
> In addition to the visual bug, I was not able to correctly use these
> non-ASCII characters as hot keys. Since I don't have a keyboard that
> has accented keys on them it could be that I can't properly test if
> they work as hot keys (since I have to hit alt-key to type them).
To test it:
$ xmodmap -pki > ~/xmm
# edit some key binding in ~/xmm
$ xmodmap ~/xmm
> Seems there was once a patch trying to make these hot keys work better
>
> http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01916.html
>
> Unsure if the bug is just an extra character is underlined in the Menu
> or if using non ASCII characters for hot-keys doesn't work.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Improving the default config
See branch dv/devel for various patches.
On Sat, Dec 31, 2016 at 07:26:54AM -0700, Jaimos Skriletz wrote:
> On Sat, Dec 31, 2016 at 6:03 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > 1. In the log there is
> >
> > Traceback (most recent call last):
> > File "/home/luthien/bin/fvwm-menu-desktop", line 78, in
> > import xdg.Menu
> > ImportError: No module named xdg.Menu
> >
> >We should get rid of any error messages during startup, even if
> >some things may not be installed.
> >
> > 1b. In the builtin menu (if no config is used), the above message
> >is generated every time you move the pointer over the xdg menu
> >item.
> >
>
> Yes we should deal with the case either python or python-xdg is not
> installed. Unsure if there is a way we can test for python-xdg with
> Test or if that should be done in the fvwm-menu-desktop script. I
> would like the script to error out if run from a console and
> python-xdg is not installed so the user is aware of a missing
> component, so maybe add a -q/--quiet option that can be used in the
> config to just have it quietly exit if python-xdg is not installed.
>
> > 2. Are the buttons of inactive windows really meant to look like
> >in the attached image? NeverFocus windows like Xclock don't
> >ever get their buttons drawn properly.
> >
>
> Yes that is how the config draws inactive buttons. This can be
> changed, I just copied this from my setup.
>
> > 3. The main menu has a submenu for module manpages, but not a
> >submenu to start them. Weird.
> >
>
> This was brought up and is something that could be added. Though
> outside of FvwmConsole I personally don't know what other modules
> would be that useful to have in a menu to be launched, without some
> additional configurations of the module. But by all means add a
> submenu.
>
> > 4. The "Copy config" dialog should *really* state the filename of
> >the config file it generates, not just the target directory.
> >
>
> Okay.
>
> > 5. Double clicking the top left window button does not close the
> >window. The menu needs a doubleclick action:
> >
> > Mouse 1 1 A Menu MenuWindowOps delete
> >
> >(or maybe "destroy" instead).
> >
>
> I would not think that double clicking the menu button would close a
> window. But this could be added, though I don't see why since this can
> be done via the X button.
It's a historical thing. Double clicking that button close
windows long before the X button even appeared.
See dv/devel.
> > 6. Clicking the "X" button works only with a delay.
> >
>
> It is set up for a single click is Close and a double click is
> Destroy. So the delay is just the function waiting for ClickTime to
> pass to make sure it wasn't a double click.
I know, but it's annoying. Shouldn't that button just bind
"Delete" on a click? More forceful methods of closing are
available through the window menu.
The first patch on the branch is an attempt to close the window
earlier, but it doesn't actually work as we have to wait for the
end of the function anyway.
> > 7. The config uses button 4+5 for window shading. It shouldn't
> >require any non-standard mouse buttons for that.
> >
> > Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> > Mouse 5TA MoveClickX Nop Raise "WindowShade False"
> >
> >Also, this should really be just
> >
> > Mouse 4TA WindowShade True
> > Mouse 5TA WindowShade False
> >
> >Otherwise it may or may not raise the window when pushing a
> >mouse wheel, depending on the speed of the wheel.
>
> Fine, again just another thing adopted because I prefer the double
> click here, but your solution is simpler.
See dv/devel.
> > 8. The MoveClickX function is used even for functions that do not
> >have a doubleclick action ("Nop" instead). Therefore clicking
> >such a indow button works only with a delay (coubleclicktime),
> >and it won't work at all if you double click:
> >
> > Mouse 1FS A MoveClickX Resize Raise Nop
See dv/devel.
> > 9. Similarly, a button with "Nop" move action won't do anything if
> >you happen to move the mouse while clicking:
> >
> > Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> >
>
> Didn't consider that as I'm just use to it, I was just trying to avoid
> writing multple functions, but I agree it would be better to not have
>
Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer
On Sat, Dec 31, 2016 at 05:37:45AM -0700, Jaimos Skriletz wrote: > On Sat, Dec 31, 2016 at 4:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote: > >> On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote: > >> >> Hello, > >> >> > >> >> This was reported by a Debian user. Please retain the CC to > >> >> 802604-forwar...@bugs.debian.org in your response, so that > >> >> the Debian BTS has a record. > >> >> > >> >> In short if the mouse cursor is over the root window and hidden with > >> >> unclutter, when switching pages (and maybe desks), focus is not given > >> >> to the window under the pointer. > >> > > >> > Works fine for me. I'd need a precise description + config file > >> > to test this. > >> > > >> > >> Using SloppyFocus with a 2x2 grid of pages with the default config and > >> the following two key bindings > >> > >> Key Right A CM Scroll 100 0 > >> Key Left A CM Scroll -100 0 > >> > >> I then run unclutter to hide the mouse after being idle for a second: > >> > >> unclutter -idle 1 -root > >> > >> I move the mouse over the root window and wait for it to be hidden. > >> Once it is hidden > >> I use the key binding to switch to a new page. After I switch to the > >> page focus is kept > >> on the window in the old page and is not transferred. > > > > Still does not happen for me. With unclutter 8-18 (Debian): > > > > * Start fvwm with default config. > > * Open two Xterms from the menu (left side of screen). > > * Open FvwmConsole and move it to the bottom right corner. > > * Type > > style * sloppyfocus > > Key Right A CM Scroll 100 0 > > Key Left A CM Scroll -100 0 > >in FvwmConsole. > > * Run "unclutter -idle 1 -root" from one of the Xterms. > > * Press ctrl-alt-right to switch to page (1 0). > > * (Optional: open an Xterm there and close it to take away the > >focus from any window on (0 0).) > > * Move the pointer roughly to the middle of the FvwmConsole > >window. > > * Press ctrl-alt-left to switch to page (0 0). > > => The pointer ends up over FvwmConsole which gets the focus. > > > > These steps work for me. "Work" = "the window does not get focus"? > I tried with various versions of the optional > step, though in my tests I left the xterm around, but this did not > seem to matter, Leaving the xterm or not did not change the result. Neither for me. > Unsure how else to describe it as those steps cause this to happen, > just tested again in a VM and have attached screen shots to show how > the focus is right before and right after I switch pages. In the > before picture the mouse is in the bottom right corner over the root > window near the panel (but not over it) and unclutter has hidden the > mouse. > > Only other thing I note, as soon as I move the mouse, focus is then > given to the window under the mouse, but until then it remains on the > window on the previous page. You probably have a different version of unclutter. In the past, there was some change of the method it uses to hide the pointer. his may well play a role here. Can you find out which version you have? I guess it's something that should be fixed in unclutter if it's still an issue with the latest version. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer
On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote: > On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote: > >> Hello, > >> > >> This was reported by a Debian user. Please retain the CC to > >> 802604-forwar...@bugs.debian.org in your response, so that > >> the Debian BTS has a record. > >> > >> In short if the mouse cursor is over the root window and hidden with > >> unclutter, when switching pages (and maybe desks), focus is not given > >> to the window under the pointer. > > > > Works fine for me. I'd need a precise description + config file > > to test this. > > > > Using SloppyFocus with a 2x2 grid of pages with the default config and > the following two key bindings > > Key Right A CM Scroll 100 0 > Key Left A CM Scroll -100 0 > > I then run unclutter to hide the mouse after being idle for a second: > > unclutter -idle 1 -root > > I move the mouse over the root window and wait for it to be hidden. > Once it is hidden > I use the key binding to switch to a new page. After I switch to the > page focus is kept > on the window in the old page and is not transferred. Still does not happen for me. With unclutter 8-18 (Debian): * Start fvwm with default config. * Open two Xterms from the menu (left side of screen). * Open FvwmConsole and move it to the bottom right corner. * Type style * sloppyfocus Key Right A CM Scroll 100 0 Key Left A CM Scroll -100 0 in FvwmConsole. * Run "unclutter -idle 1 -root" from one of the Xterms. * Press ctrl-alt-right to switch to page (1 0). * (Optional: open an Xterm there and close it to take away the focus from any window on (0 0).) * Move the pointer roughly to the middle of the FvwmConsole window. * Press ctrl-alt-left to switch to page (0 0). => The pointer ends up over FvwmConsole which gets the focus. > Note: If the mouse is over a window (hidden or not) this does not > happen and focus is transfered. If the mouse is visible over the root > window this does not happen either. It needs to be hidden. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Sat, Dec 31, 2016 at 01:07:59AM +, Thomas Adam wrote: > On Fri, Dec 30, 2016 at 11:20:59PM +0100, Dominik Vogt wrote: > > > EWMHBaseSTruts is not a Style, > > > > What? Should have paid more attention when this stuff was > > written. Got to fix this some time. > > Curious. Why? What benefit would it have to be a style? Flexibility, as always. > If it's about > applying size limits to certain windows, we already have a number of different > ways to specify that. Everything that affects windows affects either a window's state or it's style. We've spent a lot of time to eradicate global window settings; the EwmhBaseStruts command is an anachronism, imposing artificial limitations on windows when it could be expressed as Style * EwmhBaseStruts a b c d as well. > Making it per-screen is a better idea (I've a patch for that in an older CVS > tree, probably on Github). That doesn't rule out making it a style. > EWMHBaseStruts is about screen edges, not windows. It's about areas where windows are not to be placed, so it's clearly about windows. > Don't go perturbing this option. It should be deprecated and made a style instead (or possibly a collection of styles), like everything else related to windows. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] b2f4bc: !!! Start work on replacing the parsing in __execu...
Branch: refs/heads/dv/new-parser-2 Home: https://github.com/fvwmorg/fvwm Commit: b2f4bce686118c71e3b2c22c2905479588af303f https://github.com/fvwmorg/fvwm/commit/b2f4bce686118c71e3b2c22c2905479588af303f Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/Makefile.am M fvwm/add_window.c M fvwm/builtins.c A fvwm/cmdparser.h A fvwm/cmdparser_old.c A fvwm/cmdparser_old.h M fvwm/colorset.c M fvwm/conditional.c M fvwm/events.c M fvwm/ewmh.c M fvwm/ewmh_events.c M fvwm/expand.c M fvwm/expand.h M fvwm/functions.c M fvwm/functions.h M fvwm/fvwm.c M fvwm/fvwm.h M fvwm/menucmd.c M fvwm/menus.c M fvwm/module_interface.c M fvwm/move_resize.c M fvwm/read.c M fvwm/repeat.c M fvwm/schedule.c M fvwm/update.c M fvwm/virtual.c M fvwm/windowlist.c Log Message: --- !!! Start work on replacing the parsing in __execute_command_line ... ... with hook functions that are implemented elsewhere. This aims at allowing to writing and testing multiple parsers in parallel and at moving all parsing and expansion stuff to a different place. Commit: e4ee0c738b5df1504d6a8736e3ebf93f86a3a28c https://github.com/fvwmorg/fvwm/commit/e4ee0c738b5df1504d6a8736e3ebf93f86a3a28c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser.h M fvwm/cmdparser_old.c M fvwm/functions.c Log Message: --- add debug output and fix positional arguments Commit: a8d1bf48531d00c10dc17ed3ba95905ca0b4748e https://github.com/fvwmorg/fvwm/commit/a8d1bf48531d00c10dc17ed3ba95905ca0b4748e Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser_old.c M fvwm/functions.c Log Message: --- add debug output and fix command line prefixes Commit: a7a34304f8bb06013b4189f67da44092f1795ec5 https://github.com/fvwmorg/fvwm/commit/a7a34304f8bb06013b4189f67da44092f1795ec5 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/Makefile.am M fvwm/cmdparser.h A fvwm/cmdparser_hooks.h M fvwm/cmdparser_old.c M fvwm/conditional.h M fvwm/functable.c M fvwm/functable.h A fvwm/functable_complex.c A fvwm/functable_complex.h M fvwm/functions.c M fvwm/functions.h M fvwm/fvwm.h M fvwm/misc.c M fvwm/repeat.c M fvwm/screen.h M libs/FScreen.h Log Message: --- Convert special logic in __execute_command_line for functions ... ... that may move a window to a separate function flag. Move find_builtin_function() to functable.[ch]. Moved some functions to functable.[ch] and functable_complex.[ch]. This separation is needed for the parsing hooks. It was very difficult to get the #icludes right. The DesktopsInfo structure was moved to libs/FScreen.h so that the library does not depend on core header files anymore. Move WindowConditionMask from mvwm.h to conditional.h. Finish 1st draft of hook implementation (__execute_command_line) Commit: 18e740675182d319189d298f2d27abd53b15b15c https://github.com/fvwmorg/fvwm/commit/18e740675182d319189d298f2d27abd53b15b15c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser.h M fvwm/cmdparser_hooks.h M fvwm/cmdparser_old.c M fvwm/expand.c M fvwm/functions.c Log Message: --- Split pos_args into a string with all positional args and an array. Commit: ce22e8d80c29240799f75aa3f1e659cffbfbbde6 https://github.com/fvwmorg/fvwm/commit/ce22e8d80c29240799f75aa3f1e659cffbfbbde6 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/builtins.c M fvwm/events.c Log Message: --- Update execute_function calls for libstroke. Commit: 4149c9a1234627cc0a40ee696e86e5fe364a2c80 https://github.com/fvwmorg/fvwm/commit/4149c9a1234627cc0a40ee696e86e5fe364a2c80 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser_old.c M fvwm/functions.c M fvwm/modconf.c M modules/FvwmButtons/dynamic.c Log Message: --- !!!debug fprintfs Commit: 82672e0e905aca13b9a2615215488a2a549255d9 https://github.com/fvwmorg/fvwm/commit/82672e0e905aca13b9a2615215488a2a549255d9 Author: Thomas Adam <tho...@fvwm.org> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M libs/FScreen.h Log Message: --- Reinstate libs/FScreen.h Commit: ab97d146234acf939f520cff4ed0569cf8a24ecc https://github.com/fvwmorg/fvwm/commit/ab97d146234acf939f520cff4ed0569cf8a24ecc Author: Thomas Adam <tho...@fvwm.org&
[fvwmorg/fvwm] 7cfd20: Improve and clean up size hints warnings.
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 7cfd209e17ed88c34f7ec9318dd82aabc3757baa https://github.com/fvwmorg/fvwm/commit/7cfd209e17ed88c34f7ec9318dd82aabc3757baa Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/add_window.c Log Message: --- Improve and clean up size hints warnings. Commit: e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 https://github.com/fvwmorg/fvwm/commit/e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M modules/FvwmIconMan/xmanager.c Log Message: --- FvwmIconMan: Don't trigger size hints warning in fvwm core. Commit: 5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 https://github.com/fvwmorg/fvwm/commit/5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wrong. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications. Commit: ccea4a057b8dca8657da9f3a505022716ce91999 https://github.com/fvwmorg/fvwm/commit/ccea4a057b8dca8657da9f3a505022716ce91999 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Commit: 2db6922a298738568c3a012e5a62183efe543e48 https://github.com/fvwmorg/fvwm/commit/2db6922a298738568c3a012e5a62183efe543e48 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M bin/Makefile.am M configure.ac M doc/fvwm/Makefile.am M fvwm/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmAuto/Makefile.am M modules/FvwmBacker/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am R modules/FvwmCommand/FvwmCommandS.c M modules/FvwmCommand/Makefile.am A modules/FvwmCommandS/FvwmCommand.h A modules/FvwmCommandS/FvwmCommandS.c A modules/FvwmCommandS/Makefile.am A modules/FvwmCommandS/fifos.c M modules/FvwmConsole/Makefile.am M modules/FvwmCpp/Makefile.am M modules/FvwmEvent/Makefile.am M modules/FvwmForm/Makefile.am M modules/FvwmIconMan/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmM4/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmPerl/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmRearrange/Makefile.am M modules/FvwmScript/Makefile.am M modules/Makefile.am Log Message: --- Fix installation and uninstallation with --program-transform-name. Had to move FvwmCommandS to a different subdir to do this. Commit: 359820be6d7b85b9ceb796a7f1a03c964f08d9d2 https://github.com/fvwmorg/fvwm/commit/359820be6d7b85b9ceb796a7f1a03c964f08d9d2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Compare: https://github.com/fvwmorg/fvwm/compare/9a57db1dd4ae...359820be6d7b
[fvwmorg/fvwm] 7cfd20: Improve and clean up size hints warnings.
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 7cfd209e17ed88c34f7ec9318dd82aabc3757baa https://github.com/fvwmorg/fvwm/commit/7cfd209e17ed88c34f7ec9318dd82aabc3757baa Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/add_window.c Log Message: --- Improve and clean up size hints warnings. Commit: e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 https://github.com/fvwmorg/fvwm/commit/e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M modules/FvwmIconMan/xmanager.c Log Message: --- FvwmIconMan: Don't trigger size hints warning in fvwm core. Commit: 5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 https://github.com/fvwmorg/fvwm/commit/5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wrong. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications. Commit: ccea4a057b8dca8657da9f3a505022716ce91999 https://github.com/fvwmorg/fvwm/commit/ccea4a057b8dca8657da9f3a505022716ce91999 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Commit: 2db6922a298738568c3a012e5a62183efe543e48 https://github.com/fvwmorg/fvwm/commit/2db6922a298738568c3a012e5a62183efe543e48 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M bin/Makefile.am M configure.ac M doc/fvwm/Makefile.am M fvwm/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmAuto/Makefile.am M modules/FvwmBacker/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am R modules/FvwmCommand/FvwmCommandS.c M modules/FvwmCommand/Makefile.am A modules/FvwmCommandS/FvwmCommand.h A modules/FvwmCommandS/FvwmCommandS.c A modules/FvwmCommandS/Makefile.am A modules/FvwmCommandS/fifos.c M modules/FvwmConsole/Makefile.am M modules/FvwmCpp/Makefile.am M modules/FvwmEvent/Makefile.am M modules/FvwmForm/Makefile.am M modules/FvwmIconMan/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmM4/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmPerl/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmRearrange/Makefile.am M modules/FvwmScript/Makefile.am M modules/Makefile.am Log Message: --- Fix installation and uninstallation with --program-transform-name. Had to move FvwmCommandS to a different subdir to do this. Commit: 359820be6d7b85b9ceb796a7f1a03c964f08d9d2 https://github.com/fvwmorg/fvwm/commit/359820be6d7b85b9ceb796a7f1a03c964f08d9d2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Compare: https://github.com/fvwmorg/fvwm/compare/7cfd209e17ed^...359820be6d7b
Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed
On Tue, Dec 27, 2016 at 05:34:08PM -0700, Jaimos Skriletz wrote: > On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz > <jaimosskril...@gmail.com> wrote: > > On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote: > >>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz > >>> <jaimosskril...@gmail.com> wrote: > >>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> > >>> > wrote: > >>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote: > >>> >>> Hello, > >>> >>> > >>> >>> This was reported by a Debian user. Please retain the CC to > >>> >>> 849355-forwar...@bugs.debian.org in your response, so that > >>> >>> the Debian BTS has a record. > >>> >>> > >>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when > >>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and > >>> >>> previous versions) so I can also say it affects my Debian system. > >>> >> > >>> >> > >>> >> I don't get any such messages with or without FvwmIconMan. Can > >>> >> you give detailed instructions pelase? > >>> >> > >>> > > >>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian > >>> > patches, but I will compile a version without patches and test. > >>> > > >>> > >>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches, > >>> same issue. > >>> > >>> > > >>> > I tested this with other windows and modules. FvwmScript modules > >>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to > >>> > do with transient windows or not (just something I noticed). > >>> > > >>> > >>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it > >>> was not producing the warning was it was configured so FvwmIconMan did > >>> not create a button for that window. > >>> > >>> After further testing the warning seems to be due to be caused by > >>> adding/removing the button for a window from FvwmIconMan. Windows that > >>> appear there trigger the warning but ones that don't appear don't. > >> > >> Still no luck to reproduce it. After said message there should > >> always be this one which prints all the details of the window and > >> the faulty hints: > >> > >> fvwm_msg( > >> WARN, "GetWindowSizeHints", > >> "The application window (id %#lx)\n" > >> " \"%s\" has broken size hints (%s).\n" > >> "fvwm is ignoring those hints. " > >> " hint override = %d, flags = %lx\n" > >> " min_width = %d, min_height = %d, " > >> "max_width = %d, max_height = %d\n" > >> " width_inc = %d, height_inc = %d\n" > >> " min_aspect = %d/%d, max_aspect = %d/%d\n" > >> " base_width = %d, base_height = %d\n" > >> " win_gravity = %d\n", > >> > > > > I get no other output after the warning, so that message is never > > printed to stderr on my system. > > > > Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod, > > and get the output > > > > _cdim: not moved 0x55927d4a8990 'FvwmIconMan' > > > > after each time the warning is produced. > > Further testing, if I set the ManagerGeometry to something like 5x3 so > FvwmIconMan doesn't resize itself, I no longer get the warning. It is > only with the default like 0x1, causing the window to grow/shrink I > get the warning. Could be reproduced with a standalone FvwmIconMan (instead of the one inside FvwmButtons). > Wild guess, could it be some timing issue during the resizing of the > window when adding/removing a button cause the window's current size > to become invalid as per the warning? Roughly, yes. FvwmIconMan sets the minimum and maximum width and height size hints to the new geometry it wants, then requests the new size. When fvwm reads the new hints, the current geometry of the manager window becomes obviously invalid until the window is also resized. That's what triggers the warning. So, to fix this: 1. Remove the size restrictions, then resize, then set the new size restrictions. Theoretically the winodw might be resized by the user in between, but that's highly unlikely. 2. Also print the size hints that trigger this warning in a second message. Fixed on the (new) fvwm2-stable branch; patch for the development branches will follow one I've figured out how to deal with the two repositories. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed
On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote: > On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz > <jaimosskril...@gmail.com> wrote: > > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote: > >>> Hello, > >>> > >>> This was reported by a Debian user. Please retain the CC to > >>> 849355-forwar...@bugs.debian.org in your response, so that > >>> the Debian BTS has a record. > >>> > >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when > >>> opening and closing windows. I too have had this issue in 2.6.7 (and > >>> previous versions) so I can also say it affects my Debian system. > >> > >> > >> I don't get any such messages with or without FvwmIconMan. Can > >> you give detailed instructions pelase? > >> > > > > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian > > patches, but I will compile a version without patches and test. > > > > Tested with a fresh compile of Fvwm 2.6.7 without any debian patches, > same issue. > > > > > I tested this with other windows and modules. FvwmScript modules > > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to > > do with transient windows or not (just something I noticed). > > > > Nevermind this, FvwmIdentify is not a traisnent window, the reason it > was not producing the warning was it was configured so FvwmIconMan did > not create a button for that window. > > After further testing the warning seems to be due to be caused by > adding/removing the button for a window from FvwmIconMan. Windows that > appear there trigger the warning but ones that don't appear don't. Still no luck to reproduce it. After said message there should always be this one which prints all the details of the window and the faulty hints: fvwm_msg( WARN, "GetWindowSizeHints", "The application window (id %#lx)\n" " \"%s\" has broken size hints (%s).\n" "fvwm is ignoring those hints. " " hint override = %d, flags = %lx\n" " min_width = %d, min_height = %d, " "max_width = %d, max_height = %d\n" " width_inc = %d, height_inc = %d\n" " min_aspect = %d/%d, max_aspect = %d/%d\n" " base_width = %d, base_height = %d\n" " win_gravity = %d\n", Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Mon, Nov 21, 2016 at 06:25:29PM +, Jürgen Hartmann wrote: > > It's really complicated, but let me try to explain what's going > > on, in case we need to understand why I made the current patch - > > at some time in the distant future. > > [Very thorough and enlightening explanation skipped.] > > > Duh. > > > > Obviously vmplayer cannot handle this strange situation and ends > > up with no window mapped. > > Thank you for this comprehensive explanation including references for further > reading (ICCCM2). > > > As far as I understand it, HandleUnmapNotify() is broken at least > > since the day in 1998 when the fvwm sources were moved to CVS. > > I've spent much time thinking about this, reading the ICCCM2 and > > the Xlib manuals, and now I'm convinced that HandleUnmapNotify() > > must never unmap the client window itself. (The *icon* window is > > a different story.) However, since there's no documentation about > > this bit of code, it's hard to guess whether there are or were > > really broken clients that needed this buggy window manager > > behaviour. Anyway, if there are such clients, they won't work on > > any modern window manager. > > > > Over the years there were several patches to fix problems caused > > by unmapping windows in HandleUnmapNotify, but none of us ever > > figured out the real bug for more than fifteen years. :-/ > > So this fix of yours really seems to be a big step. > > How would you judge its behavior concerning stability and side effects: > Would it be to risky to use it right away in a production system, aka > "testing under wild life conditions"? The worst that can happen is that different windows aren't accessible. Regarding stability, I'd say the patched code is how it should have been from the start, but you never know what strange and broken applications are around and how they react to changes in the events before you just try it for a while. This certainly needs testing. However, this patch only affects clients that do things like iconifying or withdrawing their windows, i.e. the vast majority of programs won't be affected, but you never know what closed source programs until they break. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Mon, Nov 21, 2016 at 12:27:45AM +, Jürgen Hartmann wrote: > Concerning side effects, I can't say anything since I have no idea what > to look for. > > > Now, if I'd understand what (a) the patch in > > HandleMapRequestKeepRaised() is supposed to do, > > Which patch do you mean? Does the piece of code that you disable in events.c > origins from an earlier patch? Yes, it that piece may have been an attempt to fix the same or a similar bug with another application. It's really complicated, but let me try to explain what's going on, in case we need to understand why I made the current patch - at some time in the distant future. -- 1) Window managers have special powers in X. In the presence of a window manager, certain requests of the clients are "redirected" to the window manager for confirmation. In the case at hand, clients cannot map top level windows without the window manager's consent (i.e. the MapRequest event gets redirected to the window manager). The same is not true for unmapping. Clients can always unmap their windows; the window manager is just informed when that happens. 2) There is this old "Inter Client Communication Conventions Manual" version 2, that defines three distinct window states that any window manager should implement: normal, iconic and withdrawn. The latter means that neither the window nor its icon are visible. The ICCCM2 also describes how to get a window from each state into the other two states. 3) To withdraw a normal or iconic window, the client is supposed to first unmap the main window. As the window may not be mapped at that time, for example if its iconic, the window manager may not receive an UnmapNotify event for that. To make sure that the window manager gets it, the client is supposed to send a synthetic UnmapNotify event to the root window (the window manager always gets events for the root window). (This synthetic event contains the id of the unmapped window.) In response to this event, the window manager is supposed to write down that the window is now in withdrawn state, and unmap the *icon window* if its visible. 4) In HandleUnmapEvent() there was some code from the ancient past of fvwm, that - whenever fvwm received an UnmapNotify (that it did not trigger itself) - *it would unmap the window (that is was just told has already been unmapped*. I can only guess why this code was there, maybe the author thought that the client was asking for permission to unmap the window. 5) For some strange reason, when vmplayer wants to un-fullscreen a window, it requests the window manager to end fullscreen state, then withdraws the window as described above, and after that I lost interest in event debugging. Supposedly it maps the window again after that. ==> Putting it all together: * vmplayer requests end of fullscreen mode * vmplayer unmaps the window * vmplayer sends the synthetic event as described above * vmplayer maps the window again (which needs fvwm's consent). * fvwm receives the events generated by vmplayer * fvwm looks at the two UnmapNotify events it gets (one real and the syntehtic one) and calls XUnmapWindow. This generates another UnmapNotify event. * fvwm sees the MapRequest and generates the decorations for the window. * fvwm receives the UnmapNotify it generated itself, destroys the decorations and leaves the window unmapped. Duh. Obviously vmplayer cannot handle this strange situation and ends up with no window mapped. -- As far as I understand it, HandleUnmapNotify() is broken at least since the day in 1998 when the fvwm sources were moved to CVS. I've spent much time thinking about this, reading the ICCCM2 and the Xlib manuals, and now I'm convinced that HandleUnmapNotify() must never unmap the client window itself. (The *icon* window is a different story.) However, since there's no documentation about this bit of code, it's hard to guess whether there are or were really broken clients that needed this buggy window manager behaviour. Anyway, if there are such clients, they won't work on any modern window manager. Over the years there were several patches to fix problems caused by unmapping windows in HandleUnmapNotify, but none of us ever figured out the real bug for more than fifteen years. :-/ Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] b1912e: Fix disappearing windows.
Branch: refs/heads/dv/fix-disappering-windows Home: https://github.com/fvwmorg/fvwm Commit: b1912ee1d0af84aef588bebb4b37a118a91ec6a8 https://github.com/fvwmorg/fvwm/commit/b1912ee1d0af84aef588bebb4b37a118a91ec6a8 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-11-21 (Mon, 21 Nov 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wron. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications.
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Sun, Nov 20, 2016 at 10:02:39PM +, Jürgen Hartmann wrote:
> > > What is the secret behind this move? How does it work?
> >
> > I have no idea, and I'd not even call that a workaround. It just
> > seems that if you change random things, it starts to work.
>
> I see. That obsoletes my next question in the queue addressing side effects.
>
> What would you propose to proceed?
1) Don't panic. ;)
2) Try the attached patch.
Now, if I'd understand what (a) the patch in
HandleMapRequestKeepRaised() is supposed to do, and (b) why
XUnmapWIndow() is called in HandleUnmapNotify(), I think I could
write a decent fix instead of jsut disabling the parts of the code
that cause trouble.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From c179137faffbdebc5e2875a0f418b4679dc4fe94 Mon Sep 17 00:00:00 2001
From: Dominik Vogt <dominik.v...@gmx.de>
Date: Sun, 20 Nov 2016 23:47:52 +0100
Subject: [PATCH] fix
---
fvwm/events.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index cc4cc8f..93cb251 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -518,6 +518,7 @@ static Bool test_map_request(
return rc;
}
+#if 0 /*!!!*/
/* Test for ICCCM2 withdraw requests by syntetic events on the root window */
static Bool test_withdraw_request(
Display *display, XEvent *event, XPointer arg)
@@ -544,6 +545,7 @@ static Bool test_withdraw_request(
return rc;
}
+#endif
static int _pred_weed_accumulate_expose(
Display *display, XEvent *ev, XPointer arg)
@@ -3339,6 +3341,7 @@ void HandleMapRequestKeepRaised(
/* If the window has never been mapped before ... */
if (!fw || (fw && DO_REUSE_DESTROYED(fw)))
{
+#if 0 /*!!!*/
check_if_event_args args;
XEvent dummy;
@@ -3392,6 +3395,7 @@ void HandleMapRequestKeepRaised(
return;
}
+#endif
/* Add decorations. */
fw = AddWindow(
@@ -4159,20 +4163,31 @@ void HandleUnmapNotify(const evh_args_t *ea)
XEvent dummy;
XEvent map_event;
const XEvent *te = ea->exc->x.etrigger;
- int weMustUnmap;
Bool focus_grabbed;
Bool must_return = False;
Bool do_map = False;
+ int do_unmap;
FvwmWindow * const fw = ea->exc->w.fw;
Window pw;
Window cw;
DBUG("HandleUnmapNotify", "Routine Entered");
- /* Don't ignore events as described below. */
- if (te->xunmap.event != te->xunmap.window &&
- (te->xunmap.event != Scr.Root || !te->xunmap.send_event))
+ if (te->xunmap.event == te->xunmap.window)
+ {
+ /* Handle normally. */
+ do_unmap = 1;
+ }
+ else if (te->xunmap.event == Scr.Root && te->xunmap.send_event)
+ {
+ /* Synthetic event on the root window; the client should have
+ * taken care of calling XUnmapWindow. */
+ do_unmap = 0;
+ }
+ else
{
+ /* Nothing to do except updating some states. */
+ do_unmap = 0;
must_return = True;
}
@@ -4183,10 +4198,12 @@ void HandleUnmapNotify(const evh_args_t *ea)
* unmapped (which is the case for fvwm for IconicState).
* Unfortunately, we looked for the FvwmContext using that field, so
* try the window field also. */
- weMustUnmap = 0;
- if (!fw)
+ if (fw)
+ {
+ do_unmap = 0;
+ }
+ else
{
- weMustUnmap = 1;
if (XFindContext(
dpy, te->xunmap.window, FvwmContext,
(caddr_t *)) == XCNOENT)
@@ -4206,7 +4223,7 @@ void HandleUnmapNotify(const evh_args_t *ea)
return;
}
- if (weMustUnmap)
+ if (do_unmap)
{
Bool is_map_request_pending;
check_if_event_args args;
--
1.7.10.4
