FvwmProxy keyboard handling
I've moved this discussion to a separate thread. jpwe...@imonk.com wrote: On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: * FvwmProxy: unfinished and unmaintained Please send me the location of any feature requests or bug reports. Here's my list. 1. don't reorder others in group on raise 2. vertical centering of groups of proxies 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise 4. option to only show proxy of active window No bugs I know, but 1 and 2 address suboptimal behavior. 3 is an idea for more detailed custom behavior. 4 is a request I saw on the list a while back. It's not something I would use, but it would probably be an easy add next time I visited the code. The issue of keyboard handling and/or grabbing is completely unresolved. The original version did keyboard polling, which is unacceptable. My attempts to make it listen to events never led to anything usable, so basically there is not clean way to invoke it the way it way meant to be invoked. You'll need to be more specific. From what I see, it is using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. It calls this through a Loop function that is pretty much cutpaste from FvwmPager. And it doesn't require you to do this modifiers watch. You can use simply toggle proxies with explicit commands. If some non-xorg server is fussy, well, I'd hate to see all these capabilites effectively banned to console a few fringe users who may not otherwise get the full functionality. It seems FvwmPager and FvwmProxy are both spinning in Loop(). Does it really matter if I call FQueryPointer each time (when activated and proxies are visible)? It is immeasurable on the CPU, not even above any of 0% cpu processes I see in 'top'. I do get 1% for the single time step that I open the proxies, so I know it's there. And there's still the possibility of cpu lockups because of an infinite loop. We discussed both when we added FvwmProxy to cvs - they've been in the todo-2.6 for ages. I use SendFvwmPipe and SendText. So does every nearly other module, it seems. I 'send' resize and move commands, as some others do. It seems more appropriate than XMoveResizeWindow and the like, which many modules have. Perhaps no other module reacts to its own move commands, maybe, but I've been using this 14 hours a day for nearing a decade (less comment to follow) and I haven't had it freeze for at least a couple of years, as long as I can remember at least. Are these current bugs or reports that were never rechecked? I went to the fvwm bug tracking system and a regex on fvwmproxy came up one fixed bug about a man page. It very difficult to debug speculations. I haven't had a compelling need to fiddle with something that works, mostly. Honestly, who has read through the whole current man page, set this module up correctly, used it for a while, and NOT seen huge benefits? Of course this tool was tailored to my vision, but I see things like Expose and other alt-tab alternatives and am amazed that people live with such limited capabilites. It's like it gives me xray vision. Add on the window grouping, sticky edges, virtual tab bar, and this is half of why I even use fvwm. I *know*. FvwmProxy has realy potential to become a very helpful tool for many people (maybe except me, because I already have a solution for the same problem). Please share. If you've reached to next plateau, I'd love to come up and take a look. There are two bis problems that need to be solved first (see above). People at work say, 'wow, how do I get that' and I have to tell them it doesn't work with their KDE or gnome. All the existing fvwm users I've met are now using it. I had one fvwm convert for a while, for this purpose, but I guess fvwm is a programmer's WM. By default, it doesn't really do anything. I don't control the master rc files. You have to set it up. I've tried to put good examples in the man page. My point being, this is neither abandoned code or a curious experiment. It is heavily used by serious professionals. This module is not the focus of my work, by the productivity of all my other efforts hinges on this tool. I consider the availablilty of fvwm (and therein proxy) in making career decisions. I spent 18 months on a job a few years back with pure Win32 and you never get used to it once you know what real efficiency is like. It is a joke, a sad sad joke. FvwmPartition, in contrast, is an experiment and, as far I am concerned, the sticky edge and virtual tab capabilites of
Re: Removing debian/ from FVWM CVS.
My email service got got messed up yesterday so I am sending this message again. The fvwm mail archive appears to be way behind, so I can't tell it it went though. I've switched my subscription to a gmail account. On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: * FvwmProxy: unfinished and unmaintained Please send me the location of any feature requests or bug reports. Here's my list. 1. don't reorder others in group on raise 2. vertical centering of groups of proxies 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise 4. option to only show proxy of active window No bugs I know, but 1 and 2 address suboptimal behavior. 3 is an idea for more detailed custom behavior. 4 is a request I saw on the list a while back. It's not something I would use, but it would probably be an easy add next time I visited the code. The issue of keyboard handling and/or grabbing is completely unresolved. The original version did keyboard polling, which is unacceptable. My attempts to make it listen to events never led to anything usable, so basically there is not clean way to invoke it the way it way meant to be invoked. You'll need to be more specific. From what I see, it is using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. It calls this through a Loop function that is pretty much cutpaste from FvwmPager. And it doesn't require you to do this modifiers watch. You can use simply toggle proxies with explicit commands. If some non-xorg server is fussy, well, I'd hate to see all these capabilites effectively banned to console a few fringe users who may not otherwise get the full functionality. It seems FvwmPager and FvwmProxy are both spinning in Loop(). Does it really matter if I call FQueryPointer each time (when activated and proxies are visible)? It is immeasurable on the CPU, not even above any of 0% cpu processes I see in 'top'. I do get 1% for the single time step that I open the proxies, so I know it's there. And there's still the possibility of cpu lockups because of an infinite loop. We discussed both when we added FvwmProxy to cvs - they've been in the todo-2.6 for ages. I use SendFvwmPipe and SendText. So does every nearly other module, it seems. I 'send' resize and move commands, as some others do. It seems more appropriate than XMoveResizeWindow and the like, which many modules have. Perhaps no other module reacts to its own move commands, maybe, but I've been using this 14 hours a day for nearing a decade (less comment to follow) and I haven't had it freeze for at least a couple of years, as long as I can remember at least. Are these current bugs or reports that were never rechecked? I went to the fvwm bug tracking system and a regex on fvwmproxy came up one fixed bug about a man page. It very difficult to debug speculations. I haven't had a compelling need to fiddle with something that works, mostly. Honestly, who has read through the whole current man page, set this module up correctly, used it for a while, and NOT seen huge benefits? Of course this tool was tailored to my vision, but I see things like Expose and other alt-tab alternatives and am amazed that people live with such limited capabilites. It's like it gives me xray vision. Add on the window grouping, sticky edges, virtual tab bar, and this is half of why I even use fvwm. I *know*. FvwmProxy has realy potential to become a very helpful tool for many people (maybe except me, because I already have a solution for the same problem). Please share. If you've reached to next plateau, I'd love to come up and take a look. There are two bis problems that need to be solved first (see above). People at work say, 'wow, how do I get that' and I have to tell them it doesn't work with their KDE or gnome. All the existing fvwm users I've met are now using it. I had one fvwm convert for a while, for this purpose, but I guess fvwm is a programmer's WM. By default, it doesn't really do anything. I don't control the master rc files. You have to set it up. I've tried to put good examples in the man page. My point being, this is neither abandoned code or a curious experiment. It is heavily used by serious professionals. This module is not the focus of my work, by the productivity of all my other efforts hinges on this tool. I consider the availablilty of fvwm (and therein proxy) in making career decisions. I spent 18 months on a job a few years back with pure Win32 and you never get used to it once you know what real efficiency is like. It is a joke, a sad sad joke. FvwmPartition, in contrast, is an experiment and, as far I am concerned, the sticky edge
Re: Removing things from FVWM CVS.
On Sun, Mar 15, 2009 at 07:00:05PM +, Mikhael Goikhman wrote: On 15 Mar 2009 00:34:16 +0100, Dominik Vogt wrote: [snip] To be interactive the module should both listen to fvwm and to the input (mouse, keyboard) in the same event loop. Don't you agree? Yes. And why does this rule out text based interfaces? Please show how this is possible without adding any real toolkit. (And ncurses toolkit is another dependency, just like gtk. Programming in it is not much different from programming in gtk, it is just much more limited and more annoying.) And as I said there is a half ready support of pseudo toolkit in perllib that uses xterm, but there are serious technical obstacles to interact with xterm tty (even without ncurses, just simple readline). I tried it when started to develop perllib to get user-interactive things done without gtk, it does not work well. It's just a bit of menu handling. These things certainly existed before guis where ever invented. perllib supports this for at least Gtk and Tk toolkits. It also supports a pseudo-toolkit mode using pure xterm, xmessage and similar standard X things. Also the idea was to be able to write a module that uses Gtk if presents and fallbacks to the pseudo-toolkit mode otherwise. But I didn't find the real application for this. Usually you need real full-featured widgets for a real-life interactive module. FvwmGtkDebug is really not simple to reimplement without gtk. I don't know, I couldn't make it run anyway. Too many dependencies ;-) It looks like it's impossible to install fvwm anywhere but in /usr/local. Well, fvwm seems to ignore the --prefix=/home/something/foo option I gave it when it looks for modules. [Almost wanting to cry...] Of course ./configure --prefix works, followed by make and make install. My fvwm is always in /opt/fvwm/. Actually I have several installations. Including /usr/bin/fvwm from rpm, that is not used. When you installed another instance of fvwm, you may do Restart /opt/fvwm/bin/fvwm and this new instance will find correct modules (it only does not find them on non-standard installations). In any case you may always give full path to a module, even word Module is opional. Also you may run fvwm-config that sits in the same bin/ directory where you installed fvwm: fvwm-config --fvwm-moduledir Well, of course I know all this. I do $ configure --prefix=$HOME/foo $ make clean $ make install # restart fvwm from $HOME/foo (no module path in config) -- No such module 'FvwmButtons' in ModulePath '/usr/local/libexec/fvwm/2.5.28' * FvwmGtk Dumped in fvwm without a discussion about the taken approach and was never commented by any developers. A typical case of accepting third party work in fvwm without a maintainer. Matthias Clasen was an active developer on this list when I came. I would not call it a third party work. But why do you disagree with the idea to discuss and implement all grandiose ideas and cleanup after 2.6? A module is here for more than 10 years and I don't remember that a goal for 2.6 was removing modules. I don't disagree with anything, it just annoys me when people are bashed because they try to keep fvwm maintainable. It's ridiculous to imply that I'd not care about backwards compatibility. If I misread your messages, sorry. But I think you fully supported another opinion that spoke about removing things and breaking backwards compatibility. Im just *very* annoyed that gtk is needed to use fvwm with all features. Sorry, maybe I am wrong about this, but I really feel that you are simply saying the opposite of what I say since 2001. I don't even want to ask why 2001. This is just not true. I like most of the people on this list sympaty you and agree on many things, just not all (and even when there is a tactical disagrement it is still far from the opposite). I'd rather discuss this in private. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmProxy keyboard handling
I've found the lists.math.uh.edu archive which is not the same as what is shown on the fvwm.org page. Apparently my emails did show up, but I haven't been receiving them at my gmail or my older account. Perhaps the fvwm.org contact page needs to be updated to get the proper archive and any other newer instructions. I cutpaste this prior mail off the archive. From Dominik Vogt dominik.v...@gmx.de Subject FvwmProxy keyboard handling Date Sun, 15 Mar 2009 12:50:47 +0100 [Part 1 text/plain us-ascii (7.0 kilobytes)] (View Text in a separate window) I've moved this discussion to a separate thread. jpwe...@imonk.com wrote: On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: * FvwmProxy: unfinished and unmaintained Please send me the location of any feature requests or bug reports. Here's my list. 1. don't reorder others in group on raise 2. vertical centering of groups of proxies 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise 4. option to only show proxy of active window No bugs I know, but 1 and 2 address suboptimal behavior. 3 is an idea for more detailed custom behavior. 4 is a request I saw on the list a while back. It's not something I would use, but it would probably be an easy add next time I visited the code. The issue of keyboard handling and/or grabbing is completely unresolved. The original version did keyboard polling, which is unacceptable. My attempts to make it listen to events never led to anything usable, so basically there is not clean way to invoke it the way it way meant to be invoked. You'll need to be more specific. From what I see, it is using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. It calls this through a Loop function that is pretty much cutpaste from FvwmPager. And it doesn't require you to do this modifiers watch. You can use simply toggle proxies with explicit commands. If some non-xorg server is fussy, well, I'd hate to see all these capabilites effectively banned to console a few fringe users who may not otherwise get the full functionality. It seems FvwmPager and FvwmProxy are both spinning in Loop(). Does it really matter if I call FQueryPointer each time (when activated and proxies are visible)? It is immeasurable on the CPU, not even above any of 0% cpu processes I see in 'top'. I do get 1% for the single time step that I open the proxies, so I know it's there. And there's still the possibility of cpu lockups because of an infinite loop. We discussed both when we added FvwmProxy to cvs - they've been in the todo-2.6 for ages. I use SendFvwmPipe and SendText. So does every nearly other module, it seems. I 'send' resize and move commands, as some others do. It seems more appropriate than XMoveResizeWindow and the like, which many modules have. Perhaps no other module reacts to its own move commands, maybe, but I've been using this 14 hours a day for nearing a decade (less comment to follow) and I haven't had it freeze for at least a couple of years, as long as I can remember at least. Are these current bugs or reports that were never rechecked? I went to the fvwm bug tracking system and a regex on fvwmproxy came up one fixed bug about a man page. It very difficult to debug speculations. I haven't had a compelling need to fiddle with something that works, mostly. Honestly, who has read through the whole current man page, set this module up correctly, used it for a while, and NOT seen huge benefits? Of course this tool was tailored to my vision, but I see things like Expose and other alt-tab alternatives and am amazed that people live with such limited capabilites. It's like it gives me xray vision. Add on the window grouping, sticky edges, virtual tab bar, and this is half of why I even use fvwm. I *know*. FvwmProxy has realy potential to become a very helpful tool for many people (maybe except me, because I already have a solution for the same problem). Please share. If you've reached to next plateau, I'd love to come up and take a look. There are two bis problems that need to be solved first (see above). People at work say, 'wow, how do I get that' and I have to tell them it doesn't work with their KDE or gnome. All the existing fvwm users I've met are now using it. I had one fvwm convert for a while, for this purpose, but I guess fvwm is a programmer's WM. By default, it doesn't really do anything. I don't control the master rc files. You have to set it up. I've tried
Re: FVWM: stick between screen
2009/3/15 Jason Weber baboon.im...@gmail.com:
Start with one empty unified screen, two side by side monitors using
twinview (same card, different plugs).
Instance a new window, say a xterm.
Slide it left and right so that the left or right edge passes from
one monitor to the other. I believe that the window edge is supposed to
snap with strong preference to keep the window on only one monitor.
The only thing I know of that might be unusual is that my
monitors' horizontal resolutions are different.
Well as long as X reports things correctly then FVWM will honour that,
so I think this a red-herring. I'm not in a position to test this
myself as I am sans Xinerama, but does the following patch do anything
to help fix this? I warn you it's complete theory on my part, so
expect a quirk or fifty. ;)
-- Thomas Adam
P.S. Also Cc'ed fvwm-workers which is what you should have done from
the outset.
Index: fvwm/move_resize.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/move_resize.c,v
retrieving revision 1.304
diff -u -r1.304 move_resize.c
--- fvwm/move_resize.c 7 Dec 2007 18:52:21 - 1.304
+++ fvwm/move_resize.c 16 Mar 2009 01:11:21 -
@@ -2076,8 +2076,23 @@
/* snap to screen egdes */
if ((fw-snap_mode SNAP_SCREEN) fw-snap_proximity 0)
{
+ /* TA: 20090315: Make sure windows being told to snap to a
+ * screen; honour Xinerama screens separately -- and don't
+ * treat the screen area as one huge screen.
+ */
+ rectangle screen;
+ int screen_width;
+
+ screen_width = Scr.MyDisplayWidth;
+
+ /* Get the parameters for the screen */
+ FScreenGetScrRect(NULL, FSCREEN_CURRENT, screen.x, screen.y,
+screen.width, screen.height);
+ if (screen.width 0)
+ screen_width = screen.width;
+
/* horizontally */
- if (!(Scr.MyDisplayWidth (*px) ||
+ if (!(screen_width (*px) ||
(*px + self.width) 0))
{
dist = abs(Scr.MyDisplayHeight - (*py + self.height));
@@ -2119,23 +2134,23 @@
(*py + self.height) 0))
{
dist = abs(
-Scr.MyDisplayWidth - (*px + self.width));
+screen_width - (*px + self.width));
if (dist closestRight)
{
closestRight = dist;
-if (*px + self.width = Scr.MyDisplayWidth
+if (*px + self.width = screen_width
*px + self.width
-Scr.MyDisplayWidth + fw-snap_proximity)
+screen_width + fw-snap_proximity)
{
- nxl = Scr.MyDisplayWidth - self.width;
+ nxl = screen_width - self.width;
}
if (*px + self.width =
-Scr.MyDisplayWidth - fw-snap_proximity
-*px + self.width Scr.MyDisplayWidth)
+screen_width - fw-snap_proximity
+*px + self.width screen_width)
{
- nxl = Scr.MyDisplayWidth - self.width;
+ nxl = screen_width - self.width;
}
}
dist = abs(*px);
