physical screen boundaries
How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. -- Jason Weber
Re: physical screen boundaries
On Fri, Oct 08, 2010 at 10:04:18AM -0700, Jason Weber wrote: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Assuming you are talking about Xinerama screens, fvwm sends the modules a packet whenever the screen layout changes. The packet string is XineramaConfig. Upon receiving such a packet, a module wopuld call the function FScreenConfigureModule() which stores the module configuration is structures that can be accessed by the other helper functions in libs/FScreen.[ch]. For example, with FScreenGetScrRect() you can find out about the geometry of the given Xinerama screen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: physical screen boundaries
Jason Weber baboon.im...@gmail.com writes: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Perhaps $[vp.width]/$[vp.height] will work. I'm only using one monitor. Thomas, I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now.
Re: physical screen boundaries
Thomas Adam tho...@xteddy.org writes: On Fri, Oct 08, 2010 at 01:33:56PM -0400, des...@verizon.net wrote: Jason Weber baboon.im...@gmail.com writes: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Perhaps $[vp.width]/$[vp.height] will work. I'm only using one monitor. Thomas, I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now. Err, do you mean on the website or built as part of ./configure make sudo make install -- only for unstable, that will just be fvwm. It's generated from the not-so-lovely XML sources -- and IIRC, the man page is always built, but you would need to pass an option to ./configure to get the HTML documentation. I mean it's missing from the website: http://fvwm.org/documentation/manpages/unstable/ Unless I'm blind...
Re: physical screen boundaries
On Fri, Oct 08, 2010 at 04:06:52PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: On Fri, Oct 08, 2010 at 01:33:56PM -0400, des...@verizon.net wrote: Jason Weber baboon.im...@gmail.com writes: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Perhaps $[vp.width]/$[vp.height] will work. I'm only using one monitor. Thomas, I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now. Err, do you mean on the website or built as part of ./configure make sudo make install -- only for unstable, that will just be fvwm. It's generated from the not-so-lovely XML sources -- and IIRC, the man page is always built, but you would need to pass an option to ./configure to get the HTML documentation. I mean it's missing from the website: http://fvwm.org/documentation/manpages/unstable/ Unless I'm blind... No, your eyesight's fine. I've regenerated the whole lot -- which is what I thought I did when I released 2.5.31, but maybe I was too drunk to remember? :P Either way, the index.php file looks more correct now, so if it still looks odd, let me know. Kindly, -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
CVS tadam fvwm-web: Regenerated manpages.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: tadam 10/10/08 15:21:05 Modified files: . : ChangeLog documentation/manpages/unstable: FvwmAnimate.php FvwmAuto.php FvwmBacker.php FvwmBanner.php FvwmButtons.php FvwmCommand.php FvwmConsole.php FvwmConsoleC.pl.php FvwmCpp.php FvwmDebug.php FvwmDragWell.php FvwmEvent.php FvwmForm.php FvwmGtk.php FvwmGtkDebug.php FvwmIconBox.php FvwmIconMan.php FvwmIdent.php FvwmM4.php FvwmPager.php FvwmPerl.php FvwmProxy.php FvwmRearrange.php FvwmSave.php FvwmSaveDesk.php FvwmScript.php FvwmScroll.php FvwmTabs.php FvwmTaskBar.php FvwmTheme.php FvwmWharf.php FvwmWinList.php FvwmWindowMenu.php focus-link.php fvwm-bug.php fvwm-config.php fvwm-convert-2.2.php fvwm-convert-2.4.php fvwm-convert-2.6.php fvwm-menu-desktop.php fvwm-menu-directory.php fvwm-menu-headlines.php fvwm-menu-xlock.php fvwm-perllib.php fvwm-root.php fvwm.php index.php Log message: Regenerated manpages. Somehow this was missed from the last release I did.
Generated web pages
Thomas Adam tho...@fvwm.org writes: On Fri, Oct 08, 2010 at 04:06:52PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now. Err, do you mean on the website or built as part of ./configure make sudo make install -- only for unstable, that will just be fvwm. It's generated from the not-so-lovely XML sources -- and IIRC, the man page is always built, but you would need to pass an option to ./configure to get the HTML documentation. I mean it's missing from the website: http://fvwm.org/documentation/manpages/unstable/ Unless I'm blind... No, your eyesight's fine. I've regenerated the whole lot -- which is what I thought I did when I released 2.5.31, but maybe I was too drunk to remember? :P Either way, the index.php file looks more correct now, so if it still looks odd, let me know. At the bottom of the man page index there is a link: title-format.patch. The link doesn't go anywhere.
Re: Jumping shaded window when resized by application
On Sat, Oct 09, 2010 at 01:15:16AM +0200, Dominik Vogt wrote: 1. I have 3x2 pages. 2. A seamonky download window is on page (0, 1). (One of the individual download windows, not the big list of all downloads.) 3. Select the button to keep the window open after the download is complete. 4. Move the window to the top right corner and shade it to the right. (Only the border of the window is visible along the pages right border.) 5. Wait until the download is complete. The window will then change it's size, i.e. its width increases. So I downloaded and am using Seamonkey version 2.0.8. Following these instructions, I downloaded an ISO -- the window in question remained open after download, but the window did not move, nor did the size of the window change after download. This was even with a config of /dev/null -- although using my own .fvwm2rc had the same effect; the window behaved itself. == The shaded window jumps to page (1,2). You don't have anything in your config triggering a recapture of the window or something to make FVWM shunt the window elsewhere? I'm assuming not anyway. I attached xev to this window as well -- it doesn't show there being anything odd happening to the client once the download has finished. -- Thomas Adam -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
