Re: FVWM: Window for qwit (or qtwitter) not shown after FVWM is restarted
On Sat, Feb 11, 2012 at 09:32:29AM +0100, Markus Hutmacher wrote: Hello, I'm using FVWM-2.6.1 on Slackware64-current. I've installed qwit At least try 2.6.4. (and also qtwitter) as Twitter-clients. Both are shown in stalonetray and work as expected. But when I restart FVWM before closing qwit, it is shown in stalonetray, but I cannot manage the window to be shown. When I use the show/hide option at the icon in stalonetray, the desktop is changed, but still no window. The same is true for qtwitter, both (as the name says are qt-based. Exiting FVWM and restarting doesn't work either. Well, I suspect that qwit is doing something like this: * Click on systray icon - Focus Window. * Click again on systray icon - is window mapped ? Hide : Show It's entirely possible that through the systray icon, FVWM thinks the window is in the WithDrawn state, or something, and is never mapped again because of it. I took a very quick look at this using qwit, and cannot reproduce your problem. But when I start qwit or qtwitter in KDE and afterwards again in FVWM, both work as expected. Don't think that there's any causality here -- the two are completely different. Here my question: what does KDE with the programs what FVWM does not? is there an option I can use in the configuration? My configuration is As I say, it could be how the X11 events are being treated, but I'll struggle to know for sure until I can reproduce it. Since it seems to be working fine here for me, I'll try and rule out anything in your config first, if you'll send that to 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.)
Re: FVWM: Window for qwit (or qtwitter) not shown after FVWM is restarted
Hello Thomas, thanks for the quick answer, I will build the 2.6.4-version at first and try out if it works for me. I forgot to mention, that when the qwit-window doesn't come up and I kill the qwit-process and then again start the program, it still doesn't work. Well, I'll append my whole configuration to this mail, the configuration for qwit is in functions and in modules. Markus Am 11.02.2012 11:40, schrieb Thomas Adam: On Sat, Feb 11, 2012 at 09:32:29AM +0100, Markus Hutmacher wrote: Hello, I'm using FVWM-2.6.1 on Slackware64-current. I've installed qwit At least try 2.6.4. (and also qtwitter) as Twitter-clients. Both are shown in stalonetray and work as expected. But when I restart FVWM before closing qwit, it is shown in stalonetray, but I cannot manage the window to be shown. When I use the show/hide option at the icon in stalonetray, the desktop is changed, but still no window. The same is true for qtwitter, both (as the name says are qt-based. Exiting FVWM and restarting doesn't work either. Well, I suspect that qwit is doing something like this: * Click on systray icon - Focus Window. * Click again on systray icon - is window mapped ? Hide : Show It's entirely possible that through the systray icon, FVWM thinks the window is in the WithDrawn state, or something, and is never mapped again because of it. I took a very quick look at this using qwit, and cannot reproduce your problem. But when I start qwit or qtwitter in KDE and afterwards again in FVWM, both work as expected. Don't think that there's any causality here -- the two are completely different. Here my question: what does KDE with the programs what FVWM does not? is there an option I can use in the configuration? My configuration is As I say, it could be how the X11 events are being treated, but I'll struggle to know for sure until I can reproduce it. Since it seems to be working fine here for me, I'll try and rule out anything in your config first, if you'll send that to me? -- Thomas Adam config.tar Description: Binary data
Re: FVWM: Window for qwit (or qtwitter) not shown after FVWM is restarted
On Sat, Feb 11, 2012 at 12:35:24PM +0100, Markus Hutmacher wrote: Hello Thomas, thanks for the quick answer, I will build the 2.6.4-version at first and try out if it works for me. Can you please make sure you don't top-post? I forgot to mention, that when the qwit-window doesn't come up and I kill the qwit-process and then again start the program, it still doesn't work. Well, I'll append my whole configuration to this mail, the configuration for qwit is in functions and in modules. Well, I still can't reproduce your problem, so at this point I might hazard a guess it's a problem with either Qt or qwit. There's nothing I can do until you can get me a more generic test case. -- 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: Window for qwit (or qtwitter) not shown after FVWM is restarted
Am 11.02.2012 12:49, schrieb Thomas Adam: On Sat, Feb 11, 2012 at 12:35:24PM +0100, Markus Hutmacher wrote: Hello Thomas, thanks for the quick answer, I will build the 2.6.4-version at first and try out if it works for me. Can you please make sure you don't top-post? Well, sorry I forgot to mention, that when the qwit-window doesn't come up and I kill the qwit-process and then again start the program, it still doesn't work. Well, I'll append my whole configuration to this mail, the configuration for qwit is in functions and in modules. Well, I still can't reproduce your problem, so at this point I might hazard a guess it's a problem with either Qt or qwit. There's nothing I can do until you can get me a more generic test case. Now I've built and installed fvwm-2.6.4 and it yet I can't reproduce the problem as well. I'll keep an eye on it and hope that that the problem is solved now. Thanks for pointing me to the newest version. Markus -- Thomas Adam
FVWM: how to use the infostore command
Hi. Having read the release notes for the new InfoStore command do I need to convert any SetEnv commands to use it? I am not sure of why it exists, and now why there's two different options to do much the similar thing Thanks, Jason
Re: FVWM: how to use the infostore command
On Sat, Feb 11, 2012 at 03:06:23PM -0800, Jason Timrod wrote: Hi. Having read the release notes for the new InfoStore command do I need to convert any SetEnv commands to use it? I am not sure of why it exists, and now why there's two different options to do much the similar thing This should answer enough for you: http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html There's a distinct difference between options needing to be in the environment for programs to operate (which is itself a bug, which I think my post above alludes to, if not mentions, AFAICR), and bits of information internal to FVWM which are useful to describe -- such as one's favourite terminal program, or video player of choice, etc. Previously to this, SetEnv was the only way to do this, which was far from ideal. That's why I wrote InfoStore to do it instead -- which is slightly cleaner than cluttering up FVWM's process space with environment variables. The other motivation for it was to provide a generic way of adding labels to FVWM without the need internally for those lables to have to form part of the different parts of FVWM. So for instance, people have been wanting for ages a way to use named colorsets, as in: Colorset titlebarcs fg white, bg black Now you can with: InfoStoreAdd titlebarcs 0 Colorset 0 fg white, bg black Style * HilightColorset $[infostore.titlebarcs] ... which also means you can reuse this information elsewhere in your config, should it be applicable. I could have implemented this with perllib, FWIW, but I do not want anything in the core explicitly needing things like perl to operate. If the information in my referenced email is lacking in the documentation for InfoStore, feel free to submit a patch. -- 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: How I select windows by name from the keyboard: a recipe
As a followup to asking about how to do this a while back on the
mailing list (and then asking a related question more recently), I'm
sharing with the list how I have put this together.
The goal: allow me to select terminal windows from the keyboard in a
manner similar to searching for text in a browser: hit a key, start
typing a window name, and have some form of autocompletion. I don't
feel the need to do anything clever if several terminal windows have
the same name and I pick it; which window gets selected can be random.
The tools you'll need in addition to FVWM:
- xwininfo for getting window information. I think this is pretty
standard to have installed.
- dmenu, http://tools.suckless.org/dmenu/, for handling the general
selection process.
I have made a patch for dmenu that adds shell-like partial
autocompletion, which is very useful for this and which my scripts
assume:
http://lists.suckless.org/dev/1202/10851.html
I have a core driver script that I call 'term-front':
#!/bin/sh
# Keyboard selection of terminal windows with completion based on window
# name, via dmenu.
# dmenu will appear at the bottom of the screen.
# Generate a list of unique names of terminal windows.
genwins() {
xwininfo -root -tree |
egrep ': \([^)]* (XTerm|Gnome-terminal|9term)\) [0-9]' |
awk '{print $2}' | sed -e 's/^//' -e 's/:$//' | sort -u
}
# run dmenu to get the answer; exit if dmenu aborted.
win=$(genwins | dmenu -b -P -p win -t) || exit 1
# pass the selected window to my ToWindow function in FVWM.
echo Function ToWindow \$win\ | FvwmCommand -c
exit 0
(You may want to customize what font dmenu uses with '-fn ...'. My
actual script runs a frontend script for dmenu that sets the font
and my preferred dmenu colours; I omitted it here for simplicity.)
In my FVWM config file I have the following relevant bits (in addition
to starting the FvwmCommandS module as part of FVWM startup, so that
FvwmCommand works):
# Invoke terminal selection (ie term-front) via F4.
# Stealing F4 may not be to everyone's tastes; customize to suit.
Key F4 A N Exec exec term-front
# Aggregate all terminal windows together by turning on State 2 for them.
Style XTerm State 2
Style Gnome-terminal State 2
Style 9term State 2
# Assist function for window selection via the keyboard.
# Only matches terminal windows (ie windows with State 2 on).
# Invoked as 'Function ToWindow whatever'.
# - if the current window is $0, do nothing
# - if there is no window $0, do nothing.
# - otherwise deiconfy, focus, raise, and warp pointer to window.
DestroyFunc ToWindow
AddToFunc ToWindow
+ I Current (State 2, $0) Break
+ I Next (State 2, $0) ToWindow2
DestroyFunc ToWindow2
AddToFunc ToWindow2
+ I Iconify False
+ I Focus
+ I Raise
+ I WarpToWindow 80 20
A longer writeup of this with more blathering can be found at:
http://utcc.utoronto.ca/~cks/space/blog/unix/FvwmKeyboardWindows
http://utcc.utoronto.ca/~cks/space/blog/unix/FvwmStatesUndertood
You should read both (if you read them at all) because the second
contains a valuable improvement after I finally understood States
right. I have to thank Thomas Adam for finally getting some important
stuff about States through my evidently thick skull.
- cks
