Re: FVWM: Flickering of buttons and mouse focus
On Sun, Apr 14, 2002 at 10:23:27PM +0300, Tom Alsberg wrote: > In the current FVWM (CVS), there seems to be a bug in mouse focus... I > don't really know where the bug really is, but sometimes > windows/widgets act like they lose and get the focus very fast for > some time, like flickering. > In GTK+ applications, for example, sometimes the buttons flicker when > you're over them, and sometimes getting out of the window and getting > back in helps... Also so with Netscape's toolbars sometimes... > Most noticable is in Ghostview for me... When selecting an area with > the middle mouse button, a menu is supposed to show up enabling me to > zoom that area... It always worked, but now the menu appears for a > fraction of a second, and then disappears... That happens only in the > development/alpha FVWM from CVS... With FVWM 2.4.6 it seems fine, as > it does with TWM/CTWM... > > Any idea what the problem might be? I'm aware of this problem but don't know how to reproduce it at will. It has been around for a long time though, long before 2.4 was released. Can you try to find a way to make it happen fairly reliably? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Flickering of buttons and mouse focus
On Mon, Apr 15, 2002 at 07:52:16PM +0300, Tom Alsberg wrote: > On Sun, Apr 14, 2002 at 08:20:15PM +, Mikhael Goikhman wrote: > > On 14 Apr 2002 22:23:27 +0300, Tom Alsberg wrote: > > > > > > In the current FVWM (CVS), there seems to be a bug in mouse focus... I > > > don't really know where the bug really is, but sometimes > > > windows/widgets act like they lose and get the focus very fast for > > > some time, like flickering. > > > > > > > Does this happen with no config file too? > > I.e.: fvwm -f no-rc > > No, it doesn't happen without a config file... > I checked a bit further, and found that the problem is related to the > following in my .fvwm2rc - if I remove them then the problem goes > away: > > # For auto-raise: > *FvwmEvent: enter_window"Silent SelectiveRaise" > *FvwmEvent: leave_window"Silent SelectiveLower" >... Um, yes. It's very easy to create a race condition with the enter and leave events in FvwmEvent. THere isn't much we can do about it, though. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Flickering of buttons and mouse focus
On Tue, Apr 16, 2002 at 01:50:14PM +0300, Tom Alsberg wrote: > On Tue, Apr 16, 2002 at 12:17:59PM +0200, Dominik Vogt wrote: > > > > > > > > > > > No, it doesn't happen without a config file... > > > I checked a bit further, and found that the problem is related to the > > > following in my .fvwm2rc - if I remove them then the problem goes > > > away: > > > > > > # For auto-raise: > > > *FvwmEvent: enter_window"Silent SelectiveRaise" > > > *FvwmEvent: leave_window"Silent SelectiveLower" > > >... > > > > Um, yes. It's very easy to create a race condition with the > > enter and leave events in FvwmEvent. THere isn't much we can do > > about it, though. > > Why can't it be fixed somehow? I mean, what is exactly the cause for > that condition? This can't be fixed in general inside fvwm and/or FvwmEvent because *your* code causes the race condition. FvwmEvent can't know how and when fvwm will react to the enter and leave packets. Let's assume you have two windows: * +--+ |A | | +---+ | |B : | | | : | | | : | +--| | | | +---+ The * marks the pointer position. Now you drag the pointer down into window B, passing over window A. X generates an enter event on window A first, then an enter event on window B and a leave event on window A. FvwmEvent is informed of these events and replies with Silent SelectiveRaise (A) Silent SelectiveLower (A) Silent SelectiveRaise (B) When this actually happens is unpredictable. Under some circumstances, fvwm now raises window A while the pointer is already over B. this causes an enter event on A and a leave event on B. Next it raises B, generating enter on B and leave on A. FvwmEvent replies with "Silent Selective..." and the loop begins again. To fix that one would have to synchronize communication between X, fvwm and FvwmEvent. On one hand, this is not possible because fvwm takes input from FvwmEvent and X at the same time and can not determine which was generated first. But even if that were possible, this would slow down FvwmEvent to fvwm communication so much that the enter and leave events would become pointless. All you can do is to very carefully program the functions that do the raising/lowering. With the new 'Schedule' and 'Deschedule' commands it is possible to avoid the race condition. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Modifier keys for clicking on menus/WindowList.
On Wed, Apr 17, 2002 at 11:51:13AM +, Mikhael Goikhman wrote: > On 17 Apr 2002 02:54:53 -0700, normalperson wrote: > > > > First off, I had been using the EVWM < http://www.metaphorcity.com/evwm/ > > > shell replacement in Windows for the past five or so years, and more > > > recently, the better-known Litestep shell. > > > > During my time with EVWM, I had grown addicted to the mod-click > > functionality in its WindowList. I could Shift + Click, Meta + Click, > > and Meta + Shift + Click functionality for its WindowList to close, > > hide, and kill windows on my desktop without having to waste time > > switching to them. > > > > A couple months ago, my last months in Windows, I hacked the Popup2 > > module in Litestep to do the same things EVWM could do. ( see: > > http://www.seas.ucla.edu/~wonge/bin/ ). I was about to start adding the > > option for multiple execution options to the run menu as well (e.g. a > > regular click on a menu item could execute an application, shift-click > > could pass different parameters to the execution or run an entirely > > different app, etc.) > > > > Now I've moved to Linux and I have FVWM running quite well (being a > > full-blown WM and not just an execution/task management shell like its > > Win32 cousins). I'm still sifting through the documentation, but I > > haven't been able to find any way to mod-click on menu items within the > > user-defined menus nor the WindowList. If FVWM truly does not have this > > functionality, I guess someone (me?) could/should implement it. > > You may bind only one action to a menu item right now, regardless of > whether it was invoked by a mouse button 1 or 4, or by Enter key, with > Ctrl pressed or not, or by releasing Alt in WindowList. > > There is a discussion on the fvwm-workers list about a future of menus. > It is most certainly that it will be possible to bind different actions > in items for different mouse buttons. The full configurable Key/Mouse > functionality in menus is not considered at the moment, but a new syntax > will be extendible enough to allow this in the more far future if needed. > > > Also on the subject of the WindowList, is there a way one could > > customize it to show the CurrentDesk/Page items in its root, and then > > items from other Desks/Pages within submenus on the WindowList? > > A window may occupy several pages inside a desk, or even be outside of > the pages defined by DeskTopSize, so you may only ask for windows on > particular desks, not pages. > > WindowList command does not currently have an option to create submenus. > It is also impossible to include the WindowList menu as a popup submenu. > > The best that I may suggest now is this: > > Mouse 2 R A Menu MyWindowListMainMenu > > DestroyMenu MyWindowListMainMenu > AddToMenu MyWindowListMainMenu > #+ "Window List For" Title > + "Current Desk" WindowList CurrentDesk > + "" Nop > + "Desk 0" WindowList Desk 0 > + "Desk 1" WindowList Desk 1 > + "Desk 2" WindowList Desk 2 > + "Desk 3" WindowList Desk 3 > > But if you know to program you may create a simple FVWM module that does > whatever you want that WindowList does not currently do. It is possible > to do this in perl in 2.5.x versions. See some examples at: > > ftp://ftp.fvwm.org/pub/fvwm/devel/sources/tests/perl/ > > Maybe if I have some time, I will add a simple module similar to the > existing module-winlist that uses AddToMenu and does what you describe. But the FvwmIconMan module can already do most of this. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: large PipeReads
On Wed, Apr 17, 2002 at 07:29:25PM -0600, Gregg Dameron wrote: > Running 2.4.5 on Solaris. > > It seems that as a PipeRead script increases in size, fvwm2 struggles to > read and execute it. The maximum seems to be 1024 bytes, measured by > the string output in debug mode that begins: > > <> about to attempt '
Re: FVWM: Remember icon placement?
On Wed, Apr 17, 2002 at 09:39:45PM -0600, Steve Talley wrote: > Hello, > > I've just started using fvwm, and it is easily the best window manager > I've ever used. Great job!! I do have a question: > > How can I get fvwm to consistently remember the last position of an > icon? > > To start, I have this in my .fvwmrc: > > Style * IconBox 0 0 -0 -0, IconFill top left, IconGrid 80 80 > Style * IconPosition > > Here's an example: > > Suppose I have three non-overlapping icons in the first three > positions in my icon box. If I start an xterm, and then iconify it, > it will be placed in the fourth position (so far so good). Now > suppose I close the application whose icon was occupying the 2nd > position in the icon box. Now, if I deiconify and reiconify the > xterm, its icon will be moved to take the place of the closed app in > the 2nd position. How can I force it to go back to the 4th position > where it was initially? > > I've found that fvwm will remember an icon's position only if I > manually drag it to a specific position. Then every time it is > iconified it will return to the same position. Otherwise, it seems > that fvwm has no memory of where the icon was placed before. > > The reason I ask is because I identify a specific xterm by its icon > position. When that position isn't constant, I don't know which xterm > to go back to later. The last window manager I used (CDE) remembered > an icon's last position, and always replaced it in the same position > unless a new icon had taken its place. How can I tell fvwm to do this > as well? That couldn't be done easily until I committed my latest patch. With tomorrows snapshot you can use Move $[i.x]p $[i.y]p on an icon. Fvwm will remember that the icon was moved manually and always place it at its current position. This should be done automatically when the window is iconified, e.g. with AddToFunc my_iconify + I iconify on + I move $[i.x]p $[i.y]p Then use the my_iconify function instead of the Iconify command to iconify your windows. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Failed to write descriptor to 'FvwmAnimate'
On Fri, Jun 06, 2003 at 01:31:24PM +1000, Dennis McGregor wrote: > Hello. > > When I'm tweaking my config file I often restart fvwm using the key combo > Key Space A CSM Restart "/home/djm/bin/fvwm" > Every so often I get timeouts associated with FvwmAnimate while loading FvwmIconMan. > > ~/bin/fvwm --version > fvwm 2.5.7 (from cvs) compiled on Apr 16 2003 at 11:00:59 > with support for: ReadLine, RPlay, Stroke, XPM, PNG, Shape, XShm, SM, Bidi text, > XRender, XFT, NLS > > Some possibly relevant lines from my config are: > > *FvwmIconMan: NoIconAction "SendToModule FvwmAnimate animate" > SetAnimation 10 -.01 0 .01 .03 .08 .18 .3 .45 .6 .75 .85 .90 .94 .97 .99 1.0 > > The error message is: > [FVWM] [FlushMessageQueue]: <> Failed to write descriptor to 'FvwmAnimate': > - select rc=0 > - terminate signal=N > > It doesn't happen every time I restart, and it seems to be random whether > it happens or not - at least, I can't pinpoint what makes it occur or not. > It has never occurred when fvwm starts for the first time. > > Any ideas why this might be happening or what I can do about it? Post your config (preferrably stripped down to the minimum that shows the problem) and try to start FvwmAnimate last. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Bazaar branch of fvwm
> just FYI there's a baz branch tracking MAIN available at > http://bazaar.ubuntu.com/[EMAIL PROTECTED]/fvwm--MAIN--0/. We'll > try and keep that synced to CVS daily and would encourage anyone who's > playing with baz/tla/arch to check it out. Er, what does all of this mean? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: can't show button 6
> i am mofify my .fvwmrc. and i found i can't see button 6 because the > space left for button in the left of title is not enough. so how can i > change this. To begin with, the buttons 1, 3, 5, 7 and 9 are left of the title, while 2, 4, 6, 8 and 0 are right of the title. The title shrinks to make room if more buttons should be shown, so that is not the problem. Ownly the buttons that have some action bound to them are shown. If you want to see button 6, you should have some action bound to it in your configuration, for example key x 6 n delete or mouse 1 6 n delete (in old versions of fvwm, only the "key" command made the button appear, but not the "mouse" command (or maybe it was the other way round)). Finally individual buttons can be enabled or disabled with a style. Make sure you do not have Style * nobutton 6 in your .fvwm2rc or put Style * button 6 near the end of the file. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: xdg specs compliance
> > > Please, this mailing list is a flame-free zone. Let's stick to the facts without potential insults. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Managing focus
On Sun, Jul 17, 2005 at 05:12:38PM +0200, Vincent Bernat wrote: > Hello ! > > I would like to setup fvwm to display this behaviour about focus : > when a new window is created or deiconized, if its parent app has the > focus, then, it gets the focus, otherwise, it does not get the focus, > even if it is displayed below the mouse cursor and even if it is > requesting it specifically. > > I am using actually sloppy focus and I have two distinct problems : > - gaim popups the dialog message when a new message comes and I do >want it to be popup, but I do not want it to get the focus because >I may be typing something else. In fact, I would like it to never >get the focus, except when I deiconify myself, or when I click on >it, or when I move the mouse on it. > - when an application popups a dialog, I would like to give it the >focus to be able to use the keyboard to interact with the dialog. > > I think that the above description would solve those two problems. Is > it possible ? As I don't understand exactly what you want I can only suggest to read about the styles grabfocus and grabfocustransient in the man page. Doe that help? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: spelling of "fvwm" vs. "Fvwm" vs. "FVWM"
On Thu, Aug 09, 2007 at 01:07:12PM +0100, Thomas Adam wrote: > On 09/08/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > I think opinions have been exchanged by now. So, who of the > > people who promote "FVWM" as fvwm's name is willing to do the > > following: > > > > * Rename *all* occurences in *all* files in the fvwm and > > fvwm-web repositories from "fvwm" or "Fvwm" to "FVWM", > > Excluding symbolic names in the source files. > > I am more than happy to. > > > * This includes > > > > - The name of the CVS repositories (FVWM and FVWM-web). > > - The names of the mailing lists (FVWM, FVWM-workers, etc.) > > - File names (fvwm.c -> FVWM.c, fio.c -> Fio.c, > > fsm.h -> Fsm.h etc.) > > You're stretching the point a little far here -- you can keep the > filenames as-is. I think you have no idea of the extend of my efforts to keep naming consistent in the source tree. > > - The names of the executables (fvwm -> FVWM, make_fvwmdist.sh > > Again, you can keep that as-is. > > > * Take the responsibility to explain to the users why this was > > done and why their config files are broken. > > I am happy to update the documentation to reflect s/fvwm/FVWM/g in > *context* -- nothing else needs to change. And I'm happy if you *don't* do it just in context. I've spent many hours to have consistent spelling all over the place. > You're angry -- so I will let some of your points go without rising to > the challenge. I'm serous about every single pont. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: How to make thumbnail WindowListSkip?
On Tue, Feb 19, 2008 at 11:36:45AM +0100, Viktor Griph wrote: > On Tue, 19 Feb 2008, for.register for.register wrote: > >2. How can the two actions ( Move and Resize) work at the same time? > >I am afraid I do not understand why there are two "+I" > > They work one after each other. (That was what thought you meant by > movesize.) So the window will move while button 3 is held down. Once > released the window will start to resize in the bottom right corner. > However there appears to be a bug with the way fvwm treats this Resize > directly after a move: It interprets the move of the pointer during the > move as initial instructions for the resize. That's because when the button is pressed, the ButtonPress event is stored as the "trigger event" of the function. All actions inside a functions refer to the trigger event as if they were completely independent actions. It is clearly confusing, but I don't know what you actually expected this function to do. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm patches and esperanza
On Tue, Feb 26, 2008 at 03:07:04PM +0100, Ingo Wardinski wrote: > I managed to get core file and I attached the output of gdb fvwm2 core > and where below. It seems something related to ewmh. > Any help would be very appreciated. [snip] > #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) > at ewmh_events.c:194 You need to upgrade to the latest code from CVS (e.g. a daily snapshot). The crash is already fixed in 2.5.25 (not released yet). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm patches and esperanza
On Tue, Feb 26, 2008 at 03:24:17PM +0100, Ingo Wardinski wrote: > [ On Tuesday, February 26, 2008 at 15:20:19 (+0100), Dominik Vogt wrote: ] > > Subject: Re: FVWM: fvwm patches and esperanza > > > > On Tue, Feb 26, 2008 at 03:07:04PM +0100, Ingo Wardinski wrote: > > > I managed to get core file and I attached the output of gdb fvwm2 core > > > and where below. It seems something related to ewmh. > > > Any help would be very appreciated. > > [snip] > > > #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) > > > at ewmh_events.c:194 > > > > You need to upgrade to the latest code from CVS (e.g. a daily > > snapshot). The crash is already fixed in 2.5.25 (not released > > yet). > > > > Thanks, for sharing this information. Do I still need the patches for > menutranlucency, roundedcorners etc or are all these features included > in .25? You still need the patches. By the way, I am just building the 2.5.25 release, so if you don't want to use code from CVS, just wait until the tarball is available on the ftp server (probably today or tomorrow). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Icon frames
On Fri, Feb 29, 2008 at 02:40:26PM -0500, Dan Espen wrote: > Viktor Griph <[EMAIL PROTECTED]> writes: > > On Fri, 29 Feb 2008, Dan Espen wrote: > > > > > > > > I'm running a fairly recent CVS version of Fvwm. > > > I use root window icons, many of them shaped, > > > some of them titled. > > > > > > Recently, some of my icons started to show a 3d frame around them: > > > > > > http://mysite.verizon.net/despen/icons.gif > > > > > > The second from the top has a frame, > > > the third from the top doesn't. > > > > > > They both use png's with a transparent area around them. > > > > > > I think I like the effect. > > > What causes some of have the frame and other no frame? > > > > That would be your Style settings. The effect comes from the Style > > IconBackgroundRelief in conjunction with IconBackgrouondColorset. > > > > According to the manpage it is only drawn around icons with a background. > > I'm not sure why some icons are considered to have backgrounds, and some > > not. But if you use an IconBackgrouondColorset all icons will get the > > relief. > > Ok, I see that: > > Style * IconBackGroundRelief 0 > > turns it off and a non-zero value > turns it on. > > I don't have an iconbackground setting anywhere. > Also this is something that just recently appeared. Can you pin it down to a specific version/CVS date and provide a config? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: backing windows off currentpage
On Wed, Mar 19, 2008 at 03:17:30PM +, Thomas Adam wrote: > On 19/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > It seems that FVWM does not back windows which are on some > > non-CurrentPage. If I run xwd -id $someWindowNotOnCurrentPage the > > image comes out as completely black. I would request that FVWM exposes > > a configuration option that would keep windows backed in memory such > > that programs like xwd produce a usuable result even when they aren't > > on the current page. Perhaps it would be nice to have this feature be > > both a global tri-state (off, on for current desk, on for all desks), > > as well as a per-window option toggleable via Style or Pick type > > actions. > > But the window on $SOMEOTHERPAGEORDESK is unmapped, so of course it > will come out blank, unless you switch to that page first. Windows are unmapped in fvwm when they are on a different desk, but simply moved out of view when on a different page. In any case, there is nothing fvwm can do to force the X server to cache hidden portions of windows, and it's not the job of the window manager to do it. However, sone of these funny 3d or rendering extensions to X need to do this. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Shape regression in 2.5.25
On Mon, May 05, 2008 at 09:31:50PM -0700, Gautam Iyer wrote: > Hi All, > > I just updated to fvwm-2.5.25 this morning, and I find that my oclock > window gets 'messed up': > > oclock -transparent -geometry 75x75-0+150 -fg '#202040' -bd '#202040' & > > Then leave it running for a little bit (say 20 mins). After this the > hands aren't visible clearly anymore! Needless to say I had oclock > running for weeks on 2.5.23 with no problems. > > I'm using xorg-server-1.4.0.90 on Gentoo (if that makes any difference), This is already fixed in the latest snapshots (the future 2.5.26). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: If I enable "Desktop Effects" fvwm2 crashes
On Fri, May 16, 2008 at 09:08:17AM +0100, Chris G wrote: > I don't want it to change fvwm, I just want it not to crash! Well, if it crashes, does it leave a core file or print any error output? THe snippet you posted earlier is not from fvwm itself. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Possible bug in fvwm: Using PositionPlacement with x,y pair nolonger honors StartsOnPage
On Mon, Aug 11, 2008 at 01:28:33PM +0200, Hans Voss wrote: > When I start fvwm I start a bunch of applications (like firefox and > thunderbird) that I put on specific pages (using: Style "Firefox" > StartsOnPage 0 2 0, SkipMapping, StartsOnPageIncludesTransients, > StartsOnScreen p). Fvwm places this window flush to the left screen > border. I want to place the windows somewhat more to the right > (actually, what I want is windows of size 1461p by 933p at position > 118p and 42p). > > I now have the Style command (see before) to place them on the right > page and use a Key shortcut with ResizeMoveMaximize to put it in the > right place. > Neither firefox nor thunderbird accept the X11 -geometry option. > I have tried to include a PositionPlacement command in the Style: > Style "Firefox", StartsOnPage 0 2 0, SkipMapping, > StartsOnPageIncludesTransients, StartsOnScreen p, PositionPlacement > 118p 42p. Which *does* place the window in the right position, but no > longer on the right page. > > Am I missing something obvious or is this not doable with simple Style > commands of with a simple Function. (I suppose that there will be > someway to accomplish this using Fvwm Fixed in CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to make forune output to my backgound
On Fri, Aug 29, 2008 at 11:57:37AM +0800, for.register for.register wrote: > I have tried several ways to make fortune output > to my background, noway. I think fortune is just like > the scell command such as "ls", "echo" , how can > I display that on destop backgrounds? If you have xlock, you could run $ xlock -nolock -inroot -mode nose This paints some character with a big nose, spitting out random fortunes. Or you can use the root-tail program, e.g. $ fortune | root-tail - Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: how to make button unpressed while moving off cursor from it
On Fri, Oct 31, 2008 at 09:24:50PM +0800, for.register for.register wrote: > In fact, I dont know how to say in in English, Let me try: > > For example , I want to close a window, I press and hold the left mouse > key on the "close button" . And now I dont want to close the window > so, I move off the cursor from the "close button", and release the mouse > key. And I hope the window is still there unclosed. How the configure this? Press the "Escape" key. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Ban area for window placement
On Mon, Nov 03, 2008 at 07:22:20PM +0100, Frank Gruellich wrote: > Hi, > > I've made Xinerama working with my notebook display and an attached > external TFT screen. But the TFT is somewhat bigger than my display an > so the screen layout looks more like > > ,---. > | |--. > |TFT| note- | > | | book | > '---'--' > > Both, Xorg and FVWM (or at least the later) seem to think this about my > screen layout: > > ,--. > | | > | | > | | > '--' You should try to fix the Xinerama configuration. Fvwm relies on the screen configuration that the server uses, and if that does not reflect the real geometry of the screens it doesn't work. Although fvwm has the code to handle any layout, there is no way to override the information from the X server (except with the XineramaSLS command, but that won't help you here. > So it happens, that FVWM places windows into the top right corner where > I can't access them (easily) because X doesn't allow to move my mouse > there. Currently I have: > > Style * NoPPosition > > and nothing more regarding positioning, AFAICS. How can I FVWM restrict > in placing windows there? Ciao Dominik ^_^ ^_^
Re: FVWM: Ban area for window placement
On Tue, Nov 04, 2008 at 04:39:45PM +0100, Frank Gruellich wrote: > * Dominik Vogt <[EMAIL PROTECTED]> 3. Nov 08: > > On Mon, Nov 03, 2008 at 07:22:20PM +0100, Frank Gruellich wrote: > > > I've made Xinerama working with my notebook display and an attached > > > external TFT screen. > > You should try to fix the Xinerama configuration. > > Is it wrong? X seems to know, that I have two screens with different > size: > > ... > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Videocard0" > (**) |-->Screen "Screen1" (1) > (**) | |-->Monitor "Monitor1" > (**) | |-->Device "Videocard1" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > ... > (II) NVIDIA(0): Virtual screen size determined to be 1600 x 1200 > ... > (II) NVIDIA(1): Virtual screen size determined to be 1440 x 900 > ... > > I don't know a good method to figure out what X thinks about my layout, > but if I do a 'xwd -root |convert xwd:- png:screen.png' I get a > 3040x1200 screen.png where the top right looks scrambled (see > http://www.der-frank.org/tmp/sscreen.jpg [48kB]). However, xdpyinfo > states, that I have "number of screens:1". Confusing. ^^^ That seems to be the problem. X.org does not tell fvwm the proper geometry. > How do I > know what's FVWM idea about my screen layout? There is no way to print the layout directly, but you can find out the position and dimensions like this: Open an FvwmConsole window and type style foo positionplacement screen 0 +0p +0p exec xterm -T foo -e sleep 10 -> Window appears in top left corner of screen 0. style foo positionplacement screen 0 -0p -0p exec xterm -T foo -e sleep 10 -> Window appears in bottom right corner of screen 0. style foo positionplacement screen 1 +0p +0p exec xterm -T foo -e sleep 10 style foo positionplacement screen 1 -0p -0p exec xterm -T foo -e sleep 10 and so on for the corners of the other screens. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Restart doesn't work on dual screen
On Mon, Nov 24, 2008 at 06:47:09PM +0100, Harald Dunkel wrote: > I am running the snapshot of yesterday (2008/11/23) on 2 screens. The second > screen gets its own fvwm. Both share the same .fvwm2rc file, AFAICS. > > Problem: If I click on [Restart] on the first screen, then its fvwm exits > instead. Twm is started as a fallback. The error log file says > > [fvwm.0][SetupICCCM2]: <> another ICCCM 2.0 compliant WM is running, > try -replace > > The fvwm on the second screen is still running. How do you start fvwm (what does the command line look like). > In a new session: > If I click in [Restart] on the second screen, then its fvwm is restarted. The > first fvwm doesn't notice. Both window managers are running independent from > each other after this. Both can be restarted without being kicked out. Hm, the code in fvwm.c:main(), fvwmc:Dome() and icccm2.c:SetupICCCM2() doesn't seem to handle multi screen restarts at all. TO mee it looks like a random fvwm instance gets ownership of the _XA_WM_SX atom via the call of XSetSelectionOwner(). Only this instance can be restarted, and the instance on the first screen can *never* be restarted because it tries to start on every screen. To fix this, we would have to write code so that: * Only the master instance calls XSetSelectionOwner(). * If the master is restarted, it has to shut down the copies on the other screens by sending some signal and wait until all other instances have exited. This might take a long time. We can *not* simply wait for all children to exit, because the modules are children too. * If some other instance is restarted, the restart command and all its arguments would have to be communicated to the master instance. The master instance would then restart as described above. I think this involves opening some command pipe to the fvwm copies. * All of this also applies to shutting down. I don't think I'll have the time to do this, but I'd accept and proof read patches. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: keys don't repeat
On Fri, Dec 05, 2008 at 12:31:41PM -0800, Theodore D. Sternberg wrote: > On Fri, 5 Dec 2008, Thomas Adam wrote: > > >2008/12/5 Perry Hutchison <[EMAIL PROTECTED]>: > >>If it doesn't work when run in .xinitrc ahead of fvwm, I suppose > >>you could try putting it in an InitFunction (or SessionInitFunction > >>-- see the fvwm manpage for the difference) in your .fvwm2rc. > > > >~/.xinitrc is fine. s/InitFunction/StartFunction/ > > It doesn't work there either, i.e. > > AddToFunc StartFunction > + I xset r on > + I Module FvwmButtons > > Oh well, just knowing I can type "xset r on" in the first xterm I open > is already way better than spending the rest of my life with gnome or > kde. If that does not work, some other program or command is switching it off. Are you sure there is no "xset r off" in your .fvwm2rc? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: stick between screen
On Mon, Mar 16, 2009 at 01:14:20AM +, Thomas Adam wrote:
> 2009/3/15 Jason Weber :
> > Start with one empty unified screen, two side by side monitors using
> > twinview (same card, different plugs).
> >
> > Instance a new window, say a xterm.
> >
> > Slide it left and right so that the left or right edge passes from
> > one monitor to the other. I believe that the window edge is supposed to
> > snap with strong preference to keep the window on only one monitor.
> >
> > The only thing I know of that might be unusual is that my
> > monitors' horizontal resolutions are different.
>
> Well as long as X reports things correctly then FVWM will honour that,
> so I think this a red-herring. I'm not in a position to test this
> myself as I am sans Xinerama,
You can test Xinerama if you configure fvwm with
--enable-xinerame-emulation.
> but does the following patch do anything
> to help "fix" this? I warn you it's complete theory on my part, so
> expect a quirk or fifty. ;)
>
> -- Thomas Adam
>
> P.S. Also Cc'ed fvwm-workers which is what you should have done from
> the outset.
> Index: fvwm/move_resize.c
> ===
> RCS file: /home/cvs/fvwm/fvwm/fvwm/move_resize.c,v
> retrieving revision 1.304
> diff -u -r1.304 move_resize.c
> --- fvwm/move_resize.c7 Dec 2007 18:52:21 - 1.304
> +++ fvwm/move_resize.c16 Mar 2009 01:11:21 -
> @@ -2076,8 +2076,23 @@
> /* snap to screen egdes */
> if ((fw->snap_mode & SNAP_SCREEN) && fw->snap_proximity > 0)
> {
> + /* TA: 20090315: Make sure windows being told to snap to a
> + * screen; honour Xinerama screens separately -- and don't
> + * treat the screen area as one huge screen.
> + */
> + rectangle screen;
> + int screen_width;
> +
> + screen_width = Scr.MyDisplayWidth;
> +
> + /* Get the parameters for the screen */
> + FScreenGetScrRect(NULL, FSCREEN_CURRENT, &screen.x, &screen.y,
> + &screen.width, &screen.height);
> + if (screen.width > 0)
> + screen_width = screen.width;
> +
> /* horizontally */
> - if (!(Scr.MyDisplayWidth < (*px) ||
> + if (!(screen_width < (*px) ||
> (*px + self.width) < 0))
> {
> dist = abs(Scr.MyDisplayHeight - (*py + self.height));
> @@ -2119,23 +2134,23 @@
> (*py + self.height) < 0))
> {
> dist = abs(
> - Scr.MyDisplayWidth - (*px + self.width));
> + screen_width - (*px + self.width));
> if (dist < closestRight)
> {
> closestRight = dist;
>
> - if (*px + self.width >= Scr.MyDisplayWidth &&
> + if (*px + self.width >= screen_width &&
> *px + self.width <
> - Scr.MyDisplayWidth + fw->snap_proximity)
> + screen_width + fw->snap_proximity)
> {
> - nxl = Scr.MyDisplayWidth - self.width;
> + nxl = screen_width - self.width;
> }
>
> if (*px + self.width >=
> - Scr.MyDisplayWidth - fw->snap_proximity &&
> - *px + self.width < Scr.MyDisplayWidth)
> + screen_width - fw->snap_proximity &&
> + *px + self.width < screen_width)
> {
> - nxl = Scr.MyDisplayWidth - self.width;
> + nxl = screen_width - self.width;
> }
> }
> dist = abs(*px);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: The -geometry "+-" syntax. Documented?
On Fri, Jul 24, 2009 at 11:30:59AM +0930, Michael Talbot-Wilson wrote: > In FVWM the -geometry option conforms to the Move +- syntax but AFAIK > that's not documented anywhere in either FVWM(1) or X(7). > > Can it be relied on? > > Today if I do > > xterm -T First -geom +100-800 & > xterm -T Second -geom +100+-800 > > the window list says: > > First 0(1):80x24+100-397 > Second 0(1):80x24+100-800 > > If I write a wish script that uses the "+-" syntax to arrange images > on the page above the present one, will it continue to work on later > versions of FVWM? Yes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: emacs 23 geometry and fvwm 2.4.20
On Sat, Sep 05, 2009 at 08:08:13AM +0200, Marco Maggi wrote: > Ciao, > > I am having the problem described here[1] and I wonder if > someone is experiencing the same. > > [1] > <http://groups.google.com/group/comp.emacs/browse_thread/thread/215d350197511963#> Add this line to your .fvwm2rc: BugOpts ExplainWindowPlacement Then start eamcs and post the output on the console on this list. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: thomas adam ill
On Sun, Sep 13, 2009 at 10:31:02AM -0400, des...@verizon.net wrote: > Darren Upsolla writes: > > it has been brought to me attention thomas adam is seriously ill - > > just thought you should know > > > > darren > > Very sad news indeed. > > His contributions have been much appreciated. Yes, very sad. My best wishes to him, I hope he gets better. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Bug with Qt4 window positioning
On Sun, Oct 24, 2010 at 07:39:09PM +0200, Christian Ehrlicher wrote:
> I've a problem with fvwm2 window positioning when using Qt4 in fvwm2. It
> works
> fine with KDE. You can reproduce it with the attached example. You can
> compile
> it with the following steps:
>
> - create a subdir 'example'
> - place main.cpp in there
> - execute 'qmake -project'
> - then 'qmake'
> - and then 'make'
>
> When you start the resulting executable without an argument and then with an
> argument (doesn't matter what you give as argument) you can see that the
> resulting window position differs.
> It looks like when the window is moved before it gets shown the windeco isn't
> took into account which leads to a displacement in the y-axis.
Without going into the details: It's not a bug, it's a feature.
If you don't like that behaviour, use this line in your .fvwm2rc:
style * MoveByProgramMethod UseGravity
> I'm using the latest official release (2.5.31, also tested with official
> 2.5.26 package from openSUSE). I can also do some debugging by myself if
> someone can point me into the correct direction.
>
>
> Thx,
> Christian Ehrlicher
> #include
> #include
>
> int main(int argc, char** argv)
> {
> QApplication app(argc, argv);
>
> QLabel *lbl = new QLabel("Hello FVWM2");
> if(app.arguments().count() > 1) {
> lbl->setVisible(true);
> lbl->move(100,100);
> } else {
> lbl->move(100,100);
> lbl->setVisible(true);
> }
> return app.exec();
> }
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: The recent FvwmIconMan changes causes bad colors for me
On Thu, May 16, 2013 at 01:11:28PM -0400, Chris Siebenmann wrote: > There was a recent change (April 14th) to FvwmIconMan's source code > to, to quote the changelog: > * FvwmIconMan/x.c (change_colorset, recreate_background) > (create_manager_window): > fix bad hilight colour on some systems (64 bit issue?) > > Unfortunately on my machine[*] the effect is exactly the opposite: this > change destroys the correct colours in my FvwmIconMan setup. In fact it > appears to do very odd things. I've produced two PNGs to illustrate: > http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-good.png > http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-bad.png Yes, that's very similar to what I had. My problem is that I don't understand at all why my patches work on that X86-64 machine, I just fiddled with the code until it worked, hoping not to break something. Actually, both version of the code should work everywhere, but obviously they don't. > I don't set a general FvwmIconMan foreground or background colour. > Setting them explicitly doesn't fundamentally change the results; the > only net effect is that the iconified 'xterm1' FvwmIconMan button > doesn't have the grey cast it does in the -bad PNG here. That's the same observation I made on that bad machine. Setting the background colour of the focused button had no effect whatsoever. I moved the code that sets the colour around in the source files, and at _some_ location it worked, but not in others, although the background colour was not overwritten anywhere. > I can easily test patches/changes if people would like. That will help a lot. Pinnig the problem down is probably going to be difficult. > [*: my machine is 64-bit Fedora 18 with an ATI graphics card and the > normal Fedora 18 open source drivers. These particular screenshots > are from an Xephyr session, but I first saw the effect on the real > display.] So, you have a 64-bit CPU with a 64-bit version of the OS? What X server do you have (version?). Can you please post the output of $ ldd /path/to/fvwm2 and a minimal fvwm configuration file that shows your problem? P.S.: Do you read the list, or should I cc you on replies? P.P.S.: Please do _not_ cc me unless I specifically ask for it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: The recent FvwmIconMan changes causes bad colors for me
On Fri, May 17, 2013 at 01:11:40PM -0400, Chris Siebenmann wrote: > Here is a relatively minimal fvwm configuration file that shows the > problem for me (inside an Xephyr server): Allright, I can reproduce your problem here at home, I'll take a look. > Style "*" IconTitleFormat %i That style is invalid. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: The recent FvwmIconMan changes causes bad colors for me
On Thu, May 16, 2013 at 01:11:28PM -0400, Chris Siebenmann wrote: > There was a recent change (April 14th) to FvwmIconMan's source code > to, to quote the changelog: > * FvwmIconMan/x.c (change_colorset, recreate_background) > (create_manager_window): > fix bad hilight colour on some systems (64 bit issue?) > > Unfortunately on my machine[*] the effect is exactly the opposite: this > change destroys the correct colours in my FvwmIconMan setup. In fact it > appears to do very odd things. I've produced two PNGs to illustrate: > http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-good.png > http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-bad.png >... This should be fixed now. I backed out the patch and now use a routine from libs/Colorset.c to draw the button background, and that works for me with hopefully no risk of breaking something else. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Post-popup pointer positioning issue with tall menus
On Sat, Jun 29, 2013 at 08:24:33PM -0600, Glenn Golden wrote: > -- > FVWM version: 2.6.5 > > Minor consistency issue regarding the behavior of relatively tall menus, when > invoked via a mouse button. Example: > > Mouse 3 R A Menu fooMenu Mouse -20p -10p > > When Button 3 is clicked, if fooMenu fits vertically within the available > space > between the pointer and the bottom of the root window, then the menu pops up > with the pointer located over the top menu item (suitably offset as specified > by -20p -10p) and with that item highlighted, as desired. This is a nice > convenience because it allows invocation of the first menu item by simply > clicking Button 3 then hitting . > > But if Button 3 is clicked when there isn't enough space for the entire > fooMenu > to fit vertically downward from the present pointer position, then it pops up > instead with its bottom edge aligned with the bottom of the root window, ... > I did spend time studying the "Menu" and "MenuStyle" sections of the man page, > but could not come up with a means to accomplish the desired behavior in a way > that is independent of initial pointer position. Well, fvwm always forces menus to be completely on screen as it has not way of moving existing menus around. If you click on the bottom pixel line of the display, you'll obviously want the menu visible and not sticking downwards into the next page. Have you tried the WArpTitle option? Mouse 3 R A Menu fooMenu Mouse WarpTitle It warps the pointer to the first menu item. It might be slightly annoying as it warps the pointer even if that would not be necessary, but if it's good enough, I see no reason to change the code. > b. Add an option which allows root menus to pop partially offscreen, and > then modify the documentation of "Mouse" context-rectangle so that it > states that its behavior depends on this new option. This is really not an option. Menus depend on being completely on screen. > c. Just make the behavior strictly agree with the present "Mouse" context- > rectangle definition in the man page, and perhaps even explicitly state > that this behavior implies that tall menus may pop up partially > offscreen, depending on initial pointer position. See above. (d) Extend the WarpTitle option to "WarpTitleIfNecessary. This would warp the pointer only if the menu did not pop up at the desired item. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Post-popup pointer positioning issue with tall menus
On Sun, Jun 30, 2013 at 05:31:50PM +0100, Dominik Vogt wrote: > On Sat, Jun 29, 2013 at 08:24:33PM -0600, Glenn Golden wrote: > Have you tried the WArpTitle option? > >Mouse 3 R A Menu fooMenu Mouse WarpTitle That should be Mouse 3 R A Menu fooMenu WarpTitle of course. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: function to toggle panel
On Mon, Jan 06, 2014 at 11:09:59AM +, James Griffin wrote: > I have a panel on the bottom of the display, i'd like a function i > can bind to a key press combination that will open it if it's not > already and close it if it is. I have this in my config: #// #// Application toggling function #// #// first argument is the window name, second argument is the command to start #// the application. AddToFunc ToggleWindow + I None ($$0, CirculateHit) $$1 + I TestRc (Match) Break + I Next (currentpage, visible, !iconic, $$0, CirculateHit) Close + I TestRc (Match) Break + I Next ($$0, CirculateHit) Function MakeVisible AddToFunc MakeVisible + I MoveToDesk + I MoveToPage + I MoveToScreen + I Raise + I Iconify off + I WindowShade off AddToFunc ToggleFvwmConsole + I ToggleWindow FvwmConsole "Module FvwmConsole" AddToFunc ToggleXMessages + I ToggleWindow XMessages "Function RunXMessages" etc. If that's not what you're looking for, please describe what you're trying to do in more detail. > I've tried several ways, I can seem to get the dual function action > right. Does anyone have some tips as to how i can do this? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: function to toggle panel
On Mon, Jan 06, 2014 at 01:33:47PM +, James Griffin wrote: > Although, what I need is to have a > function that will test to see if my fvwmbuttons panel is open; if > it is not, open it; if it is close it. I see. I have this in my config: If you give the button that controls the panel an Id, you can "click" it with a command: *FvwmButtons(2x1+13+0, Padding 2, Panel(indicator 15) FvwmPagerPanel `Module FvwmPager FvwmPagerPanel 0 3`, Id panel_control_button) You can then use the fvwm core command to press the button SendToModule FvwmButtons PressButton panel_control_button 1 or as a key binding key f1 a n SendToModule FvwmButtons PressButton panel_control_button 1 This works just as if you click on the panel button in FvwmButtons with mouse button 1. Actually it's not really necessary to give the button an id, you can also use the button's coordinates (+13+0 in the example), but that is less convenient because if the FvwmButtons layout changes, you may have to recalculate the coordinates. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Clarify rule for using quote symbols.
On Fri, Jan 10, 2014 at 12:45:51AM +0200, Oleksandr Gavenko wrote: > The only thing I found in "QUOTING" section in fvwm(1) that quoted characters > are spaces (when using single/double/back quotes). [snip] > But: [snip] > Echo "XXX YYY" > [fvwm][Echo]: > "XXX YYY" > > So seems that Echo is special form and don't follow traditional > Fvwm quoting convention... Is that true or this is a bug? I'd call it a glitch. Something that wasn't really indended, that is surprising and doesn't do any harm. Note that if you use variables with the Echo command, they get properly expanded (e.g. $[w.x]) whether inside or outside quotes. The reason for this is that the whole command line is parsed by the general command line code in functions.c. This code expands variables. Then the CMD_Echo function is called with the rest of the command line as a string and just prints it. All(?) other commands use the parsing library to split the passed argument string into separate tokens. This library takes care of stripping the quotes. Actually, the command parsing code in fvwm lacks a real design; every command does its own parsing, and there are probably many more such glitches, especially in commands with complex syntax. The way to deal with this glitch is to just ignore it; every other command should handle quoting properly, and if not it's most likely a bug. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Weird problem with current Firefox Nightlies and FVWM
On Tue, Apr 22, 2014 at 12:38:44PM -0400, Chris Siebenmann wrote: > I'm seeing a weird problem with trying to use current Firefox Nightly > builds under my FVWM configuration, where some of Firefox's menus won't > appear (or won't appear consistently). This seems specific to using > Firefox under FVWM; under another window manager (Cinnamon) things work. > Old Firefox Nightly builds worked fine, so something has changed in what > Firefox is doing (which means the issue might be in Firefox or in FVWM). > > I thought I had a consistent and simple reproduction but it turns out > that I don't (it's consistent but not entirely simple). Is there any > debugging stuff that I should try in FVWM to narrow down what's going > on? Are people interested in a somewhat complex reproduction? If you issue the command bugopts explainwindowplacement on Fvwm will give a lot of information about the initial placement of new windows. This might or might not be helpful. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: window move issue
On Tue, Apr 22, 2014 at 12:52:09PM -0400, Dan.Espen wrote: > Martin Cermak writes: > > Recently I noticed an issue moving windows using FVWM. The issue > > is described in [1] and seems to be HW dependent. However, > > successful usage of some other VMs on affected boxes makes me > > think that the issue might be on the FVWM side. Ideas? Thoughts? > > Red Hat says it's a driver issue. > I agree. Me too. It looks like a severe redraw issue of the graphics driver. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: window move issue
On Wed, Apr 23, 2014 at 09:37:52AM +0200, Martin Cermak wrote: > Which is a good news I think :) However, there is some issue with > the root window redrawing, which would be worth of fixing I guess. No application whatsoever can do anything about that. Generating the expose events and redrawing the root window is the responsibility of the X server alone. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Prevent window from raising itself?
On Wed, May 21, 2014 at 03:37:46PM -0400, Tom Horsley wrote: > The latest version of google-chrome has the annoying habit of > forcing itself to the top of the stack when I right click on > a link (thus utterly obscuring the window I was planning on > pasting the copied link into :-). > > I have read through the descriptions of all the style settings > that seem to have anything to do with stacking order and I > can't find anything that looks as if it can tell fvwm to > ignore stacking order changes from windows. I'm sorry that the documentation - especially of the options disabling unwanted application behaviour - is a mess. There are too many options to document efficiently. The best bet to find them is to look for styles containing the words "ignore", "gnome" or "ewmh", but that is only a rule of thumb. > Have I finally found something I can't do with fvwm, or > am I just missing (or misreading) the docs? Are you kidding? ;-) _Any_ application behaviour that ever annoyed me can be disabled in fvwm (because if it cannot, I'll make a patch). The hard thing is to find out in which way the application does it. Try these settings one by one to see which one works. -- snip -- # annoying behaviour through the application trying to restack its windows? Style IgnoreRestack # annoying behaviour through Gnome hints? Style GnomeIgnoreHints # annoying behaviour through EWMH hints? Style EWMHIgnoreStackingOrderHints # annoying behaviour through UrgencyFunc? destroyfunc UrgencyFunc destroyfunc UrgencyDoneFunc addtofunc UrgencyFunc + I echo Ignoring UrgencyFunc $[w.id] $[w.name] # annoying behaviour through EWMHActivateWindowFunc? destroyfunc EWMHActivateWindowFunc addtofunc EWMHActivateWindowFunc + I echo Ignoring EWMHActivateWindowFunc $[w.id] $[w.name] -- snip -- The drawback of deleting UrgencyFunc or EWMHActivateWindowFunc is that these functions then won't work for _any_ application. For me that is exactly what I want. You may want to use my replacement functions anyway if you don't like windows putting themselves in the front anyway. Please report which one fixes your problem. If the problem still exists, we'll have to figure out the details. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Prevent window from raising itself?
On Wed, May 21, 2014 at 05:06:34PM -0400, Tom Horsley wrote: > On Wed, 21 May 2014 21:12:43 +0100 > Dominik Vogt wrote: > > > # annoying behaviour through EWMHActivateWindowFunc? > > destroyfunc EWMHActivateWindowFunc > > addtofunc EWMHActivateWindowFunc > > + I echo Ignoring EWMHActivateWindowFunc $[w.id] $[w.name] > > Bingo! That's the one that works for google-chrome. > Thanks for the pointer. > > I also can't imagine any reason I'd want any window to > act this way, so I think eradicating that function > for everything will probably be exactly what I want. Maybe we should add this "recipe" to the FAQ. :-p Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
> >2. Also, please turn on some debug otuput with the following fvwm > >command: > > > > bugopts DebugCRMotionMethod on > > Where? How? In the fvwm config file or in FvwmConsole. > >4. Finally, if (3) does not fix the problem and recompiling fvwm > > No output. To clarify; you're looking at the output of the X console? It's not possible that this debug code does not produce output during an fvwm run. Ciao Dominik ^_^ ^_^
Re: FVWM: [fvwm] fltk window origin and fvwm
On Fri, May 23, 2014 at 12:53:24PM +, szukw...@arcor.de wrote: > On Thu, 22 May 2014 22:25:19 +0100, Dominik Vogt wrote: > > >1. Could you make a minimal version of your program that still > >exhibits the problem and send me the source code (along with > >detailed instruction, if necessary)? > > The attached archive is a mininal version. Thanks, I'll look into it when I have time, maybe not before next week. > The attached file is not. But it shows the problem. Um, why did you send a panorama image of a french castle to the mailing list? What I wanted were instructions of how to repoduce the poblem. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
On Sat, May 24, 2014 at 12:19:59PM +, szukw...@arcor.de wrote: > On Fri, 23 May 2014 18:22:55 +0100, Dominik Vogt wrote: > >Um, why did you send a panorama image of a french castle to the > >mailing list? What I wanted were instructions of how to repoduce > >the poblem > > The image is a multipage image. If I press the FORWARD/BACKWARD > button the FLTK window jumps like a frog with LINUX and FVWM. I understand, but it's still not what I asked for. What I need are instructions and source code to make the problem happen on my system. Before I have these instructions I will do absolutely nothing to find what the problem is. > You wrote I should insert > > >In the fvwm config file or in FvwmConsole. > > the line > > bugopts DebugCRMotionMethod on > > I supposed the 'fvwm config file' is the '.fvwm2rc' file > and added the line Of course. Of use the FvwmConsole module and enter it there. > BugOpts DebugCRMotionMethod on > > This failed totally: the cursor was the WAIT clock and after > 5 minutes I press 'Control Alt F2' to finish WAITing. This has aboslutely nothigng to do with the BugOpts command. Sounds like an fvwm function that calls a command that does not finish. To find out the bug in your config file, comment out lines until it goes away and then look at the lines that cause it. We're certainly willing to help you with that, but actually we're not telepathic, so we don't know what's going on on your box unless you provide relevant information. To make that clear again: I'm not going to do anything with the source code you sent unless you give me the instructions I need (and I'm still waiting for the requested debug output). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, May 26, 2014 at 04:23:52AM +, szukw...@arcor.de wrote:
> --
> 1. You must have fltk-1.3.x and libtiff installed.
>(Me: fltk-1.3.x-r10136, tiff-4.0.3)
> 2. cd flimage-fltk13-source-1.9.3
> 3. ./bootstrap.sh
> 4. ./configure
> 5. make
> 6. ./flimage PATH_TO/PalaisDuLouvre.tif
> 7. Press the forward button ('>') from 0 to 5
> 8. Press the backward button ('<') from 5 to 0
First, I get three compile errors when building (on a Debian 32-bit
system):
1) If I don't have libtiff4-dev (version 3.9.6-11) installed:
--
flimage.cxx: In function 'void chooser_cb(const char*)':
flimage.cxx:1280:22: error: 'TIFF_free_read_info' was not declared in this scope
flimage.cxx: In function 'void exit_cb(Fl_Widget*, void*)':
flimage.cxx:1409:22: error: 'TIFF_free_read_info' was not declared in this scope
make: *** [all] Error 1
--
I fixed that by installing the package, but the root cause of the
compile error is that TIFF_free_read_info() is called even with
the configure option --disable-tiff.
2) TIFF.cxx uses the type "tmsize_t" which isn't defined anywhere.
--
TIFF.cxx: In function 'int cpStrips(TIFF*, TIFF*)':
TIFF.cxx:684:2: error: 'tmsize_t' was not declared in this scope
TIFF.cxx:684:11: error: expected ';' before 'bufsize'
--
After some research on the web I concluded that this type is
provided by some versions of libtiff, and is just a 32-bit int on
an 32-bit system, so I added
typedef int tmsize_t;
at the beginning of TIFF.cxx.
3) TIFF.cxx uses the undefined type "uint64".
--
TIFF.cxx: In function 'int cpStrips(TIFF*, TIFF*)':
TIFF.cxx:694:2: error: 'uint64' was not declared in this scope
TIFF.cxx:694:10: error: 'bytecounts' was not declared in this scope
TIFF.cxx:703:29: error: expected ')' before 'bufsize'
--
I've circumvented this problem by adding
#include
typedef uint64_t uint64;
at the beginning of TIFF64.cxx.
--
Second, after building, if I run
./flimage ~/PalaisDuLouvre.tif
The I just get a core dump:
TIFFOpen: (null): Cannot open.
zsh: segmentation fault (core dumped) ./flimage ~/PalaisDuLouvre.tif
./flimage ~/PalaisDuLouvre.tif 0.32s user 1.56s system 25% cpu 7.281 total
gdb session:
-- snip --
Core was generated by `./flimage /home/luthien/PalaisDuLouvre.tif'.
Program terminated with signal 11, Segmentation fault.
#0 0xb75550ec in TIFFFindFieldInfo ()
from /usr/lib/i386-linux-gnu/libtiff.so.4
(gdb) bt
#0 0xb75550ec in TIFFFindFieldInfo ()
from /usr/lib/i386-linux-gnu/libtiff.so.4
#1 0xb75545b6 in TIFFVGetField () from /usr/lib/i386-linux-gnu/libtiff.so.4
#2 0xb755464b in TIFFGetField () from /usr/lib/i386-linux-gnu/libtiff.so.4
#3 0x0804e824 in read_single_image (out_height=0xbfe8d1c0,
out_width=0xbfe8d1bc, read_idf=) at TIFF.cxx:180
#4 get_buf (i=i@entry=0, out_width=out_width@entry=0xbfe8d1bc,
out_height=out_height@entry=0xbfe8d1c0) at TIFF.cxx:232
#5 0x0805041a in TIFF_load (canvas=0x9d33be8, reader=0x9d2d728,
read_idf=0x9d33698 "/home/luthien/PalaisDuLouvre.tif", fsize=1971467)
at TIFF.cxx:407
#6 0x0804ca59 in load_image (fsize=1971467,
fname=0x9d33698 "/home/luthien/PalaisDuLouvre.tif", fp=0x9d2d728)
at flimage.cxx:1191
#7 chooser_cb (cs=cs@entry=0xbfe908d6 "/home/luthien/PalaisDuLouvre.tif")
at flimage.cxx:1302
#8 0x0804b7c6 in main (argc=2, argv=0xbfe8f3a4) at flimage.cxx:1594
(gdb) list
1450while((ch = *s++))
1451 {
1452if(isspace(ch)) continue;
1453*d++ = (char)tolower(ch);
1454 }
1455*d = 0;
1456}
1457
1458int main(int argc, char *argv[])
1459{
-- snip --
This looks like an incompatible version of libtiff. Do you have
an image or images in a less antique format that can be used to
make the problem show up (png? jpg? gif?). (Please post links
to the images or mail them to me directly.)
--
Third,
> --
> events.c:961:
> cre: 0(0) 0(0) 760(4)x685(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 760(4)x636(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 760(4)x429(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 689(4)x308(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 689(4)x256(8) fw 0x0040025f w 0x0066 ew 0x0066 '
Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, May 26, 2014 at 10:29:43PM +, szukw...@arcor.de wrote: > On Mon, 26 May 2014 19:43:49 +0100, Dominik Vogt wrote: > > >First, I get three compile errors when building (on a Debian 32-bit > >system): > > The library 'tiff-4.0.3' has a 'libtiff-4.pc' file for 'pkg-config'. > Older versions do not have this file. > > Therefore the tiff-library you use (3.9.6) is not found because > > #ifdef HAVE_LIBTIFF > > is not activated. Therefore 'TIFF.hh' is hidden; but 'TIFF.hh' > contains 'extern void TIFF_free_read_info();': a local function > found in 'TIFF.cxx', not in 'libtiff'. > ... Okay, I got that. I just want to point out that the code in TIFF.cxx is protected by "#if HAVE_LIBTIFF", but the calls to TIFF_free_read_info() in flimage.cxx (called from chooser_cb() and exit_cb()) are not. I.e. if HAVE_LIBTIFF is zero, you'll get compile errors in the callback functions in flimage.cxx. -- Now back to the undesirable behaviour of the windows. > The image is a multipage image. If I press the FORWARD/BACKWARD > button the FLTK window jumps like a frog with LINUX and FVWM. That is because Fltk is asking fvwm for trouble: 1. It sets the window gravity to StaticGravity when mapping the window. This is essentially *undefined* behaivour. The relevant standard, the ICCCM2, says nothing about what the window manager is supposed to do when initially mapping a window with StaticGravity. 2. The window uses the "user specified position hint" on its initial coordinates and thus prevents the window manager to find a nice place for the window. It is forbidden that applications use this hint unless the user has explicitly requested a certain window position in some way. 3. It is not really clear how a window using StaticGravity should be placed by the window manager when the application resizes it. At the moment, fvwm keeps the middle pixel of the client window (without the window manager decorations) at a constant position. Other window managers keep the top left corner of the window in a constant position. Both relies on badly specified behaviour and is more or less broken. Anyway, I'm still thinking hard whether fvwm's behaviour is optimal or not and may or may not make a patch in the future. So, to fix your application problem, I recommend that you A) use NorthWestGravity for the window, and B) do not use the "user specified position hint" in your program. I have no idea whatsoever how you can communicate this to Fltk, and I am aware that Fltk is using some secret, undocumented (but silly, no, idiotic) defaults. You may have to ask the Fltk developers how to do this. Applications insisting on using StaticGravity should really use the _NET_MOVERESIZE_WINDOW client message and refrain from reconfiguring their windows. Well, if you manage to figure out how to do these two little changes, your window will behave just as any other application window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: suspending a process on Iconify
Isn't $ killall -STOP seamonkey-bin and $ killall -CONT seamonkey-bin an option? If you're not working as root this should be fine. (Don't know from the top of my head what the correct executable name is. Maybe it's "seamonkey.bin", not "...-bin".) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: new chromium windows off screen
On Thu, Jun 05, 2014 at 10:36:08AM +0200, Harald Dunkel wrote: > Is there any style I could use to tell fvwm to ignore chromium's > window placement wishes, and to follow the regular window placement > policy instead? Certainly, the question is *which* one. :-) If you put BugOpts ExplainWindowPlacement on in your config file fvwm will emit messages explaining why the windows end up where they do. If you post that output I can give hints what to try. > Currently I get just a small stripe of the new chromium window > on the left or right edge of the screen, depending upon the > position of the previous chromium window on the virtual desktop. > > Every helpful comment is highly appreciated Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Focus of bold applications and key mapping in fvwm
On Thu, Jun 19, 2014 at 04:59:59PM +0100, Klaus Ethgen wrote: > There are several applications that steal away complete key control from > fvwm so no key bindings works if the window has the focus. Example are > kvm, spicec or several java tools that capture the whole input. > Unfortunately that left me with being unable to switch the desks or lock > the screen or other stuff that I bound to keys in fvwm. > > Is there any way to get around that problem and allow fvwm to react to > key bindings even if the bold window/application has the focus? Sadly, there is no way to prevent applications from grabbing all keyboard input if they want to. The X protocol does not allow the window manager to intervene in any way. To fix this, all you can do is to complain to the vendor to change this. :-( Well you could try to run a nested X server in a window with xnest and then run the annoying applications in there. I'm not sure whether this works, but it's worth a try. > Similar is the problem of applications to decide them self where to map > to. You can apply the style 'StartsOnPage 2 0, SkipMapping', but firefox > does remap themself directly after the start so the window will end on > the current page. > > I miss some style settings to disallow applications to act that bold. If Firefox really moves the windows around after initial mapping, the following styles should do the trick: Style FixedPPosition If the window is also mapped at funny places, one of the following two styles whould help: Style !UsePPosition, !UseTransientPPosition Style !UseUSPosition, !UseTransientUSPosition If that does not help, please explain the behaviour that annoys you in more detail. Note that the initial position of a window is affected by different styles than the styles used to prevent the application from doing funny things _after_ the window has become visible. It is not difficult to override the initial position of a window, but unfortunately there is a plethora of ways in which an application can change the position of a window afterwards. Hm, maybe fvwm should just have a style "DoWhatISay" that would disable all the freaky, unexpected behaviour that annoys user so much. ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: new chromium windows off screen
On Fri, Jun 06, 2014 at 02:14:47PM +0200, Harald Dunkel wrote: > On 06/05/14 18:10, Dominik Vogt wrote: > > On Thu, Jun 05, 2014 at 10:36:08AM +0200, Harald Dunkel wrote: > >> Is there any style I could use to tell fvwm to ignore chromium's > >> window placement wishes, and to follow the regular window placement > >> policy instead? > > > > Certainly, the question is *which* one. :-) > > > > If you put > > > > BugOpts ExplainWindowPlacement on > > > > in your config file fvwm will emit messages explaining why the > > windows end up where they do. If you post that output I can give > > hints what to try. > > > > Found it: Its !UsePPosition instead of NoUsePPosition. Note that the correct name in NoPPosition, not "NoUsePPosition". Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: WindowList, WarpToWindow and Focus
On Fri, Jul 04, 2014 at 11:11:37AM +0200, Walter Alejandro Iglesias wrote: > > First > - > > Using MouseFocus and WindowList function without WarpToWindow, i.e.: > > DestroyFunc WindowListFunc > AddToFunc WindowListFunc > + I Iconify off > + I FlipFocus > + I Raise > #+ I WarpToWindow 5p 5p > > Key Tab A M WindowList > > Style * MouseFocus > > or > > Style * FPEnterToFocus, FPLeaveToUnfocus > > I can cycle the focus over all windows using the keyboard (Alt+Tab). > But if I move the pointer with my mouse over the background (no window > focused) the WindowListFunc is unable to focus again any window. > > The curious thing is this behaviour isn't strict, some times it gives > the focus to some window after two or three Alt+Tab attempts, some times > it doesn't, some times it just raises the stacked window but without > giving it the focus. Once *magically*, after some Alt+Tab attempts, > some window gets the focus, MouseFocus allows me to cycle the focus over > windows normally again with the pointer staying on root. > > It doesn't happen using i.e.: > > Key Tab A M Next (CurrentPage) Focus > > So perhaps it's a WindowList issue. I'll check that problem later, but I can well imagine that MouseFocus does not work well with the FlipFocus command. > Second > -- > > This time commenting out Raise from WindowListFunc: > > AddToFunc WindowListFunc > + I Iconify off > + I FlipFocus > #+ I Raise > + I WarpToWindow 5p 5p > > Windows are raised anyway, unless I comment out the WarpToWindow too. > > AddToFunc WindowListFunc > + I Iconify off > + I FlipFocus > #+ I Raise > #+ I WarpToWindow 5p 5p > > Using this: > > Key Tab A M Next (CurrentPage) WarpToWindow 5p 5p > > Windows are raised too. I thought that the window was raised by > WarpToWindow but using this last Key binding with ClickToFocus it > doesn't. Besides, if WarpToWindow raises why to include Raise in > default WindowListFunc? I can confirm this. Raising is hard coded into the WarpToWindow command, and that's not documented. I'll add the option "!raise" to the WarpToWindow command to circumvent this. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
On Sun, Jul 06, 2014 at 06:27:29PM +, szukw...@arcor.de wrote: > did you find anything I made wrong? Other than the hints I already sent you (and to the list)? No. I've never used fltk, so I'm the wron person to ask. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, Jul 07, 2014 at 10:48:34PM +, szukw...@arcor.de wrote: > On Mon, 7 Jul 2014 19:36:06 +0100, Dominik Vogt wrote: > >Other than the hints I already sent you (and to the list)? No. I've > >never used fltk, so I'm the wron person to ask. > > Wrong answer. >... > Only FVWM cannot fix the main window: a window of X11. It's your application, and I've already given you advice how to fix it in a way that every window manager handles properly: Use NorthWestGravity, not StaticGravity. I'm not going to break other applications by changing fvwm to what you think is right. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fltk window origin and fvwm
> >I'm not going to break > >other applications by changing fvwm to what you think is right. > > > > The matter is not what I think is right. The matter is > HOW to 'Use NorthWestGravity, not StaticGravity' in the > configuration file fvwm2rc. The gravity is set by the application, not by the window manager. So, if fltk does not use NorthWestGravity, then change fltk or use something else. > Searching in FLTK-1.3 I found that in fact the values > > attr.bit_gravity = 0; // StaticGravity; 7:NorthWestGravity > hints->win_gravity = StaticGravity; // NorthWestGravity > > are used. After replacing bit_gravity with 7 and win_gravity > with NorthWestGravity, the window in question showed up as > wanted. If fltk-1.3 relies on poorly defined behaviour, then that's fltk's problem, not fvwm's. The only way to fix that is to change fltk. There's no possible sensible reason to use StaticGravity on all windows, and in many cases it's really just broken. If an applications wants to keep the top left corner of the window at the same position when it's resized, just use NorthWestGravity. That's what NorthWestGravity is meant for. The meaning of StaticGravity is only properly defined if just the decorations of a window change, but the contents stay the same (and are not resized). Practically, when a window with StaticGravity is in fvwmresized, it keeps the center of the client window at the same place. Other window managers keep the top left corner of the client window in place, which is equivalent to NorthWestGravity unless the decorations of the window change. StaticGravity should really never be used unless you have a really good reason to care about the size and placement of the window decorations, and even then it's probably just a bug in the application. StaticGravity during resize is not really standardized anyway. > HOW must run the line(s) in fvwm2rc to change these values? Fvwm (or any other window manager) cannot override the application window's gravity. Ciao Dominik ^_^ ^_^
Re: FVWM: FvwmIconMan not seeing mouse clicks under virtualbox
> I have Linux SL6.4 running under virtualbox 4.3.12 hosted on a Windows 7 > system (on a Dell laptop, if it makes any difference). > > Originally when I set this up FvwmIconMan wasn't seeing any mouse clicks, > and xev didn't show the events being delivered to the window (though it did > show the other events I would have expected). > > Then, for a while, it started working. Then it stopped again in the middle > of a session for no obvious reason, and it hasn't worked since. Could that be related to modifier keys? These nested X window systems often have the problems that they notice that a modifier key has been pressen (shift, ctrl, num-lock etc.) but not that it's been released. When the problem shows up, focus the virtualbox window and hit all modifier keys once and see if that helps. Is FvwmIconMan running separately or inside FvwmButtons? > All the other bits of fvwm seem to be still working: title-bar buttons (so I > can iconify things, just not get them back conveniently), root-window menus, > FvwmPager. Other X clients seem fine too. Hmm. Ciao Dominik ^_^ ^_^
Re: FVWM: new chromium windows off screen
On Thu, Jul 10, 2014 at 06:56:46PM +0200, Harald Dunkel wrote: > > On Fri, Jun 06, 2014 at 02:14:47PM +0200, Harald Dunkel wrote: > >> Found it: Its !UsePPosition instead of NoUsePPosition. > > > > Note that the correct name in NoPPosition, not "NoUsePPosition". > > > > Does this mean that NoUsePPosition is not supported at all? Yes. One day I had enough of that zoo of different on-off-options and since then I only add new options that are negated with an exclamation mark. > Maybe its just me, but I think the man page about NoUsePPosition, > NoPPosition, !UsePPosition, !USPosition, etc is *highly* confusing. > > Maybe it would help to drop the "No" in front of on/off flags > completely? Yes, it is confusing, and that's one of the first things I'd clean up if it ever came to fvwm-3.x. Meanwhile, the options are just there for backwards compatibility. However, I've noticed that the old options are still used in the man page. I'll change that in a minute. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Force application to use my icons
On Thu, Jul 31, 2014 at 09:02:07PM +0200, Walter Alejandro Iglesias wrote: > On Thu, Jul 31, 2014 at 06:22:47PM +0100, Dominik Vogt wrote: > The curious thing is I'm now using a modified version of fvwm.org FAQ's > Thumbnail function that includes this line: > > echo WindowStyle IconOverride, Icon /tmp/icon-$[w.id].png || \ > > And in this case the trick works. But if I use plain Iconify using i.e. > this style: > > Style xboard IconOverride, Icon xboard.png > > Xboard obeys the first time after restarting fvwm, but from the second > time I iconify and upwards it insists in loading some big svg file (I > know the simple dirty solution would be to remove that file). I even > tried to fool it with: > > Style xboard IconOverride, Icon xboard.svg:48x48 > > Without success. I'm not sure what you mean. Can you try to explain it again? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Force application to use my icons
On Thu, Jul 31, 2014 at 10:06:14PM +0200, Walter Alejandro Iglesias wrote: > # THUMBNAILS ON ICONS --- > DestroyFunc Thumbnail > AddToFunc Thumbnail > + I Raise > + I SetEnv Icon-$[w.id] $[w.iconfile] This variable is not used anywhere. > + I TestRc (Match) Test (f $[w.miniiconfile], f /tmp/icon-$[w.id].png) \ ^ Note that this function will never run for windows that do not have an associated miniicon. > DestroyFunc DeThumbnail > AddToFunc DeThumbnail > + I PipeRead "echo WindowStyle Icon \\$\\[Icon-$[w.id]\\]" > + I UnsetEnv Icon-$[w.id] > + I Exec rm -f /tmp/icon-$[w.id].png Add + I DestroyWindowStyle (see explanation below) > That works as expected replacing icons with thumbnails, thanks to the > "IconOverride" option passed to WindowStyle. Now, if instead of using > the Thumbnail function I use just "Iconify" to iconify the window with a > style as you told me: > > Style xboard IconOverride, Icon xboard.png > > this time the same IconOverride option doesn't do its magic. It doesn't work because you forget to destroy the window specific style. A style specified with the WindowStyle command is always preferred over styles specified with the Style command. You need to add this at the end of the DeThumbnail fucntion: + I DestroyWindowStyle Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Force application to use my icons
On Fri, Aug 01, 2014 at 11:20:37AM +0200, Walter Alejandro Iglesias wrote:
> On Fri, Aug 01, 2014 at 06:45:55AM +0100, Dominik Vogt wrote:
> > It doesn't work because you forget to destroy the window specific
> > style. A style specified with the WindowStyle command is always
> > preferred over styles specified with the Style command.
>
> I wake up this morning thinking exactly on that. I'd replaced Thumbnail
> with Iconify in the ShowDesktop function (to speed it up) and forgot
> about FvwmEvent in DeThumbnail. I had it in front of my nose!
>
> Sorry guys, I'm getting old and idiot.
No, the icon syntax is simply a pain. It took me half a day to
figure out what's going wrong. Icon choices are simply
unintuitive and hard to understand.
> > You need
> > to add this at the end of the DeThumbnail fucntion:
> >
> > + I DestroyWindowStyle
>
> I've added this to DeThumbnail and all works perfectly. Thanks Dominik.
Youre welcome. :-) I'm glad that it works now. I had a tough
fight with your configuration because I use FvwmCpp to process my
config file, and then I have to replace *some* line continuations
('\') with "\\", but not all (the ones inside duoble quotes can be
left unchanged).
And I also noticed that if I define a MiniIcon style for the
window and run the scripts too, the mini icon is displayed on top
of the real icon. I wonder if that's a bug or if it's a secret
feature that I could not find in the documentation yet.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Force application to use my icons
On Fri, Aug 01, 2014 at 10:04:51PM +0200, Walter Alejandro Iglesias wrote: > On Fri, Aug 01, 2014 at 05:25:40PM +0100, Dominik Vogt wrote: > > And I also noticed that if I define a MiniIcon style for the > > window and run the scripts too, the mini icon is displayed on top > > of the real icon. I wonder if that's a bug or if it's a secret > > feature that I could not find in the documentation yet. > > The function I've posted? Well the aim is to get something similar to > what MacOSX does. Oh, that's something your function does. I didn't even read the image processing functions. :-) > Let me explain the whole history. I borrowed the > idea from here: > > http://zensites.net/fvwm/guide/advanced_functions.html > > And combined it with what I've read in the fvwm.org FAQ: > > http://www.fvwm.org/documentation/faq/#toc_7.18 > > Note that Thomas put two versions in the FAQ, the first using > DestrowWindowStyle and the second using SetEnv. Actually, it was me who put Q7.18 into the FAQ. I cannot remember who wrote these functions in the first place, though. ;-) > I got the thing working (the function I've pasted in my second message), > I simplified a bit the pipe commands (used just import) and instead of > icons like the guy of the first site did I used mini icons at the top of > the thumbnail. The result I got was: > > http://roquesor.com/Downloads/fvwm_desktop.png Nice. > The problem came because, time ago I'd borrowed from some place (I don't > remember from where) a ShowDesktop function, I modified it a bit too: > > DestroyFunc ShowDesktop > AddToFunc ShowDesktop > + I SendToModule FvwmAnimate pause > + I All (AcceptsFocus, CurrentPage, Iconic, State 1) RestoreDesktop > + I TestRc (Match) Break > + I All (AcceptsFocus, CurrentPage, !Iconic, !State 1) ThisWindow State 1 True > + I All (AcceptsFocus, CurrentPage, !Iconic, State 1) Thumbnail > ^ > (replaced with Iconify) > + I SendToModule FvwmAnimate play > > DestroyFunc RestoreDesktop > AddToFunc RestoreDesktop > + I SendToModule FvwmAnimate pause > + I All (AcceptsFocus, CurrentPage, Iconic, State 1, !Focused) Iconify > + I All (AcceptsFocus, CurrentPage, Iconic, State 1) Iconify > + I All (AcceptsFocus, CurrentPage, State 1) ThisWindow State 1 False > + I SendToModule FvwmAnimate play > > Thumbnail was too slow for this function, the idea is ShowDesktop to be > instantaneous. Hence I put here "Iconify". I forgot DeThumbnail > function :-), FvwmEvent reseted the icon each time the application was > de-iconified that's why the icon setted in styles worked just the first > time and the IconOverride was ignored. Oh, I see. MoveToDesk should work better and faster and not trigger any unwanted application behaviour on iconification: -- addtofunc showdesktop + i all (currentdesk, !iconic) movetodesk 42 addtofunc restoredesktop + i gotodesk 42 + i all (currentdesk) movetodesk -42 + i gotodesk -42 -- The restoration function is a bit complicated because at the moment you cannot say "all (desk 42) ..."; you can only check for the current desk. Note that sticky windows are not affected. If that is necessary, you would have to unstick them, store their "sticky" status in one of the windowstate flags and restore their stickyness in the restoredesktop function. I'm to lazy to do that now, but if you would like to see how to do that, just ask. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
Hi Thomas, this guy asked about porting mvwm patches to fvwm, and I don't know what to answer. As you know, I've been inactive in fvwm for years, and I even missed your fork. Can you tell me a bit about your project, its goals and what your plans are for the future relation of fvwm and mvwm? Cleaning up fvwm is definitely important work, and had I had the time in the past, the 3.0 release would have made such an effort. On Sat, Aug 02, 2014 at 10:49:35PM +0100, Michael Treibton wrote: > I've been trying to port some patches from mvwm, which is the clean-up > effort of another person who uses fvwm. > > The one I'm interested in is a change to libs/FScreen.h to introduce > separate monitor support, which as I can understand it, makes each > screen separate with its own set of desks and pages. I'm finding it > useful. > > Do you know what the plans are with mvwm and if me trying to do this > work is wanted? I am not a programmer, and I cannot tell how much > effort it would be to review any work I do end up doing. > > It's a big change and difficult to split up, the original is here: > https://github.com/ThomasAdam/mvwm/commit/04af8e7f3160a9ee98d67e67c040f9a944cbb409 > > Then there are changes to make use of many monitors across the code base. > > I'm hoping the mvwm guy will help me, but he hasn't responded to any > of my emails, so I wanted to ask here. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: pages and desks [Re: FVWM: fvwm - porting patches from mvwm]
On Thu, Aug 14, 2014 at 04:49:57PM +0100, Thomas Adam wrote: > On 14 August 2014 15:52, Bob Woodside wrote: > > I should be very upset to see this unique feature dropped. > > Sure; it was more a consideration of fitting EWMH into this, where > that concept of page/desk definitions often contradicts the use of > pages, where desks are the only thing that can effectively map to what > EWMH considers, AFAICT. I know, but fvwm should not drop features because the EWMH spec is crap. Apart from the normal uses of desks, the virtually unlimited number of desks allows some very nifty scripting in fvwm. E.g. the "show desktop" feature discussed recently that can be implemented by moving all windows on the current desk to (current desk -100) or something. I wouldn't want to loose this flexibility. With pages, you don't have this flexibility because the size of the root window is limited to 65536x65536 pixels (the coordinates are 16 bit values in the X protocol). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Thu, Aug 14, 2014 at 12:51:33AM +0100, Thomas Adam wrote: > > this guy asked about porting mvwm patches to fvwm, and I don't > > know what to answer. As you know, I've been inactive in fvwm for > > years, and I even missed your fork. Can you tell me a bit about > > your project, its goals and what your plans are for the future > > relation of fvwm and mvwm? > > Sure. I need to be careful about calling it a fork, because it's still > compatible with fvwm. The reason I've forked it and called it mvwm is > to allow me to run the two side-by-side, and that also trying to do this > in CVS would have made me cry [0]. Same for me. I really do not want to work with CVS anymore, and I'd be happy if we had an fvwm git repository tomorrow. :-) > You can have a look here for the TODO file: > > https://github.com/ThomasAdam/mvwm/blob/master/TODO I have taken a look, and can provide background information on various points. Also, I'm interested in discussing the list and helping with the implementation. Do you have already set up a place to discuss the "mvwm" work? Ideally, if the plan is to keep compatible to the current fvwm at least for a while, it would be cool if fvwm-workers gets a copy of the "mvwm" discussions. I think the fvwm users should be a part of the renewal process. Just two quick comments on points of the TODO list. 1) Static vs. dynamic linkage Today, there's really no reason anymore to statically link the fvwm library. Back in the days when I vehemently fought for keeping static linkage, the library was small, and dynamic linking was somewhat unstable. Both is not the case anymore; switching to dynamic linking is a good thing today. 2) Parsing That each command and style does its own parsing is terrible and has bothered me for many years. As a first step I would like to write a new parser that can be configured to deal with the syntax of every existing command and style. The commands can then be adapted to the parser one by one, and if we clean up the commands one day, the parser should still be usable. Switching to a real parser would also remove tons of bugs in the various functions and save a lot of code. And I'd like to start discussing that as soon as possible. > I'm also keen to shrink some of the things fvwm offers---things like the > decor stuff, and having complicated colour gradients, ying/yang > drawings, etc., just seem really strange to me, and a lot of bloat. Hm, the yin-yang gradients were more an expression of the enthusiasm we experienced when the colorsets were invented than a real feature. :-) It was so cool that things like that were suddenly possible with just a little extra code. > I've ripped out a lot of the fvwm modules I > consider to be passe, perhaps too aggressively. Many years ago we already concluded that all of the gui-like modules (buttons, taskbar, iconman, iconbox, pager etc.) should eventually be replaced by a single module (with the provisional name "FvwmGui"). In my eyes, it * combines all the functionality of the obsolete modules, * uses colorsets consequently to allow configuring _all_ gui elements, * can be reconfigured at run time through user interaction (e.g. dragging elements to a different spot in the window), * can parse all the old module configurations, at least in the beginning, * can replace all the old modules with symlinks for compatibility. > The net result of this is to over time amass no real sweeping changes > from fvwm, but to change the underlying things quite a bit. That's > really important, because I believe in fvwm. Ideally, I'd try to keep compatible to fvwm as long as possible. Of course that is not possible once we start cleaning up the syntax. > [0] You and I have looked at this in the past, moving to it. If that's > ever something you want to pick up again, just say the word, all the > bits and pieces are there, and I still maintain the fvwm git repo on > Github. I am happy that you have started the process - something I never managed. And yes, I'd love to help with all the work that needs to be done as soon as possible. For me, there are two important questions: * What is the relationship between fvwm and mvwm. It is clear that once the work starts, fvwm2 is sentenced to an eventual death. The question is how to manage the process of replacing fvwm2 with the reworked code (mvwm, fvwm3, whatever). * We need a place to get organized and discuss things. Maybe it would suffice to simply use fvwm-workers and prefix all rework related messages with "MVWM:" or whatever. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
> I think I've noted this above, but to be clear, the relationship is that > fvwm continues as it is at the moment, and people are free to work on > it, commit to it, fix bugs, etc. With mvwm, it's a way for us to try > out completely radical ideas, and break fvwm's compatibility, > eventually. This was exactly my plan for fvwm-3.0. Fvwm has some pretty useful and flexible concecpts, but the basic code structure is also 25 years old. Large parts of the implementation and the syntax are terrible > As for replacing one against the other, I'm not sure. Of course I've no problem if someone wants to continue maintaining the old code, but - once we have the new code - I'm not the person who will do that. The compat stuff can be separated from the new core code, maybe as a module or script. But it's illusive to assume that it would be possible to be completely compatible and redo all the parsing. Fvwm's scripting is too powerful. For me, personally, it's important that we won't say that the "old" fvwm is crap and needs to be replaced with something new, better etc. It just needs to be renovated. P.S.: And I do want a window manager with a reference to cats in its name. ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Fri, Aug 15, 2014 at 02:37:10PM +0100, Thomas Adam wrote: > > P.S.: And I do want a window manager with a reference to cats in its > > name. ;-) > > Maybe the 'm' in mvwm could stand for "moggy" or something then? Maybe as > time progresses we'll think of something different. Felinevwm (short: fvwm3) would be fine with me. ;-) Anyway, talking about names is not urgent in any way. > Dominik, I've taken the liberty of augmenting the TODO file in the mvwm > repository with some of your notes from your previous email. Thank you for > that. That's grand. There has be so much talk, and so little has been documented. > I'd appreciate some thoughts about where to base further discussion as I'm > keen to keep momentum going. For practical reasons I suggest to start on fvwm-workers for the moment. We need to use the momentum we have now, because next week real life might catch up with me. It it turns out to be impractical, we can think about something else. For the time being I'd like to not shut out the people reading the fvwm-workers list right from the start. I'll start a new mail thread about parsing with the prefix "REWRITE: " in a minute. In the mean time I've created a github user id 'domivogt' and cloned the mvwm repository and would be happy if you gave me push access so that I can start to work in topic branches there. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Function To Manage FvwmButtons Instances
On Sat, Aug 16, 2014 at 08:05:11AM +0100, Jamie Griffin wrote: > What I've got so far is two functions: one that checks the top > taskbar, stops it if it's open and then opens the bottom dock; the > other function does the same but for the other fvwmbuttons dock. > Here they are: > > DestroyFunc OpenDock > AddToFunc OpenDock > + I All (Panel) Close > + I TestRc (NoMatch) KillModule Panel Is there a specific reason why you try to kill the module in two different ways? The first line might also kill other windows. Anyway, for the scripting you might want to give the modules a unique name. > + I TestRc (Match) Module FvwmButtons Dock -g +300-0 > > DestroyFunc OpenPanel > AddToFunc OpenPanel > + I All (Dock) Close > + I TestRc (NoMatch) KillModule Dock > + I TestRc (Match) Module FvwmButtons Panel -g $[vp.width]x24+0+0 > > The problem with this approach is I have to have them bound to > separate key strokes. When I first create the keybindings it's > possible I might forget which one is which and so if I press the > wrong one, it doesn't handle that well. I'd much prefer it to be > bound to a single key stroke and have it check which instance is > open, then close the open fvwmbuttons and start the other, as I > mentioned. > > I'd be very grateful if anyone could offer a solution or some help. You can use a wrapper function: DestroyFunc ClosePanelOpenDock AddToFunc ClosePanelOpenDock + I All (Panel) Close ... (Better use killmodule instead of close.) DestroyFunc CloseDockOpenPanel AddToFunc CloseDockOpenPanel + I All (Dock) Close ... DestroyFunc SwitchPanelOrDock AddToFunc SwitchPanelOrDock + I Next (Panel) ClosePanelOpenDock + I TestRc (nomatch) CloseDockOpenPanel key f1 a n switchpanelordock As a little example for advanced scripting in complex functions: THere is a function in my config that (1) starts a certain application if it's not already running, (2) closes it if it's running, on the current page and not iconified, shaded etc., (3) makes the window visible on the current page if the application is running but not on the current page, or iconified, shaded etc. #// #// Application toggling function #// #// first argument is the window name, second argument is the command to start #// the application. AddToFunc ToggleWindow + I None ($$0, CirculateHit) $$1 + I TestRc (Match) Break + I Next (currentpage, visible, !iconic, $$0, CirculateHit) Close + I TestRc (Match) Break + I Next ($$0, CirculateHit) Function MakeVisible AddToFunc MakeVisible + I MoveToDesk + I MoveToPage + I MoveToScreen + I Iconify off + I WindowShade off + I Raise Example uses: AddToFunc ToggleFvwmConsole + I ToggleWindow FvwmConsole "Module FvwmConsole" More complex example: AddToFunc RunXMessages + I Exec rxvt -geometry -0-0 -T XMessages -n XMessages -e tail -f ~/.X.err AddToFunc ToggleXMessages + I ToggleWindow XMessages "Function RunXMessages" Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Function To Manage FvwmButtons Instances
On Sat, Aug 16, 2014 at 09:50:15AM +0100, Jamie Griffin wrote: > Aside from any errors, would you have any recommendations to improve > what i'm trying to achieve? In my eyes, this is a good approach. Well, in the CloseFooOpenBar function you might want to check whether Bar is already open and only start it if it's not. + I none (Bar) This way you can also call the function elsewhere without creating duplicate instances of the dock or panel, e.g. when you restart fvwm. > One idea I had was to have a form of some kind pop-up when I start > the fvwm session asking which, if any, panel/dock i'd like to start. This will probably annoy you very quickly. Just choose a default you want and start that during fvwm startup. If it's not what you want sometimes, just press the key to switch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Function To Manage FvwmButtons Instances
On Sat, Aug 16, 2014 at 12:11:28PM +0100, Jamie Griffin wrote: > > On 16/08/2014 10:30, Dominik Vogt wrote: > >On Sat, Aug 16, 2014 at 09:50:15AM +0100, Jamie Griffin wrote: > >>Aside from any errors, would you have any recommendations to improve > >>what i'm trying to achieve? > >In my eyes, this is a good approach. Well, in the CloseFooOpenBar > >function you might want to check whether Bar is already open and > >only start it if it's not. > > > > + I none (Bar) > > > >This way you can also call the function elsewhere without creating > >duplicate instances of the dock or panel, e.g. when you restart > >fvwm. > > > >>One idea I had was to have a form of some kind pop-up when I start > >>the fvwm session asking which, if any, panel/dock i'd like to start. > >This will probably annoy you very quickly. Just choose a default > >you want and start that during fvwm startup. If it's not what you > >want sometimes, just press the key to switch. > > Thanks again for your help and suggestions. I got it working by > swapping out Next with None in the wrapper function. Oh, I meant you should an additional "None" in the inner function so that you can call the inner functions without the wrapper at startup. > One thing i've considered is, having changed my taskbar/panel/dock > if I want to keep that layout for next session could this be easily > integrated with the FvwmSaveDesk module? FvwmSaveDesk hasn't been maintained in decades, you should rather not use it. But you can easily do something like .fvwm2rc: Read $HOME/.fvwm/setup_dock_or_panel Then add addtofunc closedockopenpanel ... + i exec exec echo clodedockopenpanel > $HOME/.fvwm/setup_dock_or_panel And the other way round in the other function. But make sure that you don't use a file in a publicly writeable location because then someone else could put his own fvwm commands in there. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Populating an FvwmButtons button with PipeRead output
By the way, I've been using the module interface for a similar
task. One of the buttons in FvwmButtons displays the time and
date, another one current memory usage and a third one the top
cpu using process. This is updated every fifteen seconds.
Because I don't like processes (FvwmCommand) to be started all the
time I wrote the ModuleListenOnly fvwm command and implemented the
module as a zsh script (attached). Note that the module interface
uses the "long" C type, and the script is written for systems
where sizeof(long) is four. It needs to be adapted of eight byte
longs, i.e. 64-bit systems.
The command to start the script is
+ I ModuleListenOnly fvwm_periodic -u 15 -d 3 -c clock -t topproc -M mempct
in the InitFunction and the RestartFunction. The ModuleListenOnly
allows to write one way modules. They can send packets to fvwm,
but fvwm does not send them any packets.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
#!/usr/bin/zsh
emulate zsh
setopt HUP
zmodload zsh/zselect
LC_ALL=de_DE@euro
MODULE="FvwmButtons"
IDCLOCK=""
IDMEM=""
IDPROC=""
SECS="15"
ISECS="3"
usage () {
echo "usage: module-args $0 [-c id] [-t id] [-M id] [-m module] [-u
secs] [-d delay]"
echo "Update certain button titles in FvwmButtons"
echo " module-args: filled out by fvwm when started as a module"
echo " -h: display this help message"
echo " -c buttonid: update clock at the given button id"
echo " -M buttonid: update used memory at the given button id"
echo " -t buttonid: update topproc at the given button id"
echo " -m module:name of the module [$MODULE]"
echo " -u secs: update buttons every secs seconds [$SECS]"
echo " -d secs: initial delay [$ISECS]"
}
send () {
printf \\00\\00\\00\\00\\xa0\\00\\00\\00%159s\\00\\00\\00\\00\\n "$1" \
>&$OF || exit 1
}
changebutton () {
send "SendToModule '$MODULE' ChangeButton $1"
}
update_proc () {
CM='?'
PM='?'
NM='?'
ps -A --format "%C %P %c" | {
# skip header
read
while read C P N; do
test $[CM < C] = 1 && CM="$C" && PM="$P" && NM="$N"
done
}
changebutton "'$IDPROC' Title '$PM $CM% $NM'"
}
update_mem () {
TOTAL=1
FREE=0
while read T V R; do
test x"$T" = x"MemTotal:" && TOTAL="$V" && break
done < /proc/meminfo
while read T V R; do
test x"$T" = x"MemFree:" && FREE="$V" && break
done < /proc/meminfo
PCTM="$[(100 * (TOTAL - FREE)) / TOTAL]"
changebutton "'$IDMEM' Title 'mem: ${PCTM}%'"
}
update_clock () {
T=`strftime '%R %a %d.%m.' $EPOCHSECONDS`
changebutton "'$IDCLOCK' Title '$T'"
}
#
# parse options
#
test $# -le 4 && echo "fvwm_periodic must be started by fvwm" 1>&2 && exit 1
OF="$1"
IF="$2"
shift 5
while test ! $# = 0; do
case "$1" in
-h|-\?|--help)
usage
exit 0
;;
-c|--clock)
test $# = 1 && usage && exit 1
shift
IDCLOCK="$1"
test ! x"$IDCLOCK" = x && zmodload zsh/datetime
;;
-M|--mem)
test $# = 1 && usage && exit 1
shift
IDMEM="$1"
;;
-t|--topproc)
test $# = 1 && usage && exit 1
shift
IDPROC="$1"
;;
-m|--module-name)
test $# = 1 && usage && exit 1
shift
MODULE="$1"
test x"$MODULE" = x && usage && exit 1
;;
-u|--update-secs)
test $# = 1 && usage && exit 1
shift
SECS="$1"
SECS="$[SECS]"
test "$[SECS]" -le 0 && usage && exit 1
;;
-d|--delay-secs)
test $# = 1 && usage && exit 1
shift
ISECS="$1"
ISECS="$[ISECS]"
test "$[ISECS]" -lt 0 && usage && exit 1
;;
**)
break
;;
esac
shift
done
test $# -gt 1 && usage && echo "error: unknown option $1" && exit 1
#
# main body
#
trap exit HUP INT QUIT KILL PIPE TERM
# sleep is not a builtin, so prefer zselect
test "$[ISECS > 0]" = 1 && zselect -t ${ISECS}00
while true; do
test ! x"$IDCLOCK" = x && update_clock
test ! x"$IDMEM" = x && update_mem
test ! x"$IDPROC" = x && update_proc
zselect -t ${SECS}00
done
Re: FVWM: Using Two FvwmIconMan
On Mon, Aug 18, 2014 at 08:36:11AM +0100, Jamie Griffin wrote: > I'm using 1 FvwmIconMan in my taskbar which is swallowed (it's > fvwmbuttons really) but, I want to have another fvwmiconman opened > when I change my layout. > > When I close the fvwmbuttons taskbar that has fvwmiconman 1 > swallowed, what is the right way to start another (2nd) fvwmiconman > ? 'Module FvwmIconMan 2'? Do I just use the manager number as an > argument? The man page is not clear on that at all. Just start a second FvwmIconMan with a different name: Module I.e. # config lines *MySecondFvwmIconMan... Module FvwmIconMan MySecondFvwmIconMan Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Mon, Aug 18, 2014 at 09:32:11AM -0400, Dan Espen wrote: > I haven't examined mvwm all that closely. At the moment, mvwm is mostly fvwm with a lot of old and obscure features removed and some changes of repository layout. > I had assumed that the mvwm work would eventually fold back into Fvwm. I think Thomas has something more radical in mind, either forking off permanently, or replacing fvwm2 with fvwm3 eventually. > I read the parsing write up. > My guess is that you are trying to develop a table driven parser > for all (or most) fvwm commands? That definitely must be one goal of the syntax rewrite. > I just did something similar for a work project. > But I didn't have a lifetime, so I just implemented the table > driven parser for the commands I was dealing with at the time. > Since then I've gone back and added a few more commands. Well, at the moment it's too early to think about how a new parser should look like. First we need to find out what the current fvwm needs from a parser. Than we can think about replacing commands and streamlining the syntax. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Mon, Aug 18, 2014 at 11:25:51AM -0400, Dan Espen wrote: > Dominik Vogt writes: > >> I just did something similar for a work project. > >> But I didn't have a lifetime, so I just implemented the table > >> driven parser for the commands I was dealing with at the time. > >> Since then I've gone back and added a few more commands. > > > > Well, at the moment it's too early to think about how a new parser > > should look like. First we need to find out what the current fvwm > > needs from a parser. Than we can think about replacing commands > > and streamlining the syntax. > > I've never been in favor of an incompatible change not backed up > by an automatic conversion program. But that's just me. No, not just you, I'm not fond of breaking the existing fvwm syntax either. But on the other hand fvwm2 has really hit a brick wall in ways of extensibility. If all else fails, backwards compatibility can be provided as some kind of module or input filter. > I'm not looking to dump fvwm2. It works too well for me. It works perfectly for me too. But I wish it was easier to introduce new features, and I'm still dreaming about some kind of "database" approach to window configuration where you can just dump configuration into, e.g. specific to window id, resource pattern, class pattern, for all windows, for windows with certain properties etc. When a window needs information about it's style, a lookup in the database spits out the most specific style information for each style. This would be so much more configurable (and hence able to get funny applications under control) than that mess of the style logic we have now. But eventually, some features like decors or the icon choosing code are too broken to be replaced by something better that is yet compatible. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Mon, Aug 18, 2014 at 12:37:37PM +0100, Michael Treibton wrote: > On 18 August 2014 05:50, Dan Espen wrote: > > Brian writes: > > > >> On Sun, 17 Aug 2014 15:25:43 +0100 > >> Michael Treibton wrote: > >> > >>> On 15 August 2014 21:05, Dominik Vogt wrote: > >>> > I'll start a new mail thread about parsing with the prefix > >>> > "REWRITE: " in a minute. > >>> > > >>> > In the mean time I've created a github user id 'domivogt' and > >>> > cloned the mvwm repository and would be happy if you gave me push > >>> > access so that I can start to work in topic branches there. > >>> > >>> Can I help in some way? > >>> > >>> Michael > >> > >> I too would like to help someway. Is there a person to send a > >> skills resume to for review and assignment to the project? > >> Brian Amundsen in Minnesota. > > > > Read this: > > > > http://fvwm.org/documentation/dev_cvs.php > > > > anyone can write and submit a patch. > > Thank you, Dan. I was hoping more for mvwm. I can't see how the > instructions would be the same? The git repository is at git://github.com/ThomasAdam/mvwm Just clone it and start hacking. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Mon, Aug 18, 2014 at 01:40:33PM +0100, Michael Treibton wrote: > On 18 August 2014 12:44, Thomas Adam wrote: > > Is this perhaps not clear enough? I appreciate the enthusiasm, but this > > groundwork is really important before we can move forward. Unless there's > > anyone else who wishes to help out with this---which would mean > > understanding a fair amount of fvwm internals at this point, etc., I am not > > sure what else to suggest you can do for now. > > I'm interested in mvwm specifically as i've already tried to port your > patches to fvwm already without success. Fair enough. If I understand Thomas right, he considers the patches you're interested in as purely experimental, with the long term goal to support it in a clean way. However, the fvwm sources are a real mess at the moment, and we need to focus on cleaning that up first, before we can start adding new features in a new, clean way. > i'm worried this is turning into an 'exclusive club' at the moment. As long as I have any voice here, fvwm and any attempts to rewrite its code base will never be "exclusive". :-) > what's the contribution path to 'outsiders' like me? > the roadmap (in the TODO) lists quite boring features - is this all > theres going to be? The TODO is just the foundation of the new project. It lists a lot of very important infrastructure changes that are actually very un-sexy for users. > have you (and others) got enough experience with fvwm to carry this > off? Um, I think, if *anybody* has the expertise, it's me. ;-) Although I had taken a break for some years, I've been fvwm's most active maintainer and developer. > - or do you need others to help? Yes. I do not believe in private creations of single authors. At the moment, help would equal taking an active part in the ongoing discussions. I'm afraid that we don't have any cool features that we could ask people to implement at the moment, but only "boring" things about technical issues. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: fvwm - porting patches from mvwm
On Mon, Aug 18, 2014 at 12:39:51PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > It works perfectly for me too. But I wish it was easier to > > introduce new features, and I'm still dreaming about some kind of > > "database" approach to window configuration where you can just > > dump configuration into, e.g. specific to window id, resource > > pattern, class pattern, for all windows, for windows with certain > > properties etc. When a window needs information about it's style, > > a lookup in the database spits out the most specific style > > information for each style. This would be so much more > > configurable (and hence able to get funny applications under > > control) than that mess of the style logic we have now. > > Easy enough to do if you're willing to accept the overhead of > reading multiple files at startup. But with the existing implementation you cannot do dynamic things like the following in the core without adding new code: * if window is in the top right corner, make the default shading direction northeast, i.e. Style ($[w.x] == -0 && $[w.y] == 0) DefaultShadeDirection NE * if the window uses ewmh hints, and uses static gravity, use the alternative resize algorithm, * if the window is sticky, use a different coulour set for the decorations. Style (Sticky) Colorset , HilightColorset This could all come mostly for free with a priority based style database. At the moment, such features have to be hard coded manually. > My borders vary by window type. I could have a file, HandleWidths > containing: > > Style * HandleWidth 7 > Style "sun-awt-X11-XWindowPeer" HandleWidth 0 > Style "*xbiff" HandleWidth 6 > Style "XSysStats" HandleWidth 6 > > Writing an FvwmForm or FvwmScript to update the file is trivial. > > And so on, for Lenience, Key bindings, Mouse bindings. > Personally I don't need it and I'd prefer to keep my various > customizations organized by Style. The user interface for this isn't affected, only the internal representation. The user does not see the database. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mvwm - documentation
On Sun, Aug 24, 2014 at 04:09:13PM +0100, Michael Treibton wrote: > On 24 August 2014 10:00, Thomas Adam wrote: > > But heed my previous email; when you get down to it, *roff (mdoc) *is* > > the abstraction layer. That mdoc allows for all these things, and is > > still letting you use the very typesetting language man pages render > > with, etc., is a winner in my eyes. > > https://github.com/ThomasAdam/fvwm/blob/ta/asciidoc/Documentation/FvwmDecor/DefaultColors.txt > > the mdoc version is going to be a lot more work - many more commands > to include - and it gets in the way. That example lacks almost all the markup in the text. It does not allow to automatically generate links in html format, or identify command names, command options, styles, strings, key sequences etc. by markup. An Asciidoc source file without all that is useless. I've spent weeks to add the proper markup to the original fvwm man pages before they were converted to xml. I won't accept any documentation format that throws all this extra information away for no reason. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mvwm - documentation
Folks, I'm back from my (very) extended fvwm holiday for roughly a month now, and I hardly know this place anymore. Can we *please* keep the personal discussions off, and the technical discussions on the list? Really, developers can be difficult at times (myself being a good example), but certainly if we try, everybody can get along with each other regarding the technical stuff. Working on fvwm and the rewrite is tedious and - as stated elswhere - can be boring and may not be rewarding immediately. All the more, help from people who are willing to tackle boring stuff is welcome. There are no intentions to change development to a closed model, and I'm eager to hear any opinions and comments by any user or developer on the direction we're taking - as long as they eventually reach the necessary techical level. But still, please try to respect the many hours of work some of us have spent for fvwm (and the experience we gained), and please understand that everybody needs to spend their time economically. So, specifically, I ask everybody to really read and think about the messages on the lists, to assume a constructive attitude, to accept that people are different and one might find it difficult to get along with somebody else, who is technically brilliant. And please try not to launch personal attacks and try not to take replies personal even if they are. As it looks like the problems have been sorted out now, can we please go back to the issues we have to solve? To me it looks like a good idea to move this thread of discussion from the user's list to the fvwm-workers list. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mvwm - documentation
On Mon, Aug 25, 2014 at 09:22:59PM +0400, Roman Grazhdan wrote: > >I've spent weeks to add the proper markup to the original fvwm man > >pages before they were converted to xml. I won't accept any > >documentation format that throws all this extra information away > >for no reason. > > So Dominik, you would set requirements later so that I could check > what I'm doing against them? > I like the current manual very much, it's really helpful and as > close to easy to use as a documentation for something like fvwm > can get, and I'd like it to stay this way. Me too. My only personal requirements are that (a) the final, rendered man page should mostly look like it looks now (not losing the markup I mentioned, although we have a bit too much at the moment), and (b) that I'll be able document new features in the future without much overhead. I've always been very happy with the roff format we had before the switch to xml. Before xml there were these short instructions about editing the man pages right at the top (e.g. in the 2.4.0 tarball): -- .\" Formating instructions for the fvwm man page: .\" .\" - Do not use \f... formatting instructions. .\" - Avoid single and double quotes wherever possible. .\" .\" For further details, please refer to the Linux Man-Page how-to. .\" .\" contexttypeface example .\" -- -- - .\" filenames: italics (.I).I .fvwm2rc .\" command line options of fvwm2 cmd: bold (.B) .B \-cmd .\" arguments of command line options: italics (.I).BI \-cmd command .\" built in commands: bold (.B) .B Move .\" references to built in commands: bold (.B) .RB See Move .\" references to man page sections: bold (.B) .RB See SYNOPSIS .\" references to style options: italics (.I).RI See Lenience .\" built in command options: italics (.I).BI "Move " "0 0" .\" command syntax:bold/ita. (.BI) .BI "Move [" "x y" "]" .\" environment variables: italics (.I).I $DISPLAY .\" key names: small (.SM) .SM Tab .\" style names and strings: double quotes "stylename", "x" .\" single characters: single quotes '@' .\" module names: bold (.B) .B FvwmTheme .\" links to web pages:bold (.B) .B http://fvwm.org .\" acronyms: small (.SM) .SM ICCCM .\" .\" .\" The name fvwm is written in lower case throughout this man page. .\" .\" Note that the word "will" is rarely correct in a man page or any document. .\" Describe what fvwm does, not what it will do, even if you haven't .\" written the feature yet. dje 2/3/01. .\" .\" A note to everyone who needs to write dates. Don't use 2/3/01 notation, .\" a non-american person simply can't parse such sequence of digits. .\" Please use 3-Feb-2001 or 2001-02-03 forms. migo 16/May/2001. -- Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mvwm - documentation
On Mon, Aug 25, 2014 at 09:27:17PM +0100, Thomas Adam wrote: > On Mon, Aug 25, 2014 at 04:19:37PM -0400, Dan Espen wrote: > > Very sorry you still don't like the XML format. > > I find it clumsy, but I'm willing to put up with it. > > Personally I almost always go online and read Fvwm man pages > > as HTML. Anything we can come up with that renders HTML > > is good with me. > > That's definitely an output format we'll be doing, even with mdoc---to > lose that would be irritating to say the least. > > > I want to mention, when I wrote F_CMD_ARGS, > > one of the things I had in mind was to put function > > documentation in the .c files. I envisioned some kind of > > extract run generating the actual man page input. > > I was trying to make the functions easy to find by giving > > them a uniform appearance. > > Interesting. Whilst I don't like macros in place of formal function > arguments myself, I can see why you did this, Dan. Well, for me the macros F_CMD_ARGS and F_PASS_ARGS helped me a lot, even without documnetation. Before we had them, you had to change more than 300 funtion declarations and function headers and maybe 1000 argument lists in internal calls when you added or removed a command argument. Now, I could add in another command argument and had to change only a couple of calls that are too specific to use F_PASS_ARGS. They have saved me many, many hours of boring, tedious and error prone work and have definitely improved the overall code quality. Apart from that, I'm not a big fan of macros that contain more than a constant or a very simple expressions. But sometimes they can really help. > On the point about > documentation, this is precisely what doxygen allows for. We could > always make use of that---and certainly it would be an interesting > excerise to do, as it would help appraise and justify the existing > functions we have, and help identify any potential cleanups, etc. I've worked with Doxygen on several occations but never got fond of it. People forget to update the source code documentation, and summaries of whole modules are hardly ever written. Often you end up with a loose collection of poorly maintained function descriptions without the correllations documented. Personally I find it easier to remember writing decent documentation when it's all in a single place (one of my main woes with the xml files). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: mvwm - documentation
On Mon, Aug 25, 2014 at 10:10:11PM +0100, Michael Treibton wrote: > On 25 August 2014 19:33, Dominik Vogt wrote: > > So, specifically, I ask everybody to really read and think about > > the messages on the lists, to assume a constructive attitude, to > > accept that people are different and one might find it difficult > > to get along with somebody else, who is technically brilliant. > > And please try not to launch personal attacks and try not to take > > replies personal even if they are. > > i feel like i should offer a public apology. Apology accepted, but really, there's no need for one. Let's just forget about past problems on the mailing lists and go back to work. Everybody will be fine if there is progress in the work. > and i hope we can move forward from this. That is exactly what we need now, especially since the current work we all do is not very exciting. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Positioning a menu
> >> I've got a taskbar at the bottom of the screen and a start button > >> (FvwmButtons) which when pressed is supposed to open a menu right above it, > >> like Windows '98 style. The taskbar is 25 pixels in height and i'd like the > >> menu to overlap the top of it by one pixel, giving the appearance its part > >> of it. So, appearing the very far left of the screen, 24 pixels from the > >> bottom. +0-24 in X geometry. > > For example: > > > > Menu SomeMenuName Rectangle +0-24 0 0m > > > > The thing to note here is the "Rectangle" option. > > > > -- Thomas Adam > Thanks Thomas, > > I've tried that and it too does not work as intended. This is the > invocation line in .fvwm/config: > > [ ... ] > *Panel: (1x1, Frame 1, Padding 0 0, Icon mini/mini.start.xpm, Action > (Mouse 1) 'Menu FvwmRootMenu Rectangle +0-24 0 0m') > [ ... ] +0-0 0 -100m-24p or 1x24+0-0 0 -100m The position in the context ractangle seems to be broken when using negative values, or I don't understand my own documenation anymore. Something to clean up in the future. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Positioning a menu
On Thu, Aug 28, 2014 at 01:50:21PM +0200, Dominik Vogt wrote: > The position in the context ractangle seems to be broken when using > negative values, or I don't understand my own documenation anymore. > Something to clean up in the future. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: will mvwm have a web site?
On Sun, Aug 31, 2014 at 03:31:18PM +0100, Michael Treibton wrote: > I'm curious if and when mvwm will get its own website? Will you want > help with that when you start this? Of course I cannot speak for Thomas. But as long as I see "mvwm" only as a working name for something that is really fvwm3 (the plans are more then ten years old, and what we're doing is really the old plan for fvwm3 - with some new ideas added by Thomas), I see no need for a new web site, name or logo. > What about a new logo? I see the old fvwm site that there are > lots of logos! These are the result of the fvwm logo competition we had many years ago. The official logo is the one with the cat's tail on www.fvwm.org. > Some are cats?! Yes. :-D Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: will mvwm have a web site?
> >>> Some are cats?! > >> > >> Yes. :-D > > > > ok. > > > > so will it always be cats? I like cats - but I think also Thomas likes > > teddy bears? Is there a famouse teddy bear that has the letter 'm' for > > its name? > > i nominate this one - http://xteddy.org/teddies/leo.jpg :-D Well, I'm fine if everybody has their own logo. After all, the only places where it appears are the web site, FvwmBanner (which I guess nobody really uses because it's annoying), and there is a small version of the logo for use as a sidepic in menus. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Thu, Sep 04, 2014 at 08:56:52AM -0400, Tom Horsley wrote: > Just wondering if this strikes a familiar note? The newest > google-chrome running on my fedora 20 system utterly fails > to redraw anything at all (not only no web content, but > no menu bar, navigation buttons, etc) when I minimize it, > then later restore it from the window list. I get nothing > but fvwm window decorations and a totally white window > inside them (at least it is the right size :-). > > Out of curiosity, I tried it under gnome 3 in fedora 21 > (the fedora 20 video drivers won't run gnome 3) and the > window contents do get restored when I fully restore the > window, but in gnome 3, in the "preview" with all the small > copies of the windows you can click on to actually do the > restore, the google-chrome preview window is totally blank. > > It is like the gnome shell is doing something "extra" when > actually restoring the google-chrome window that makes > it really redraw. Any clue what that might be and if I > can convince fvwm to do it too? First of all, write a bug report for the application. Some hints: * Does it redraw if you place another window on top of it, covering it partially or even completely when you remove the other window? * Does the broken application gobble cpu? * Try the RefreshWindow command on the offending window with something like All (window-name) RefreshWindow RefreshWindow actually tries to force an application redraw by covering that window completely for a moment. If anything of this works, it should be possible to automate that. Maybe you can add Thiswindow (window-name) RefreshWindow to your de-iconification function. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Dynamically Populating FvwmButtons
On Thu, Sep 04, 2014 at 02:30:58PM +0100, Jamie Griffin wrote: > On 04/09/2014 10:20, Thomas Adam wrote: > >On Thu, Sep 04, 2014 at 09:48:52AM +0100, Jamie Griffin wrote: > >>Is there a way to populate a set of buttons based on the contents of a file > >>or directory, perhaps using a default icon and a predefined template of an > >>FvwmButtons instance? > >> > >>So, for example, if I had some documents in a directory each the same format > >>and not likely to change often, can I have a Container filled to a grid of > >>say 'nxn' depending on the number of documents in the directory which could > >>be obtained through a script and/or PipeRead and then use a default icon for > >>each button. > It's not so much I can't write it, i'm just considering starting > something I think would work well if set up using that method and > wanted to know if it is worth me trying that approach. Just be careful with the filenames when you read them in via PipeRead or send them to FvwmButtons with "SendToModule changebutton". You probably want to forbid a some characters in file names (single and double quotes, backticks, backslashes, newlines, dollar characters and maybe other whitespace. If you pass them to fvwm, bad things could happen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Thu, Sep 04, 2014 at 04:42:49PM -0400, Chris Siebenmann wrote: > > On Thu, Sep 04, 2014 at 08:56:52AM -0400, Tom Horsley wrote: > > > Just wondering if this strikes a familiar note? The newest > > > google-chrome running on my fedora 20 system utterly fails > > > to redraw anything at all (not only no web content, but > > > no menu bar, navigation buttons, etc) when I minimize it, > > > then later restore it from the window list. I get nothing > > > but fvwm window decorations and a totally white window > > > inside them (at least it is the right size :-). > [...] > > First of all, write a bug report for the application. > > > > Some hints: > [...] > > What I'm seeing is that nothing works to get Chrome to redisplay. > Covering and uncovering Chrome does nothing, resizing the Chrome window > does nothing, RefreshWindow does nothing, and Chrome doesn't gobble > CPU. In fact I have iconified a Chrome window that was playing a Youtube > video and when I deiconified it the audio continued but there were > absolutely no video updates. > > In addition, Chrome doesn't seem to pay attention to keyboard input > once iconified and deiconified. For instance, Control-W will normally > close my Chrome windows but after a deiconify it's completely ignored. > Chrome *does* still notice and respond to fvwm's Close, though, so it > is not completely ignoring X events. Sounds pretty broken. Other things to try are to resize the window or to restart fvwm or to use the "Recapture" or "RecaptureWindow" command. Maybe clicking somewhere in the window where one of the controls should be helps? But I have litte hope that anything of this wokrs. Probably the window waits for some specific odd event that never comes. Do you display icons too, or have them just in the icon manager? Maybe it waits for the icon window to appear? Try to comment out all icon related styles in your configuration file and see if that helps (i.e. make fvwm use and display whatever icon pixmap or icon window the application provides). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: ToggleTitle and Maximize
On Fri, Sep 05, 2014 at 02:03:16PM +0300, Nikos Leonardos wrote: > Thank you Thomas for the quick response. > > On 05.09.14 11:53, Thomas Adam wrote: > > On Fri, Sep 05, 2014 at 12:37:41PM +0300, Nikos Leonardos wrote: > > It will do, because those won't be applied necessarily in the order you > > think they will. What I would do is to use State instead to achieve this. > > Could you explain why they are not applied in this order? In > particular, why should they be applied in order for your > ApplyWindow function below, but not for my FuncToggleTitle > function above? Fvwm is lazy about applying styles to windows to reduce the number of useless updates. For example, if you read in a file that defines twenty new styles, you wouldn't want the windows to be updated twenty times. So, fvwm waits until no more commands are coming in and then updates all windows that need updates at the same time. The one situation where this is confusing is in complex functions. Styles will only be applied when the outermost function has completed. In your case, use the UpdateStyles command to apply style updates immediately. From the man page: > To force that all pending changes are applied immediately, use > the UpdateStyles, Refresh or RefreshWindow commands. (I'm not sure that the refresh commands would really do that.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Fri, Sep 05, 2014 at 06:16:55AM -0400, Tom Horsley wrote: > On Fri, 05 Sep 2014 11:49:17 +0200 > Bert Geens wrote: > > > However shading and unshading the window after deiconifying returns the > > application to normal behaviour for me (fvwm 2.6.5). > > So now I have to ask: What the heck is shading and unshading > and how do I do it? :-). Shading means to reduce the window to its title bar (in fvwm you can also "shade" a window to any of its borders or corners to make it really small). Use the WindowShade command to do that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Fri, Sep 05, 2014 at 07:34:51AM -0400, Tom Horsley wrote: > On Fri, 05 Sep 2014 11:49:17 +0200 > Bert Geens wrote: > > > However shading and unshading the window after deiconifying returns the > > application to normal behaviour for me (fvwm 2.6.5). > > By golly, it works for me too (once I found the WindowShade function > and added it to my window operations menu). Thanks! Now, that is a real surprise to me. Shading and unshading a window is almost the same as just resizing it, except that some additional Ewmh or Gnome state may be communicated to the window. Could one of you please try what happens if you add the following lines at the end of the function fvwm/icons.c:CMD_Iconify(), right before the final return: FlushAllMessageQueues(); XFlush(dpy); EWMH_SetWMState(fw, False); GNOME_SetHints(fw); GNOME_SetWinArea(fw); (Even if it works it is not a proper solution, just an attempt to fire extra events at the window and see what happens.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Thu, Sep 04, 2014 at 05:34:08PM -0400, Chris Siebenmann wrote: > > Probably the window waits for some specific odd event that never > > comes. > > An odd event or maybe a sequence of events? Odd as in "I've no idea for which event or why". ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Fri, Sep 05, 2014 at 04:08:09PM -0400, Chris Siebenmann wrote: > > Could one of you please try what happens if you add the following > > lines at the end of the function fvwm/icons.c:CMD_Iconify(), right > > before the final return: > > > > FlushAllMessageQueues(); > > XFlush(dpy); > > EWMH_SetWMState(fw, False); > > GNOME_SetHints(fw); > > GNOME_SetWinArea(fw); > > > > (Even if it works it is not a proper solution, just an attempt to > > fire extra events at the window and see what happens.) > > I tried this and it appears to have made no difference to the > behavior of Chrome: de-iconifying still results in blank white, > and WindowShade'ing it fixes this. Sigh. Do you use any of the window shading related styles? WindowShadeSteps WindowShadeScrolls or WindowShadeShrinks WindowShadeLazy or WindowShadeAlwaysLazy or WindowShadeBusy Or the obsolete WindowShadeAnimate command? Can you post all your WindowShade related settings please? And what exactly is the command that triggers shading? (All these questions aim at finding out exactly what the WindowShade command does on your system, and what the difference is between shading and resizing windows manually.) Also, please try to grab the bottom border of the bad window, and drag it all the way up to the title bar (in opaque resize mode, not in wire frame mode). Stop resizing, then resize the window again to its original size. One more thing to try: Does maximizing and unmaximizing the window help? Or making it sticky and unsticky? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Fri, Sep 05, 2014 at 04:46:50PM -0400, Chris Siebenmann wrote: > > Also, please try to grab the bottom border of the bad window, and > > drag it all the way up to the title bar (in opaque resize mode, > > not in wire frame mode). Stop resizing, then resize the window > > again to its original size. > > This has no effect, but during the opaque resize things flicker > and I can occasionally see flashes of bits of window content. Sounds really broken. > > One more thing to try: Does maximizing and unmaximizing the window > > help? Or making it sticky and unsticky? > > Maximizing and unmaximizing the window has no effect. > > However, making it sticky and then unsticky is a winner; the moment > I make it sticky the window contents pop back (and they stay when I > unsticky it again, until I iconify it again). In addition while the > window is set sticky I can iconify it and then deiconify it and the > contents stay visible. Actually, stickyness and maximization are Ewmh window states - just like shading. That's why I suggested trying them. So, if you replace deiconify with AddToFunc Deiconify + I iconify off + I stick toggle + I stick toggle That should hide the problem without a lot of resizing and moving the window around. On Fri, Sep 05, 2014 at 04:57:29PM -0400, Tom Horsley wrote: > I'm not really sure it is worth trying to fix from the fvwm side > now that we have a work around. No, of course not; I won't add crazy stuff to window handling jsut because of one broken application. It might be worthwhile to add another BugOpts option (or a style) that makes fvwm tell windows that they are shaded when they are actually iconified. > This has got to be a chrome bug > google ought to fix (doesn't it?, he queried hopefully :-). I hope so, but things can take a long time until they're fixed. (Please don't send replies to me directly but only to the list.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Special window manager hand holding required?
On Fri, Sep 05, 2014 at 11:11:49PM +0100, Thomas Adam wrote: > On Fri, Sep 05, 2014 at 09:36:42PM +0100, Dominik Vogt wrote: > > (All these questions aim at finding out exactly what the > > WindowShade command does on your system, and what the difference > > is between shading and resizing windows manually.) > > It's to do with EWMH_SetWMState() -- that's the only difference, and > indeed in terms of CMD_WindowShade(), not calling that won't refresh the > contents. > > The call-chain looks like this: > > EWMH_SetWMState() -> ewmh_ChangeProperty() -> XChangeProperty() Actually, in many places there's no XFlus() after these calls, so the change may be delayed somewhat. But that does not explain the symptoms. > I do not know why, in the case of the XChangeProperty() call happening > and fvwm receiving the PropertyNotify event for the EWMH-class of > events (it's not just windowshade, sticky also makes the window work > correctly), that the window is then magically refreshing its contents > and returning to normal. Well, the Ewmh stuff defines an atom for stickyness and one for shading, but nothing for iconify (as that information is already available from elsewhere). So I guess when the application receives a PropertyNotify event for one of these atoms it re-examines the window's state and concludes that ist should start redrawing again. Actually I don't understand all this crap logic. The real criterion is: If you receive an Expose event, redraw. If you don't receive one, don't redraw. A window that is iconified is unmapped and a window that is shaded is either hidden or unmapped. In both cases the window does not get Expose events and any special logic is superfluous. > That really is the culprit here---and indeed, WindowShading is no > different to resizing anyway, and having spent a while trying to debug > this, I can only conclude fvwm isn't to blame, nor do I want to dig > around in Chrome's internals. Thinking about it - shading in fvwm is very different from resizing in fvwm because when you shade a window, only the frame is resized, but the client window keeps its size. This is meant to prevent crazy redrawing during animated window shading. Furthermore the final size of the client window would be 0 pixels anyway, and the animation might make the window smaller than the requested minimum size. So I actually only move the window around in the frame during the animation without resizing it. Ideally the application wouldn't even notice that the window is shaded (shading would work *better* if there wasn't this stupid _NET_WM_STATE_SHADED atom). Well, I've probably made clear what I think of the Ewmh spec in the past. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
FVWM: REWRITE: Request for help -- parsing of command token
For testing pusposes I need to get an overwiev of what types of commands people use in fvwm. Could everybody please look through their configuration files and post any commands: 1) That contain whitespace, quoting characters or variables (e.g. $[foo] or $w) in the first word of the line. Expamples: -- snip -- |* FvwmButtons: ... | Move 0 0 |"Resize" ... | ` Stick ` ... |Some\ Function ... |Some$[env.function]" ... -- snip -- If it's not obvious, please include the command line that is actually executed. 2) Such things in conditional commands or function or menu definitions in place of the command name, menue name or function name. Examples: -- snip -- AddToFounc Foo$[desk.n] I "Desk$[w.desk] Func" + I \ MyOwnFunc\ a b c All `Destroy` + I PipeRead 'cd $HOME/.fvwm2/palettes; /bin/ls *.pal | sed -e \"s:\\(.*\\)\\(\\.pal\\):+ &\\1 Function SetPalette \\1\\2:\"' -- snip -- (With the same explanation as above, if necessary). 3) Fvwm allows to start modules without using the "Module" command, e.g. with just "FvwmButtons" instead of "Module FvwmButtons". Do you use this? Did you know that's possible? Please be careful to not post sensitive information, and please post only interesting lines, not your whole configuration files! If you have a similar line multiple times, plese post it only once. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: REWRITE: Request for help -- parsing of command token
On Sat, Sep 13, 2014 at 09:14:03AM +0100, Dominik Vogt wrote: > For testing pusposes I need to get an overwiev of what types of > commands people use in fvwm. Could everybody please look through > their configuration files and post any commands: My own lines: #define CLOSE CloseAnimated + D CLOSE Cpp macro expansion + I None ($$0, CirculateHit) $$1 In a function called with "Foo ''" uses in the condition and executes after removing the quotes + I Exec $1 Similar to above. + I PipeRead 'cd $HOME/.fvwm2/backgrounds; /bin/ls *.bg.* | sed -e \"s#\\(.*\\)\\(\\.bg\\..*\\)#+ &\\1%$HOME/.mvwm/backgrounds/\\1.thumb.png% Function SetDefaultBackground \\1\\2\:\\1.thumb.png#\"' Complex quoting AddToFunc MakePaletteMenu + I DestroyMenu PaletteMenu + I AddToMenu PaletteMenu `Palettes [ MVWMPALETTE]` Title + I + `show current palette` FvwmButtons ColourTable + I + "" Nop + I AddToMenu PaletteMenu + I PipeRead 'cd $HOME/.fvwm2/palettes; /bin/ls *.pal | sed -e \"s:\\(.*\\)\\(\\.pal\\):+ &\\1 Function SetPalette \\1\\2:\"' Menu definition inside a complex function Read .fvwm2rc.$[screen] > 3) Fvwm allows to start modules without using the "Module" command, >e.g. with just "FvwmButtons" instead of "Module FvwmButtons". >Do you use this? Did you know that's possible? No, yes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: REWRITE: Request for help -- parsing of command token
On Sat, Sep 13, 2014 at 11:50:15PM -1000, p...@pair.com wrote: > in message <20140913081403.ga3...@gmx.de>, > wrote Dominik Vogt thusly... > > > > For testing pusposes I need to get an overwiev of what types of > > commands people use in fvwm. Could everybody please look through > > their configuration files and post any commands: > > > > 1) That contain whitespace, quoting characters or variables > >(e.g. $[foo] or $w) in the first word of the line. > > These seems to be most obvious ... > > DestroyFunc deiconify-func > AddToFuncdeiconify-func > + I Iconify false > + I WindowShade false > + I $0 Would you use any weird stuff as "$0", or just a couple of plain words? > > Expamples: > > -- snip -- > > |* FvwmButtons: ... > > | Move 0 0 > > |"Resize" ... > > | ` Stick ` ... > > |Some\ Function ... > > |Some$[env.function]" ... > > -- snip -- > > > >If it's not obvious, please include the command line that is > >actually executed. > > Do the characters on the next line of continuation line count? Not really. Continuation lines are concatenated before the parser does anithing with them. > > 3) Fvwm allows to start modules without using the "Module" command, > >e.g. with just "FvwmButtons" instead of "Module FvwmButtons". > >Do you use this? Did you know that's possible? > > Hunh, I have both usage ... > > key g A 4 Module FvwmConsole But you could also use just > key g A 4 FvwmConsole without the "Module" command. I've never seen anybody using that, though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
