Cannot launch FvwmConsole
Hi all, I'm currently using the 20060518 cvs snapshot (that includes patches from http://abdn.ac.uk/~u15dm4/fvwm/, but I doubt they are related to the problem). When I try to launch FvwmConsole, I see in the log: FvwmConsole server error in exec, errno 2: No such file or directory Some other information.. I have the following files: /usr/lib/fvwm/2.5.17/FvwmConsole /usr/lib/fvwm/2.5.17/FvwmConsoleC /usr/lib/fvwm/2.5.17/FvwmConsoleC.pl $ echo $FVWM_MODULEDIR /usr/lib/fvwm/2.5.17 Thomas Adam also suggested grabbing the 2.5.16 FvwmConsole, which I did and pointed to in a menu (/usr/lib/fvwm/2.5.16/FvwmConsole), but I still get the same error. I've also tried moving FvwmConsole to my home directory and changing ModulePath to reflect this, but it didn't help either. Let me know if you have any suggestions or ideas. Thanks, Scott
Re: manual placement quirk: window not always placed at outline
On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote:
I have been bothered by a situation where I create a window and manually
place it at one location, but the window actually appears in a different
location. It is easy to reproduce with a very small .fvwm2rc:
Style * ManualPlacement
EdgeResistance 0 100
Start by placing an xterm in the lower right corner of the screen,
touching the side and bottom. Place the mouse near the upper left
corner of the window, within the window. Type xterm and press enter.
You will see the new window outline appear exactly over the border of
the first xterm; that is, it appears snapped to the edges of the screen.
Press enter to place the window. Note that it is placed not where the
outline was, but at the pointer position.
I investigated the code in __move_loop, in move_resize.c. (I am using
fvwm 2.5.16, but the file is identical in the 20060529 snapshot I just
checked). The problem is that in case ButtonRelease (line 2445),
there is a test that says if the mouse is in the same position it
started in, don't apply the snap. This idea is that if the mouse didn't
move, the outline never snapped, so the window shouldn't snap either.
This is an ill-conceived test for two reasons. One, the mouse could
have moved and moved back to its original position! It's not actually
that hard to achieve this. Two, there are cases other than mouse
movement that causes the window outline to snap. For example, if an
EnterNotify or LeaveNotify event is received (2301), a MotionNotify
event is faked up, and in case MotionNotify (2483), DoSnapAttract is
called to snap the outline. This is in fact what happens in the test
case above.
However, it is not always the case that the initial outline is snapped.
If there were not already a window below the mouse when I ran xterm, no
EnterNotify event would have been received, and thus the outline would
have appeared unsnapped, at the pointer. This inconsistency is cause of
further confusion to the user: Why does the outline initially appear
snapped sometimes and not other times?
To resolve this issue, we must 1. decide whether the outline should
initially appear snapped or unsnapped;
Unsnapped. In case of moving a window, placing it before touching
the mouse should not move the window at all.
2. ensure that the outline in
fact initially appears snapped or unsnapped consistently;
Ok.
3. ensure that
the window gets placed where the outline appeared.
Ok.
I took what seems to be the simplest approach (a necessity for me, given
the serpentine nature of this function), which is also the behavior I
find the most natural: I decided that the outline should always start
out snapped. It is only a couple of lines to snap the outline at the
top of the function, and then unconditionally snap on ButtonRelease.
The below patch Works For Me.
Andrew
PS. Please Cc: me, as I am not subscribed.
--- move_resize.c.orig2006-05-29 14:15:16.0 -0700
+++ move_resize.c 2006-05-29 14:18:37.0 -0700
@@ -2197,6 +2197,10 @@
xl_orig = xl;
yt_orig = yt;
+ /* Without this, the outline sometimes initially shows snapped,
+ * sometimes unsnapped. At least this is consistent. */
+ DoSnapAttract(fw, Width, Height, xl, yt);
+
/* draw initial outline */
if (!IS_ICONIFIED(fw)
((!do_move_opaque !Scr.gs.do_emulate_mwm) || !IS_MAPPED(fw)))
@@ -2463,15 +2467,9 @@
xl = xl2;
yt = yt2;
}
- if (xl != xl_orig || yt != yt_orig || vx != Scr.Vx ||
- vy != Scr.Vy)
+ if (do_snap)
{
- /* only snap if the window actually moved! */
- if (do_snap)
- {
- DoSnapAttract(
- fw, Width, Height, xl, yt);
- }
+ DoSnapAttract(fw, Width, Height, xl, yt);
}
*FinalX = xl;
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: manual placement quirk: window not always placed at outline
On Tue, May 30, 2006 at 11:11:11PM +0200, Dominik Vogt wrote: On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote: To resolve this issue, we must 1. decide whether the outline should initially appear snapped or unsnapped; Unsnapped. In case of moving a window, placing it before touching the mouse should not move the window at all. Hmm, I didn't really think about this case. However, I'm not sure that makes the most sense. Surely if you initiate a move, you want to put the window someplace other than where it was? And as soon as you move a single pixel (which most people would do without even meaning to, assuming they are using the mouse), the window will snap, causing a jarring discontinuity. I think I would rather have the snap happen right away. Anyhow, if we go with your answer, fixing the code is non-trivial. The whole event loop would probably need to be cleaned up. I don't think I'm up to doing it myself. Andrew
Re: FVWM: how to grow up
On 5/28/06, Thomas Adam [EMAIL PROTECTED] wrote: On Sun, May 28, 2006 at 11:58:09PM +0800, pipehappy wrote: But when I want it grow up, how can I do? Look at the Maximize command. Perhaps you want something like this: Maximize 0 grow -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band. Thanks Adam first. I tried Maximize 0 growup And it only can grow up to the upper edge of screen if there is no other window(Yes, I also find it in man page). So can anyone give me some tips on how to make the window grow up to the upper edge of the screen no matter there is a window above it or not? Thanks
Re: FVWM: how to grow up
On Tue, 2006-05-30 at 12:53 +, pipehappy wrote: I tried Maximize 0 growup And it only can grow up to the upper edge of screen if there is no other window(Yes, I also find it in man page). So can anyone give me some tips on how to make the window grow up to the upper edge of the screen no matter there is a window above it or not? Thanks It would be nice if the grow* options ignored any obstacles on a lower layer. This doesn't appear to be the current situation, but if it was, then you could solve your problem by promoting your window to a higher layer, growing it, and then placing it back in the original layer. Does anyone know of any reason why it might be a bad idea to have the grow* options behave in the suggested manner? --Dan Ost
Re: FVWM: fvwm and GTK dialoges (fonts) [Arghhhhh]
Hi Dan, Am 2006-05-25 11:53:00, schrieb Dan Espen: You can't post attachments here. Put them on the web somewhere and post a link. I do not know, what you are talking about... :-(=) I have forgotten to attach the pics... My message was written with 'nano' and send manualy with 'ssmtp' as text/plain only. Put them on the web somewhere and post a link. Does not work, since I have only Mail- and NO Web-Access. I don't think this is an Fvwm question. I'm not a Gtk expert. Most of my use is thru Gtk-Perl. ;-)Me php-gtk. For Gtk1, I used the Gtk preferences dialog to control font size. For Gtk2, you can also use preference dialogs, but if you don't want global control you can do this: my $font_desc = Gtk2::Pango::FontDescription-from_string (Nimbus bold 8); $object-modify_font ($font_desc); I will look at this, but it seems, if I use fvwm tke GTK angine started by fvwm is overriding the fonts in Xdialog (GTK 1.2) while using twm all is working fine but twm looks crappy... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com)
FVWM: [SOLVED] Re: fvwm eat my $TMPDIR
Hello *, I have found the culpable... it is a changed symlink! Under Woody, 'sh' was a symlink to bash and if I upgraded to Sarge, this System was working fine... symlink was not touched and Debconf has asked me whether I want to change the symlink to dash. On a NEW installes Sarge system it was different and nothing was working as bevore... Please note, that my $HOME is on a NFS-Share... Yeah... a fresh Sarge installation makes a symlink 'sh' to 'dash' which will break many BASH scripts AND the environement... Changeing the symlink back to bash and all works fine... NOW there is an other problem with fvwm and the shell but this in another separated Mail. Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com)
FVWM: $SHELL in fvwm
Hello *, I have encountered, that the command Exec invoke sh every time which had broken many of my scripts under Sarge. My question is: Why does 'fvwm' not use $SHELL and use 'sh' only as fallback? My login shell is /bin/bash. Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com)
FVWM: How to stop FvwmPager from resizing?
OK, ahead of time...forgive me if this is a stupid question. I feel silly posting...but I cannot figure this out :( I have an FvwmPager placed in the lower right corner of my screen...no issues there I would like to disable resizing and moving of FvwmPager. Here is some of my configuration: Style "FvwmPager" NoHandles, NoTitle, WindowListSkip, Sticky, StaysOnTop Mouse 1 SF A Resize Mouse 2 TSIF A Move I stupidly thought by haveing NoHandles that would somehow disable resizing...but then having the Mouse option as such, it seems like that notion is just wrong ;) I have been looking through the man pages and nothing is "jumping right out at me." I'm not really sure how to disable the mouse on the sides or the frame -only- for FvwmPager. I'm sure it so painfully obvious I deserve the RTFM comments ;) Thanks ahead of time... Scot -- Scot P. Floess 27 Lake Royale Louisburg, NC 27549 252-478-8087 (Home) 919-754-4592 (Work) Chief Architect JPlate http://sourceforge.net/projects/jplate Chief Architect JavaPIM http://sourceforge.net/projects/javapim
Re: FVWM: How to stop FvwmPager from resizing?
On 2006.05.30 09:59:42 -0400, Scot P. Floess wrote: OK, ahead of time...forgive me if this is a *stupid* question. I feel silly posting...but I cannot figure this out :( I have an FvwmPager placed in the lower right corner of my screen...no issues there I would like to disable resizing and moving of FvwmPager. Here is some of my configuration: Style FvwmPager NoHandles, NoTitle, WindowListSkip, Sticky, StaysOnTop Mouse 1 SFA Resize Mouse 2 TSIF A Move I stupidly thought by haveing NoHandles that would somehow disable resizing...but then having the Mouse option as such, it seems like that notion is just wrong ;) I have been looking through the man pages and nothing is jumping right out at me. I'm not really sure how to disable the mouse on the sides or the frame -only- for FvwmPager. I'm sure it so painfully obvious I deserve the RTFM comments ;) The style options FixedPosition and FixedSize should do the trick. HTH Björn
Re: FVWM: How to stop FvwmPager from resizing?
Björn: That didn't help...I can still resize FvwmPager. Is it possible my Mouse settings are overriding? For instance, does order in my .fvwmrc matter? Should I do Mouse settings first and Style after? Björn Steinbrink wrote: On 2006.05.30 09:59:42 -0400, Scot P. Floess wrote: OK, ahead of time...forgive me if this is a *stupid* question. I feel silly posting...but I cannot figure this out :( I have an FvwmPager placed in the lower right corner of my screen...no issues there I would like to disable resizing and moving of FvwmPager. Here is some of my configuration: Style FvwmPager NoHandles, NoTitle, WindowListSkip, Sticky, StaysOnTop Mouse 1 SFA Resize Mouse 2 TSIF A Move I stupidly thought by haveing NoHandles that would somehow disable resizing...but then having the Mouse option as such, it seems like that notion is just wrong ;) I have been looking through the man pages and nothing is jumping right out at me. I'm not really sure how to disable the mouse on the sides or the frame -only- for FvwmPager. I'm sure it so painfully obvious I deserve the RTFM comments ;) The style options FixedPosition and FixedSize should do the trick. HTH Björn -- Scot P. Floess 27 Lake Royale Louisburg, NC 27549 252-478-8087 (Home) 919-754-4592 (Work) Chief Architect JPlate http://sourceforge.net/projects/jplate Chief Architect JavaPIM http://sourceforge.net/projects/javapim
Re: FVWM: How to stop FvwmPager from resizing?
On 2006.05.30 12:29:41 -0400, Scot P. Floess wrote:
Björn:
That didn't help...I can still resize FvwmPager. Is it possible my
Mouse settings are overriding? For instance, does order in my .fvwmrc
matter? Should I do Mouse settings first and Style after?
In the reply that you sent off-list, your Style command was split into
two lines, Fixed{Size,Position} being on the second line. Does this look
the same in your .fvwmrc? If so, you need to remove the line break _or_
add a backslash at the end of the first line.
Apart from that, I have no idea why it is not working for you.
HTH
Björn
Re: FVWM: Restarting FvwmTabs (was: FvwmTabs FocusModel not working correctly)
Hi Alexander, I get this error message Use of uninitialized value in concatenation (.) or string at /usr/lib/fvwm/2.5.16/FvwmTabs line 1890. FvwmTabs (v) started with: Perl 5.8.7, X11::Protocol 0.53, Tk 804.027. You are still not running a recent release of fvwm or FvwmTabs. I am therefore not surprised that you're still having a problem! :) SCoTT. :)
