Re: FVWM: fullscreen focus problem
2010/1/7 MK halfcountp...@intergate.com:
On Thu, 07 Jan 2010 14:22:38 +0100
Zoilo Gomez zo...@xs4all.nl wrote:
It looks as though some applications (vlc, xine, etc) still pass the click
to the window which allows the client to accept focus. Thus, although you
have NeverFocus set, it's not doing it's job properly.
I do not understand what you mean - in any case there is no mouse click
or so.
I would guess that if you are using, eg, SloppyFocus, even tho you do not
have to click on the app, fvwm must pass a focus window event to the
application, which is what would happen if you had to click to focus.
It handles the EnterNotify event on the window and sets focus accordingly.
Of course with NeverFocus this should not happen. In fact, you *do not say
that the VLC window takes focus* -- you just
say the Flashplayer window loses it. Is that correct? If so, I would say
that is a choice made by the flashplayer -- when it
goes out of fullscreen, it gives up focus -- probably when recalculating the
geometry, the mouse is considered to leave.
Then it focusses again when it recieves the appropriate window event
notification (when you move the mouse *back into* the window). The fact
that the mouse is already in the window does not count, since we cannot be
continually sending
this signal -- it only happens when the mouse enters (SloppyFocus) or you
click inside.
No -- VLC really is taking focus, as are other applications like Xine
when NeverFocus is set. FVWM propagates the click event to the
application which is setting focus on it, stealing it away from the
window which had the focus originally. This has nothing to do with
the focus policy used -- if anything it's more noticeable with
SloppyFocus because you wouldn't ordinarily click the client window to
take focus. FVWM receives the buttonpress event, works out whether
the window should handle focus or not, propagating the click events as
necessary to the application. With XTerm, there are only
{Enter,Leave}Notify events as you'd expect, as well as KeymapNotify
events. But with Xine and Vlc, PropertyNotify events are being
generated on my setup -- this shouldn't happen.
Zolio, if you set the Unmanaged style on the Vlc window temporarily,
this should sort you out.
-- Thomas Adam
Re: FVWM: 2.4 = 2.5 upgrade breaks xcuckoo
2010/1/8 Jim Kalb jimk...@gmail.com: Hello all! I've been using 2.4.20 (under Slackware 13.0) and grown attached to the following functions, which depend on the old Unix program xcuckoo: If, from my limited googling, this application just updates the window title periodically, it's probably using XSetWMName() or something. That's OK, but like xprop, which will try and do the same thing, not all applications will like or accept this. You might want to ditch xcuckoo though and look into wmctrl -- which was written sometime this century. -- Thomas Adam
Re: FVWM: 2.4 = 2.5 upgrade breaks xcuckoo
On Fri, Jan 08, 2010 at 05:25:38PM +0100, Viktor Griph wrote: 2010/1/8 Jim Kalb jimk...@gmail.com: I just tried upgrading to 2.5.28 and both stopped working. [...] So I assume that there's some generally-used window manager modernization that breaks xcuckoo and probably nothing can be done about it short of modifying xcuckoo (not something I'm competent to do). Can you give fvwm 2.5.27 a try? I think what you are seeing is the result of the Fvwm now retains utf8 window names when the WM_NAME changes, and the utf8 name converted to the default charset match the old WM_NAME bug fix in 2.5.28. Hmm. I am not so sure. The condition SET_HAS_EWMH_WM_NAME(fw, 1) for that fix was just shifted up -- but it has always been set in fvwm/ewmh_names.c::EWMH_WMName() to True. When a client receives a PropertyNotify event, and the event was for WM_NAME, then we just return immediately from any further processing if the fw window has EWMH_WM_NAME. So the only time a WM_NAME event change can happen from things like xprop and wmctrl can only be when the client isn't listening to such things -- which for most apps is going to be rare. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm doesn't maximize windows after screen resolution change
On Tue, Jan 12, 2010 at 10:25:26PM -0800, Craig wrote: I recently started using fvwm in a VMWare virtual machine, and am having a problem. After resizing the screen, maximizing a window continues to operate as if the screen dimensions had not changed. Is it possible for fvwm to automatically detect the new dimensions when they are changed? That's because FVWM needs to be restarted after you change the screen resolution as it's not XRandr-aware and still reads the old values from X. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm doesn't maximize windows after screen resolution change
On Wed, Jan 13, 2010 at 12:39:11AM -0800, Craig wrote: On Wed, 13 Jan 2010 08:21:01 +, Thomas Adam said: ... That's because FVWM needs to be restarted after you change the screen resolution as it's not XRandr-aware and still reads the old values from X. -- Thomas Adam Is there a plan to make FVWM XRandr-aware? In the meantime, is there a work around? I find it useful to re-size my VMWare Player Window. Well, assuming you change resolutions via FVWM, then it should just be a case of: DestroyFunc XRandRChangingResolutionFunc AddToFunc XRandRChangingResolutionFunc + I PipeRead `xrandr --blah --option etc` + I Restart Note that the use of PipeRead is probably pointless, but you should probably keep it, since you really do only want to restart FVWM when the resolution has really changed. Yes, suppport is planned in so much that it's on the cards for FVWM 3.0, just like a lot of things are. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: how to set focus delay?
On Wed, Jan 13, 2010 at 12:55:42AM -0800, Craig wrote: Is it possible to configure fvwm to have focus delay? I have only found options for raise delay. What focus policy are you using? With ClickToFocus, see something like: Style * ClickToFocus FvwmAuto 900 -menter Focus -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: how to set focus delay?
On Wed, Jan 13, 2010 at 03:54:16AM -0800, Craig wrote: I had both of those styles in my config prior to your suggestion to use FvwmAuto 900 -menter. Since !FPFocusByProgram prevented that from working, I removed it along with several other styles I thought might be It would do, yes. I was generalising. too drastic. Putting !FPFocusByProgram back in...done. What about !FPFocusByFunctionWarpPointer? What about it? Can be used to not warp the pointer if it receives a Focus event from FVWM, independant of using Focus NoWarp. You probably just want to leave this as-is. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm and lxpanel
On Wed, Jan 13, 2010 at 05:14:49AM -0800, Craig wrote: On Wed, 13 Jan 2010 12:26:06 +, Thomas Adam said: On Wed, Jan 13, 2010 at 04:23:23AM -0800, Craig wrote: Is it possible to prevent windows from being placed or moved under/over a panel such as lxpanel? Read up on EWMHBaseStruts in man fvwm. The panel is reserving space: xprop | grep _NET_WM_STRUT _NET_WM_STRUT(CARDINAL) = 0, 0, 26, 0 Adding EwmhBaseStruts 0 0 50 0 to my config results in windows being placed even lower on the screen; however, it does not prevent me from moving it under the panel (or over it if StaysOnTop is not set). Of course. That area isn't a wall -- you can move windows over it, newly placed windows aren't put on it. Also, firefox will still start up in that area if the second window it's restoring is closer to the top of the screen than the first one. See: !UsePPosition. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm and lxpanel
On Wed, Jan 13, 2010 at 06:35:14AM -0800, Craig wrote: On Wed, 13 Jan 2010 13:48:03 +, Thomas Adam said: .. Of course. That area isn't a wall -- you can move windows over it, newly placed windows aren't put on it. I've added SnapAttraction to my config make it more difficult to move a window under/over the panel. Are there other suggestions on how to keep windows from under/over-lapping the panel? That's one way -- the other is to use trickery pre/post moving a window. The above will do, but it won't stop windows moving over that area. Also, firefox will still start up in that area if the second window it's restoring is closer to the top of the screen than the first one. See: !UsePPosition. That didn't work, but this does; Style * FixedPPosition This is only going to mask the fact that the window is likely smaller than the working area. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm doesn't maximize windows after screen resolution change
On Wed, Jan 13, 2010 at 02:52:17PM -0800, Craig wrote: On Wed, 13 Jan 2010 12:39:09 +, Thomas Adam said: ... Oh, well then tough -- you'll have to decide when to restart FVWM then. Is there a program I could run that is aware of screen size changes, and use it to directly or indirectly restart fvwm? xrandr? xdpyinfo? But don't get me to repeat myself, please --- the answer I gave you still stands: to do what you want isn't possible, I've given you all the alternatives I can think of, and you've said they're no good for you. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: x2x and x2vnc
2010/1/15 Craig 4gq7nrk...@sneakemail.com: Sometimes, if a window is at the edge of the screen, it prevents x2x from moving control to another other computer. Same problem with x2vnc. I tried adding these lines to my config, yet the problem still occurs. EdgeThickness 0 Style x2x* Sticky, StaysOnTop Style x2vnc* Sticky, StaysOnTop This problem does not occur until some time after fvwm is restarted, and I have yet to determine exactly when it does. What makes you think this has anything to do with FVWM, out of interest? -- Thomas Adam
Re: FVWM: Cursor Position
On Tue, Jan 26, 2010 at 12:40:05PM -0800, Davidson Russell wrote: My company runs 2.5.26. In this release, when we right click on the desktop and select a window to focus on, the cursor automatically moves to the upper left corner of the selected window. Is this a bug? Is this a feature? Is there a way to turn this off? I've been searching for release notes for 2.5.26 and haven't had any luck. AddToFunc WindowListFunc + I Iconify off + I FlipFocus + I Raise + I WarpToWindow 5p 5p WarpToWindow 5p 5p is responsible for moving the cursor. Perhaps you want to redefine it like this? DestroyFunc WindowListFunc AddToFunc WindowListFunc + I Iconify off + I FlipFocus NoWarp + I Raise But at this point, anything else from me is academic. Enjoy. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
[rdav...@yahoo.com: Re: FVWM: Cursor Position]
Another off-list reply. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci. ---BeginMessage--- thanks, that fixed it. - Original Message From: Thomas Adam thomas.ada...@gmail.com To: Davidson Russell rdav...@yahoo.com Cc: fvwm@fvwm.org Sent: Tue, January 26, 2010 2:02:25 PM Subject: Re: FVWM: Cursor Position On Tue, Jan 26, 2010 at 12:40:05PM -0800, Davidson Russell wrote: My company runs 2.5.26. In this release, when we right click on the desktop and select a window to focus on, the cursor automatically moves to the upper left corner of the selected window. Is this a bug? Is this a feature? Is there a way to turn this off? I've been searching for release notes for 2.5.26 and haven't had any luck. AddToFunc WindowListFunc + I Iconify off + I FlipFocus + I Raise + I WarpToWindow 5p 5p WarpToWindow 5p 5p is responsible for moving the cursor. Perhaps you want to redefine it like this? DestroyFunc WindowListFunc AddToFunc WindowListFunc + I Iconify off + I FlipFocus NoWarp + I Raise But at this point, anything else from me is academic. Enjoy. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci. ---End Message---
Re: FVWM: Google Summer Of Code 2010
On Sat, Jan 30, 2010 at 11:53:57AM -0500, MK wrote: On Fri, 29 Jan 2010 23:16:38 + Thomas Adam thomas.ada...@gmail.com wrote: Hi all, So I am going to raise this now, unlike last year where we only had a few days to come up with something. Is there anyone here who's thinking of wanting to work on FVWM via GSOC? I had not thought of it specifically, but I do want to apply to GSOC this year, have been programming C obsessively for 2-3 years, and using fvwm for 5-10, altho I've never contemplated the source. I'm starting a FSF internship for the spring (until the end of April) and am fairly busy at the moment, but I will have a look at the TODO list and get back to you early next week. If there's something I'm capable of, I will probably be interested. Well, I am no where near coming up with a list of proposals, so I wouldn't get too enamoured with the TODO list. It's still very early days, but I'll keep your name on my list. This wasn't an invitation to reply off-list, either. Do pleas check in future. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Google Summer Of Code 2010
On Thu, Feb 04, 2010 at 12:57:17PM -0500, MK wrote: On Sat, 30 Jan 2010 17:01:15 + Thomas Adam thomas.ada...@gmail.com wrote: Well, I am no where near coming up with a list of proposals, so I wouldn't get too enamoured with the TODO list. It's still very early days, but I'll keep your name on my list. Just to make sure, which TODO list are you referring to here: the one that comes with the 2.5.28 source? Or something more recent? fvwm/docs/todo-3.0 (Does your MUA/editor allow for wrapping text at ~74 characters? If so, suggest you turn it on, as your reply was all on one long line. ;)) -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Moving windows BeOS style?
On Fri, Feb 05, 2010 at 08:01:45PM -0500, des...@verizon.net wrote: Johann \Myrkraverk\ Oskarsson joh...@myrkraverk.com writes: On Fri, Feb 5, 2010 at 9:05 PM, des...@verizon.net wrote: Johann \Myrkraverk\ Oskarsson joh...@myrkraverk.com writes: On Fri, Feb 5, 2010 at 12:07 PM, Thomas Adam thomas.ada...@gmail.com wrote: On 5 February 2010 09:36, Johann Myrkraverk Oskarsson joh...@myrkraverk.com wrote: Ok, this thread is filled with misunderstanding, and I apolagize for not being clearer. I use the xkb option altwin:meta_win so my windows key actually generates the Meta event: KeyRelease event, serial 142, synthetic NO, window 0x1c1, root 0x1a6, subw 0x0, time 1299299808, (-4,173), root:(696,558), state 0x40, keycode 115 (keysym 0xffe7, Meta_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Looks like a keysym, not a modifier. Indeed. But it could all be tied together, with the output from: xmodmap -pm To discuss, send replies to Fvwm.org. Normally you will get cc'd unless you say you are subscribed. You mean you haven't attempted to try and get a consultancy fee from the off-list reply, Dan? That's my standard response to erroneous misuse of an email client these days. :P -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Application icons in panel and icon man
On Mon, Feb 08, 2010 at 08:53:25PM +0100, Nathan H?sken wrote: Hi, I am using fvwm for not to much time, and I like it very much. Thanks for the great work! What is nagging me: besides urxvt and gvim, every application is shown with the standard rotatet square icon. How can I change it? I think you want: *FvwmIconMan: DrawIcons Always ... and note theat unless the application defines for itself an icon, you'll want to set a style on the application to define the miniicon. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Application icons in panel and icon man
On 9 February 2010 07:33, Nathan Hüsken f...@lonely-star.org wrote: OK, I can redefine the icon for those applications. I understand, firefox and co. have no obligation to define their icon. But it still amazes me, that they do not. But they tend to. Look: _NET_WM_ICON Most applications, if they define this will allow FVWM to use them. You can use xprop to find out.Read up on: EWMHDonateIcon EWMHDonateMiniIcon ... in the FVWM man page. I am also wondering: Can you confirm that firefox,thinderbird,pidgin and chromium do not define an Icon? Otherwise something might be wrong with my installation ... See above. -- Thomas Adam
Re: FVWM: Window manager refit windows function
On 9 February 2010 11:53, Nathan Hüsken f...@lonely-star.org wrote: Hi, fvwm has many cool windows replacing and resizing functions. But one thing I was not able to do so far: A function that refits all windows on the screen by making minmal adjustments. What do I mean? Lets say I have 3 windows. I put one in top right, on in bottom right and one on the left. I do this roughly with the mouse. Now if the do not overlap, I can grow every one by letting them take all free space. But if they only overlap a little, that would not work. So a function, that makes the current active windows on the screen take all free space without overlap, by moving windows as little as possible would be really cool. Does anything like this exist or is possible? Yes -- you can use Maximize to grow until it hits the other edge of the window, to fill the remaining space. There's examples of this in man fvwm. You could also probably use FvwmRearrange as well, although that's less obvious. -- Thomas Adam
Re: FVWM: Window manager refit windows function
On 12 February 2010 08:29, Nathan Hüsken f...@lonely-star.org wrote: I am sorry if I am bothering or am asking stupid questions, but I really can not find it in the fvwm documentation (looking throught the manpages and the html documentation). I understand how PipeRead works (that I found in the manpages), but to make it rearrange my whole desktop, it needs to get a list of all windows and their geometry. I have seen $[w.width] (only in this list, where is it documentated), but that gives me only the current window. I need all windows ... All (foo) PipeRead `.` But you will likely need to double-up on your expansion parameters in PipeRead, so: $$[foo] for instance. I am being deliberately vague here -- since I assume you're wanting to try to do this yourself? If not, when I get back from work, I'll give you a solution using FvwmPerl -- won't take me long, I suppose. -- Thomas Adam
Re: FVWM: fvwm forum completly down?
On Fri, Feb 12, 2010 at 09:57:00AM -0500, des...@verizon.net wrote: Nathan H?sken f...@lonely-star.org writes: Hi, Search in google for fvwm stuff very often brings up results from http://fvwm.lair.be (and I am guessing some former fvwm forum). But the site is not reachable. At first I thought it was temporarly down, but now ... Is the fvwm forum in some other way reachable? It's down and last time we heard, no recovery date. I've asked for help, but no one's yet come forward -- not surprising when the problem is rather PhpBB-specific, and those folks haven't gotten back to me either. :P Either way, the new forums are here: www.fvwmforums.org -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: chromium under fvwm and opening pdf files
On Sun, Feb 14, 2010 at 12:09:25AM +0100, Nathan Huesken wrote: Hi, When I use chromium under Xfce4, it opens pdf files using evince. When I use chromium under fvwm, it opens pdfs using firefox (which opens pdfs using evince, but is started and takes long to start). I am not sure, if this is really a fvwm thing, but it is my only guess. Maybe someone in the list knows ... Read up on how mailcap entries work. Nothing to do with FVWM. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: chromium under fvwm and opening pdf files
On Sat, Feb 13, 2010 at 06:45:03PM -0500, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: On Sun, Feb 14, 2010 at 12:09:25AM +0100, Nathan Huesken wrote: Hi, When I use chromium under Xfce4, it opens pdf files using evince. When I use chromium under fvwm, it opens pdfs using firefox (which opens pdfs using evince, but is started and takes long to start). I am not sure, if this is really a fvwm thing, but it is my only guess. Maybe someone in the list knows ... Read up on how mailcap entries work. Nothing to do with FVWM. Desktop environments are messing up what used to be a well defined boundary between the window manager and X. On my Fedora system, /etc/mailcap contains: audio/*; /usr/bin/xdg-open %s image/*; /usr/bin/xdg-open %s application/msword; /usr/bin/xdg-open %s application/pdf; /usr/bin/xdg-open %s application/postscript ; /usr/bin/xdg-open %s text/html; /usr/bin/xdg-open %s ; copiousoutput So, from this system's point of view, mailcap is just a thin layer on top of xdg-open. Ah yes. I'd forgotten about that. I thought this only affected applications running under GNOME or KDE, where those frameworks offer a means of defining known applications. For instance, unless I run gnome-settings-daemon, I get to use .mailcap just fine. I can understand what the XDG are trying to do, but this seems completely bogus, when they should be completely dependant on mailcap entries entirely, rather than reinventing the wheel. Still, not a lot we can do about it. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
FVWM: FvwmWiki -- up and running.
Hello all, Finally, my fvwm-TODO list is receiving attention. I've finally got the FvwmWiki up and running again, albeit in a limited fashion for now until I convert all the pages over. You can find the wiki here: http://fvwmwiki.xteddy.org/fvwmwiki I am so sorry it's taken me this long to get round to this -- we're really talking years here, for me to find the time for this. I know it's been asked a lot on these lists where it's gone. Hopefully those of you who asked will appreciate it. It's no longer using MoinMoin anymore, since this just didn't scale at all between versioned upgrades whatosever. Instead, I've gone with using ikiwiki [1], which will hopefully ease maintenance a little. The ikiwiki for FvwmWiki is backed by a Git repository. The files in question use the MarkDown markup to describe [2] the pages. This is somewhat different to the previous markup used for the old MoinMoin wiki. I've spent most of today writing a terrible perl script hack to convert the old MoinMoin files over. Thankfully, since I've contributed lots to the old FvwmWiki, I was able to recall most of the pages in amongst all the bloody spam which was present. :) Alas, I have only had time to convert over the FvwmModule pages -- I'll get round to the others in due course, I promise. In terms of editing, you'll need to create yourself an account [3]. You can either have an account directly on the wiki, or if you have an OpenID account, use that instead. Of course, because this wiki is backed by a VCS, you can also checkout and push anonymously using Git, which means the ability to edit/create markdown pages using your favourite $EDITOR as well. Hence: cd git clone git://fvwmwiki.xteddy.org/srv/git/fvwmwiki.git Ought to get you started. This also allows for anonymous push access as well. I've enabled this for a few reasons: * I know from personal experience how annoying it is to edit wiki pages directly in a browser. * Serious contributors are likely going to want to take the time to make their pages as good as possible, which isn't likely by editing text directly in a browser. However, I would ask to be careful here -- my domain, xteddy.org, of which fvwmwiki.xteddy.org is obviously hosted from, is only a tiny VM instance from bytemark -- it only has 150MB RAM. It's fine for persistant IRC sessions, and a webserver, but if I suddenly find that there's been several anonymous checkouts spamming the wiki to death, I will withdraw anonymous SSH access, and editing of the wiki will only be avaiable via the browser instead. Obviously at the moment, it's very minimal until I convert the existing pages over (I've got a nasty perl script I've written to do this, but it still requires some manual fix-up, another sinkhole of my time). But I encourage anyone who wants to, to contribute! This is a great way to contribute to FVWM, especially if you're not a programmer, and want to turn your hand to improving documentation, etc. Where I was largely motivated before from the old wiki to structure it well, my time is less and less likely to be spent on this one (as I am concentrating more and more on trying to make FVWM 2.5.X stable!) So here's some random tasks for would-be contributors to consider: * Styling of the wiki. * Coming up with a defined structure for it. * Implementing page templates for known areas where bulk-contributions are likely (c.f. writing pages to describe FVWM-modules, Style commands, user-configs, etc). * Amalgamating other sources of FVWM info to one reference point on the wiki. If anyone is seriously going to do this, would they let me know so we can discuss it? Otherwise there's a serious chance for overlap from myself and other contributors. Obviously, if this turns out to be some major success story, I'd like to talk to Jason Tibbets about the possibility of moving it to fvwm.org, perhaps under the guise of wiki.fvwm.org, although I suspect we're a long way off from that. For now, I am happy to host all of this for the benefit of the FVWM community. Thanks go to Klaus Umbach, for hosting the original wiki, and offering to host this replacement. Whilst that offer was greately received, the realisation of hosting it myself for better means of access seems more logical. I would also ask that if there is anyone reading this who can offer a more permenant hosting solution for this wiki, then do please get in touch. Other than that, I hope this helps those who were asking about the wiki, and I hope people contribute to it! Any problems, let me know. -- Thomas Adam [1] http://www.ikiwiki.info [2] http://daringfireball.net/projects/markdown/ [3] http://fvwmwiki.xteddy.org/fvwmwiki/ikiwiki.cgi?do=prefs -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Forum
On 15/02/2010, Richard Humphreys r_j_humphr...@yahoo.co.uk wrote: Hello, I've been away from linuxfvwm for a year or two so I thought I'd refresh myself by taking a glance at the forums. http://fvwm.lair.be/ appears to be blank. Has the forum moved or ceased to exist? Until I get help, they will be here: http://fvwmforums.org Until then, you've got this list, or #fvwm on irc.freenode.net for support. -- Thomas Adam
Re: FVWM: FvwmWiki -- up and running.
On Wed, Feb 17, 2010 at 08:54:07AM +1100, Kathryn Andersen wrote: Have you considered mirroring the git repository on github? (http://github.com) That could ease the load on xteddy.org for git checkouts. It's not the git aspect that's the problem (I already host a number of FVWM things on github), it's whether or not the bandwidth to xteddy.org is monumental. What do you have in mind? Just the CSS, or changing the page.tmpl template also? I don't care -- either or just one of them. I care much more about the *content*, as that's the one thing I've always been able to provide. As for aesthetics, I couldn't care less. I'd be interested in helping with the styling, if that's okay. It's a wiki -- edit it. :P -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: FvwmWiki -- up and running.
On Fri, Feb 19, 2010 at 12:19:13PM +1100, Kathryn Andersen wrote: The fact that you were quicker off the mark than I was means that there were improvements quicker, which is good all around, IMHO. There's still other things to do: http://fvwmwiki.xteddy.org/todo/ -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
FVWM: Advance Notice: Offline from Tuesday 9th March - Unknown
All, Just in case anyone might have noticed my absence, I will be moving house on Tuesday 9th March, and until I get Internet access sorted out won't be online to do any FVWM development. This might well take up to a month. The wiki will remain online though as this is externally hosted. -- Thomas Adam
Re: FVWM: fvwm development - and interview idea
On 24 February 2010 22:50, David Chanters david.chant...@googlemail.com wrote: On 23 February 2010 00:16, des...@verizon.net wrote: Look at the TODO file in the source tree. i did this, and have some questions: - whats the update with the fvwm-convert2.6 script? Functional, as far as I know. I have a patch kicking around to get it to try and convert over FvwmTheme config lines to Colorsets, although it's a little tricky, and won't ever be able to completely automate the process. - according to the TODO file, the only thing remaining is this script? No -- there's test-cases to write, which I am in the process of. The whole purify test suite needs an overhaul anyway. If I can't be bothered^H^H^H^^get round to doing it at that level, then I'll list it as a potential GSOC project. This isn't hard -- it's just very boring work. :) I have a number of patches in my queue for review, as well as fixing another MinOverlap bug. These should probably take slightly higher priority than test-cases, although none of the patches up for review are bug-fixes. whats outstanding with the convert2.6 script thats holding 2.5.x becoming 2.6.0? It just needs a shed-load more testing than it's gotten at the moment (i.e., other than me scouting the Internet for older config files. :P) Does that answer your question? -- Thomas Adam
Re: FVWM: fvwm forum completly down?
On 26 February 2010 08:33, Viktor Griph vik...@griph.se wrote: 2010/2/12 Thomas Adam tho...@xteddy.org: I've asked for help, but no one's yet come forward -- not surprising when the problem is rather PhpBB-specific, and those folks haven't gotten back to me either. :P Do you have any link to a mail conversation where you describe the problem? Or could you describe what the problem is briefly? Restoring a .tar.gz copy of the database is problematic in that: * The CGI times out (hacked by me originally to fix this as the stupid PHP pages have some convoluted logic to offer hard-coded timeouts.) * And even when that purportedly succeeds and there appears to be information in the database, the front-end PHP pages don't seem to recognise the fact that there is data. I don't have any mail links, no. But those two points are it -- the second one being more interesting. And I am told there's been schema change either, so it should just work. -- Thomas Adam
Re: FVWM: Vertical motion only?
On 26 February 2010 09:03, Tom Horsley tom.hors...@att.net wrote: This is weird: I'm on fedora 12 with fvwm-2.5.26-4.fc12.x86_64 Can you at least try the CVS version, please? and qt-4.6.2-1.fc12.x86_64. I try building the shapedclock qt example program. This sample is designed to be run with no window decorations, so it looks for mouse drag events and calls move() to move itself. When running fvwm, I can only move vertically. It is like fvwm is utterly ignoring the X movement, and only paying attention to Y movement. OK -- attach xev to this QT window and capture the entire output when you move the QT application up and down and then to the right and the left? If I set the window style to Unmanaged, I can move it OK, I swear I've seen this before, and/or read about it before on this list. Ah well. :) -- Thomas Adam
Re: FVWM: sticky pidgin
On Fri, Aug 28, 2009 at 07:06:05PM -0500, Jonathan Kotta wrote: I have the style 'Style Buddy List Sticky' to make Pidgin's buddy list window sticky. It used to work, but it hasn't for many months (I rarely restart, so it doesn't bother me much, but today it did). I can reproduce this with a minimal config (e.g. just the above Style command). So I started an FvwmEvent to run the following function on add_window events: [ Coming back to this rather later than I planned to...] What's the status of this, Jonathan? Does it still happen? Can you verify this using the CVS version of FVWM with the same version of pidgin you mentioned? -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: fvwm stability in the last few months
On 28 February 2010 23:07, David Chanters david.chant...@googlemail.com wrote: hi i've had lots of issues with stability of fvwm on the last few months - crashes from loading menus with background images for the menus. Can you run: $ hash -r $ fvwm --version And paste the output? I am *seriously* starting to doubt at this point that you're running a recent CVS version at all. and then today the resize window that usually comes up isnt present - after i did a cvs update early on this morning HideGeometryWindow never -- Thomas Adam
Re: FVWM: Multiple virtual desktops on a Xinerama/xrandr screen
On 23 February 2010 22:43, Martin Cracauer craca...@cons.org wrote: I also wonder how the whole thing mixed with second video cards. Can you have one xrandr screen across multiple card? If not, how do you do triple-screen? I still think the whole thing is unworkable for anybody who ever rose over oh I had this on Windows functionality. See: http://ktown.kde.org/~seli/fakexinerama/ I don't really don't want to discuss this anymore on this list -- so consider the above an end to the matter. -- Thomas Adam
Re: FVWM: Per application urgency handling
On Thu, Mar 04, 2010 at 06:04:07PM +, - Tethys wrote: Is it possible to have different behaviours for handing urgency hints depending on the application that set the hint? For example, I might want my instant messanger to do one thing, and my web browser to do something different. Specifically, firefox is raising itself to the top of the window stack every so often, which is *really* annoying. I'm assuming FF isn't going to be setting the UrgencyHint here -- more likely you want to: DestroyFunc EWMHActivateWindowFunc (although I haven't verified it) that this is because of an urgency hint. Currently, I can configure UrgencyFunc to do what I want when the hint is set, but it seems to be on a global level. Ideally, I'd want to be able to do: Style Pidgin UrgencyFunc IMUrgencyFunc Style Xchat UrgencyFunc IMUrgencyFunc Style Firefox UrgencyFunc BrowserUrgencyFunc or something along those lines. Any ideas? Yes, see: DestroyFunc UrgencyFunc AddToFunc UrgencyFunc + I ThisWindow (SomeName, etc) DoSomethingWithSomeName + I ThisWindow (SomeOtherName, etc) DoSomethingWithSomeOtherName And so on, and so forth. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: Google Summer Of Code 2010
On Fri, Jan 29, 2010 at 11:16:38PM +, Thomas Adam wrote: Hi all, So I am going to raise this now, unlike last year where we only had a few days to come up with something. Alas, this year, it is not to be. Despite my best efforts, I was unsuccessful in submitting an application on time. I am very sorry to have gotten anyone's hopes up on this. As they say: Better luck next time. Sorry all. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On Tue, Mar 16, 2010 at 08:46:35PM +, David Chanters wrote: hi. i see in the cvs changelog for fvwm that the initialmapcommand doesnt now run on restart of fvwm. i liked this feature to remind me a restart had happened and that some windows got hidden for free can i have the old feature back? No, I am afraid not. Before I fixed it, it was broken. I can't even think of what you mean when you say hidden. I suppose you can use something like this: DestroyFunc ExitFunction AddToFunc ExitFunction + I Test (ToRestart) All (SomeApp) Iconify But that's a really specific use-case, and may well just prove more silly when the iconified window is recaptured by FVWM on restart anyway (due to the window potentially receiving an icon, etc.) -- depending on what you mean by hidden in this case though, as it's anyone's guess. Mind if I ask you something? Either you seem to be singling out the work I am doing on FVWM, or you've got some extremely borderline, and *coincidental* use-cases for the fixes I've been implementing over the last year. Somehow this isn't tallying with me. -- Thomas Adam It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On 16 March 2010 21:36, David Chanters david.chant...@googlemail.com wrote: On 16 March 2010 21:15, Thomas Adam tho...@xteddy.org wrote: No, I am afraid not. Before I fixed it, it was broken. I can't even think i dont like this - can you add an option to keep the old behavior? Sorry, but to revert this would just be wrong -- so the answer is no. I suggest you restate what it is you thought you had with the old (and *broken*) behaviour, and then I will suggest to you: * Ultimately why you were wrong to make that assumption. * An alternative solution. Although I suspect, given my previous reply to you, it's going to go unheeded. -- Thomas Adam
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 03:14:43PM -0700, Perry Hutchison wrote: Perhaps the OP needs to put a command in RestartFunction to DeIconify all windows? No! Not RestartFunction. Please. Use: AddToFunc StartFunction I Test (Restart) Foo You *only* need RestartFunction if you're using FVWM 2.4.X -- which for most people is unlikely. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 10:15:00PM +, David Chanters wrote: also - why isnt anyone peer-reviewing these changes? these decisions need discussion - no one seems to do that - why is any idiot allowed to commit changes like this without discussion? Because this idiot knew it was the right thing to do? Getting defensive and potentially hostile over something isn't going to really motivate people to help you -- although see my previous reply to you anyway -- call it a good-will gesture on my part to help you resolve your previous reliance on broken behaviour. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: initialmapcommand with restart
On Wed, Mar 17, 2010 at 11:16:09PM +, Thomas Adam wrote: On Wed, Mar 17, 2010 at 10:10:35PM +, David Chanters wrote: On 17 March 2010 22:00, des...@verizon.net wrote: The way I understand your request, you are asking for Fvwm to un-minimize windows on a restart. or any window that id used initialmapcommand on - it was useful if id done something to these windows to put them in their original state when restarting fvwm Well, you could cheat. If you knew you had groups of windows which you had toggleable actions on, such as Iconify and Maximize, then you could make use of State to assign those actions, such as: Style foo State 1, InitialMapCommand Iconify Style bar State 2, InitialMapCommand Maximize AddToFunc StartFunction + I Test (Init) Exec exec foo + I Test (Init) Exec exec bar + I Test (Init) Break + I All (State 2) Iconify + I All (State 3) Maximize s/State 2/State 1/ s/State 3/State 2/ Sorry about that, I got ahead of myself. :P So, any windows with State 1, will be uniconified on restart, otherwise they start iconic. Likewise for State 2, for unmaximizing windows on restart. There are timing issues here in terms of foo and bar starting up before the Break statement runs -- see the wiki on FunctionSynchronisation on how to potentially solve this. But ought not to be too much of a problem. Ideally, a more stateful approach using WindowStyle might be appropriate, but it won't work since when the window is recaptured by FVWM on restart, the same windowid is used, as the window is already mapped. Obviously. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: window buttons and button-focus
On 29 March 2010 09:47, JUNG, Christian christian.j...@saarstahl.com wrote: I've tried to use a function like that: DestroyFunc CloseWindow AddToFunc CloseWindow + C Close Mouse 1 2 A Function CloseWindow But this does not work exactly the way I would like to. I do not know if this is maybe a bug, but shouldn't the function be triggered only if the mouse pointer is over the button and the mouse key depressed? On buttons (e.g. FvwmForms) this works as I'd like. Does anyone has a solution for this? The pointer is grabbed at the time the function is invoked, and as such the action would apply regardless. FVWM has no way of knowing where the mouse is to correctly invoke the function as you're wanting it. -- Thomas Adam
Re: FVWM: window buttons and button-focus
On Mon, Mar 29, 2010 at 01:07:53PM -0500, Jonathan Kotta wrote: On Mon, Mar 29, 2010 at 4:04 AM, Thomas Adam tho...@xteddy.org wrote: On 29 March 2010 09:47, JUNG, Christian christian.j...@saarstahl.com wrote: I've tried to use a function like that: DestroyFunc CloseWindow AddToFunc CloseWindow ?? ??+ C Close Mouse 1 2 A Function CloseWindow But this does not work exactly the way I would like to. I do not know if this is maybe a bug, but shouldn't the function be triggered only if the mouse pointer is over the button and the mouse key depressed? On buttons (e.g. FvwmForms) this works as I'd like. Does anyone has a solution for this? The pointer is grabbed at the time the function is invoked, and as such the action would apply regardless. ??FVWM has no way of knowing where the mouse is to correctly invoke the function as you're wanting it. -- Thomas Adam You can cancel the action by pressing escape before releasing the mouse button. Really? There's no code anywhere to support this. What is it you're doing which makes you think this is actually working? -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: window buttons and button-focus
On 30 March 2010 14:12, JUNG, Christian christian.j...@saarstahl.com wrote: -Original Message- From: thomas.ada...@gmail.com [mailto:thomas.ada...@gmail.com] On Behalf Of Thomas Adam Sent: Monday, March 29, 2010 11:04 AM To: JUNG, Christian Cc: fvwm@fvwm.org Subject: Re: FVWM: window buttons and button-focus The pointer is grabbed at the time the function is invoked, and as such the action would apply regardless. FVWM has no way of knowing where the mouse is to correctly invoke the function as you're wanting it. Thanks for the reply Thomas. I'm curious: If the mouse button is pressed the function is entered and waits until the mouse button is released? I'll read the code... For the duration of the function, but it also depends on the action in the function (c.f. use of H -- for hold, as well as PipeRead). This is a deliberate thing -- you're free to change it, but I won't want to help you with the fallout. :P -- Thomas Adam
Re: FVWM: 2.5.29 released.
On Fri, Apr 02, 2010 at 04:05:58PM -0400, Bob Woodside wrote: On Friday 02 April 2010, des...@verizon.net wrote: Glyn Millington g...@millingtons.org writes: Thomas Adam tho...@xteddy.org writes: Hello all, As promised earlier, FVWM 2.5.29 has been released. [snip] Hmm, my guess is that this is a forgery. I haven't seem an commit emails, etc. Hmmm...well, yesterday *was* April 1. Sorry -- I feel guilty now. But do you *really* think that a watchdog process to restart FVWM when it crashes for extra stability, is *really* something we'd have? :P Perhaps it's my English subtlty kicking in. Sorry guys. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: New fvwm install, getting way different click/focus behavior.
On Mon, Apr 05, 2010 at 06:48:22PM -0300, Eric Cristianini wrote:
Hi guys,
I have developed a module for/with fvwm 2.4.20 and have it deployed
over 1.000 machines, all touchscreen, no keyboard/mouse. Basically
its like the FvwmButtons application.. but it let me create and
group buttons.. or have them floating.
So this is bespoke? Is *it* FvwmButtons, or something you've created
yourself? If so, I dread to think what it might be, but hopefully it's
academic for the purposes of this email.
So far, the behavior with the NeverFocus style option was... any
button i click gets activated.. and thats the correct behavior i
want.. any button on the screen that gets clicked.. do its action.
Err, no. NeverFocus simply doesn't pass the click to the application at
all to focus it. As such, you can still use the click to do thing with the
application, but if it's a terminal, for instance, typing intp it is going
to be a problem.
Now, with {Mouse,Sloppy}Focus, the *EFFECT* (and I mean that strongly) will
be such that the pointer entering into said application which has NeverFocus
applied will look as though the clicks are to the window with focus -- but
only because of how NeverFocus works. Please tell me you can understand
this?
Yesterday i had to do a clean install in an identical machine, but
this time i installed from scratch.. fvwm 2.4.20 same linux as the
other machines
Use 2.5.X -- if you can't roll that out, more fool you.
For my surprise the click/focus behavior is way diff now...
everytime i click something not focused it just do nothing
removing my mouse bindinds and using the original fvwm config i
can see it shows me the root (builtin) menu... even if i clicked on
an app (not focused)
Sounds like a Numlock problem to me, but can't say for certain.
To make things a bit easier to understand... lets say i open 2
xman for example... side to side... if i click on help of the
first.. it will just focus it... if i click on help of the
second.. it will move the focus to that... not running the option.
Is this still with NeverFocus? I've noticed some applications ignore this,
most likely because of XSetInputFocus(). What's that? ICCCM you say?
Pfft, like authors listen to that these days...
That said i tried all documented focus/click options, no love... the
point here is the fvwm versions are the same... configuration
ditto... i tried the default fvwm2rc that comes, same thing... but
all the other machines runs fine, with just the install of app and
replacement of system.fvwm2rc
Then are you really running the versions of software you claim?
-- Thomas Adam
--
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Vector buttons viewer
On Fri, Apr 02, 2010 at 07:00:25PM +0300, Alexander Gromnitsky wrote: Hi, I've concocted a (very) simple JS viewer for FVWM vector buttons: http://bit.ly/aQjnd4. It uses a canvas element for drawing (doesn't work in IE). Theoretically, you may found it useful even for creating vector buttons. There is no server code, so it is possible just save the html page with the javascript and use the viewer locally. I've found converting them to SVGs or PNGs easier. YMMV, but thanks for your efforts. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: 2.5.29 released.
On Fri, Apr 02, 2010 at 05:17:01PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: On Fri, Apr 02, 2010 at 04:05:58PM -0400, Bob Woodside wrote: On Friday 02 April 2010, des...@verizon.net wrote: Glyn Millington g...@millingtons.org writes: Thomas Adam tho...@xteddy.org writes: Hello all, As promised earlier, FVWM 2.5.29 has been released. [snip] Hmm, my guess is that this is a forgery. I haven't seem an commit emails, etc. Hmmm...well, yesterday *was* April 1. Sorry -- I feel guilty now. But do you *really* think that a watchdog process to restart FVWM when it crashes for extra stability, is *really* something we'd have? :P Perhaps it's my English subtlty kicking in. Oh yeah, forgot about you being from England. Makes sense now. In my defense, at least I didn't believe it. I think this is an email that had me confused on day one, disbelieving on day two, and tomorrow it will be the funniest email ever. Now all I need to do is convince Tibbets the tarballs in incoming really do exist. :P I think I'll leave humour to other, more seasoned, people. :) -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: New fvwm install, getting way different click/focus behavior.
On Mon, Apr 05, 2010 at 08:10:53PM -0300, Eric Cristianini wrote: Something i have created myself using some ideas from the said app (fvwm interface, console interface exec stuff), it was written from scratch as i was in need of a very simple app and needed a number of features that would make almost impossible (not worth) to modify fvwmbuttons to implement those. Also it had to be written from scratch 'cause of licensing. Then I can't say what undefined behaviour you're dragging in... Yup, i applied the NeverFocus to *, but i see that behavior with any option i use, including the default config that comes with fvwm... every thing i click on.. the thing shows me the root menu... on top of the app... very odd/weird. What? You need to think really hard here. And I mean *really* hard. So you have this: Style * NeverFocus ... and yet, clicking on an application in this way brings up the root window? Utter nonsense. Again, think very carefully. It could be this touchscreen driver you speak of, or some kind of synaptics issue (if it's using that, etc.) Either way, what you're seeing, has nothing to do with how FVWM might interpret the events. Oh, and consider using 2.5.X, that at *least* has EWMH support. You'd benefit from that, if nothing else. The fact that you can't deploy that means your circumstances are the pits. Fix that first, then it might be worthwhile. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: raising an icon via the window list
On 15 April 2010 03:54, des...@verizon.net wrote: phutc...@windriver.com (Perry Hutchison) writes: Once in a while I lose track of an icon. I can find the window in the window list, but clicking it there -- with any of the 3 mouse buttons and with or without Ctrl, Alt, or Shift -- raises the window _and_ deiconifies it. Ordinarily this is what I want, but when I'm trying to track down a lost icon I really want to raise and warp to the icon while leaving the window iconified. How would I go about programming one of the mouse buttons to do this, without changing the behavior of the other buttons as would happen if I redefined WindowListFunc? Nothing stopping you from creating another windowlist binding with a different function: Mouse 1 A S WindowList Function WARPER DestroyFunc WARPER AddToFunc WARPER + I Focus + I WarpToWindow 50 50 But I think you'll find that WarpToWindow is the only way to move the pointer and works on windows not icons so I don't think it's doable. Slightly easier would be: Mouse ... WindowList (Iconic) foo DestroyFunc foo AddToFunc foo + I WarpToWindow 5 5 You could then even go as far as putting the pointer in the middle of the icon by simple mathematics involving $[ip.height] and $[ip.width] if you wanted. -- Thomas Adam
Re: FVWM: [parse_colorset]: ERROR error reading root background
Hi --
On Sun, Apr 25, 2010 at 09:23:46PM -0400, des...@verizon.net wrote:
Hi,
I get the subject line error message from fvwm.
The error occurs putting a pixmap in a colorset like this:
Colorset 2 TiledPixmap weird10.xpm
As long as the xpm file has no mask, you get the error.
The logic is in fvwm/colorset.c:
Can you send me the .xpm in question? I can't seem to trigger this
condition.
if (image != None mask_image != None)
{
...
}
else
{
fvwm_msg(
ERR, parse_colorset,
error reading root background);
In this case there is an image but no mask.
XPM images only have a mask if one of the colors in
the image is None.
Yes -- OK. The error message is misleading in this case. I suspect we also
need to be checking for cs-mask as well -- since there's no guarantee that
if that's None, that mask_image won't be either. But I'd need this XPM file
to work it out -- especially since this function is used with other image
types as well.
Sorry for the brevity; must dash...
-- Thomas Adam
--
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: vmware player doesn't show
On Thu, Apr 29, 2010 at 09:03:04AM +0200, Harald Dunkel wrote: Hi folks, I need vmplayer on Linux (Debian unstable) to run XP. X window manager is fvwm 20100428. Problem: Vmplayer shows the management window, but when I click on [play virtual machine] then there is no window showing the virtual screen. Alt-Tab doesn't list the virtual screen, either. The virtual machine seems to be running, though. Using twm there is no such problem. The .fvwm2rc file is empty (zero bytes), i.e. fvwm is running with its built-in configuration. Using the examples .fvwm2rc file I get the same problem. Any helpful comment would be highly appreciated. http://communities.vmware.com/thread/107947 -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: raising an icon via the window list
On 9 May 2010 21:39, David Chanters david.chant...@googlemail.com wrote: hi can i ask how this is easier than the other suggestion? is this more efficient with fvwm? Not sure what you mean here - it's just a note that you can warp the pointer to an icon by using simple mathematics with one of FVWM's own internal variables. -- Thomas Adam
Re: FVWM: Using multiple fonts (i18n)
On Fri, May 21, 2010 at 09:00:08PM -0400, sokuban wrote: Does anyone have a copy of this patch they could send me or know where I could get a copy of it? Or does anyone who is in a similar situation as me have another solution that works? http://forum.ubuntu.org.cn/download/file.php?id=56775 I doubt that will apply, and from a quick look at the code, it needs a clean up anyway, but it should give you something to go on. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Using multiple fonts (i18n)
On Sat, May 22, 2010 at 10:21:55AM -0400, sokuban wrote: I notice that you got it from the ubuntu forums. Is there a thread related to this patch that I could follow/read for more information? (It should be fine if it is in Chinese or whatnot.) http://jianlee.ylinux.org/Computer/Software/fvwm.html -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: emacs - can't start maximised anymore
On Tue, May 25, 2010 at 09:55:05PM +0200, Jean Felder wrote: In fact, I'm launching emacs daemon at startup with the command emacs --daemon Then, I'm using emacsclient -c The first time, I'm using emacsclient, the window is launched but not maximised. The second time, everything works fine : the second window is maximised. I've tried to use FvwmIdent and I've got emacs as name for both windows. So, I don't understand where the problem is. Perhaps, this is emacs related. Almost certainly. I refuse outright to install emacs on my machine, but I suspect what's happening here is that the emacs client window is maximized by FVWM, but something is then undoing it. Out of interest, does this help any? Style Emacs InitialMapCommand Schedule 5000 Maximize -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: emacs - can't start maximised anymore
On Tue, May 25, 2010 at 07:30:20PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: On Tue, May 25, 2010 at 09:55:05PM +0200, Jean Felder wrote: In fact, I'm launching emacs daemon at startup with the command emacs --daemon Then, I'm using emacsclient -c The first time, I'm using emacsclient, the window is launched but not maximised. The second time, everything works fine : the second window is maximised. I've tried to use FvwmIdent and I've got emacs as name for both windows. So, I don't understand where the problem is. Perhaps, this is emacs related. Almost certainly. I refuse outright to install emacs on my machine, but I Heresy! :) suspect what's happening here is that the emacs client window is maximized by FVWM, but something is then undoing it. Out of interest, does this help any? Style Emacs InitialMapCommand Schedule 5000 Maximize I much prefer to control the size of Emacs windows with X-Resources. This is what I use in my X-Resources: That's useful to know, but it's missing the point. The window shouldn't be repositioned after it's mapped in the way that it is by emacs -- that's a bug which they've introduced, perhaps as a side-effect of something else. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Way to delay SloppyFocus
On 14 June 2010 07:57, Thomas Adam tho...@xteddy.org wrote: Hi -- On 14 June 2010 05:46, Piotr Isajew p...@ex.com.pl wrote: Hi. I use SloppyFocus as default focus style in fvwm (2.5.29). I would like to ask, if there is any reasonable way to delay focus change, when mouse pointer enters the window? Some googling told me that it should be possible by setting focus style to ClickToFocus and using FvwmAuto module appropriately, but maybe there is more elegant way to do this? http://www.mail-archive.com/fvwm@fvwm.org/msg01082.html Oh -- and yes, it really is that elegant. It's the best way. -- Thomas Adam
Re: FVWM: next stable release? (dont shoot!)
On Sun, Jun 13, 2010 at 09:58:56PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: 2. Perhaps more importantly, we have a number of users who compile FVWM up themselves, or we have environments where FVWM is deployed in rather interesting circumstances (perhaps you've alluded to one below, in your deployment scenario?) -- out-of-the-box, FVWM won't work, due to these external dependencies not being part of most base-perl installs. It was OK for FvwmTabs, that has a handy TK dialogue to tell you as such -- but for a script a number of people are using, and *will* be using, it's slightly frustrating. Pretty much agree but XML parsing from Perl isn't that rare. Especially for users that will want auto generated menus. As long as it's an optional feature, I think it's okay. Well, the script's use itself is optional, yes. But the dependencies it relies on obviously cannot be. :) If you or *anyone* else wanted to actually help, by all means look at writing more purify tests -- that alone would likely throw up some interesting bugs if they were structured properly -- I have several ideas on how to improve these tests, so if anyone is seriously interested, do please ask me! As I remember, Dominik created the tests and I took one pass thru the man pages vs. the tests. It was a horrible, boring experience, one I never wanted to repeat again. Well I for one am very appreciative we have at least that -- even if it was all those years ago. Thanks. :) I thought maybe we could come up with a scheme were when a new command was written, we'd add comments to the source code that could be auto-generated into test cases. Sadly, I think the plan was too ambitious. Well that was one idea -- and it need not be as elaborate as comments or anything. I was thinking more along the lines of having a testing framework written in something like perl (as many do exist) which could be used to aggregate many test of different types (Styles, Menus, Decors, etc) all of which have a common interface, for exmple. That way, reports can easily be generated, etc. I think the Purify tests put too much of a burden on the project and we shouldn't put a lot of effort into them. Hmm -- as they stand at the moment, most likely they do. But I have already appreciated their benefit first-hand, despite them being somewhat outdated already. If it wasn't for those tests, Dan, I'd not have been able to fix your menu background pixmap issue back in December. :) I certainly don't think anyone's efforts are in vain whatsoever if they wanted to make a start on this -- but yes, it might initially be boring, but the benefits for FVWM which come from it are likely to be huge in terms of bug-fixing, spotting problems, etc. -- Thomas Adam
Re: FVWM: is this is a bug?
On Sun, Jun 20, 2010 at 07:21:47PM +0100, Michael Treibton wrote: hi i have this - SetEnv numofterms 10 key q R A Echo $[numofterms] which works. but when i change numofterms to be a different number, my key binding still shows 10. why? is it a bug? Ah. You've been hit by the expansion problem. It's not a bug, it's just that we're exposing FVWM's internals to the user again. :) When FVWM encounters a line such as: Key q R A Echo $[numofterms] It will expand that, to be (in your case): Echo 10 So the full line might look like this (although note that this isn't how FVWM stores it or anything, I am just doing this for ease of explanation): Key q R A Echo 10 Which means now, that $[numofterms] has been interpolated out fully -- and won't ever be interpolated again. What you need to fix your problem is this: Key q R A Echo $$[numofterms] And, as in the above, you need to read the thing backwards, just like FVWM is doing when it parses the line. So first time around (when it encounters the keyword Key) FVWM will expand it out like this: Key q R A Echo $[numofterms] Then, when the action for the q binding is encountered, FVWM still sees to run: Echo $[numofterms] ... thus honouring the expansion of $[numofterms] for no matter how many times you might change this environment variable. Is that clear? The trick is to read these things backwards -- and you need two $s -- one for the Echo command, the other for the Key command. If you, or anyone else, feels this information needs adding to the man page or making clearer, *please* send me a patch. It would save me a lot of time. :) 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.)
Re: FVWM: Paging behavior changed from fvwm version 2.5.26 to 2.5.28
On Mon, Jun 21, 2010 at 03:58:42PM -0600, Jaimos Skriletz wrote: On Mon, Jun 21, 2010 at 06:05:37PM +, halfdog wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello List, Perhaps someone can give me a hint, how to restore the old (prior 2.5.28) paging behavior in fvwm 2.5.28. At the moment, the simple configuration from below behaves differently on ubuntu jaunty (2.5.26) and lucid (2.5.28). Just a debugging suggestion, have you tried to use Fvwm 2.5.26 from Jaunty on your Lucid install. It could be that the problem is not with fvwm, and if you get the same behaviour with 2.5.26 from Jaunty (or even if you download the current Fvwm from fvwm.org and make your own custom deb with 'make deb-inplace') then you know that there is something else running in Lucid that has caused this behavior. The Ubuntu packages leech directly from Debian's (thankfully). The PTS for FVWM has no extraneous patches which would affect this: http://patch-tracker.debian.org/package/fvwm/1:2.5.28.ds-3 -- 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.)
Re: FVWM: FVWM Forum
Hi -- On 2 July 2010 09:13, Nikolaus Klepp off...@klepp.biz wrote: This is not directly a FVWM related question, but would it be possible to restore the fvwm forum? I find myself frequently redirected to fvwm.lair.be - which is down for ages. www.fvwmforums.org Until someone who has a clue about PhpBB (which isn't me) volunteers to help me get it up and running, then the forums are all but dead. Please search the mailing list archives for previous replies on this, from me. -- Thomas Adam
Re: FVWM: hidden console -
On Mon, Jul 05, 2010 at 09:11:24PM +0200, Andrej wrote: When I touch any place at north border of the screen, HiddenConsole pops out. Is it possible to have more hot spots at screen border which will pop up different hidden programs. For example, if whole border is 100%, if I would touch first 30% of the border with mouse , terminal would pop up, if i would touch between 30% and 60% opera would pop up and so on. No. For this, you can do it a number of ways. In no particular order: 1. Use EdgeCommand, and manually work out the inter-quartile ranges based on mathematics using $[vp.x], $[vp.y], $[pointer.x], $[pointer.y] -- use a function and PipeRead to do this. 2. Use FvwmButtons, and with my ActiveAction patch (might need manual munging to apply to CVS, not sure): http://xteddy.org/fvwm/patches.html#toc7 Although this pre-supposes you *want* the words on the screen as buttons, likely not. -- 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.)
Re: FVWM: Looking for a simple rootless configuration for windows
On Thu, Jul 08, 2010 at 03:59:23PM -0700, Jean Florentine wrote: Hi All, If somebody would have a ready configuration for a rootless window manager with a button small window and a page manager could you please send me a copy of it. Many thanks. John Oddly enough you'll need to be more specific. Rootless window manager? What's this? And what small button -- where? What *window* do you speak of? Is the button as this alluded to window related? As for a pager, see FvwmPager. But come on! Be more specific, please. -- 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.)
Re: FVWM: Looking for a simple fvwm configuration to run under Cygwin/windows in rootless mode
On 9 July 2010 13:30, Jean Florentine jeanflorent...@yahoo.com wrote: Hi, I am running fvwm under Cywin/Windows, In Cygwin i start XWin in rootless mode, then i start fvwm, but i cannot manage to get a proper fvwm set-up i just look for a ready to use fvwm configuration that offers a page manager and a few buttons and possibly set scrollbars on the x-Window, would you have that or point me to it. By the way i tried to install fvwm-themes but it is failling to start Jean But FVWM doesn't care about any of this -- I mean, as far as FVWM is concerned, its calls to XMapWindow(), etc., will work as-is -- it neither knows about or cares whether X11 is running in seamless mode or not. So I fail to understand why you think there will be a need for a different FVWM config to some other. As Dan pointed out though, I too can't see why you'd want FvwmPager in this case, since as I understand Rootless mode, virtual desktops don't apply. What is it about even the default config (c.f., fvwm -f /dev/null) which isn't giving you a starting point? Annoying though, you've now got two separate threads asking the same question. Kindly pick one of them, and stick to it -- I'd rather not have two parallel threads with the same conversation happening in them. :) -- Thomas Adam
Re: FVWM: Looking for a simple fvwm configuration to run under Cygwin/windows in rootless mode
On Fri, Jul 09, 2010 at 07:28:44AM -0700, Jean Florentine wrote: Hi, Hello. Adding fvwm@ back on the Cc list, since you seem to have forgotten it. in other words i am looking for a .fvwm2rc files and its dependancies that display at start up he buttons window, and an independant window allowing to navigate the desks and pages. What buttons window? Do you mean FvwmButtons? Again, be specific. As for navigating pages and desks, see: FvwmPager -- I mentioned this before. i have an example but the dektop selector is only available on the 1sst desk, so if i go say to the 2nd desk, i cannot come back to the 1st desk. Well, I don't know if this is out of ignorance or due to what Rootless does, but a minimal config for your FvwmPager would look like this: Style FvwmPager Sticky AddToFunc StartFunction I Module FvwmPager ... just those two lines. Be sure to read up on the options FvwmPager accepts to suit your needs (c.f. FvwmPager * *, for instance). Whether or not a pager still makes sense in the environment you're describing is academic at this point, but it still illustrates what you're trying to do regardless. Soory for the threads but i did update my request after your first response making it more understandable. That's OK -- it's usually odd to start another thread when doing so. So can you provide me a working configuration ? See above, but it's meaningless without clarification. One more thing please -- do not top-post. -- 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.)
Re: FVWM: SloppyFocus: switching workspaces keeps focus on window
On Sat, Jul 10, 2010 at 09:20:50PM -0400, sokuban wrote: So the other day I decided to try out sloppy focus for fun (instead of click to focus). It was a little weird at first, but after a while I started to really like it. But there's one thing that's always been bugging me. When I switch workspaces with a keyboard shortcut, a random (or I think it might be the window from last time) window will be focused, and if I move the mouse into other windows or even click in other windows it'll still keep it's focus until I mouseover it, then mouseover the window I want. This is quite a pain. Is that a bug or some sort of feature? Any way to change it? Which applications? I know I've looked into this in the past, as has Dominik Vogt. As far as I can tell this isn't FVWM, it's the application. Note that we have CoerceEnterNotifyOnCurrentWindow() which should ensure what you're describing doesn't happen -- although its use depends upon what you're meaning when switching workspaces (desks versus pages, for instance.) -- 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.)
Re: FVWM: is this is a bug?
On Mon, Jul 12, 2010 at 03:24:41PM +0100, Michael Treibton wrote: On 20 June 2010 19:28, Thomas Adam tho...@xteddy.org wrote: Key q R A Echo $$[numofterms] And, as in the above, you need to read the thing backwards, just like FVWM is doing when it parses the line. ?So first time around (when it encounters the keyword Key) FVWM will expand it out like this: Key q R A Echo $[numofterms] Then, when the action for the q binding is encountered, FVWM still sees to run: Echo $[numofterms] ... thus honouring the expansion of $[numofterms] for no matter how many times you might change this environment variable. Is that clear? ?The trick is to read these things backwards -- and you need two $s -- one for the Echo command, the other for the Key command. If you, or anyone else, feels this information needs adding to the man page or making clearer, *please* send me a patch. ?It would save me a lot of time. ?:) wowza! thanks. how do i go about adding this information to the man page? i dont know anything about how i would do this. It's a complete and utter pain the arse, due to the messy XML. First step is to checkout the FVWM CVS sources [1]. From there, you can look in the doc/ directory, and then do what I do, and just grep for the right file. When you've edited the file(s) in question, make sure you compile FVWM from the top-level directory -- ensuring you --enable-htmldoc, so that you can see not only the manpage generation, but the resultant HTML pages. When you don't get the results you expected, spend an hour trawling through the documentation for docbook and try again. When, after half-an-hour it's still not working for you, give me a shout, and I might just do it for you. :) Yes, it will suck, I am sorry to say. But don't let that put you off trying, you might get lucky and hit upon avoiding the nuainces; perhaps beginners luck. :) Should you get past that, see docs/DEVELOPER-CVS, or the same CVS information [1] you read before about how to submit patches. where did you learn about this information? Mis-spent youth. also, is there not a wiki? can this information not go there as well? It could -- go see fvwm.org for the link, or if you prefer [2]. is the wiki officially part of fvwm? wouldnt it be easier to replace the website with it? That's a complete non-sequitur to your question. -- Thomas Adam [1] http://fvwm.org/documentation/dev_cvs.php [2] http://fvwmwiki.xteddy.org -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Arrows Key don't works with Xorg 1.7.x
On Fri, Jul 16, 2010 at 07:19:19AM +1000, Jake Moe wrote: Also, you could double-check that you haven't accidentally set it to something else later on in your configuration. grep -i key ~/.fvwm/* | grep -i left Just a thought... More likely it's an evdev problem. Can I see your /var/log/Xorg.0.log file? Do you have anything unsetting SendCoreEvents in your xorg.conf file? -- 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.)
Re: FVWM: Arrows Key don't works with Xorg 1.7.x
On Sat, Jul 17, 2010 at 10:43:08AM -0200, Mauricio E. Silva wrote: The xev output also looks fine too. I've not seen it -- so can I see it? The FVWM configuration is the same configuration in all my machines with little changes between the 2.4 and 2.5 series. Then use FvwmConsole, and type: PrintInfo Bindings ... and see what that says -- the output is sent to STDERR, so ensure it ends up in something like ~/.xsession-errors for you to see. Furthermore, you should use FvwmConsole to remap your keys as in: Key Up A A Echo I see you ... and still look in ~./.xsession-errors Either way, if FVWM had a problem with that binding (due to a bad keysym, which I doubt) you'd still see the errors in ~/.xsession-errors in this case. And Thomas the logger of one machine is in http://lan.no-ip.org/Xorg.0.log I don't think the problem may be the 'evdev', because the FreeBSD version 8 is using the driver 'kbd'. Fine. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: hidden console -
On Mon, Jul 05, 2010 at 08:19:43PM +0100, Thomas Adam wrote: On Mon, Jul 05, 2010 at 09:11:24PM +0200, Andrej wrote: When I touch any place at north border of the screen, HiddenConsole pops out. Is it possible to have more hot spots at screen border which will pop up different hidden programs. For example, if whole border is 100%, if I would touch first 30% of the border with mouse , terminal would pop up, if i would touch between 30% and 60% opera would pop up and so on. No. For this, you can do it a number of ways. In no particular order: 1. Use EdgeCommand, and manually work out the inter-quartile ranges based on mathematics using $[vp.x], $[vp.y], $[pointer.x], $[pointer.y] -- use a function and PipeRead to do this. 2. Use FvwmButtons, and with my ActiveAction patch (might need manual munging to apply to CVS, not sure): http://xteddy.org/fvwm/patches.html#toc7 Although this pre-supposes you *want* the words on the screen as buttons, likely not. How did this pan out for you in the end? Did you come up with any solution? -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Arrows Key don't works with Xorg 1.7.x
On Mon, Jul 19, 2010 at 10:44:04PM -0200, Mauricio E. Silva wrote: Don't get killed trying to find the problem... my configuration file it's old and big, i'll will start a new configuration from scratch and see what happen. I don't suppose you're got a non-standard keyboard mapping? Perhaps one that isn't US or UK? I ask because the only thing left I can suggest is that you're calling setxkbmap or xmodmap before any XClients have started. I've said so many times before that if you are, you *must* start these programs before hand. If they're in StartFunction or something, shift them to ~/.xsession or ~/.xinit, as in: xmodmap blah exec fvwm It is *not* enough to start these keyboard programs any other way, as FVWM never remaps the keys once X11 has loaded -- which can be the only thing which explains why restarting FVWM [0] works for you, despite the mappings looking OK. HTH, -- Thomas Adam [0] No, not a bug.
Re: FVWM: Best way to control icon placement when windows are iconified
On Wed, Jul 21, 2010 at 04:39:26PM -0400, Chris Siebenmann wrote:
I am currently using a somewhat hacked version of fvwm 2.4.20 and I
would like to move to fvwm 2.5.x (for whatever x is current when I get
all of the pieces working). One of the stumbling blocks is duplicating
one piece of icon placement behavior in my current setup.
I do not have an icon box ('Style * IconBox none'). How I want icon
placement to work is this:
Why? Just let it be the default (which is the whole screen).
- when a window is iconified for the first time (and does not have any
sort of icon placement specified), the icon is put right under the
mouse cursor.
You can do this with a state, windowstyle, and FvwmEvent. Here's a rough
outline -- oh, and it assumes 2.5.X, since you can't do this at all easily
on 2.4.X. Good luck.
# All windows, regardless, get state 1 which is removed when iconified.
Style * State 1
DestroyModuleConfig A:*
*A: iconify SomeFunc
*A: deiconify SomeOtherFunc
AddToFunc StartFunction I Module FvwmEvent A
DestroyFunc A
AddToFunc A
+ I ThisWindow (State 1) MoveIconWindow
+ I TestRc (NoMatch) Break
DestroyFunc MoveIconWindow
AddToFunc MoveIconWindow
+ I Move m+0 m+0
+ I ... (other things?)
DestroyFunc SomeOtherFunc
AddToFunc SomeOtherFunc
+ I ThisWindow (State 1) WindowStyle 1 False
... which is far from idea -- something would have to set the state of the
window to state 1 again if the placement of the icon was to go back to
being under the mouse (unless the window was then subsequently closed
anyway. YMMV.)
- when a window is iconified after that, the icon reappears wherever
it was last.
See above.
I can see how to use a user function to handle the first-time icon
placement (I think; just use a function that does Iconify + Move to
$[pointer.x] $[pointer.y]), but the bit I'm stuck on is how to get icons
to stay where they are after that. Is there a conditional or a command
that would apply for this?
See above.
(It looks like $[i.x] et al are only defined if the window is iconified,
so one can't abuse them to determine whether the icon has already been
positioned somewhere before the Iconify happens.)
See above.
The other option is that I could add a new conditional that tests on
IS_ICON_MOVED() et al; would people find such a patch generally useful
and interesting for the main line code?
No thanks. Not for 2.4.0, and not for 2.5.X, FVWM's in a feature freeze,
and 2.4.X receives no new features anyway.
See above. :)
-- 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.)
Re: FVWM: Best way to control icon placement when windows are iconified
On Wed, Jul 21, 2010 at 09:54:12PM +0100, Thomas Adam wrote:
On Wed, Jul 21, 2010 at 04:39:26PM -0400, Chris Siebenmann wrote:
I am currently using a somewhat hacked version of fvwm 2.4.20 and I
would like to move to fvwm 2.5.x (for whatever x is current when I get
all of the pieces working). One of the stumbling blocks is duplicating
one piece of icon placement behavior in my current setup.
I do not have an icon box ('Style * IconBox none'). How I want icon
placement to work is this:
Why? Just let it be the default (which is the whole screen).
- when a window is iconified for the first time (and does not have any
sort of icon placement specified), the icon is put right under the
mouse cursor.
You can do this with a state, windowstyle, and FvwmEvent. Here's a rough
outline -- oh, and it assumes 2.5.X, since you can't do this at all easily
on 2.4.X. Good luck.
# All windows, regardless, get state 1 which is removed when iconified.
Style * State 1
DestroyModuleConfig A:*
*A: iconify SomeFunc
*A: deiconify SomeOtherFunc
AddToFunc StartFunction I Module FvwmEvent A
DestroyFunc A
AddToFunc A
+ I ThisWindow (State 1) MoveIconWindow
+ I TestRc (NoMatch) Break
DestroyFunc MoveIconWindow
AddToFunc MoveIconWindow
+ I Move m+0 m+0
+ I ... (other things?)
DestroyFunc SomeOtherFunc
AddToFunc SomeOtherFunc
+ I ThisWindow (State 1) WindowStyle 1 False
s/1/State /
-- 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.)
Re: FVWM: Moving windows on mouse 2 button-down instead of button-up?
On Tue, Jul 27, 2010 at 04:55:52PM -0400, Chris Siebenmann wrote:
I wrote:
| This doesn't happen for other buttons, eg I also have 'Mouse 1
| T N Move' and if I use mouse button 1 on window titles they move
| immediately without waiting for button-up.
I was mistaken about what I had button 1 bound to, which has led me
to a workaround. If you have the Move in a function it activates
immediately, as you'd expect:
Mouse 2 IT NMoveFunc
DestroyFunc MoveFunc
AddToFunc MoveFunc
+ I Move
('M' instead of 'I' is equivalent; I assume that other options probably
would cause some variety of the button-up behavior I was seeing on the
basic Move.)
This is due to the fact that functions *grab the pointer* when they execute,
for obvious reasons. (You don't want some other application subsequently
grabbing the pointer at the point a function is running and having random
actions applied to it, for which that window was not intended to ever
receive).
So, not a bug, or anything to worry about at all.
-- Thomas Adam
--
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Bug with turning off user states on specific windows in fvwm 2.5.30?
On Tue, Jul 27, 2010 at 01:00:24PM -0400, Chris Siebenmann wrote: [.. other stuff snipped..] So, either I'm missing something about fvwm 2.5.30, or there's a bug here. All things considered, the first is probably more likely -- does anyone have any ideas? UpdateStyles? Shouldn't be needed though as style lines are updated automatically. Certainly I don't have a problem with the stuff you've posted. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Bug with turning off user states on specific windows in fvwm 2.5.30?
On Tue, Jul 27, 2010 at 06:08:59PM -0400, Chris Siebenmann wrote: | On Tue, Jul 27, 2010 at 01:00:24PM -0400, Chris Siebenmann wrote: | | [.. other stuff snipped..] | | So, either I'm missing something about fvwm 2.5.30, or there's a bug | here. All things considered, the first is probably more likely -- does | anyone have any ideas? | | UpdateStyles? Shouldn't be needed though as style lines are updated | automatically. Certainly I don't have a problem with the stuff you've | posted. I tried putting UpdateStyles at the end of both functions and it didn't seem to make a difference in what happened; it still looks like the window I was repeatedly iconifying and deiconifying was not getting its user state 1 turned off. (Also, I tried inverting the sense of the user state, so that user state 1 started out off, things were guarded with 'ThisWindow (!State 1)', and I used 'WindowStyle State 1' to turn it on, and this behaved the same way.) Committed a fix to CVS for this. I wouldn't rely on the style anyway, and would instead use: Pick (State n) DoFoo Pick State n Off ... etc. -- 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.)
Re: FVWM: Moving windows on mouse 2 button-down instead of button-up?
On Tue, Jul 27, 2010 at 12:23:57PM -0400, Chris Siebenmann wrote: This doesn't happen for other buttons, eg I also have 'Mouse 1 T N Move' and if I use mouse button 1 on window titles they move immediately without waiting for button-up. It's also worth mentioning (for the archives) that the behaviour mentioned here, is directly related to the setting of *ClickTime* -- the higher the value, the longer delay there will be between button press, and action. -- Thomas Adam
Re: FVWM: Visual nastiness on Fedora 13
On Mon, Jul 26, 2010 at 06:30:20PM +0100, - Tethys wrote: I've upgraded from F11 to F13. Since then, my fvwm doesn't look as pleasing as it used to. I've kept the same ~/.fvwm/config file. However, I now have borders around my icons, where previously there weren't any. This only seems to apply to applications that set their own icons. If I explicitly add an icon with a Style in my config file, it appears without a border, as I'd expect. Secondly, my pager now has inactive windows being mostly black, where previously they were grey. Again, nothing has changed in my ~/.fvwm/config. Look at the following style conditions: IconBackgroundRelief IconBackgrouondColorset I suspect in your case, you just need to set IconBackgroundRelief 0, or somesuch. -- Thomas Adam
Re: FVWM: Visual nastiness on Fedora 13
On 28 July 2010 12:02, - Tethys tet...@gmail.com wrote: On Wed, Jul 28, 2010 at 9:46 AM, Thomas Adam tho...@xteddy.org wrote: I suspect in your case, you just need to set IconBackgroundRelief 0, or somesuch. Yep, that fixed it. It still doesn't explain why the relief appeared when using the same config file and the same version of fvwm as my previous install. But at least it works now. Thanks. Because FVWM is only meant to draw the relief under certain conditions by default. -- Thomas Adam
Re: FVWM: Bug with turning off user states on specific windows in fvwm 2.5.30?
On Tue, Jul 27, 2010 at 11:21:29PM +0100, Thomas Adam wrote: On Tue, Jul 27, 2010 at 06:08:59PM -0400, Chris Siebenmann wrote: | On Tue, Jul 27, 2010 at 01:00:24PM -0400, Chris Siebenmann wrote: | | [.. other stuff snipped..] | | So, either I'm missing something about fvwm 2.5.30, or there's a bug | here. All things considered, the first is probably more likely -- does | anyone have any ideas? | | UpdateStyles? Shouldn't be needed though as style lines are updated | automatically. Certainly I don't have a problem with the stuff you've | posted. I tried putting UpdateStyles at the end of both functions and it didn't seem to make a difference in what happened; it still looks like the window I was repeatedly iconifying and deiconifying was not getting its user state 1 turned off. (Also, I tried inverting the sense of the user state, so that user state 1 started out off, things were guarded with 'ThisWindow (!State 1)', and I used 'WindowStyle State 1' to turn it on, and this behaved the same way.) Committed a fix to CVS for this. Really, this time. Bloody CVS! Of course, this isn't helped by the fact that the email announcements from CVS are taking up to 9 hours to get sent out for some stupid reason. Chris -- please cvs up -- does this fix things for you? -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: CMD_Exec() leaks an extra file descriptor to children
On Tue, Jul 27, 2010 at 10:49:10PM +0100, Thomas Adam wrote:
On Tue, Jul 27, 2010 at 12:21:17PM -0400, Chris Siebenmann wrote:
There's a small file descriptor leak in CMD_Exec() in fvwm/builtins.c;
it opens /dev/null, dup2()s it to standard input, and then never closes
the original file descriptor before exec'ing the command.
The neurotically correct fix for this (in what I think is the right
fvwm coding style) is:
--- fvwm/builtins.c 31 Dec 2009 17:44:56 - 1.437
+++ fvwm/builtins.c 27 Jul 2010 16:17:52 -
@@ -2459,6 +2459,10 @@
fvmm_deinstall_signals();
fd = open(/dev/null, O_RDONLY, 0);
dup2(fd,STDIN_FILENO);
+ if (fd != STDIN_FILENO)
+ {
+ (void)close(fd);
+ }
if (fvwm_setpgrp() == -1)
{
fvwm_msg(ERR, exec_function, setpgrp failed (%s),
(It seems extremely unlikely that fvwm would ever have stdin closed at
this point, so the less neurotic fix is just '(void)close(fd);'.)
You've not read any of the documentation about submitting patches.
Nevermind, I will modify this and apply it to CVS soon -- I can't/won't
apply it as-is.
Fixed in CVS.
-- Thomas Adam
--
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.
FVWM: FVWM Book?
Hello all, I toy with this idea at least three times a year, which must mean something. :) I know I've asked this in the past of most people, but I will ask it again -- not so much in terms of the particulars -- but if there's enough interest. Would a book on FVWM be useful? I am thinking more in terms of discussing how/what to do with FVWM, and what's needed to achieve it. The standards behind how FVWM manages windows, and how FVWM allows the user to control what this means, etc. In the past I have called for a co-contributor, but this has fallen though, so I figure if it's ever to get off the ground, I'll probably have to go it alone, alas. What do people think? Whilst I realise the idea is a little odd, seeing as a window manager changes a lot, but there's a tonne of stuff that could so easily be written to make it somewhat timeless over different revisions of FVWM. Kindly, -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: FVWM Book?
On Thu, Jul 29, 2010 at 11:13:48AM +0100, - Tethys wrote: On Wed, Jul 28, 2010 at 11:35 PM, Thomas Adam tho...@xteddy.org wrote: Would a book on FVWM be useful? Yes, a book would be useful. But I'd question why you're doing it. If you're hoping to make money, then I'd say clearly the market for FVWM isn't big enough, and it's not going to happen (having published a book myself, I know a bit about this). If you're wanting to write it simply to increase the level of knowledge about FVWM, then I think it's a great idea. But at that point, I don't know if it would even be worth publishing it in paper format, as opposed to, say, just a PDF. Not to make money, no. And publishers like No Starch Press publish books on lego, for instance. So I'd hardly say market-share is really a limiting factor. :) -- Thomas Adam
Re: FVWM: FVWM problem in Fedora 13
On Thu, Jul 29, 2010 at 03:09:05PM +, Georg Wittig wrote: Hello FVWM community, I don't know if my problem is related to FVWM at all, but I'll try in this newsgroup. I'm running a fully updated Fedora 13 with the newest Fvwm RPM (fvwm-2.5.26-4.fc12.x86_64). Then it's not the newest. FVWM 2.5.30 is. The problem occurs, when xscreensaver jumps in (gnome-screensaver is disabled). When I return to my workststation and enter my password to xscreeansaver, then the screen is unlocked and my windows are shown again. But then the keyboard is completely unresponsive. The standard work-around I found is - either restarting fvwm from a text console - or by moving the mouse to another window and back again. The last one usually works fine - except when the window occupies the complete screen (for VNC windows of virtual machines for example). Yes, this seems like an annoyingly intermittent problem which other window managers have had reports of (XMonad being the main one). If you could try to see if: fvwm -f /dev/null ... also exhibits the problem you describe, then we can rule it out as a FVWM bug. -- 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.)
Re: FVWM: FVWM Book?
On Thu, Jul 29, 2010 at 09:50:39PM -0400, Giovanni Tumiati wrote:
Thomas Adam wrote:
I toy with this idea at least three times a year, which must mean something.
:) I know I've asked this in the past of most people, but I will ask it
again -- not so much in terms of the particulars -- but if there's enough
interest.
Would a book on FVWM be useful?
I hope there *is* enough interest because an FVWM book would be
useful to me.
However I would not necessarily need a paper book - a pdf (or some
such) version would be adequate,
although NoStarch press books have been reasonable.
The distribution format is irrespective of whether it's published or not,
and most publishers are keen on electronic formats these days, as well as
paper editions.
I am thinking more in terms of discussing how/what to do with FVWM, and
what's needed to achieve it. The standards behind how FVWM manages windows,
and how FVWM allows the user to control what this means, etc.
That kind of book would help current users certainly, and may also
elicit interest in others - is one of the
objectives to have the book expand the user base?
Hell, no. I have no interest in attracting more users; merely documenting
this for those who already know about FVWM.
Do you have an idea what the table of contents would contain
(roughly of course)?
* Preface...
* Introduction / Explanation as to what window management is (c.f. with
role within X11, etc.)
* History of FVWM (via comparison with other WMs). Explain what FVWM
is, and why it came about.
* Components of FVWM
- Installation (via distributions).
- Via vanilla tarball.
* Comparison of FVWM 2.4.X / 2.5.X (or just run with 2.5.X and where
necessary add an addendum/footnote where there's any differences in
syntax.
* Setup
- Base setup from tarball (FvwmFormSetup).
(Distros tend not to provide pre-built .fvwm2rc files in lieu of
this).
- Example .fvwm2rc files distributed with the tarball (?)
- fvwm-{themes,crystal} - but see later chapters?
* Generic Concepts
- Command-line switches to FVWM.
- Structure / explanation of .fvwm2rc file with rationale for
recommendation as to why it is that way. (Some aspects of the
file are order dependant still).
* Functions
- Builtin functions (a la ConfigFvwmDefaults).
- User-defined functions (a la StartFunction).
* Context
- Window
- Menu
- Function
- Changing contexts (forcing contexts therein for some
operations).
* Modules
- Standard
- Non/Standard.
| Things like FvwmEvent, FvwmScript, FvwmButtons ought to get the
shit documented out of them.
* Decors
- Styles.
- Vectors.
- Pixmaps.
* Focus policies.
* Bindings.
- Key
- Mouse
* Window Operations
- Moving
- Resizing
- Maximising
- etc...
* Scripting
- PipeRead.
- Perllib
- rubylib (:P -- perhaps released as part of the book?)
-- 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.)
Re: FVWM: FVWM Book?
On Thu, Jul 29, 2010 at 12:51:57AM +0200, David Odin wrote: On Wed, Jul 28, 2010 at 11:35:56PM +0100, Thomas Adam wrote: Hello all, I toy with this idea at least three times a year, which must mean something. :) I know I've asked this in the past of most people, but I will ask it again -- not so much in terms of the particulars -- but if there's enough interest. Would a book on FVWM be useful? I am thinking more in terms of discussing how/what to do with FVWM, and what's needed to achieve it. The standards behind how FVWM manages windows, and how FVWM allows the user to control what this means, etc. In the past I have called for a co-contributor, but this has fallen though, so I figure if it's ever to get off the ground, I'll probably have to go it alone, alas. What do people think? Whilst I realise the idea is a little odd, seeing as a window manager changes a lot, but there's a tonne of stuff that could so easily be written to make it somewhat timeless over different revisions of FVWM. I would certainly support the idea of a book about fvwm. Including a chapter about how to make a whole theme (window decorations, menus, modules configurations, etc.) from scratch (or from mockups) would make that book perfect. You already have a buyer :) Haven't you read fvwm-themes.sf.net? ;) -- 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.)
Re: FVWM: FVWM problem in Fedora 13
On Mon, Aug 02, 2010 at 03:29:27PM +0200, Georg Wittig wrote: With -f /dev/null I wasn't able to reproduce the problem. But I didn't test it thoroughly, because fvwm is pretty unusable to me in that mode. :-) Thomas, If I understand you correctly you suspect the cause of the problem not to be in fvwm, but somewhere else (xscreensaver? the X server? xkb?). Yes, I do. However, you might want to try with using the IgnoreModifier command. If you're able to still reproduce it, can you try and create some minimal example config, with instructions on how to reproduce the bug? I am still dubious FVWM is to blame, as I use xscreensaver, and have never seen this problem in FVWM (but have seen it/read about it in other window managers.) -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 11:37:51AM +0200, Michael Großer wrote: Hi! Thank you very much. This destroy_window event could be the solution I was looking for. I will try to solve my problem over the weekend. AFAICT there's nothing left to solve? Oh, and do not top-post on this list, please. -- Thomas Adam
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: space for all my different projects. I configured a lot of bindings so I can use the keyboard to create new windows or operate with the viewports. I studied the sample config files of the fvwm95 project to get suggestions. I created a digital Why? You won't learn anything from looking at that file -- it's very old. clock at the bottom right corner of my screen using 3 instances of xclock to let it show me the day of the week (1st instance), the date (2nd instance) and the time (3rd instance). Fvwm is automatically positioning these instances for me using Wait and Prev and setting some styles. Wait and Prev? Hmm, see the following as to why this is not a good thing anymore: http://fvwmwiki.xteddy.org/Tips/FVWMStartupProcedure/ Later, I will fix the focus problem (I asked for in this mailing list) and I will build a task bar for me at the bottom, where is still some room in the middle. I think that the fvwm95 project will show me how I can get such a task bar. The documentation of the fvwm project is hard to read and could be written a bit more well-arranged. But, I understand the stuff that is written in the documentation, How could it be improved? [...] -- Thomas Adam
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: Thomas Adam wrote: On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: space for all my different projects. I configured a lot of bindings so I can use the keyboard to create new windows or operate with the viewports. I studied the sample config files of the fvwm95 project to get suggestions. I created a digital Why? You won't learn anything from looking at that file -- it's very old. To get a clue how things work. The man pages have the theory and the fvwm95 config files contain the practice and can immediately be tested. In other words: The man pages are the reference and the fvwm95 config files are an example. But 90 percent of my own config files is code that I checked against the man pages, because I actually want to understand my own code. Sure -- and it's not your fault, it's just that to solve this problem properly, requires a lot more effort/changes than simply updating the config file to reflect newer changes in syntax, etc. That has only been half-heartedly done recently -- there's a lot of crap still in there which either needs to be removed, or updated. Note that I am not talking about the fvwm95 example file specifically, but about the config files installed via FvwmFormSetup. That's a big contention point historically in FVWM though. :) Some examples: 1. FuncFvwmRaiseLowerX == This page... http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html ... does not explain, how FuncFvwmRaiseLowerX exactly works. I just use it and I don't understand it. I just use it to move windows with Win + left mouse button and it does the job for me. I don't now why. This could be improved. Perhaps just make a link to the document that gives more information about FuncFvwmRaiseLowerX. By default, it looks like this: AddToFunc FuncFvwmRaiseLowerX + I Raise + M $0 + D Lower And is invoked (by default) like this: Mouse 1 T A FuncFvwmRaiseLowerX Move Mouse 1 FS A FuncFvwmRaiseLowerX Resize Mouse 2 FST A FuncFvwmRaiseLowerX Move Hence, what this function does is wrap two similar functionalities together. * Whenever the function is run on a window (+ I) it's raised -- always. * If the window is moved (+M) then the action passed into that function is called -- so in the above example, we have a choice of either Move or Resize depending on the binding. * If the user double-clicks (either on the Title (T), Frames (F) or Sides (S), then the window is lowered. In the link to the fvwmwiki article I gave you, I explain where this function is defined, and why it's not accessible to the user, and why they have to redefine it for themselves. But I take your point that there is little documentation on what the function does, but its definition is in man fvwm. I will look at improving this later on this evening. 2. destroy_window = This page... http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php ... mentions destroy_window only two times. I can guess what it does, and I think, I will solve my problems with this, but one little section for each event that explains what exactly causes the respective event, would be a nice improvement. Note also -- there is this rather idiotic thread: http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html But take away from that post that some of the information you're wanting -- whilst useful -- might be adding bloat. In your case, are you saying for FvwmEvent you want an explanation of what each event does, and when it's triggered? I could add that, but assumed the names themselves are self-documenting. Again -- can you provide an example using destroy_window what sort of information you're wanting to see? 3. continuous text == The human race is an image processing animal. When I was studying the bindings syntax, I needed a reference. I needed the particular options in tables. But, I found them amongst continuous text. The first thing that I did was creating my own reference (half German, half English) that I attached to this e-mail message. I am *especially* keen on this sort of information because of the impending 2.6.0 release. I have no problems delaying FVWM further if this sort of thing is going to be useful; *but* making the data tabular also might lose readability in things like man page formats. You are aware we have HTML documentation which fragments the monolithic manpage, right? http://fvwm.org/doc/unstable/index.html Just look at the attachments to guess what I mean. Sorry, I don't speak German. But if you can be more specific about which areas you think would benefit from tabulating information, I am happy to work with you to accomplish this. I've been banging on for *years* about this sort of thing, and finally it might actually happen. :) You've made my day. :) -- Thomas Adam
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 04:19:20PM +0200, Michael Großer wrote: Thomas Adam wrote: On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: 2. destroy_window = This page... http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php ... mentions destroy_window only two times. I can guess what it does, and I think, I will solve my problems with this, but one little section for each event that explains what exactly causes the respective event, would be a nice improvement. Note also -- there is this rather idiotic thread: http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html But take away from that post that some of the information you're wanting -- whilst useful -- might be adding bloat. In your case, are you saying for FvwmEvent you want an explanation of what each event does, and when it's triggered? I could add that, but assumed the names themselves are self-documenting. Again -- can you provide an example using destroy_window what sort of information you're wanting to see? Such kind of information could be nice: - destroy_window: -- Generates an event if a window disappears. Well, nothing generates these events from FvwmEvent's point of view -- FvwmEvent will just react to events -- but I take your point, they could be explained better. Look at this: http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html#menus 31.1.13. Menu The orange color of the headwords and then the documentation in black color is a good start. That's a CSS issue only from the resulting HTML output. The documentation itself is single-sourced in a monstrous mess of docbook XML (which **will** be changing in 2.6.0 -- it's just fucking abysmal to keep it the way it is for much longer. That's a promise) -- so what we change will affect not only the HTML, but the man page as well. Now, look here: http://fvwm.org/doc/unstable/commands/Mouse.html Read this text: Context describes where the binding applies. Valid contexts are 'R' for the root window, 'W' for an application window, 'D' for a desktop application (as kdesktop or Nautilus desktop), 'T' for a window title-bar, 'S' for a window side, top, or bottom bar, '[', ']', '-' and '_' for the left, right, top or bottom side only, 'F' for a window frame (the corners), '', '^', '' and 'v' for the top left, top right, bottom right or bottom left corner, 'I' for an icon window, or '0' through '9' for title-bar buttons, or any combination of these letters. 'A' is for any context. For instance, a context of FST applies when the mouse is anywhere in a window's border except the title-bar buttons. Only 'S' and 'W' are valid for an undecorated window. Now, read this text: Context --- It describes where the binding applies. Valid contexts are: - 'R' for the root window - 'W' for an application window - 'D' for a desktop application (as kdesktop or Nautilus desktop) Yes. OK. Point taken. Shouldn't be too difficult to do. For this hack, I chose the list form. The table form would also be good idea. It doesn't matter if you choose the list form or the table form as long as you break up this continuous text form that is hard to read. Tables I think. They translate into groff much easier. It could help to keep the orange color of the letters because the more color, the more eye catching is the relevant information. In terms of HTML, yes. That won't change, but manpages are a different kettle of fish. * context * modifiers * focus policies OK. No problems. I will look at this later on when I get back from work. -- Thomas Adam
Re: FVWM: Events when windows close?
On Thu, Aug 12, 2010 at 10:03:01AM +0200, Michael Großer wrote: I cannot find any displayable man page. But, I found some kind of source file named FvwmEvent.1.in. There, I found: Download the file -- the direct link to the raw file is here: http://github.com/ThomasAdam/fvwm/raw/49a53ee408cba26f7649fc4b56df0d309b485cfd/modules/FvwmEvent/FvwmEvent.1.in Then you have to actually run man over it: man ./FvwmEvent.1.in I am especially keen for you to do this, so I can ensure my troff skills are still OK. I know troff fairly well. :) Are you sure that a WM_CLASS property causes both the res_class and the res_name event? I don't know so much about this WM_XXX stuff, but if I think logically, shouldn't it mean WM_NAME in the second event? If not, what is the difference between res_class and res_name? Why two events have to exist? Why not one? Or is one of them an alias of the other? No, I mean WM_CLASS -- that holds two properties therein: The resource name and the class name. Go see the ICCCM2. -- Thomas Adam
Re: FVWM: Fvwmpager crashes if no pages are to be shown
On Thu, Aug 12, 2010 at 04:21:53PM +0200, michael.gros...@gmx.de wrote: Hi! I think that I found the first bug. I made a combination of pagers for me as shown in the attachment. Straight in the bottom left corner, I made an FvwmPager that I called minipager. I gave it these Geometry attributes: *minipager: Geometry 110x44+2+978 I deliberately chose the 44 to hide the viewports (pages). I only want to see the desks and nothing else (see the PNG attachment). But, this size specification 44 triggers the bug. The problem is, as soon as I hold down the Shift+Win+Right key binding (or any other binding - see my attached binding config file) to quickly scroll through all 12 desks or to scroll through all 12 viewports for 20 seconds, the minipager disappears. I think that it simply crashes. Try not to think -- it's either crashing or it isn't -- and as I suspected, I am unable to reproduce this. Note that I am using 2.5.31 though -- a version you should be using, and one I seem to recall asking you to use before. So I am afraid unless you can ascertain a corefile for me to analyse, or provide additional instructions using FVWM 2.5.31 which *still* exhibit this problem, I am unable to help you. -- 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.)
Re: Finally solved: FVWM: Events when windows close?
On Fri, Aug 13, 2010 at 01:31:36PM +0200, Michael Großer wrote: Then, I handle the dirty details. # 1. if a window is already focussed, then do nothing Current implies focused, of course, but: DestroyFunc focus_a_window AddToFunc focus_a_window + I Current (Focused) Break # 2. if no window was focussed, then focus a window under the mouse AddToFunc focus_a_window I PointerWindow (!Focused) Focus ... which has the benefit of working OK with ClickToFocus as well. # 3. if no window was under the mouse, then focus a visible window AddToFunc focus_a_window + I TestRc (NoMatch) Next (AcceptsFocus, Visible, CurrentPage) Focus # 4. if a window was not visible (because the just now disappeared #window hid it), then try again to focus it AddToFunc focus_a_window + I TestRc (NoMatch) Next (AcceptsFocus, CurrentPage) Focus If this kind of knowledge transfer is welcome, please let it me know. For the FvwmWiki, yes. Go forth, and contribute to it. You'd be the first. -- Thomas Adam
Re: FVWM: WindowList: KDE 3 like behaviour possible?
On Fri, Aug 13, 2010 at 10:12:29PM +0200, michael.gros...@gmx.de wrote: Hi! If I use fvwm and press Alt+Tab, then at first the first position of the window list is selected. If I use KDE 3 and press Alt+Tab, then at first the second position of the window list is selected. I like it more if the second position ist selected at the start. FVWM has the CurrentAtEnd option, but the KDE 3 behaviour would be more elegant. Is there a way to make WindowList, FvwmWindowMenu or another similar tool to behave in the KDE 3 manner? If not, then I will use the CurrentAtEnd option, but before I decide in favor of this option, I want to make sure that I did not overlook something. You would need to mess around with MenuCursorMove to achieve this. Pointless, if you ask me. -- 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.)
FVWM: FVWM Forums are back.
Hello all, Finally, after too long, I've bitten the bullet, cracked out my awk skills, and munged my last backup I had of the forums, and shoved them fully working here: www.fvwmforums.org Anyone who was previously registered at the older site of fvwm.lair.be, should find that their former username/password works as intended. Certainly in my munging of the raw SQL, I won't have changed that. I would like to ask for someone who's more interested in this than I am to come up with a nice forum theme. Note that due to a few reasons, I am currently only running PHPBB 3.0.5 -- a few revisions behind the latest. Any one thinking of doing this should email me off-list, please. Any problems, let me know. Otherwise, for the rest of you, I hope to God you're happy to have the old forums back. I need to thank Jaimos Skriletz for very kindly hosting the actual forum content, although the domain name is mine. Thanks, Jaimos! A weight off my mind and shoulders. :) -- 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.)
Re: FVWM: Fvwmpager crashes if no pages are to be shown
On Fri, Aug 13, 2010 at 12:51:44AM +0200, michael.gros...@gmx.de wrote: On Thu, Aug 12, 2010 at 04:21:53PM +0200, michael.gros...@gmx.de wrote: Hi! I think that I found the first bug. I made a combination of pagers for me as shown in the attachment. Straight in the bottom left corner, I made an FvwmPager that I called minipager. I gave it these Geometry attributes: *minipager: Geometry 110x44+2+978 I deliberately chose the 44 to hide the viewports (pages). I only want to see the desks and nothing else (see the PNG attachment). But, this size specification 44 triggers the bug. The problem is, as soon as I hold down the Shift+Win+Right key binding (or any other binding - see my attached binding config file) to quickly scroll through all 12 desks or to scroll through all 12 viewports for 20 seconds, the minipager disappears. I think that it simply crashes. Try not to think -- it's either crashing or it isn't -- and as I suspected, I am unable to reproduce this. Note that I am using 2.5.31 though -- a version you should be using, and one I seem to recall asking you to use before. So I am afraid unless you can ascertain a corefile for me to analyse, or provide additional instructions using FVWM 2.5.31 which *still* exhibit this problem, I am unable to help you. I just now reproduced this bug in Debian Squeeze with FVWM 2.5.30. Core dump and/or FVWM 2.5.31 is more complex, so I will try these options later. Has there been any progress on this? -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Fvwmpager crashes if no pages are to be shown
On Sun, Aug 29, 2010 at 01:10:42PM +0200, Michael Gro?er wrote: Result: I cannot find a way to get ulimit -c returning an unlimited result. It's really quite simple. You do this in your ~/.bashrc file: ulimit -c unlimited ... and then you start FVWM in the normal way. Don't go near /etc/security/limits.conf -- that's per-process, and not what you're after. -- Thomas Adam -- It was the cruelest game I've ever played and it's played inside my head. -- Hush The Warmth, Gorky's Zygotic Mynci.
Re: FVWM: Fvwmpager crashes if no pages are to be shown
On Sun, Aug 29, 2010 at 01:10:42PM +0200, Michael Großer wrote: Thomas Adam wrote: On Fri, Aug 13, 2010 at 12:51:44AM +0200, michael.gros...@gmx.de wrote: On Thu, Aug 12, 2010 at 04:21:53PM +0200, michael.gros...@gmx.de wrote: Hi! I think that I found the first bug. I made a combination of pagers for me as shown in the attachment. Straight in the bottom left corner, I made an FvwmPager that I called minipager. I gave it these Geometry attributes: *minipager: Geometry 110x44+2+978 I deliberately chose the 44 to hide the viewports (pages). I only want to see the desks and nothing else (see the PNG attachment). But, this size specification 44 triggers the bug. The problem is, as soon as I hold down the Shift+Win+Right key binding (or any other binding - see my attached binding config file) to quickly scroll through all 12 desks or to scroll through all 12 viewports for 20 seconds, the minipager disappears. I think that it simply crashes. Try not to think -- it's either crashing or it isn't -- and as I suspected, I am unable to reproduce this. Note that I am using 2.5.31 though -- a version you should be using, and one I seem to recall asking you to use before. So I am afraid unless you can ascertain a corefile for me to analyse, or provide additional instructions using FVWM 2.5.31 which *still* exhibit this problem, I am unable to help you. I just now reproduced this bug in Debian Squeeze with FVWM 2.5.30. Core dump and/or FVWM 2.5.31 is more complex, so I will try these options later. Has there been any progress on this? Unfortunately no. I have to work to make my customers happy and earn money :-( Latest news was: It crashes in 2.5.26, 2.5.30 and 2.5.31. I don't think it's crashing at all. In fact, I think FvwmPager is as stable as it's ever been. Without your entire config present, I can't offer an explanation as to why you get the results you do -- it might very well be that the pager is closing, but that's different from crashing. Let's see what I notice first of all: # start several pagers AddToFunc StartFunction + I GotoDesk 0 0 + I FvwmPager minipager 0 11 + I Wait minipager + I GotoDesk 0 0 + I FvwmPager 0 3 + I Wait FvwmPager + I GotoDesk 0 1 + I FvwmPager 0 3 + I Wait FvwmPager ... etc., etc. You seem to have not heeded my very original advise to you regarding *why* the above is problematic. It doesn't have anything to do with your problem, BTW, it's just mildly frustrating that you're asking for help and not doing anything with the advise you're given. It also makes me dubious about how much else you're selectively ignoring, but it's a Bank Holiday for me, so you get the benefit of my doubt. :) (And who says I don't live up to my namesake?) So by this point, for each of your defined desks, we have a separate pager per *page*. Meanwhile, there's only one instance of your minipager running, it's just sticky. Fine. But if it closes, then it closes completely and you'll never see it again. If it crashed you would get a corefile -- I promise you that. So I suspect something is closing it. I don't know what, I *might* be able to tell from looking at the rest of your configs, and even an ~/.xsession-error log, if FVWM ever printed anything there. But I really don't think there's anything untoward happening here. There's no link necessarily between continually bombarding FVWM with module commands to switch desks, and a pager closing/crashing. Heck, I made myself dizzy switching pages and desks earlier, following your instructions, and still couldn't get it to crash. But the minipager there is a gratuitous hack for what is simply a desk chooser -- something you can use FvwmButtons for -- and this is ultimately what you *should* be doing. Here: DestroyModuleConfig foo:* *foo: Columns x *foo: Rows y *foo: (1x1, Title z, Action (Mouse 1) GotoDesk z) ... where: x, y and z, are calculated from $[pages.nx] $[pages.ny], etc. That's an exercise best left to you to work out -- hint: PipeRead is your friend here and a simple for(( .)) loop in sh. Now -- the part that makes this more interesting is making your requirement of seeing only four desks per desk for which you're currently on. Well, here's one way of doing it using FvwmEvent: DestroyModuleConfig foo2:* *foo2: new_desk SomeFunc AddToFunc StartFunction I Module FvwmEvent foo2 DestroyFunc SomeFunc AddToFunc SomeFunc + I KillModule FvwmPager some_alias + I PipeRead `[[ $[desk.n] -le 3 ]] echo \ Module FvwmPager some_alias 0 3 || [[ $[desk.n] -gt 3 ]] [[ $[desk.n] -le 7 ]] \ echo Module FvwmPager some_alias 4 7` ... etc., etc. Note that I'd use a simple modulo calculation to make this easier here. Now -- the interesting part here is that if you made this pager sticky -- you could then also selectively work out within a given range
