"luke.leighton" <luke.leigh...@gmail.com> writes: > g'day all, i'm a long-time fvwm user (15 years so far), mostly because > it's lightning-quick to start up, doesn't get in my way and gives me > the ability to run 24 (6x4) virtual screens. hurrah. > > i've started using ORCAD 16.3 under Wine (yes, amazingly it actually > works) and here's where the problems start: mouse focus when dialog > boxes are created. i've raised a bugreport on winehq and it was > instantly closed with the accusation "it's fvwm's fault!". well... > we'll leave that judgement aside - i've encountered issues where mfc42 > c++ code was written incorrectly that quotes worked quotes on w95 but > the exact same program wouldn't work on nt 3.51 > > so the symptoms are: first dialog popup window has correct focus: the > bar at the top of the dialog box goes its lovely reddish colour. type > some data in, press ok, all is well. click another action (usually > but not always) right-mouse to edit properties, second (or sometimes > third or fourth) dialog box comes up: no focus. > > move the mouse into the dialog box: no focus. > > move the mouse around in the main window: no focus. > > move the mouse onto the bar at the top of the main window: this is > where it gets strange. sometimes the dialog box will get focus, > sometimes the main window will get focus. > > move the mouse outside of the main window and then back again: again > this doesn't work as expected - sometimes the dialog box will get > focus, sometimes the main window will. > > the only way that i found which will *reliably* get focus into the > dialog box is to follow this procedure: > > 1) have an xterm hiding behind the main window whose drag bar is just > visible behind the main window > 2) get the popup dialog created (by whatever action) > 3) move the mouse onto the *xterm* top drag bar > 4) move the mouse *slowly* down to ensure that the mouse is not moved > so fast such that it does not hit the main window's top drag bar (i.e. > move the mouse slowly enough to ensure that it hits the main window's > top drag bar) > > at this point - after the mouse has been moved out into the xterm and > into the main window's top drag bar - the focus is correctly set to be > in the dialog box. > > clearly, this is a complete pain. editing a schematic where an > operation should take 5 to 10 seconds maximum actually takes double to > triple that time (especially on a 1920x1200 screen, the mouse having > to be moved a considerable way with quite a lot of accuracy), this > procedure clearly and dramatically slowing down the speed at which > work can be carried out. > > obviously, i'm not going to change the fvwm2 "focus" system which > requires clicking on the top bar in order to set mouse focus: that > would be a) too easy b) require working practices operational changes > regarding the use of every *other* program which would clearly be > massively inconvenient (i.e. i quite like mouse-move focus and am > happy with it). > > this isn't restricted to ORCAD: it's other programs as well. it's > just that the use of ORCAD requires a significant number of popup > dialog boxes, so the bug in the interaction between wine and fvwm2 > obviously shows up more frequently. > > obviously the wine team claim that because this bug doesn't occur on > any other window manager that obviously it's not their problem, it > can't possibly be a bug in their code, therefore they're not going to > investigate. we'll deal with that flawed line of reasoning later. > > thoughts as to how to proceed?
Anything more technical from the Wine folks than it's Fvwm's fault? I vaguely recall some settings in Wine about how it interacts with the WM. Are they still there, and have you tried different settings? On the Fvwm side you might try: Style * FPLenient -- Dan Espen
