Re: travis-ci - fvwm.git master branch is "protected"

[Viktor Griph]

Den 24 mar 2016 5:22 em skrev "Thomas Adam" :
>
> Hi all,
>
> I've to document this formally, but I wanted to let you know of a few
options
> I've enabled for the "master" branch on the main fvwm Git repository.
>
> All pushes by default (across all branches) will now have Travis CI ran
> against them.  Travis is a Continuous Integration tool[1] which allows the
> code to be compiled.  If there's any errors, an email is sent out
indicating
> where the logs can be found[2].

Cool. Would it be possible to stick some unit test framework to it as well?

> Additionally, the master branch (which is where all the stable code
intended
> for releases ends up) now has protection enabled, which means code will
not be
> merged there by default, should Travis CI be unable to build it.  This
should
> help things be more robust, and provides a much more powerful alternative
to
> the old snapshot mechanisms of yesteryear.  This also means commits
directly
> on master are discouraged---but that's OK because we've discussed that
before.

Is our strategy for handling of branches and pull requests summarized
anywhere?

/Viktor

Re: FVWM: A small issue with SetEnv

[Viktor Griph]

2012/3/12 Roman Grazhdan ro...@cloudcabin.org:
 It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
 proposed to use

 ModulePath +:$./modules

 instead of

 ModulePath /usr/lib/fvwm/2.6.4:$[FVWM_USERDIR]/modules

 which looks pretty sane to me, the latter depends on fvwm version and is
 anyway redundant.

 But using the better variant does not work for me - module doesn't start
 and here's what I get when I start it manually with FvwmConsole:

 [fvwm][executeModule]: ERROR No such module 'FvwmPiazza' in
 ModulePath '/usr/lib/fvwm/2.6.4:'/home/tartan/.fvwm'/modules'

 What did I do wrong here? Another user from the same thread has
 everything working just fine, I went back to what I had before Thomas'
 correction.


It looks as if you triggered some kind of quoting of the variable. Is
the ModulePath part of a function, and not on its own line in the
config file?

/Viktor

Re: FVWM: Today the desktop, tomorrow the world

[Viktor Griph]

2009/7/18 Michael Talbot-Wilson div3uni...@view.net.au:
 I'd like the pager miniatures to be headed with the word World
 replacing Desk, i.e. World 0, World 1 and so on.

 Is there any straightforward way to do this?  Some point in the source
 code to check out?  Is the word Desk hardwired or is there a
 configuration that would do it?  Where do I start?

There is no way to simply replace the Desk prefix with something
else from configuration. You may however use the DesktopName command
to rename individual desks. Desk %s is hardwired in FvwmPager.c.

/Viktor

Re: FVWM: How to make thumbnail WindowListSkip?

[Viktor Griph]

On Tue, 19 Feb 2008, for.register for.register wrote:


Hi, All

How to make thumbnail WindowListSkip?


That depends on how the thumbnainnig is done, but there is probably a 
WindowStyle command somewhere setting the icon of the window. If that is 
the case addinf WindowListSkip to that would do. You would also have to 
remove the WindowListSkip when deiconifying.


 

There is another question ( I did not find any answer in fvwm manul)
How to set the the mouse bindings when I want to use Alt+mouse3(hold)
to movesize of the current window directly?


I'm not sure exactly what you want to do. Maybe something like this:

DestroyFunc MoveResize
AddToFunc MoveResize
+ I Move
+ I Resize Direction SE

Mouse 3 W M MoveResize

/Viktor

Re: FVWM: devilspie

[Viktor Griph]

On Fri, 8 Feb 2008, [EMAIL PROTECTED] wrote:


Hello,

Does anyone use devilspie with fvwm? It seems to mostly work for me, but
I can not get 'undecorate' command to remove titles/borders. Is this
supposed to work?


I don't know how devilspie works, but if it's using motif hints fvwm
does support them, but you need to turn on the support with Style *
MwmDecor

/Viktor

Re: FVWM: SIGSEGV in colorset.c

[Viktor Griph]

On Tue, 5 Feb 2008, Dominik Vogt wrote:


On Tue, Feb 05, 2008 at 03:00:18AM +0600, Roman S Dubtsov wrote:

On Tuesday 05 February 2008, Dominik Vogt wrote:
[snip]

There is no output of FvwmButtons in there.  Can you please post
a stack trace in a new thread please?


Log file has these lines that are related to FvwmButtons (starting from line
52):

ComboPanel: Cause of next X Error.
   Error: 13 (BadGC (invalid GC parameter))
   Major opcode of failed request:  70 (PolyFillRectangle)
   Minor opcode of failed request:  0
   Resource id of failed request:  0x320

I doubt I will be able to post a stack trace since FvwmButtons did not dump
core, they just exited due to some error condition. (The message above looks
like it is from default X11 error handler which exists after printing a error
AFAIK). Could you please hint me how to obtain log file solely from
FvwmButtons?


You can't.  Most of the modules, including FvwmButtons, do not
print much to the console.  FvwmButtons should really write a core
file here as it crashes with abort().  I have committed a patch
that tries to force a core by accessing a null pointer instead.


Actually you could write up a script that lies inbetween fvwm and the 
modules to do some redirection of output. But since the modules mostly 
don't generate any output that wouldn't be of mush help. However it is 
fully possible to attach a gdb process to any running module do do live 
debugging. The attached script starts a module and then opens an xterm 
with gdb attached to that module. It should be put into the module path

and then used as

DebugModule FvwmModule module arguments

/Viktor#!/bin/sh
i=1
args=
while [ $i -lt 6 ]
do
args=$args $1
i=`expr $i + 1`
shift
done
title=gdb: $1
module=$1
shift
which=`which which`
module=`env PATH=$FVWM_MODULEDIR $which $module`
$module $args $@ 
module_pid=$!
xterm -T $title -e gdb $module $module_pid

Re: FVWM: SIGSEGV in colorset.c

[Viktor Griph]

On Fri, 1 Feb 2008, Roman S Dubtsov wrote:


Hi,

Thanks a lot for the replies!

First, I have forgot to mention that I run FVWM under gnome-session manager. I
think that this may be important, because sometimes gnome-settings-daemon
resets the wallpaper to the one from gnome settings (I wish I could turn this
off, very annoying). After FVWM crash I still have X up and running and I am
able to restart FVWM from console.


It's definately wallpaper changes that cause the error, and most likely 
multiple wallpaper changes in a short time frame. I've not been able to 
reporduce it myself yet, and I'm not going to install gnome for this.



Next, I have two separate screens: DFP and TV set up using nvidia proprietary
driver. I have also reproduced the issue using open-source nv dirver, so
screen setup probably is not an issue.


this shouldn't be an issue.



Also, I have attached:
* crash.log.bz2 --- log file obtained after source modifications described in
Viktor's e-mail,
* gdb.log.bz2 --- gdb log,
* fvwm.tar.bz2 --- my config (stripped down a bit).


It seems as if XGetGeometry does the right thing, and gets the size of the 
root pixmap, but XGetImage, still generates a BadMatch error. That is 
quite strange, since the XServer is grabbed until after the call to 
XGetImage. If the pixmap was invalid, I'd think that XGetGeometry should 
fail as well, but apparently it doesn't.



[snip]

PS. I have added a check for NULL after XGetImage with a goto to the cleanup
portion of the function and was not able to reproduce the crash.


That's as I expect. THat is actually the best solution I can come up with 
right now. But it will not get rid of the X-errors. We should at least add 
that kind of checks to all XGetImage calls. But ideally we should also 
find a way to not get the error at all. I belive the error will be reduced 
if the event queue is checked for additional background changes before 
doing any redrawing. That should also save updating root transparancy for 
a background that is remeoved directly. It will however not guarantee that 
the background pixmap isn't removed during the actual update.



PPS. Just in case, periodically (several minutes after startup, and a day or
two later) I also observe screen lock-ups after dragging a window: window is
not moved, I cannot click on anything, but if there's video output, it goes
on normally. After ~10-15 seconds everything is back to normal.


My guess is hat this is due to the gnome-setting daemon refreshing the 
background, as you said it would. Computing the average color of the 
background images is somewhat timeconsuming, and fvwm won't do anything 
else during that time. If you specify a bg on your RootTransparent 
colorsets there should be no averaging, and mostly you will get good 
results anyway. (With the exception on when you have many very different 
color-wise background images, so you can't select a bg that matches to 
them.)


/Viktor

Re: FVWM: SIGSEGV in colorset.c

[Viktor Griph]

On Sat, 2 Feb 2008, Roman S Dubtsov wrote:


On Saturday 02 February 2008, Viktor Griph wrote:

...snip...
If you specify a bg on your RootTransparent
colorsets there should be no averaging, and mostly you will get good
results anyway. (With the exception on when you have many very different
color-wise background images, so you can't select a bg that matches to
them.)


Thanks! I'll try. Somehow, I was thinking that it is impossible to specify bg
with RootTransparent.


Just remember to remove the bg if we ask you to try to reproduce the bug 
again.  It won't happen without bg-averaging.


/Viktor

Re: FVWM: SIGSEGV in colorset.c

[Viktor Griph]

On Fri, 1 Feb 2008, Roman Dubtsov wrote:


Hello,

I have intermittent FVWM crashes. They occur when I start either
gnome-control-center, nvidia-settings, or wine (this one works almost
always). I use FVWM from Debian.

[EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V
fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text,

Core is not always dumped, sometimes FVWM crashes with X11 error
message similar to this:

[fvwm.0][FvwmErrorHandler]: ERROR *** internal error ***
[fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28


That is a BadMatch error from XGetImage (probalby line 1149 in 
colorset.c), which would then return null, and explain the segfault on 
line 1170. According to the man page of XGetImage, that is caused by 
trying to read outside the pixmap. Which seems quite strange since on line 
1045-1048 the pixmap and size is set to that of the root_pic. And it then 
verifies the with at line 1102-1121, and the XServer is grabbed during the 
test until after the XGetImage call.



Is there anything else I can do to help to resolve the issue?
colorset.c in CVS head did not change since 2.5.23, so I did not build
and test it, but will surely do if necessary.


I'm interesting in having verified that cs-picture == NULL for the 
colorset, and also have the with and hight queried from the image before 
the XGetImage printed. I must be missing some possible path here. But I 
fail to see how the picture can be non-NULL - at least not with your 
Colorset definition.


Can you add something like
{
int w;
int h;
XID dummy;

if (
!XGetGeometry(
dpy, average_pix, dummy,
(int *)dummy, (int *)dummy,
(unsigned int *)w, (unsigned int *)h,
(unsigned int *)dummy,
(unsigned int *)dummy))
{
fprintf(stderr, failed to get dimension\n);
}
else
{
fprintf(stderr, width: %d, height: %d, expexted: %dx%d\n,
w, h, cs-width, cs-height);
}
fprintf(stderr, picture: %p\n,  cs-picture);
}

before the call to XGetImage? And try to reproduce the error.

/Viktor

Re: FVWM: fvwm vs gnucash

[Viktor Griph]

On Mon, 3 Dec 2007, Tom Horsley wrote:


On Mon, 3 Dec 2007 17:06:16 +0100
Jindrich Makovicka [EMAIL PROTECTED] wrote:


I once wrote even simpler example, using only plain X libraries, no GTK:

http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg14479.html

I forget to include a build command in the original post. Something like

gcc -o test -O2 -L/usr/X11R6/lib -lX11 -lXpm -lXext test.c

should do the job. Could you test this code if fvwm still fails? If the
window shows up for one second, it is wrong, if it shows for 6 seconds
(all the time the program runs) it is ok.


It doesn't fail for me, the window stays up the whole time. If I
restore the sleep(1) call, then the window disappears for a second,
then comes back. Whatever is going on with GTK is apparently
somewhat different.



I remember fixing that bug. the issue with gtk windows can however be seen 
by removing the first sleep, and replacing XUnmapWindow with 
XWithdrawWindow(dpy, win, scr).


That is: it happens when a program requests to be moved to the withdrawn 
state before it has been reparented by fvwm.


/Viktor

Re: FVWM: dragging windows inside the pager

[Viktor Griph]

On Mon, 26 Nov 2007, [EMAIL PROTECTED] wrote:

It is more like it does not work, and then - now twice - I see it work 
for very brief periods of time. I am pretty sure it's not numlock - it 
is one of the first things I checked. Now the whole thing does not work 
again;


Check that you don't have any ModulePath specified in your 
configuration file. What you are experiencing might be a bug with 
FvwmPager in version 2.5.18. (You caould not move a window with the middle 
button unless you had changed page since it was last mapped.)



/Viktor

Re: FVWM: WindowListSkip broken?

[Viktor Griph]

On Fri, 26 Oct 2007, Viktor Griph wrote:


On Fri, 26 Oct 2007, Thomas Adam wrote:


On Fri, Oct 26, 2007 at 09:09:31PM +0200, Viktor Griph wrote:

Maybe the documentation is a bit unclear, and possible the name of the
option (which actualy was changed in 2.5.22) is a bit confusing. A better
name would probably be IncludeSkipList.


I don't think this is a good idea.  There are a number of modules
(FvwmPager, FvwmTaskBar, etc.) which use UseSkipList.  You would have to
change those as well, breaking the commonality which has already been
established.


It's true that modules use this keyword, but they use it the reverse meaning, 
i.e they obey the style, rather than use the option to disobey the style. 
Having thw options with the same name thet do the opposite thing can't be 
good. And it's not even consistent throughout the modules (I.e FvwmIconMan 
uses UseWinList instead of USeSkipList))


Having thought some more about this I believe that the best thing to do 
would to unify the meaning of UseSkipList to that it should obey the 
WindowListSkip style, which is default for the WindowList command, and 
change the option to have the items included to be !UseSkipList, but keep 
UseListSkip as is (deprecated). This would break compatibility with the 
change made in 2.5.23 only, and that change is very confusing the way it 
is now.


Comments?

/Viktor

Re: FVWM: WindowListSkip broken?

[Viktor Griph]

On Fri, 26 Oct 2007, Thomas Adam wrote:


On Fri, Oct 26, 2007 at 09:09:31PM +0200, Viktor Griph wrote:

Maybe the documentation is a bit unclear, and possible the name of the
option (which actualy was changed in 2.5.22) is a bit confusing. A better
name would probably be IncludeSkipList.


I don't think this is a good idea.  There are a number of modules
(FvwmPager, FvwmTaskBar, etc.) which use UseSkipList.  You would have to
change those as well, breaking the commonality which has already been
established.


It's true that modules use this keyword, but they use it the reverse 
meaning, i.e they obey the style, rather than use the option to disobey 
the style. Having thw options with the same name thet do the opposite 
thing can't be good. And it's not even consistent throughout the modules 
(I.e FvwmIconMan uses UseWinList instead of USeSkipList))


/Viktor

Re: FVWM: WindowListSkip broken?

[Viktor Griph]

On Thu, 25 Oct 2007, Ryan Daly wrote:


All:

In FVWM v2.5.23, it appears that WindowListSkip (or something related)
is broken.

I have...

Style Console  NoTitle, NoHandles, WindowListSkip



Here you state that the Colsole window shouldn't be listed by the 
WindowList command, by giving it the style WindowListSkip. From the 
documentation:

Windows with the WindowListSkip styles do not appear in
the menu that is created with the WindowList command ...



...and...

Key Tab A M WindowList Root c c NoGeometry, SortByClass, NoDeskNum, \
NoHotKeys, CurrentDesk, UseSkipList, NoCurrentDeskTitle


But here, using the option UseSkipList, you tell WindowList to include 
windows even if they are styled with WindowListSkip.



When I do Alt+Tab, I see the Console listed.


Yes, that's what you ask it to show.


Am I using incorrect options, or is there a bug somewhere?


Maybe the documentation is a bit unclear, and possible the name of the 
option (which actualy was changed in 2.5.22) is a bit confusing. A better 
name would probably be IncludeSkipList.


/Viktor

Re: FVWM: disappearing windows?

[Viktor Griph]

On Tue, 1 May 2007, Tom Horsley wrote:


Having gotten really curious about what was going on, I installed
xmon to watch the protocol messages as the windows appear and
disappear. Everything is relatively similar with no window manager
and with FVWM until a whole batch of expose events happen
in a row, then I see a PropertyNotify that refers to the WM_STATE
atom, then the window gets unmapped.

Anyone know of any funny shenanigans pygtk and/or fvwm (or the
combination) get up to?


Is it possible that the application uses EWMH to trigger a move of the 
window just as it's being mapped (Firefox 2 does that on session recovery, 
which might result in windows being moved off screen if firefox crashed on 
a different page than active when restarted.)


Have You tried to move the window back on screen using the All cammand 
from FvwmConsole?



/Viktor

Re: FVWM: Sorting option...

[Viktor Griph]

On Fri, 16 Feb 2007, [EMAIL PROTECTED] wrote:



On Fri, 9 Feb 2007, [EMAIL PROTECTED] wrote:


Is there an easy way to modify the following...

DestroyFunc DeiconifyAndRearrange
AddToFunc DeiconifyAndRearrange
 + I All (CurrentDesk, Iconic)  State 9 True
 + I All (CurrentDesk, State 9) Iconify off
 + I All (CurrentDesk, State 9) Iconify on
 + I All (CurrentDesk, State 9) State 9 False


...so that when the icons are turned back on, they're done so in a sorted
fashion?



That depends on your definition of sorted. You may use the UseStack option
to the All command to have them iconified/deiconified in the stacking
order instead of the normal internal order.


I installed the latest (v2.5.21) and now have the UseStack option.  Is
there a way to have that sort alphabetically?


No, you can't use it for sorting alphabetically, only to retain the 
stacking order of windows during restacking operations. There is no way to 
sort on titles when using the All command. You would probbly have to write 
some simple module to do that.


/Viktor

Re: FVWM: Sorting option...

[Viktor Griph]

On Fri, 16 Feb 2007, Viktor Griph wrote:


On Fri, 16 Feb 2007, [EMAIL PROTECTED] wrote:



On Fri, 9 Feb 2007, [EMAIL PROTECTED] wrote:


Is there an easy way to modify the following...

DestroyFunc DeiconifyAndRearrange
AddToFunc DeiconifyAndRearrange
 + I All (CurrentDesk, Iconic)  State 9 True
 + I All (CurrentDesk, State 9) Iconify off
 + I All (CurrentDesk, State 9) Iconify on
 + I All (CurrentDesk, State 9) State 9 False


...so that when the icons are turned back on, they're done so in a sorted
fashion?



That depends on your definition of sorted. You may use the UseStack option
to the All command to have them iconified/deiconified in the stacking
order instead of the normal internal order.


I installed the latest (v2.5.21) and now have the UseStack option.  Is
there a way to have that sort alphabetically?


No, you can't use it for sorting alphabetically, only to retain the stacking 
order of windows during restacking operations. There is no way to sort on 
titles when using the All command. You would probbly have to write some 
simple module to do that.


/Viktor



I had some time to kill this evening, and put something together, mostly 
as a proof of concept. It's based on FvwmWindowMenu, and sorts in 
alphabetic order, no configuraton possible.


/Viktor

FvwmSort.in.gz
Description: GNU Zip compressed data

Re: FVWM: Sorting option...

[Viktor Griph]

On Fri, 9 Feb 2007, [EMAIL PROTECTED] wrote:


Is there an easy way to modify the following...

DestroyFunc DeiconifyAndRearrange
AddToFunc DeiconifyAndRearrange
 + I All (CurrentDesk, Iconic)  State 9 True
 + I All (CurrentDesk, State 9) Iconify off
 + I All (CurrentDesk, State 9) Iconify on
 + I All (CurrentDesk, State 9) State 9 False


...so that when the icons are turned back on, they're done so in a sorted
fashion?



That depends on your definition of sorted. You may use the UseStack option 
to the All command to have them iconified/deiconified in the stacking 
order instead of the normal internal order.


/Viktor

Re: FVWM: FvwmWindowMenu 2.5.21

[Viktor Griph]

On Wed, 24 Jan 2007, Elliot Sowadsky wrote:


 Hi list!

 I've upgraded to the newest unstable version today and since then I
 can't fire up FvwmWindowMenu module again. The relevant parts from
 .xsession-errors and .fvwm2rc are:

Use the Makefile from 2.5.20.
For some reason the .21 Makefile.in is old.



It is an issue with different autoconf versions being used to make the 
two builds. I'll look into it to find a solution that works with both 
autoconf  2.60 and autoconf = 2.60.


/Viktor

Re: FVWM: Is there a fix for the MiniButton staying in bug?

[Viktor Griph]

On Tue, 7 Nov 2006, [EMAIL PROTECTED] wrote:


I remember reading about this a long time ago but I never got around
to looking any harder.  Now that I'm using Linux/FVWM even more of the
time it would be nice to fix the problem.

The MinuButtons buttons don't pop out again after use, is there a
fix to make them do so?



I'm not sure exactly what 'bug' you are referring to here. If it is 
buttons staying pushed down when using the FvwmButtons module I urde you 
to search for and read about hangon to the Exec command when used in 
actions. It might be that you incorrectly use hangons.


/Viktor

Re: CVS domivogt: * Fixed the TitleWarp menu style.

[Viktor Griph]

On Wed, 25 Oct 2006, Tavis Ormandy wrote:


On Wed, Oct 25, 2006 at 10:34:08PM +0200, Dominik Vogt wrote:

Hello, I really liked this behaviour, is it possible to re-enable it as
an option? Ever since this was introduced I've been launching the wrong
applications :)


What's the problem?



The pointer used to warp to the first entry, but now it it doesnt move.
It's not a problem, I just preferred the old behaviour! I'm having to
re-learn my menu-using habits :)

Thanks, Tavis.


You can add the special option WarpTitle to the menu commands you want to 
warp to the title.


/Viktor

Re: FVWM: XMMS_Playlist is always StickyPage and StickyDesk

[Viktor Griph]

On Mon, 25 Sep 2006, Michelle Konzack wrote:


Am 2006-09-25 16:06:12, schrieb Viktor Griph:


Not having used XMMS, this is just a wild guess, but you might try to
style it with EWMHIgnoreWindowType.


Before I tell you, that this option is not in my Fvwm2 manpage,
I have tried it.  -  No change!



The option was added in fvwm 2.5.15 and is in the manpager. If you are 
using a version prior to 2.5.15 I suggest that you upgrade. You may 
however test to see if the style EWMHIgnoreWindowType would help in the 
particular way. Just do the following test:


1) Does Stick off make the window bahave as you want?
2) If so, does WindowStyle Slippery make the window bad again?

If you answered yes to both questions you'll want the 
EWMHIgnoreWindowType style for that window. If not, then something else is 
wrong with the application.


/Viktor

Re: FVWM: XMMS_Playlist is always StickyPage and StickyDesk

[Viktor Griph]

On Mon, 25 Sep 2006, Thomas Adam wrote:


On Mon, 25 Sep 2006 13:22:13 +0200
Michelle Konzack [EMAIL PROTECTED] wrote:


Hello,

I have never used StickyPage and StickyDesk but since I have upgraded
from Debian Woody to Sarge my XMMS_Playlist is always StickyPage and
StickyDesk.

XMMS_Player and XMMS_Equalizer are normal and stay on the Page where
I have started it.

I was thinking, this is a change from 2.5.8 to 2.5.12/17 but it can
not be, since my Devel-Workstation with a Woody-chroot is working
fine with the same fvwm configuration (it is on a NFS-Share)

Any suggestions?

Is this posible a Bug in fvwm?


No, anything to do with XMMS is almsot _always_ a bug in XMMS, since
that doesn't like to obey anything any $WINDOW_MANAGER (including FVWM)
might ask it to do.  I suggest you ask on the XMMS mailing-list.   Note
that as a tip to you, you can configure XMMS to at least obey some of
what the window manager says -- it's in its preferences somewhere.



Not having used XMMS, this is just a wild guess, but you might try to 
style it with EWMHIgnoreWindowType.


/Viktor

Re: FVWM: avoid switching desktops?

[Viktor Griph]

On Mon, 18 Sep 2006, Ralf Fassel wrote:


* Thomas Adam
|  Look att UrgencyFunc in the manpage. It might be that firefox
|  (incorrectly) use the urgency hint when a new tab is opened.  In
|  that case Destroying UrgencyFunc should stop the behavior, but you
|  might want to redefine it in some other way to maybe just ignore
|  firefox.
|
| Nope, it's certainly not that.  I can't even reproduce this, and I
| have the same version of Firefox as listed.  The only thing I can
| think of is if something like FvwmEvent (perhaps listening on
| 'visible_name') is somehow causing it.

It's EWMHActivateWindowFunc.



That was my second guess ;-)


The default seems to be in fvwm/ConfigFvwmDefaults:

   # Needed by the ewmh support
   AddToFunc EWMHActivateWindowFunc
   + I Iconify off
   + I Focus
   + I Raise

Victors message has set me up the right path to check with the
sources, and in the default configuration files I found this function
and just removed it: no more switching the desktop when firefox gets
called.
I'll try w/o EWMHActivateWindowFunc and see what else breaks :-)

Q: how would I write something like
 if application != firefox then
   ... original code
 endif
in EWMHActivateWindowFunc?

I guess it would be something along the lines of
  Current (Firefox) Break
but I don't want the current window, but the one which initiated the
call.



You will want the ThisWindow function inplace of Current.

/Viktor

Re: FVWM: install on OS X?

[Viktor Griph]

On Mon, 18 Sep 2006, Victor Eijkhout wrote:

As far as I can tell, fink only gives me 2.14.something, and I want to try 
2.15. So I download the source. I'm on 10.4.7.


Configure largely succeeds (can't find readline and other minor stuff).
Make runs for a while with only a large number of warnings like this:
fvwm.c: In function 'LoadDefaultLeftButton':
fvwm.c:838: warning: pointer targets in assignment differ in signedness
fvwm.c:839: warning: pointer targets in assignment differ in signedness
fvwm.c:840: warning: pointer targets in assignment differ in signedness
fvwm.c:841: warning: pointer targets in assignment differ in signedness
fvwm.c:842: warning: pointer targets in assignment differ in signedness

It bombs on this:

if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../..   -I/usr/X11R6/include 
-Wall -Wno-implicit-int -g -O2 -MT getline.o -MD -MP -MF .deps/getline.Tpo 
-c -o getline.o getline.c; \
then mv -f .deps/getline.Tpo .deps/getline.Po; else rm -f 
.deps/getline.Tpo; exit 1; fi

getline.c: In function 'get_line':
getline.c:67: warning: implicit declaration of function 'read_history_range'
getline.c:115: warning: implicit declaration of function 'append_history'
getline.c:116: warning: implicit declaration of function 
'history_truncate_file'
gcc  -Wall -Wno-implicit-int -g -O2   -o FvwmConsoleC  FvwmConsoleC.o 
getline.o -L../../libs -lfvwm -lreadline -ltermcap

/usr/bin/ld: Undefined symbols:
_append_history
_history_truncate_file
_read_history_range
collect2: ld returned 1 exit status
make[3]: *** [FvwmConsoleC] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Anyone any idea? I was not able to find anything about OS X installation in 
the FAQ or through searching the mailing lists.




The warnings look as if they are coming from gcc4. It's type checker is 
very aggressive.
The errors are problems linking to readline. Since configure doesn't find 
it they should really not be called. Try to explicit disable readline with 
configure and see if the errors go away.


/Viktor

Re: FVWM: end_WindowList

[Viktor Griph]

On Tue, 12 Sep 2006, Bianchi Roberto wrote:



Hi,
I have installed fvwm 2.4.19 on a RedHat EL4 and it works fine, but with the
following problem:

When I try to obtain the list of the windows, with the sequence:

FvwmCommand -m -i1 -f $HOME/bob -S $HOME/bob
Send_WindowList


the program never print the tag end_windowlist.

What I'm doing wrong?



Nothing. FvwmCommandS doesn't relay 0-length packages (as M_END_WINDOWLIST 
and M_END_CONFIGUREINFO) to FvwmCommand. Not in 2.4.19, and not in 2.5.18 
at least.


/Viktor

todo-2.6: C.23 XForms sliderall demo

[Viktor Griph]

I've been doing some tests, and the problem is partly fixed in the current 
version. Keybindings no longer stop working as in the bug description, but 
the focused window decorations are still incorrect in the same way as 
reported.


sliderall is an unmannaged window that takes focus on EnterNotify, and 
keeps the focus until any other window takes focus, or the wm gives focus 
away to some other window. When fvwm detects an unmannaged window stealing 
focus it does not change the decoration of the focused window, and if the 
unmanaged window gives away the focus fvwm sends it back to the window 
that had focus before. With SloppyFocus, as in the case of the report the 
focus will not be taken by fvwm if the mouse enters the root window, but 
fvwm will still show the earlier focused window as focused.


What is the desired behaviour in this case?
a) defocus the window when an unmannaged window takes focus
b) always refocus the last focused window if the mouse enters the root 
window when focus is stolen by an unmanaged window?

c) something else?


/Viktor

Re: MapWindow directly after UnmapWindow

[Viktor Griph]

On Tue, 29 Aug 2006, Dominik Vogt wrote:


On Mon, Aug 28, 2006 at 08:07:31PM +0200, Viktor Griph wrote:

On Mon, 28 Aug 2006, Andreas Ehliar wrote:


I have a problem with fpga_editor as reported in bug 4062.  With some
help from #fvwm I managed to find something suspicious. fpga_editor
does an UnmapWindow request and a MapWindow request right after each
other.

An example program that does the same is located at
http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c .

The example program will show a window for 1 second and it will then
disappear if running under fvwm.

The bug seems very similar to the bug reported in this thread:
http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html




This bug is related to the handling of MapRequests in fvwm. (See
http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.)
I know  of three different ways to address it, but don't know if there is
any downside to them.



The different approches are
1) Change AddWindow to look at the trigger event for the mapped window if
the window in the execution context is gone. I think this is too late in
the line to address this.



2) Change the Handling of MapRequest to call AddWindow with the window
being mapped in the execution context. (I think this is better than 1)


I don't actually understand the problem or the suggested
solutions.  Can you explain it a bit?



The problem is that, if the program calls MapWindow before the window has 
been reparented to the root it will get a XMapRequest with window= old 
decoration parent window and window set to the client. Handle event sets 
the window of the execution context to xany.window (parent in this case) 
if the parent window is not root. When this is a destroyed decoration it 
will be passed to AddWindow in the function called from HandleMapRequest. 
the suggested fix would be to modify the context to have the window of the 
MapRequest event set to the context before calling AddWindow if the 
trigger event is a MapRequest. (I'm not entirely sure on how 
CaptureAllWindows works, but I believe this logic would be ennouh to keep 
it working correctly.)



3) Decide that Maps following Unmaps is a bad application behaviour and
have the handling of Unmap check if the window is about to remap before
deciding to destroy it.


That's wrong.  If a window is unmapped the window structure must
be destroyed.  There is no reliable way to find out if the window
is remapped or if it was destroyed and a different window got the
same id.



The idea was to check for a MapRequest of FW_W_PARENT before reparenting 
the window, while the server is grabbed, and if sush event exists not 
unparent it. The problem is only if the window is mapped again before the 
client is reparented to root.



I'm most interested in knowing if there would be any downside with
solution 3, in which case solution 2 is the one to take.




/Viktor

Re: MapWindow directly after UnmapWindow

[Viktor Griph]

On Mon, 28 Aug 2006, Andreas Ehliar wrote:


I have a problem with fpga_editor as reported in bug 4062.  With some
help from #fvwm I managed to find something suspicious. fpga_editor
does an UnmapWindow request and a MapWindow request right after each
other.

An example program that does the same is located at
http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c .

The example program will show a window for 1 second and it will then
disappear if running under fvwm.

The bug seems very similar to the bug reported in this thread:
http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html




This bug is related to the handling of MapRequests in fvwm. (See 
http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.) 
I know  of three different ways to address it, but don't know if there is 
any downside to them.


The different approches are
1) Change AddWindow to look at the trigger event for the mapped window if 
the window in the execution context is gone. I think this is too late in 
the line to address this.


2) Change the Handling of MapRequest to call AddWindow with the window 
being mapped in the execution context. (I think this is better than 1)


3) Decide that Maps following Unmaps is a bad application behaviour and 
have the handling of Unmap check if the window is about to remap before 
deciding to destroy it.


I'm most interested in knowing if there would be any downside with 
solution 3, in which case solution 2 is the one to take.


/Viktor

Re: CVS griph: * use ewmh allowed actions to track window movability

[Viktor Griph]

On Thu, 10 Aug 2006, Dominik Vogt wrote:


On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   06/08/10 04:24:48

Modified files:
.  : NEWS
modules: ChangeLog
modules/FvwmPager: FvwmPager.h x_pager.c

Log message:
* use ewmh allowed actions to track window movability in pager


Hm, I guess that works, but it ties pager actions to the
configuration of the ewmh stuff.  I have long been planning to
allow the user to disable specific ewmh features.  If a user did
that, the pager would break.



Would an option to disable allowed actions really be useful to a user? All 
it does it to tell applications what actions are possible on a window. The 
only thing I can think of that can break it is if a EWMHFixedPosition 
style was added, that makes the ewmh allowed actions differ from the fvwm 
allowed actions. In event of that allowed actions could be made part of 
the configure window package. If that's the only pitfall, then currently a 
comment in is_function_allowed warning about it would be ennough to avoid 
unintended breakage.


/Viktor

Re: CVS griph: * use ewmh allowed actions to track window movability

[Viktor Griph]

On Thu, 10 Aug 2006, Dominik Vogt wrote:


On Thu, Aug 10, 2006 at 12:58:06PM +0200, Viktor Griph wrote:

On Thu, 10 Aug 2006, Dominik Vogt wrote:


On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   06/08/10 04:24:48

Modified files:
.  : NEWS
modules: ChangeLog
modules/FvwmPager: FvwmPager.h x_pager.c

Log message:
* use ewmh allowed actions to track window movability in pager


Hm, I guess that works, but it ties pager actions to the
configuration of the ewmh stuff.  I have long been planning to
allow the user to disable specific ewmh features.  If a user did
that, the pager would break.


Would an option to disable allowed actions really be useful to a user?


I meant an option to disallow window movement via EWMH messages.
EWMH applications could be disallowed to move windows this way,
but the pager should still be allowed to.



The reason why I did the ewmh implementation in the pager was that it was 
simple, and I didn't have to mess with the configure message. I'm not yet 
comfortable with the module interface code, and don't really know the best 
way to send allowed actions. Straightforward would be to just add them to 
window_flag, but that feels wrong. Another way would be to add a struct 
with allowed actions to the package and send it after the flags part of 
the message. Both these ways should I probably be able to do. I'm not sure 
if it's possible to add some function call result directly to the 
CONFIGARGS package, and that was when I started to look at other 'easier' 
solutions. The change to the pager is minimal to move it to use flags sent 
by fvwm instead of read via ewmh once the flags are sent.


/Viktor

Extending the ways for modules to request information back

[Viktor Griph]

I've been wanting a way to have fvwm perform tests for modules and respond 
to the module for some time now. While it's possible to use SendToModule 
with an argument 6 alias, or the program name, that may lead to the reply 
being sent to more modules than the originating module. To allow this kind 
of talkback I want to have a way to send a M_STRING (or a new similar 
message) to the module in current execution context. This could be done 
with an option to SendToModule, but that would risk breaking some configs 
or modules using a name or alias matching the literal option. The other 
way would be to add a new command, only usable form modules (similar to 
Send_WindowList and Send_ConfigInfo). I think that Send_Reply is a 
suitable name.


Another similar thing that would be very useful is a Send_Rc prefix 
command with the following syntax:

Send_Rc token command

That should generate a package with the token and the return-code of 
the command along with the usual window context to the originating 
command. Another way to allow similar functionality for modules would be 
to the returncode preserved for each module, so that it's possible to send 
TestRc commands without having to define a function to do so.


What do you think? Which of these are useful, and which ways are the best.

/Viktor

Re: CVS griph: * make non-icon mode pager use fvwm command for moving

[Viktor Griph]

On Wed, 9 Aug 2006, seventh guardian wrote:


On 8/9/06, Viktor Griph [EMAIL PROTECTED] wrote:

On Wed, 9 Aug 2006, FVWM CVS wrote:
 * don't add title height and border width to coordinates on pager move

I think that this chagen is correct. I did some tests without it, and is
seems as if high-title windows would slip down the screen without it. At
least it was definately wrong for TitleAtLeft/Right styles. I #if 0:ed the
code, so someone else can look at it and see if I'm correct in that it was
incorrect before.


I've noticed another problem with my icons. They are usually on the
bottom left corner of the screen, and in the pager they are a bit
lower (partialy in the screen bellow). This may mean the coordinates
sent from fvwm are not being correctly used by the pager. This may be
part of the problem above.



My icons seems to be at the right position in the pager, altough the 
scaling makes things tricky to test. If it were possible to make a 1:1 
scale pager testing would be easy. Maybe I should look into what limits 
the pager size to a quarter of a pager and remove it for debugging 
purpose.


/Viktor

moving icons across desks with Move breaks drawing

[Viktor Griph]

With a blank config the following produces some erractic behaviour:

Style * Icon SOME_ICON

AddToFunc BreakIcon
+ I Iconify on
+ I MoveToDesk 1
+ I Move 0 0

Next BreakIcon

results in a non-updated (icon match background and can be moved as such 
with Move, and icon title blank until the icon is highlighted) icon window 
at the top left corner.


I've no idea where the error is. I don't even know the expected result of 
the above function. (Are Move ever supposed to bring a window (or it's 
icons) to the active desk?


/Viktor

Re: Tracking flag changes from modules

[Viktor Griph]

On Tue, 8 Aug 2006, seventh guardian wrote:


On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote:

On Tue, 8 Aug 2006, seventh guardian wrote:

 On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote:
  Is there any way that the module interface allows keeping track of
 changes
  to the window flags of a window? Currently FvwmPager allows moving of
  FixedPosition mini-windows, but the main window does not move. Just
  checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition
 flag
  was set after the window was added to the pager (i.e with 'WindowStyle
  FixedPosition') since the flags get outdated.
 
  I've been looking some at the module interface, but I think that no
  message exist to indicate change in window flags. Is this correct?

 Actually, the window flags are part of some message, but they should
 not be used.  Looking at a flag does not solve the problem anyway
 because the decision whether a window can be moved or not is much
 more complex (affected by a number of styles).


 What about providing modules a way to ask fvwm to move the windows
 instead of the module moving them through X calls? This way the
 sanity checks would be done in fvwm, leaving all these problems to
 the window manager. It would work the same as moving the viewport. The
 pager asks fvwm to move the viewport, it doesn't directly move all the
 windows.

 But it would require a rewrite of the pager, and some major changes to
 the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be
 a 2.6 feature?


The mechanism for asking fvwm to move a window is already there. It's just
to send the Move command. However, this does not fix the problem, since
there is no way for the pager to know if the move was successful or not.
It could move the mini window back to te original position on button
release and then send the move command and wait for a corresponding
configure-package to know the new position if the window was moved. This
however would cause windows jumping back and forth in the pager.

Some sort of meanpath would be to add a message for ignored requests and
have it have the same info as the configure window package, but that's
definately a hack. Both these 'solutions' would allow the miniature window
to move, but have them jump back on non-moveable windows. The best thing
would be to not allow movement on non-moveable windows to start in the
pager view.


Well, it could work properly. Just ask for a null move (move the
window to its current position) as soon as the user tries to move the
miniwindow. If the command was rejected fvwm issues a simple error
packet. The Pager now knows it can't move the window. If the command
wasn't rejected then the pager can send the real Move command, to move
the window to its new position.

While this could work, it probably requires a largeer rewrite of the 
pager code to allow it to wait for a response from fvwm before starting 
the move. This resoponse can come mixed with several other messages that 
has to be taken care of in the normal way.



What about adding a command to check for movement ability (CanMove or
something like this)? This way fvwm would tackle the multiple style
conflicts, and the pager needed to know nothing about the actual flags
and stuff. Also, no new packet would be required. It would work the
same way as the above solution, so the above could be simpler.


A CanMove command is not needed, and not desireable. Instead it should be 
a 'Movable' conditional, which probably is quite easy to add. There is 
still one problem, that already affects the code somewhat: The 
SendToModule command can be used to send instructions back to the module 
on a successful test. However, it can only direct the messages by name, 
which mean that they might get to multiple instances of a module. Properly 
designed messages, in combination with the module knowing which messages 
it's waiting for can solve this, but it would be nice for a way for a 
module to uniqely define itself to fvwm as a recipent in a SendToModule 
command.


/Viktor

Tracking flag changes from modules

[Viktor Griph]

Is there any way that the module interface allows keeping track of changes 
to the window flags of a window? Currently FvwmPager allows moving of 
FixedPosition mini-windows, but the main window does not move. Just 
checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag 
was set after the window was added to the pager (i.e with 'WindowStyle 
FixedPosition') since the flags get outdated.


I've been looking some at the module interface, but I think that no 
message exist to indicate change in window flags. Is this correct?


/Viktor

icon movement tracking

[Viktor Griph]

Should the flag tracking icon movement be set by MoveToPage? Currently 
it's not, which makes icons jump back to the initial page if do for 
example 'Style * IconTitle' if an icon has been moved to another page by 
MoveToPage. On a sidenote the same problem exists whenever moving icons 
with the pager, even if they are kept on the same page.


/Viktor

Re: Tracking flag changes from modules

[Viktor Griph]

On Tue, 8 Aug 2006, seventh guardian wrote:


On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote:
 Is there any way that the module interface allows keeping track of 
changes

 to the window flags of a window? Currently FvwmPager allows moving of
 FixedPosition mini-windows, but the main window does not move. Just
 checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition 
flag

 was set after the window was added to the pager (i.e with 'WindowStyle
 FixedPosition') since the flags get outdated.

 I've been looking some at the module interface, but I think that no
 message exist to indicate change in window flags. Is this correct?

Actually, the window flags are part of some message, but they should
not be used.  Looking at a flag does not solve the problem anyway
because the decision whether a window can be moved or not is much
more complex (affected by a number of styles).



What about providing modules a way to ask fvwm to move the windows
instead of the module moving them through X calls? This way the
sanity checks would be done in fvwm, leaving all these problems to
the window manager. It would work the same as moving the viewport. The
pager asks fvwm to move the viewport, it doesn't directly move all the
windows.

But it would require a rewrite of the pager, and some major changes to
the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be
a 2.6 feature?



The mechanism for asking fvwm to move a window is already there. It's just 
to send the Move command. However, this does not fix the problem, since 
there is no way for the pager to know if the move was successful or not. 
It could move the mini window back to te original position on button 
release and then send the move command and wait for a corresponding 
configure-package to know the new position if the window was moved. This 
however would cause windows jumping back and forth in the pager.


Some sort of meanpath would be to add a message for ignored requests and 
have it have the same info as the configure window package, but that's 
definately a hack. Both these 'solutions' would allow the miniature window 
to move, but have them jump back on non-moveable windows. The best thing 
would be to not allow movement on non-moveable windows to start in the 
pager view.


/Viktor

Re: Documentation for module developers

[Viktor Griph]

On Sun, 30 Jul 2006, Thomas Adam wrote:


On Mon, 31 Jul 2006 00:19:51 +0400
Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:


On Sun, Jul 30, 2006 at 06:02:51PM +0100, Thomas Adam wrote:

On Sun, 30 Jul 2006 14:40:50 +0400
Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:


  Hi,

Are http://www.fvwm.org/documentation/dev_modules.php is the only module
related documentation available? BTW, I found an error on this page: in
section 'Colorset support' InitPictureCMap() should be PictureInitCMap()
instead (this function  was renamed on 2002-04-22 according to main
ChangeLog).


Other than that minor fix, was there some specific information not listed
on that page you were after?


Yes. I want full FVWM API description. For example, FScreenInit,
FRenderInit and many other functions used in modules aren't described
there. Tutorials are also welcome. Of course I can figure out all
missing details by reading source code, but this cost time.



Currently there isn't any such documentation about those.  Do what you can
by reading the source code and sporadic comments therein where applicable.
This is all I do.  If you feel like documenting it yourself as you go, that
too would be good.  :)

-- Thomas Adam




There is '[C]Modules from scratch'[1] which gives a quick introduction to 
the module communication, but it's not using the fvwm libs.


There is however one thing in there that is worth noting, either as a bug 
in the module communication or in the documentation:


 | Basically you have to send the command NOP FINISHED STARTUP to FVWM
 | before it will start talking to your module. This isn't mentioned
 | anywhere on the module page, and is barely eluded to in the fvwm man
 | page.

/Viktor

[1] http://fvwm.lair.be/viewtopic.php?t=260

Re: Flags - is negation prefered?

[Viktor Griph]

On Mon, 17 Jul 2006, Thomas Adam wrote:


On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote:

Yes, but then the 2.5 manual should be updated. I'll start doing
that..


Don't be too hasty.  :)  Things like:

Style foo !Icon

Won't work.



Another thing to remember is that all options that still are supported, 
but not preferred should still be documented, or someone searching for 
what an option in a config file does might not find it.


/Viktor

Re: Flags - is negation prefered?

[Viktor Griph]

On Mon, 17 Jul 2006, Dominik Vogt wrote:


On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote:

Hi.

I have a question. Is the flag vs. !flag syntax the prefered one? I
ask this because even though some styles only have the !(stylename)
counterpart, some are still documented as (stylename)Off. So if the
flag negation is prefered to the (stylename) vs. (stylename)Off, or
the other way round, then it should be explicit in the man page. This
is the only way we can avoid compatibility confusion in a future
version.

My opinion is that the flag vs. !flag style is simpler to parse, and
it should be prefered. the (stylename)Off code should be maintained
for compatibility's sake, but marked as deprecated.


The ! negation style is preferred.  I coded it for exactly the
reasons you describe.  There are so many different typed of on/off
syntax.



Should the old style negation options be deprecated in the code (give 
warnings) before 2.6?


/Viktor

Re: CVS griph: * add variable filters

[Viktor Griph]

On Sun, 16 Jul 2006, Dominik Vogt wrote:


On Fri, Jul 14, 2006 at 05:30:03PM -0500, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   06/07/14 17:30:03

Modified files:
.  : ChangeLog NEWS
fvwm   : expand.c fvwm.1.in
libs   : Strings.c Strings.h

Log message:
* add variable filters
* make backslash escape character within $[...] expressions


If you write such patches that are monitored by several developers
it would be nice to explain what you are doing and how.  We have
to be very careful with big changes in the parsing code because it
has the potential to break everything.  Personally I want to
proofread such changes.


I'll do so in the future. The changes are quite isolated. Most additions 
are done in new functions. Appart from that the start of the filters are 
registered in the parsing of the variable name and sent to the expansion 
functions. They have some code added for when the filters are non-NULL. 
With filters==NULL the same code as before is executed. I can understand 
that you want to proofread the changes.




The syntax I quoted that Mikhael suggested has not really been
thought about a lot.  It's just an ad-hoc idea.  Now that you
implemented it, I think it has several general issues:

The best way to see limitations in a (simple) system is to implement it 
and play around with it. It's not mush work put down into the 
implementaion. I mainly needed the single and quote filter myself when
the ranged positional parameters changed expansion and thought I'd give 
it a try.



* There is currently no way to quote a literal string, which is a
  very important feature.  It would allow users to write monsters
  like this more easily:

+ I PipeRead 'cd $HOME/.fvwm/palettes; /bin/ls *.pal | sed -e 
\s:\\(.*\\)\\(\\.pal\\):+ \\1 Function SetPalette \\1\\2:\'

I see your point. I aslo thought about the gettext expansion, and possible 
problems of changing the ':' meaning.



* The syntax is too verbose.  The strings you have to write eat
  up too much space.  Also, the name filters is misleading.

In almost all syntax in fvwm is verbose. Why should this be an exception? 
Except for the fact that the way it is done now makes the filters to be 
parsed several times. I'm sure it's possible to optimize that by 
preparsing the filter-string and invent some easier to deal with 
representation. However I didn't want to try to do that since I thought 
that the patch might have to be reverted anyway.



  I suggest to follow zsh's example:

$[(flags)name]

  Where name is the parameter name itself and flags describes
  the modifications to apply to the expansion process.



Thinking of this compared to the one currently implemented I must say that 
this has several advances:
* it will most likely not break anything existing (at least I've never 
seen an environment variable containing braces.

* it's easier to preparse the flags since the order doesn't matter.



  Flags:

qstyle[n] (quote)
  Quote the string n times using the given style.
  style can be one of

   q   quote normally for use as a token
   mi  quote for use as a menu item label
   mt  quote for use as a menu title

l (literal)
  Quote a literal string, i.e. everything up to the closing
  brace.

r0 (recursive expansion off, default)
r1 (recursive expansion on)
  Enable or disable recursive expansion ($[$[X]])

  Note:  If the flags l and r1 are present, recursive
  expansion takes place first, and the result is used as
  literal input for further processing - it is *not*
  interpreted as a variable name.

s[n] (split)
  Split string into individual tokens (by removing n levels
  of quotes and whitespace). n defaults to 1.

t (tokenize)
  Treat the resulting string as a single token (Useful in
  ranges).

  Examples:

With X=foo`bar`, $0=0, $1=1, ... (without the
quotes):

$[(qq)X]
  -- 'foo`bar`'

$[(s1qq)X]
  -- 'foo' 'bar'

$[(lqq2)foo`bar`]
  -- 'foo`bar`'

$[(lr1)X]
  -- foo`bar`

$[(qq)1-3]
  -- '1' '2' '3'

$[(tqq)1-3]
  -- '1 2 3'

  Maybe flags should be separated by colons to allow more and
  longer flag names like $[(literal:qq)foo bar]

Thinks that are not good in the current patch:

* I think we shouldn't have different styles of quoting filters.
  Just quote: should be enough.  This is because quoting is just
  meant to be used *internally by fvwm*.  And fvwm does not care
  wether tokens are quoted by , ', ` or \.  Fvwm could just
  choose the type of quotes that has the shortest result.

  A string quoted this way can *not* be passed to a shell for
  example.

What I did regarding filters was to try implement the ones in todo-vars 
based on what was given there.



* It should be possible to add multiple levels of quotes in a
  single filter (usefull in 

Re: FVWM crashes with $[0]

[Viktor Griph]

On Fri, 14 Jul 2006, Scott Smedley wrote:


I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]


Is this supposed to be fixed? FVWM still crashes on my system
when I type Echo $[0] in FvwmConsole.

I am using current version of CVS.

Scott.



There is something wrong with __eae_parse_range. I'm not that good on 
sscanf, but I think that it will match %u-%n even for 0 and return a 
good number, meaning that n will have a random value. Then it might 
segfaut later on *input == 0 since input += n


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Fri, 14 Jul 2006, Dominik Vogt wrote:


On Fri, Jul 14, 2006 at 09:07:21AM +0200, Viktor Griph wrote:

On Fri, 14 Jul 2006, Scott Smedley wrote:

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]


Is this supposed to be fixed? FVWM still crashes on my system
when I type Echo $[0] in FvwmConsole.

I am using current version of CVS.


There is something wrong with __eae_parse_range. I'm not that good on
sscanf, but I think that it will match %u-%n even for 0 and return a
good number, meaning that n will have a random value.


Yes, one big problem is that %n may or may not increase the return
code by one, so if

 rc = scanf(..., %u-%n, ...);

returns one, this can mean is parsed just the integer and stopped,
or it parsed the integer, found a '-' and assigned the %n too.

Fixed.



sscanf seems to not be very restrictive when it comes to unsigned 
integers. It seems as if it accepts signed integers as well. At least 
$[-1] hang fvwm now.


/Viktor

Re: more on expansion behaviour

[Viktor Griph]

On Fri, 14 Jul 2006, Scott Smedley wrote:


Hi all,

Help please.

addtofunc fn
+ i echo executing $[0-]
+ i $[0-]
fn echo hello

How come fn doesn't print out hello?



After some time debuging it turns out to be problem with the parse 
function usage. I'm not sure the best way to fix it, but this is what 
happens:


in functions.c the functon to execute is peeked from the action string. 
It's then passed to expand_vars. Before expand_args_extended no 
parsefunctions were used in expand_vars, so everything was good. With 
expand_args_extended using PeekToken the input to expand_vars gets 
overwritten and the expansion fails.


expand_vars is only called from functions.c, once with a peeked token and 
once on the entire action string. Looking at the code I'm not even sure 
why it can't do things the other way around. (First expand and then peek 
the function name.) In fact the curent behaviour seems wrong as per this 
example:

AddToFunc TestFunc
+ I Echo Hello hello
+ I $*
TestFunc Echo Hello hello

This will print hello and produce an error. If expansion was made before 
the function token is peeked it will produce the exact same result.


/Viktor

Re: CVS domivogt: * Removed ifdefs from fifos.c.

[Viktor Griph]

On Wed, 12 Jul 2006, FVWM CVS wrote:


Log message:
* Removed ifdefs from fifos.c.
* Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat
  issues.




Is it really neccessary to defene everything with FVWM_ as a prefix? If 
it's not already defined, why not define it using the expected name?


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Scott Smedley wrote:


Hi all,

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]

I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:

if (input[m] == ']')

Then I get a SEGV because this is an illegal memory access.

Can anyone else confirm this problem?



I can'tr make it crash with just Echo $[0]. However the following make it 
crash 100%:


AddToFunc TestFunc I Echo $[0]
TestFunc $[0]

I'll investigate that further after breakfast to see if it's the same 
crash, or a different one.


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Viktor Griph wrote:


On Thu, 13 Jul 2006, Scott Smedley wrote:


Hi all,

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]

I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:

if (input[m] == ']')

Then I get a SEGV because this is an illegal memory access.

Can anyone else confirm this problem?



I can'tr make it crash with just Echo $[0]. However the following make it 
crash 100%:


AddToFunc TestFunc I Echo $[0]
TestFunc $[0]

I'll investigate that further after breakfast to see if it's the same crash, 
or a different one.


/Viktor



Can you see if the fix I comitted for the above fixes your error as well? 
It's possible that it's the same error if your strlen doesn't segfault on 
NULL-input (and you did call Echo $[0] from within a funcion called by a 
trailing space or something else to form an argument string with no 
tokens).


/Viktor

Re: CVS domivogt: * Removed ifdefs from fifos.c.

[Viktor Griph]

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 09:16:24AM +0200, Viktor Griph wrote:

On Wed, 12 Jul 2006, FVWM CVS wrote:


Log message:
* Removed ifdefs from fifos.c.
* Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat
 issues.




Is it really neccessary to defene everything with FVWM_ as a prefix? If
it's not already defined, why not define it using the expected name?


I use the fvwm prefix to document that we modified its meaning.
If we had just

 #define O_NOFOLLOW 0

someone might rely ona that flag although it's just a dummy to
make the compiler happy.



Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just 
O_NOFOLLOW in there as well. It was all the stat-wrappers that I was 
concerned about. The code use many of them unwrapped already, so if there 
is a chance that some of them might not be defined it would be better to 
provide them, with the assumed values you did, under the name expected by 
the programmer.


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Scott Smedley wrote:


Hi all,

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]

I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:

if (input[m] == ']')

Then I get a SEGV because this is an illegal memory access.

Can anyone else confirm this problem?



I can'tr make it crash with just Echo $[0]. However the following make it
crash 100%:

AddToFunc TestFunc I Echo $[0]
TestFunc $[0]

I'll investigate that further after breakfast to see if it's the same
crash, or a different one.


There are several bugs/crashes in expand_args_extended():

1) It does not check the range of the positional parameters.  It
   happily parses and uses for example $[999].  I didn't try it,
   but I guess it causes random memory access.

I believe that SkipNTokens just stops when there is no more to consume. 
Then $[999] will be empty if there are less then 1000 words in the string.




2) In the if (is_single_arg) it uses the token returned by
   PeekToken as the base for further parsing functions.  This is
   strictly forbidden because PeekToken returns a pointer to a
   static buffer.

Not true. With 'is_single_arg' true 'upper' will always be -1, so no other 
parse-function will be called on the string.



3) As I said in an earlier message, PeekToken never returns an
   empty string.  Calling PeekToken(, ...) returns a NULL
   pointer which the code accessed later.



This was the error I fixed already.

/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Viktor Griph wrote:


On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Scott Smedley wrote:


Hi all,

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]

I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:

if (input[m] == ']')

Then I get a SEGV because this is an illegal memory access.

Can anyone else confirm this problem?



I can'tr make it crash with just Echo $[0]. However the following make it
crash 100%:

AddToFunc TestFunc I Echo $[0]
TestFunc $[0]

I'll investigate that further after breakfast to see if it's the same
crash, or a different one.


There are several bugs/crashes in expand_args_extended():

1) It does not check the range of the positional parameters.  It
   happily parses and uses for example $[999].  I didn't try it,
   but I guess it causes random memory access.

I believe that SkipNTokens just stops when there is no more to consume. Then 
$[999] will be empty if there are less then 1000 words in the string.




Checking the code again I see no reason to have a limit  to only work with 
10 arguments. The main purpose of expand_args_extended was to allow access 
to parameters beyond the 10th. That's why it's using parse-functions to 
find the selected parameters rather than looking them up in the arguments 
array that $0-$9 expansion does.





2) In the if (is_single_arg) it uses the token returned by
   PeekToken as the base for further parsing functions.  This is
   strictly forbidden because PeekToken returns a pointer to a
   static buffer.

Not true. With 'is_single_arg' true 'upper' will always be -1, so no other 
parse-function will be called on the string.




I think that, for readability some change is needed, but I don't think 
it's neccessary to use GetNextToken instead of PeekToken. It just adds an 
extra free in an extra if. For readability it would probably be nicer to 
add !is_single_arg to the if (upper = 0)


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote:

On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Dominik Vogt wrote:

[snip]

Not true. With 'is_single_arg' true 'upper' will always be -1, so no other
parse-function will be called on the string.


Then, why do you not write

if (is_single_arg)
  ...
*else* if (upper = 0)
  ...

?



Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].


--

Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:

* A range of args like $[0-1] is expanded to the original text,
 not the unquoted form.

  I.e. in 'foo a0  a1  a2'

 $[0-1] is expanded to 'a0  a1' but should be expanded to
 'a0 a1'.


Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.


Yes, I really want that.  Fvwm has always worked this way and
changing this would break many functions.  Mikhael suggested
several times to add some notion of expansion modifies to instruct
fvwm to quote the result, i.e. $[quote:0] to get '0' instead of
'0'.  I think this is the right approach.

The fact that $* works differently just means that it's broken.

[snip]


* According to the man page, things like $[*] or $[3-] are
 removed from the command line if there are no arguments.  This
 is wrong as it prevents that the string '$[*]' is passed to
 another command.  These variable should not be treated
 specially.  Currently, not even $[0] is identical to $0.



The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?


Heck, you're right.  I still don't it this is good:

  destroyfunc bar
  addtofunc foo
  + i addtofunc bar i $0

If you now invoke

  foo echo $1
  bar 0 1 2

It should print '1', but currently it prints an empty string.
It's just the way the other $-Variables (like $w) work:  If it can
not be expanded, keep the Variable reference.

Anyway, it's too risky to change now.


* The code is written too complicated too understand easily (as
 you can see from the fact that I only understood about 50% of
 it), and it's nested too deep.


The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.


Look at the code I've committed.  It uses a subfunction to parse
the parameter range and reduces the number of nesting levels by
two.  It also properly unquotes argument ranges.  Note that I did
not test anything.


I don't have much time now, but two random test results:

 Echo $[-0]

should print the first argument but prints $[-0]



This construct is not in the manpage (and thus never implemented (at 
lest not in my version. I've not checked the  newcode yet.))



 Echo $[1-0]

(or any other invalid range) should be just copied, but it is
replaced with an empty string.



This worked with my version. The function should return -1 when it should 
be copied and 0 when it should be replaced with an empty string.



/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Dominik Vogt wrote:

[snip]

Not true. With 'is_single_arg' true 'upper' will always be -1, so no other
parse-function will be called on the string.


Then, why do you not write

if (is_single_arg)
  ...
*else* if (upper = 0)
  ...

?



Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].


--

Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:

* A range of args like $[0-1] is expanded to the original text,
 not the unquoted form.

  I.e. in 'foo a0  a1  a2'

 $[0-1] is expanded to 'a0  a1' but should be expanded to
 'a0 a1'.


Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.


Yes, I really want that.  Fvwm has always worked this way and
changing this would break many functions.  Mikhael suggested
several times to add some notion of expansion modifies to instruct
fvwm to quote the result, i.e. $[quote:0] to get '0' instead of
'0'.  I think this is the right approach.

The fact that $* works differently just means that it's broken.



$* has always worked they way it works as well. I for sure have some 
functions that rely on passing arguments to other functions, so changing 
the behaviour of $* would break my config. Also reading the todo-vars file 
it states that $[number] should be unquoted for backwardscompability. 
The $[range] can be treated differently as that is a new feature. I see 
use for both the 'raw' style and the unquoted style, but as I understand 
the todo it really should be single-quoted as they are niether $[number] 
not $[range], which are the only exceptions to that rule listed.


Regarding the dequoting of the positional parameters I belive the best 
thing would be to make a function to unquote an entire string. I'm not 
sure how optimized it is to peek every token just to get rid of the 
quotings. Also the most flexible code for the argument expansion would be 
keeping the raw string as long as possible, and then dequote it and 
possible requote it depending on filter-selection.


Maybe the best thing is to remove the $[range] alltogether until the 
filter-system is ready to not add another exception to how things work.

I'd really like to hear Mikhael's opinion on this.



[snip]


* According to the man page, things like $[*] or $[3-] are
 removed from the command line if there are no arguments.  This
 is wrong as it prevents that the string '$[*]' is passed to
 another command.  These variable should not be treated
 specially.  Currently, not even $[0] is identical to $0.



The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?


Heck, you're right.  I still don't it this is good:

 destroyfunc bar
 addtofunc foo
 + i addtofunc bar i $0

If you now invoke

 foo echo $1
 bar 0 1 2

It should print '1', but currently it prints an empty string.
It's just the way the other $-Variables (like $w) work:  If it can
not be expanded, keep the Variable reference.

Anyway, it's too risky to change now.


* The code is written too complicated too understand easily (as
 you can see from the fact that I only understood about 50% of
 it), and it's nested too deep.


The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.


Look at the code I've committed.  It uses a subfunction to parse
the parameter range and reduces the number of nesting levels by
two.  It also properly unquotes argument ranges.  Note that I did
not test anything.



I'll take a look at the code more later. Currenlty I've only looked at the 
diff to get some idea of what you are doing.


/Viktor

Re: FVWM crashes with $[0]

[Viktor Griph]

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 05:00:27PM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Viktor Griph wrote:


On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Dominik Vogt wrote:


On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:

On Thu, 13 Jul 2006, Scott Smedley wrote:


Hi all,

I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:

Echo $[0]

I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:

if (input[m] == ']')

Then I get a SEGV because this is an illegal memory access.

Can anyone else confirm this problem?



I can'tr make it crash with just Echo $[0]. However the following make
it
crash 100%:

AddToFunc TestFunc I Echo $[0]
TestFunc $[0]

I'll investigate that further after breakfast to see if it's the same
crash, or a different one.


There are several bugs/crashes in expand_args_extended():

1) It does not check the range of the positional parameters.  It
 happily parses and uses for example $[999].  I didn't try it,
 but I guess it causes random memory access.


I believe that SkipNTokens just stops when there is no more to consume.
Then $[999] will be empty if there are less then 1000 words in the
string.



2) In the if (is_single_arg) it uses the token returned by
 PeekToken as the base for further parsing functions.  This is
 strictly forbidden because PeekToken returns a pointer to a
 static buffer.


Not true. With 'is_single_arg' true 'upper' will always be -1, so no
other
parse-function will be called on the string.


Then, why do you not write

if (is_single_arg)
  ...
*else* if (upper = 0)
  ...

?



Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].


--

Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:

* A range of args like $[0-1] is expanded to the original text,
 not the unquoted form.

  I.e. in 'foo a0  a1  a2'

 $[0-1] is expanded to 'a0  a1' but should be expanded to
 'a0 a1'.


Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.



* Currently, $* is broken too as it does not remove quoting but
 just copies the input string.


See above.



* According to the man page, things like $[*] or $[3-] are
 removed from the command line if there are no arguments.  This
 is wrong as it prevents that the string '$[*]' is passed to
 another command.  These variable should not be treated
 specially.  Currently, not even $[0] is identical to $0.



The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?


* The code is written too complicated too understand easily (as
 you can see from the fact that I only understood about 50% of
 it), and it's nested too deep.



The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.



Waiting for a responce I've done some minor cleanup as suggested, and
removed the range-checks again. One thing that still looks weird to me,
(that wrote it) is the

argument_string = SkipSpaces(
SkipNTokens(argument_string, lower), NULL, 0);


The token parser stops after the first non-token character, e.g. a
space.  In your old code, SkipSpaces was necessary, in the patch I
just committed it isn't.


args_end = SkipNTokens(argument_string, upper - lower + 1);
while (argument_string  args_end  isspace(*(args_end - 1)))
{
args_end--;
}

which seems to assume that SkipNTokens can end with any number of spaces
before or after the next token in the list. Is that so? Or is either
SkipSpaces or the while-loop unneeded?


If the tokens are copied dequoted, trailing spaces have to be
removed.  If $[*] does not dequote, it should keep trailing
whitespace.



The only time it removed the trailing whitespace was in ranges with closed 
upper end. It kept them for $[*] and $[2-] etc.


/Viktor

using lstat

[Viktor Griph]

Is there some define to check for systems that have lstat?

/Viktor

Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug

[Viktor Griph]

On Tue, 11 Jul 2006, Dominik Vogt wrote:


On Tue, Jul 11, 2006 at 10:16:09AM -0500, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   06/07/11 10:16:09

Modified files:
.  : ChangeLog NEWS configure.ac
modules: ChangeLog
modules/FvwmCommand: FvwmCommand.1.in FvwmCommand.c
 FvwmCommandS.c fifos.c

Log message:
fix tempfile vulnerabilities in FvwmCommand (bug #2791).


Can you explain what you actually did, please?



Sure.
First: When deciding on the default path the three files that are to be 
used are tested with lstat (or stat if lstat is unavalable) to have the 
same owner as the process owner, not have nore than one hard link and not 
be a directory nor a symbolic link. If any of the tests fail the path will 
be redirected to $FVWM_USERDIR instead of /var/tmp to avoid attacks 
blocking the module. If some tests are impossible to do they are 
concidered OK.

Second: All open() calls use O_NOFOLLOW if that flag is defined.

I believe this should be ennough, but if one are really paranoid one could 
add checks of the opened files in FvwmCommand.c to verify that they are 
fifos with correect permissions.


/Viktor

Re: Periodic command

[Viktor Griph]

On Wed, 5 Jul 2006, Scott Smedley wrote:


Hi Dominik,


Can you have multiple peridic commands or just one?


Multiple.


I suggest to replace the command Periodic with some option to the Schedule
command


The current specification for Schedule is:

Schedule delay_ms [command_id] command

So, would something like the following do?

Schedule delay_ms [command_id] [Periodic] command

Perhaps someone has a better suggestion?



I think the above is good. The only problem with it is that if someone has 
a function named Periodic and use to execute that with Schedulte the above 
will break that config. One way to avoid that, and also give room for more 
possible options to Schedule in the future, is to put options before the 
delay. That way any string before the delay number could be read as an 
option. So


Schedule [Periodic] delay_ms [command_id] command

would be a possible easier to parse syntax.

/Viktor

Re: FVWM: fvwm and gettext ;-)

[Viktor Griph]

On Sun, 18 Jun 2006, Michelle Konzack wrote:


Hello *,

my girlfriend and me have translated my whole Workstation into de, fr,
tr, ar and fa but it was a nightmare, because 'gettext' was not able to
find the $[gt.XXX] strings...

Since I have to translate several Desktops (around 60) I want to know,
whether someone has written a tool which find the $[gt.XXX] strings and
create the fvwm.pot file

OK, I have done it allready with a BASH script, but it is tooo slow
and the functions are limited...

Only my Workstation has already 280 Strings... (my Develstation
is a nightmare, even if I have allready all i18n.)

if someone is interested in my BSH-Script please let me know.
(I have currently no possibility for uploads.

Short desription:

1)  Message strings must be

   $[gt.Some text to translate]

   (see desription 'man fvwm2' = LocalePath)

2)  Output is always fvwm.pot in the director where it was started
   (overrides previously versions)

3)  To read ONE file use

   tdgettext-fvwm -r -i file

4)  To read all files in the current directory

   tdgettext-fvwm -r -i '*'

5)  Now rename it from fvwm.pot to fvwm.po and translate it

6)  With the command tdgettext-fvwm -c' it will compile it to fvwm.mo

7)  Copy the file to $HOME/locale/CC/LC_MESSAGES/fvwm.mo where CC is
   the country code of your translated fvwm.po

8)  Put in your ~/.fvwm/config following line:

   LocalePath $HOME/locale/:+

9)  Restart and enjoy an internationalized and localized fvwm DeskTop.

Note 1: I like to see some people which test this script, because
   I want to improve it, but first it must work perfectly.

Note 2: Currently I am rereading the WHOLE bunch of Fvwm manpages
   since I have forgotten many options (and some are added
   since 2.4) and the manpages are better then the newspapers...

   Hey, I have found many spelling errors. Where can I report them?



You may report errors in the manpage to the fvwm-workers list. The 
preferred method is that you send in a patch against the cvs version 
where you fix the errors. Also note that many manpage errors have been 
fixed in cvs since 2.5.16 was released, so I recommend you to get the cvs 
version (or a recent snapshot) of the manpage instead of the 2.5.16 
version to avoid double work in finding and fixing the errors.


/Viktor

Matlab figure window refusing to move

[Viktor Griph]

I believe this to be a bug in matlab, but I report it here as someone 
might know of a workaround for i.


It seems as if an obscured matlab figure will refuse to be moved, unless 
some not yet completely known conditions are met on the final 
destionation. It just bounce back to the original position. In some cases 
when moving it from obscured by one window to obscured by another window 
it seems to sometimes generate some race conditing in moving between the 
both positions.


The following two files contain output from xev tied to a matlab figure:
http://www.dd.chalmers.se/~griph/matlab-refuse-move.txt
http://www.dd.chalmers.se/~griph/matlab-race.txt

Anyone got any idea of what's behind this and if tere is any way to make 
fvwm work around the problem?


/Viktor

Re: What are the hide windows in frame.c?

[Viktor Griph]

On Fri, 5 May 2006, Dominik Vogt wrote:


On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote:

When are the hide windows useful in frame.c? The call to
frame_reparent_hide_windows in frame_create_move_resize_args casue X to
generate extra VisibilityNotify events to clients during capture and
redecoration (bug #3977).


The hide windows are emtpy windows (with a None background
pixmap).  I introduced them to reduce flickering of the window
decorations when a window is resized, and - more important -
shaded or unshaded.

The problem is that when you resize a window, you can tell X which
border its subwindows should stick to.  But you can not tell it
where the subwindows of subwindows should go, and it's not
possible to resize subwindows in the same operation.

Because of this, I use the hide windows to cover some parts of the
decorations, resize the window, redraw the the changed parts of
the decorations windows (using a background pixmap, not using the
foreground), then unmap the hide windows to uncover the changed
decorations.  Usually, the hide windows stay invisible because
htey have no contents and just show what was below them until they
are covered by something else.



Now I understand the need for them for resize operations.


Would it be possible to narrow down the need for
that function call to some specific case?


I don't see any way but at the expense of flickering decorations
and subwindows, especially with opaque resizing.


Am I right if I say that the hide windows do no good if it is a setup 
request and the frame size has not changed? I'm not sure how the initial 
mapping is treated, but I believe they do no good for that either. It's 
just a little harder to seed that condition from withing the function.




Actually, if applications like xdvi have a below par redraw
algorithm (i.e. they redraw whenexer they receive an Expose
event), that's the applications' problem and not the problem of
the window manager.


It's true that the application may be behaving badly, but there are 
several application that show similar flickering due to the exrtra events 
on a redecoration. if it's possible to work around the events with the 
window mannager it's a good thing to do, but not at the expense of some 
other functionality. Just for reference the thing that annoys me most 
about this is the fact that my titleless pager and xbuffy flash whenever 
I redecorate (including even disable an already disabled title bar button)



/Viktor

Re: What are the hide windows in frame.c?

[Viktor Griph]

On Tue, 9 May 2006, Viktor Griph wrote:


On Fri, 5 May 2006, Dominik Vogt wrote:


On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote:

When are the hide windows useful in frame.c? The call to
frame_reparent_hide_windows in frame_create_move_resize_args casue X to
generate extra VisibilityNotify events to clients during capture and
redecoration (bug #3977).


The hide windows are emtpy windows (with a None background
pixmap).  I introduced them to reduce flickering of the window
decorations when a window is resized, and - more important -
shaded or unshaded.

The problem is that when you resize a window, you can tell X which
border its subwindows should stick to.  But you can not tell it
where the subwindows of subwindows should go, and it's not
possible to resize subwindows in the same operation.

Because of this, I use the hide windows to cover some parts of the
decorations, resize the window, redraw the the changed parts of
the decorations windows (using a background pixmap, not using the
foreground), then unmap the hide windows to uncover the changed
decorations.  Usually, the hide windows stay invisible because
htey have no contents and just show what was below them until they
are covered by something else.



Now I understand the need for them for resize operations.


Would it be possible to narrow down the need for
that function call to some specific case?


I don't see any way but at the expense of flickering decorations
and subwindows, especially with opaque resizing.


Am I right if I say that the hide windows do no good if it is a setup request 
and the frame size has not changed? I'm not sure how the initial mapping is 
treated, but I believe they do no good for that either. It's just a little 
harder to seed that condition from withing the function.




Actually, if applications like xdvi have a below par redraw
algorithm (i.e. they redraw whenexer they receive an Expose
event), that's the applications' problem and not the problem of
the window manager.


It's true that the application may be behaving badly, but there are several 
application that show similar flickering due to the exrtra events on a 
redecoration. if it's possible to work around the events with the window 
mannager it's a good thing to do, but not at the expense of some other 
functionality. Just for reference the thing that annoys me most about this is 
the fact that my titleless pager and xbuffy flash whenever I redecorate 
(including even disable an already disabled title bar button)




I just checked it and the pager flashing is caused by some other thing, 
and probably will have to be taken care of wfrom within the pager code.



/Viktor

Re: FVWM: Problem resizing window

[Viktor Griph]

On Sat, 6 May 2006, Lukas Lipavsky wrote:


I also have to add (I found out right now). This problem only happens
if terminal is run in the window (I tried urxvt and xterm). In this
case also

ResizeInWindow 10 0
ResizeInWindow -10 0

doesn't result in same size window horizontal size. On non-terminal
windows, all work without any problem :((

I have no idea why this happen and whether/how can i eliminate/workaround it.



You want to use the style ResizeHintOverride. Terminals use hints to 
indicate that they only want to resize full lines and columns. That style 
tells fvwm to ignore those hints. Note that the style seems to require 
recapture in order to be applied to existing windows.



/Viktor

What are the hide windows in frame.c?

[Viktor Griph]

When are the hide windows useful in frame.c? The call to 
frame_reparent_hide_windows in frame_create_move_resize_args casue X to 
generate extra VisibilityNotify events to clients during capture and 
redecoration (bug #3977). Would it be possible to narrow down the need for 
that function call to some specific case?


/Viktor

Re: FVWM: Windows appearing where they were invoked?

[Viktor Griph]

On Mon, 17 Apr 2006, seventh guardian wrote:


On 4/17/06, Mikhael Goikhman [EMAIL PROTECTED] wrote:

On 17 Apr 2006 00:45:10 +0100, seventh guardian wrote:


There's a minor itch though: it takes me back to the page where it
started. Even so, it's better than before!


Then you didn't use my implementation of StartHere with SkipMapping:


Ops.. You're right.. I only corrected the matching string.. Sorry

On 4/17/06, Mikhael Goikhman [EMAIL PROTECTED] wrote:

On 17 Apr 2006 00:49:29 +0100, seventh guardian wrote:


Oh.. and another one: if the app gets executed from a terminal or from
another app, it goes to the same page as before.. not good if you have
rox-desktop or any other launching app or desklet..
Maybe if I delete the style afterwards :?


I would delete the style after 20 seconds by adding one line:


  DestroyFunc StartHere
  AddToFunc   StartHere
  + I Style $1 SkipMapping, StartsOnPage $[desk.n] $[page.nx] $[page.ny]


  + I Schedule 2 Style $1 !SkipMapping, StartsAnyWhere


  + I Exec sleep 2; $0




Thanks! That does the trick! But I would reduce the time to 5 seconds
or so.. If not, firefox popups will keep appearing on the page of the
last created window..

Once again, thanks a lot!

By the way, is this used by the majority of us or only a few? I wonder
if there could be a style for this, like Style *
PlaceOnCurrentPage..



The problem with adding sush a style is that there is no way for fvwm to 
know what page was visible when the command that generated a window was 
executed. While it sometimes would be possible using _NET_WM_PID in 
combination with WM_CLIENT_MACHINE for the local machine, there is no 
foolproof way to tell where a window originates from.


/Viktor

Re: FVWM: Windows appearing where they were invoked?

[Viktor Griph]

On Sat, 15 Apr 2006, Elliot Sowadsky wrote:


 Currently, whenever I start an application, it appears in the current
 page, and not in the page where it was invoked. I guess that is the
 default behaviour of every wm out there, but I wonder if it wouldn't
 be nicer to have the application windows appearing by default in the
 page where they were invoked.

 This way you would simply go to page X and start firefox, go to Y and
 open up a terminal, and in Z start amsn. This way you would populate
 your work area and then return to the first page where probably
 firefox is already loaded. Currently you either start an app in one
 page and wait for it to load so that you can move to another page, or
 you load them all in the same page and then move them individually.

 I believe there is no _real easy_ way to do this, or is it? If there
 isn't, would it be useful or not?

Heres how i do it.

AddToMenu Applications Applications Title
+   app StartOnCurrentDesk app appname

AddToFunc StartOnCurrentDesk
+   I PipeRead `echo Style $1 StartsOnPage $[desk.n] $[page.nx] $[page.ny]`
+   I Exec exec $0



There is no needto PipeRead that Style command.

Some applications support the -xrm flag to specify resources. In that case 
it's more efficient to do, for example for xterm:

Exec exec xterm -xrm *Page:$[desk.n] $[page.nx] $[page.ny]

/Viktor

Re: Inconsistency during resizing shaded windows

[Viktor Griph]

On Sat, 15 Apr 2006, Mikhael Goikhman wrote:


On 14 Apr 2006 19:32:16 +0200, Viktor Griph wrote:


On Fri, 14 Apr 2006, Serge (gentoosiast) Koksharov wrote:


2) If this problem can't be solved without much hassle I think we should
make it clear in documentation that ResizeOpaque style don't applies to
shaded windows.


I like it the way it is. I'm really not interested in the content of
shaded windows. Vote for a change of documentaion


Yes.


possible together
with an option to the WindowShade command to use the last shade direction.


Ok, but adding this feature (storing the last shade direction per window)
is not urgent. A user may implement this using custom functions.

I believe, but haven't checked it up, that the shading direction isn't 
overwritten when unshading a window, so it would really just be some 
option to use whatever value already in there. Possible with addition to 
make sure that the default value for windows that haven't been shaded 
before make sence.


/Viktor

Re: Inconsistency during resizing shaded windows

[Viktor Griph]

On Fri, 14 Apr 2006, Serge (gentoosiast) Koksharov wrote:


 Hi,

Yesterday I've noticed little inconsistency during resizing shaded
windows under fvwm 2.5.16 and current CVS version:

I have in my ~/.fvwm/config `Style * ResizeOpaque'. But during resizing
of any shaded window this style ignored and window resized as rubberband
outline. I propose two possible solutions:

1) Solve this inconsistency. Maybe unshade the window before resizing,
resize it, then shade it again.



You can actually do this yourself, given that you don't use different 
shading directions. Just define your own resize function:

AddToFunc ResizeFunc
+ I ThisWindow (Shaded) WindowShade off
+ I Resize
+ I TestRc (Match) WindowShade on


2) If this problem can't be solved without much hassle I think we should
make it clear in documentation that ResizeOpaque style don't applies to
shaded windows.



I like it the way it is. I'm really not interested in the content of 
shaded windows. Vote for a change of documentaion, possible together 
with an option to the WindowShade command to use the last shade direction.


/Viktor

Re: On my recent commits.

[Viktor Griph]

On Sat, 15 Apr 2006, Serge (gentoosiast) Koksharov wrote:


On Thu, Apr 13, 2006 at 05:56:52PM +0200, Viktor Griph wrote:

* should the options be allowed in any order. Now Reverse has to precede
UseStack.


If I understood your changes correctly, UseStack and Reverse options are
not directly related to each other. In this case I think they should be
allowed in any order. If I'm wrong, leave it as is, but please make a
note about order in the `fvwm' manpage.

The options are not depending on each other. However the reason for the 
current order requirement was that it was easier to write up in the man 
page. All [Reverse] [UseStack] [(Conditions)] command implies an 
order. To allow any order requires some more generic means of documenting 
the options. Something like All [options] [(Conditions)] command and 
then state the possible values for options.


/Viktor

Re: FVWM: xpad incorrect behaviour under FVWM

[Viktor Griph]

On Mon, 10 Apr 2006, Serge (gentoosiast) Koksharov wrote:


On Fri, Apr 07, 2006 at 05:55:25PM -0400, Dan Espen wrote:

When I turn on edit lock, fvwm interprets the first click
(and every click) as a request to move the window.
The window-move feedback window appears.


Yes, exactly. But in other WMs which I tried, double LMB click allows you to
edit note's text. So, it's xpad behaving incorrectly or FVWM lacks some
functionality?



I  don't think niether fvwm nor xpad behaves incorrectly. However, the way 
fvwm deals with xpad's request to move the window causes xpad to recive a 
focus out event, and then lock the edit box again. So while no party 
really doesn't do anything wrong they don't work well together. The focus 
change occurs as fvwm grabs the keyboard to allow for keyboard movement of 
the window.


I beleive that a client should not expect not to lose focus during a 
movement, but the EWMH-specification dodn't state anything about it.


/Viktor

Re: style matching in current CVS

[Viktor Griph]

On Thu, 6 Apr 2006, Dominik Vogt wrote:


On Thu, Apr 06, 2006 at 11:13:03AM +0200, Dominik Vogt wrote:

First, this code from style.c generates a warning:

if (SID_GET_HAS_NAME(s_id)  (fw-style_name == NULL 
(matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE ||
 matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == TRUE ||
 matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)) ||
matchWildcards(SID_GET_NAME(s_id), fw-style_name ) == TRUE)
{
return True;
}

style.c: In function `fw_match_style_id':
style.c:176: warning: suggest parentheses around  within ||

Second, the code may access a NULL pointer style_name if neither
of the first three matchWildcards is true.

I just noticed this warning and logic error myself and were about to 
change it.



Also, I think even if style_name is not NULL, the usual style name
matching should be done:
You are probably right. It was just that you said it should use it instead 
of the normal matching. However, that probably only creates a lot of more 
problems than anything else, so I think that the way you changed it to is 
good. I have updated the manpage to reflect the change.


Just some conciderations: The manpage states that styles are search for in 
a specific order. I really fail to see how this information is useful 
while examining the logic, other than for the face that matchig early will 
save some comparitions. Am I missing something?





if (SID_GET_HAS_NAME(s_id))
{
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == 
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == 
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)
{
return True;
}
if (fw-style_name == NULL 
matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == 
TRUE)
{
return True;
}
}


(Note that multi-line conditions with mixed  and || operators
are hard to read.  If you happen to edit such a condition, please
split it into separate conditions.)



I see your point and will do that in the future. It should prevent errors 
as the one above.



(I have committed this code to CVS, but feel free to change it).


I've committed a copy-paste-error fix (you never compared with 
style_name).


/Viktor

Re: style matching in current CVS

[Viktor Griph]

On Thu, 6 Apr 2006, Dominik Vogt wrote:


On Thu, Apr 06, 2006 at 11:42:17AM +0200, Viktor Griph wrote:

Just some conciderations: The manpage states that styles are search for in
a specific order. I really fail to see how this information is useful
while examining the logic, other than for the face that matchig early will
save some comparitions. Am I missing something?


Do you mean this text:

 They are searched in the reverse order stated.
 When two conflicting styles apply to the same window, the style
 that was changed last wins.
I've always thought the first sentece They are searched in the reverse 
order stated. referre back to the order given in the previous statement, 
i.e I've read stated as stated here. Now that you say it it is fullt 
pssible, and probably makes more sence to interpet it as some sort of 
double information the the second sentence you quoted.


 

This just means that style lines issued later override earlier
styles.  The text is confusing, though.


I've committed a copy-paste-error fix (you never compared with
style_name).


:-P

By the way, the function fw_match_style_id wasn't mentioned in
your original ChangeLog entry.  Please try to always mention *all*
changed functions.  This simplifies code maintenance enormously.


I thougt I did that. I must have overwritten the changelog entry for 
fw_match_style_id with some subsequent addition to an alrady open 
changelog witout reverting to a recently saved one.




Ciao

Dominik ^_^  ^_^

--
Dominik Vogt, [EMAIL PROTECTED]

Re: FVWM: Switched to fvwm 2.5 from fvwm 2.4 and having minor

[Viktor Griph]

On Thu, 6 Apr 2006, Ramasubramanian Ramesh wrote:


Hi,

After a very long delay I switched from fvwm 2.4 to 2.5 and am having a 
couple of issues. Hope you can help me solve it. BTW, I did not change 
anything in my .fvwm2rc file.


[...]
2) With version 2.4, I moved windows by clicking on the title, holding the 
left button down and dragging the window where ever I want and then releasing 
it. However with  version 2.5 I need to click and release the left button, 
move the window and then click left button and release it to place it in the 
new posision. I want to restore old behavior. What part of fvwmrc need to be 
modified?


This is related to a bug-fix with bindings. To get the old behaviour you 
will have to not use the Move command directly, but use it as an 
I(mmediate) action in a function. You can for instance do


AddToFunc Immediate
+ I $0

and then replace all Move on bindings with Immediate Move in your 
config.


/Viktor

Re: FVWM: Default Actions for Menues

[Viktor Griph]

On Wed, 5 Apr 2006, Ulrich Mueller wrote:




On Tue, 4 Apr 2006 [EMAIL PROTECTED] wrote:



You could just not display the title and make the topmost entry look like the 
title. It should be easy to do. . . .



thanks, thats an idea, but doesnt exec the default action
when clicking on the menu entry in the superior menu,
also double clicking via Menu ... Exec as Dominik and Dan proposed
doesnt fulfill this in deeper menu levels yet,
so I still think about patching...

Clicking on the menu entry in the superior menu already has an effect: It 
posts the menu. That is prevents it from closing until you have moved the 
mouse to it and beck to the parent menu.


/Viktor

FVWM: FvwmButtons panles

[Viktor Griph]

Is it possible to bind both a Panel and an Action to button in 
FvwmButtons? I'm shifting layers of my FvwmButtons and would like any 
panel to show up on the same layer as the FvwmButtons currently reside 
when the Panel is opened. Is it possble to achive that in any way?


I've been trying with
*FvwmButtons: (Action PointerWindow All (PanelWindow) Layer 0 
$[w.layer],  Panel PanelWindow PanelCommand)

without success.

/Viktor

Re: XResources and styles

[Viktor Griph]

On Sat, 25 Mar 2006, Dominik Vogt wrote:


On Fri, Mar 24, 2006 at 06:32:18PM +0100, Viktor Griph wrote:

Hi,

does it exist any standard regulating the use of XResources? The reason I
ask is that I recently found out that fvwm honors the resources Desk, Page
and fvwmscreen for initial window positioning, and I find them quite neat
to use together with apps supporting the -xrm option.

I think that it  would be good with a way to specify a style with
resources in a similar  way. The idea was that under AddWindow, before
lookup_styles, add a resource lookup for some resource, say fvwmstyle,
and if present map it to a WindowStyle command with rhe resource value as
the style.



All in all it comes down to two questions:
Would adding such a resource break any standard?


I don't think so.



Good. Then I think it's ok as long as the resource starts with fvwm.


and
Is the feature described above something that should be added to fvwm?


I think it's a good idea, but I wouldn't export the style syntax
to the X resources.  Instead, it should just add the style name to
use for the application, i.e. (wahtever the correct syntax is).

 -xrm fvwmstyle: foobar



The correct syntax for that would be -xrm *fvwmstyle:foobar.


would tell fvwm to use the style foobar for the application
(instead of the application name).

This way, the whole configuration is still in the config file and
there is no need to allocate styles dynamically (which is slow and
potentially buggy).



Sounds good, still if all you want is SkipMapping in addition to some 
default styles for the application, and want that for several different 
applications, that can result in many styles. However I belive that this 
way will be better with fvwm 3, so I'll give a try to implement it.


I alrady have a draft implementaton[1] of my earlier suggested behaviour 
that I did while waiting for a reply. Implementing the suggested 
functionality will require an addition to the window structure. That also 
raise the question if a provided style name should be used for anything 
but style lookups, and if these should be any other ways, but resources, 
to set the provided style name. While this can be decided later, it's good 
to think of it aleady. One possiblity would be a SetStyle command that 
changes the style name used by a window.



/Viktor

[1] http://www.dd.chalmers.se/~griph/style_resource.diff

XResources and styles

[Viktor Griph]

Hi,

does it exist any standard regulating the use of XResources? The reason I 
ask is that I recently found out that fvwm honors the resources Desk, Page 
and fvwmscreen for initial window positioning, and I find them quite neat 
to use together with apps supporting the -xrm option.


I think that it  would be good with a way to specify a style with 
resources in a similar  way. The idea was that under AddWindow, before 
lookup_styles, add a resource lookup for some resource, say fvwmstyle, 
and if present map it to a WindowStyle command with rhe resource value as 
the style.


All in all it comes down to two questions:
Would adding such a resource break any standard?
and
Is the feature described above something that should be added to fvwm?

/Viktor

Re: Compile error - latest cvs

[Viktor Griph]

On Tue, 21 Mar 2006, Alex Wallis wrote:


Just updated my cvs version to the latest and get this error
[...]


Fixed. I accidently broke C90-compability (mixed declarations with 
statements) when doing warnings for unconsumed parts of style options.


/Viktor

Re: Menu Title patch

[Viktor Griph]

On Wed, 15 Feb 2006, Dominik Vogt wrote:


On Wed, Feb 15, 2006 at 09:25:11AM +0100, Viktor Griph wrote:

On Wed, 15 Feb 2006, Dominik Vogt wrote:


On Tue, Feb 14, 2006 at 07:27:55PM +0100, Viktor Griph wrote:

On Thu, 9 Feb 2006, Dominik Vogt wrote:

I have applied the patch with some changes and bugfixes:

* The text of the menuitem is always drawn in the given colour
 set (this required a bugfix in the text drawing library).


I don't think this should be done if no colorset is specified for the
title. In that case I belive it should use the color of the normal items,
or old configs using other color than black will get a black title color.


That's exactly what I said (or maybe wanted to say).  Currently:

* No TitleColorset given - normal item colours are used.
* TitleColorset given - foreground of cs is used.
* TitleColorset and HilightTitleBack given - foreground and
  background of cs ase used.


In that case it's not working, because I don't have a TitleColorset, and
my menu title is black, while the rest of the items are khaki.


Works perfectly for me.  Can you post an example config that shows
the problem?


Just the following is ennough:

Colorset 0 fg khaki,bg rgb:dd/00/00
MenuStyle * MenuColorset 0


/Viktor

Re: Comments

[Viktor Griph]

On Wed, 15 Feb 2006, Bert 'theBlackDragon' Geens wrote:


On 2/14/06, Viktor Griph [EMAIL PROTECTED] wrote:

(and the emacs mode
does not deal with that either ;)))


I don't know if you're using my emacs mode or the old one that's
floating about the web, but I've fixed mine so it only higlights start
of line comments. I'm not sure if it's allowed to have those preceded
by spaces though, so if somebody could tell me that I'd be very
grateful.


Comments are allowed to be preceded by spaces.


The mode I'm talking about is this one btw:
http://www.lair.be/projects_fvwm-mode.php

If you would know of a better or more up to date one, please do tell
me as I haven't manage to find any (only a very old one that I didn't
really like).

I've actually been using a havily modified version [1] of that old mode, 
but I tested your mode before stating that the emacs mode didn't hilight 
comments correctly (to be on the safe side ;)).


I've not posted it before since you posted your mode inbetween my start of
adopting it for 2.5 and it being in somewhat working mode. Also I hadn't 
done anything in emacs lisp prior to that, so it's not very well written 
(and it's possible to follow my own evolving in the knowledge of emacs 
lisp by looking through how the coding style evolves in that file.)


It only has support for config files, and not FvwmScript. It also can be a 
little slow sometimes since it's designed to be context sensitive for 
where keywords can be, and I really don't know the best way to optimize 
emacs lisp. (My brother asked me to do it for the reason that he always 
mixed up some keywords.)


The reason why I stick to this mode and don't move over to your is 
probably that I have quite a fast machine, so I don't notice slowdowns in 
the fontlocking, and more importantly: Your mode does not font-lock 
comments spanning multiple lines (with escaped newlines), which makes 
commenting out long commands highlight strangely.


The reason why I've never noticed that comments should be at start of 
commands is that I, normally always use it that way. It were just in a 
quick test I decided to try to disable the trail of a style command, and 
figured it didn't work.


/Viktor

[1] http://www.dd.chalmers.se/~griph/fvwm-mode.el.gz

Re: FVWM: new user question

[Viktor Griph]

On Wed, 15 Feb 2006, [EMAIL PROTECTED] wrote:


I am trying to run fvwm in the cygwin bash shell that came
with the cygwin setup.exe, when i try to run it with XWin,
XWin runs, but i get an error with fvwm:
[FVWM][main]:ERROR can't open the display

is there a setting i have not set yet?
Sincerely,
   Omar Ziranhua



Make sure that you have the DISPLAY environment variable set. If you start 
fvwm from within X, or from an init script, this will be done. If you try 
to start fvwm from a console outside of X you will have to start it 
specifying your display. (On most setups this is :0, but I'm not sure if 
that's the case on cygwin)


Try to run fvwm with the command

fvwm -d :0


/Viktor

Re: Menu Title patch

[Viktor Griph]

On Thu, 9 Feb 2006, Dominik Vogt wrote:

I have applied the patch with some changes and bugfixes:

 * The text of the menuitem is always drawn in the given colour
   set (this required a bugfix in the text drawing library).


I don't think this should be done if no colorset is specified for the 
title. In that case I belive it should use the color of the normal items, 
or old configs using other color than black will get a black title color.


/Viktor

Re: fvwm hangs with xine (PR#3828)

[Viktor Griph]

 Full_Name: 
 Version: 2.5.14,2.5.16
 CVS_Date: 
 OS: linux
 X_Server: xorg 6.8.2
 Submission from: (NULL) (213.247.189.13)
 
 
 This occurs, when I launch xine (xine-ui-0.99.3), choose
 settings-Setup...-audio, select speaker arrangement combobox and try
to
 scroll it. After that fvwm stops to respond to any events, using 100% of
 processor time and occupying more and more memory.
 

This is probably a bug with xine-ui, and the way it forces the combo box
windows to stay in place. It doesn't seem to take the border added by fvwm
in account.

A workaround is to do 'Style Xitk Combo !Borders'. I'm not sure if
anything can be done in fvwm to avoid the race condition.

Adding a Shift command

[Viktor Griph]

Seeing that there has only been one new command in the last 2.5 years I 
think it was time to add another. ;)


I think that a parameter shifting command for use in functions could be 
useful. It could be used for small recursive (yes I know, that would not 
be very efficient) function calls:

AddToFunc Inline
+ I $0
+ I Shift
+ I Inline $*

A sample call of the above would be
Function Inline WindowStyle !Title, !Borders, !Handles UpdateStyles \
Maximize 100 100 Break

Appart from that it would also provide meanns to get direct access to 
positional paramiters after $9.


Thoughts? Is this something that anyone but me would use?

/Viktor

EdgeScroll and pixel steps

[Viktor Griph]

Currently EdgeScroll divides pixel steps1000 by 1000 and enables wrap. I 
belive this to be a bug (and is reportd as sush (#3162)). However, it is 
useful to allow for warps when using pixel steps as well, so just removing 
that ability is no good solution.


One possible solution would be to add another way of specifying wraps to 
the syntax, and make it the required method for pixel sizes (or change 
the check with pixels so that the size has to be larger than the screen 
width, and an even multiplicand of 1000, in order for division to take 
place (for compability with configs using for example EdgeScroll 1024000p 
768000p)).


I can think of several possible syntaxes, and can't decide on which one is 
best. One can either add a prefix (or another suffix) option 'w' to the 
individual coordinates. (w1024p or (1024pw or 1024wp)), or one can add 
optional keywords to the EdgeScroll syntax after the step parameters. 
(i.e. EdgeScroll 1024p 768p wrap|wrapx|wrapy)


/Viktor

Re: FVWM: Loosing Bindings

[Viktor Griph]

On Tue, 31 Jan 2006, David Berg wrote:


I recently copied my fvwm config files from my ubuntu laptop to my debian
sarge destop.  Both systems run the same version of fvwm (2.5.12) but on
my debian system I loose all my bindings (mouse, keyboard, buttons) after
a period of time.  I haven't been able to tie the bindings dissapearing
to any particular event and have no idea where to begin with debugging
my config files.

The only think I can think of that is different between the installs
is that on the Ubuntu box I had installed fvwm-themes then derived my
config files from themes to the point where all I was using from themes
was a few icons and the fvwm-themes-root program.  On the Debian Box I
had copied my config directory over then insalled fvwm-themes because
the background wasn't right.

Restarting fvwm doesn't fix the problem.  I have to completely restart
X to get the bindings back.

Any help?

thanks

--Dave



See FAQ entry #0.1:
 http://fvwm.org/documentation/faq/#0.1

you are probably using numlock on your stationary computer, wheras it's 
not convinient to do so with a laptop keayboard. You would probably then 
do with IgnoreModifiers 2 in your config.


/Viktor

Re: fvwm starts when other window manager is already activeOrganization:

[Viktor Griph]

On Thu, 22 Sep 2005, Manoj Srivastava wrote:


Hi,
 [Please retain the CC to [EMAIL PROTECTED]
  so that the Debian BTS has a record of your input]

 This was reported by a Debian user.

   Recent versions of fvwm, while being able to detect other
versions of fvwm currently running:
--
__ fvwm
[FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try 
-replace
--
are unable to detect other window managers.(Tested with ratpoison and
woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and
enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm,
making this almost every other window manager other than fvwm
itself).

   Older versions of fvwm used to display this warning:
--
[FVWM][CatchRedirectError]: ERROR another WM is running
--
   But the newer ones do not, for reasons I could not debug. This
is a regression, and the other window managers are able to detect
fvwm and refuse to run.

   Please see http://bugs.debian.org/328621 for details.

   manoj



I've done some tests and belive that this bug is due to a change in X with 
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, 
and all have the bug. However I'm sure that the bug was not present when I 
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something 
else that has changed since then. The bug is however not present in 
2.4.19, so it must be soemthing that has changed in the early 2.5.x 
versions, which I weren't able to compile now.


/Viktor

Re: fvwm starts when other window manager is already activeOrganization:

[Viktor Griph]

On Sat, 28 Jan 2006, Bernhard R. Link wrote:


* Viktor Griph [EMAIL PROTECTED] [060128 14:36]:

I've done some tests and belive that this bug is due to a change in X with
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch,
and all have the bug. However I'm sure that the bug was not present when I
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something
else that has changed since then. The bug is however not present in
2.4.19, so it must be soemthing that has changed in the early 2.5.x
versions, which I weren't able to compile now.


I'm seeing the bug here with the Debian sarge version of XFree86 namely
4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken
from Xorg, though.

Hochachtungsvoll,
Bernhard R. Link



Well, I really don't know about that. thinking about it the only x-server 
I'm certain it has worked with is a version of Xsun on solaris 2.8. 
Looking at the fvwm code I believe it might be that an XSync has been 
changed to an XFlush in the startup code before changing the errorhandler 
from the one that traps running WMs to the normal fvwm error handler. But 
since I'm not sure exactly how this WM-trapping is supposed to work I 
leave to someone else to decide if changing it back to XSync is correct.


/Viktor

Re: fvwm starts when other window manager is already activeOrganization:

[Viktor Griph]

On Sat, 28 Jan 2006, Dominik Vogt wrote:


On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote:

On Thu, 22 Sep 2005, Manoj Srivastava wrote:


Hi,
[Please retain the CC to [EMAIL PROTECTED]
 so that the Debian BTS has a record of your input]

This was reported by a Debian user.

  Recent versions of fvwm, while being able to detect other
versions of fvwm currently running:
--
__ fvwm
[FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running,
try -replace
--
are unable to detect other window managers.(Tested with ratpoison and
woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and
enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm,
making this almost every other window manager other than fvwm
itself).

  Older versions of fvwm used to display this warning:
--
[FVWM][CatchRedirectError]: ERROR another WM is running
--
  But the newer ones do not, for reasons I could not debug. This
is a regression, and the other window managers are able to detect
fvwm and refuse to run.

  Please see http://bugs.debian.org/328621 for details.

  manoj



I've done some tests and belive that this bug is due to a change in X with
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch,
and all have the bug. However I'm sure that the bug was not present when I
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something
else that has changed since then. The bug is however not present in
2.4.19, so it must be soemthing that has changed in the early 2.5.x
versions, which I weren't able to compile now.


No, the only change since at least 2.3.0 was introducing the
-replace option.  We haven't touched this code in *ages*.


Have you not?

$ cvs log -r1.290 -N fvwm.c

revision 1.290
date: 2002/03/17 17:34:15;  author: domivogt;  state: Exp;  lines: +7 -10
* Replaced Xsync with XFlush almost everywhere.  Note: it's rarely 
necessary to use XSync.  XFlush usually suffices and is faster.

* More work on frame layout.
* Some general clean up.

The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c:

Index: fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.289
retrieving revision 1.290
diff -u -r1.289 -r1.290
--- fvwm.c  15 Mar 2002 17:02:25 -  1.289
+++ fvwm.c  17 Mar 2002 17:34:15 -  1.290
@@ -557,21 +559,21 @@
CWEventMask | CWOverrideRedirect | 
CWColormap
| CWBackPixmap | CWBorderPixel, 
attributes);

   XMapWindow(dpy, Scr.NoFocusWin);
-
   SetMWM_INFO(Scr.NoFocusWin);
   FOCUS_SET(Scr.NoFocusWin);

-  XSync(dpy, 0);
+  frame_init();
+  XFlush(dpy);
   if(debugging)
   {
  sync_server(1);
   }

-  SetupICCCM2 (replace_wm);
+  SetupICCCM2(replace_wm);
   XSetErrorHandler(CatchRedirectError);
   XSetIOErrorHandler(CatchFatal);
   XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW);
-  XSync(dpy, 0);
+  XFlush(dpy);

   XSetErrorHandler(FvwmErrorHandler);



I think that last XSync really should be there since, if I understand the 
test correctly it relies on an error to be generated if a window manager 
already exists, and XSync does wait until all requests are processed, and 
the errors handled, but XFlush just flushes the output buffer. I guess 
it's up to the threadin model of the X-server weather or not any errors 
generated by recently flushed requests are handled before or after the 
request to change error handler to FvwmErrorHandler is processed.


/Viktor

Re: FVWM: StaysOnTop style

[Viktor Griph]

On Tue, 17 Jan 2006, Ivan Butorin wrote:


Hello,

I'm trying to write some kind of simple function that places window on
top of others:

DestroyFunc PlaceOnTop
AddToFunc PlaceOnTop
+ I DestroyWindowStyle
+ I WindowStyle StaysOnTop, !Iconifiable
+ I RefreshWindow

but 'StaysOnTop' style doesn't work (!Iconifiable, which was put here
just for test, works). It looks like applying 'StaysOnTop' style
doesn't work on existing windows.

Could you please tell me what am I doing wrong?



The StaysOnTop, StaysOnBottom and Layer window styles are initial styles 
only. To change the layer of an existing window you should use the Layer 
command. So you would have to use Layer 0 6 to put the layer on top 
(unless you have set a different top layer with the DefaultLayers command)


/Viktor

Re: make rpm-dist and deb-dist both fail with the same error

[Viktor Griph]

On Mon, 16 Jan 2006, Alex Wallis wrote:

I just updated my cvs sources (did a fresh checkout to be sure) and I keep 
getting an error with both make rpm-dist and make deb-dist as follows.


Making all in FvwmTabs
make[5]: Entering directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules/FvwmTabs'
make[5]: *** No rule to make target `FvwmTabs.pod', needed by `FvwmTabs.1'. 
Stop.

make[5]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules/FvwmTabs'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16'
error: Bad exit status from /var/tmp/rpm-tmp.34739 (%build)


RPM build errors:
   Bad exit status from /var/tmp/rpm-tmp.34739 (%build)
make[1]: Leaving directory `/home/awol/work/cvs/fvwm/rpm'
awol-dev:/home/awol/work/cvs/fvwm#

I get almost exactly the same error for both rpm-dist and deb-dist

It's probably an oversight.

Alex



It seems as the same error is shiped with the 2.5.15 tarballs. It seems as 
if modules/FvwmTabs/Makefile.am concider the final manpage as a part of 
the distrubution, rather than the pod-file. When making make tries to 
rebuild the manpage from the pod, but the pod is missing. I don't have 
enough knowledge on automake to know what changes are needed, so somone 
else will have to fix it.


/Viktor

Re: FVWM: How to get a application's focus auto call by gmrun.

[Viktor Griph]

On Thu, 12 Jan 2006, Mikhael Goikhman wrote:


On 13 Jan 2006 00:29:52 +0800, Joey Watson wrote:


thanks for you answer my question. I am not familiar with fvwm config file
grammar.
but I think maybe you misunderstand what I mean.

I mean that I want automatically set focus to the application what called by
gmrun.

Style gmrun GrabFocus seems make gmrun get focus.


You may either always pass a focus to any new window: Style * GrabFocus,
or implement the solution from FAQ #3.18.

 http://fvwm.org/documentation/faq/#3.18



You can use FvwmEvent to change the style when gmrun gets focus:

*FvwmEvent: Cmd Function
*FvwmEvent: focus_change FocusChangeStyle

AddToFunc FocusChangeStyle I None (Focused) Break
+ I ThisWindow (Gmrun) Style *  GrabFocus
+ I TestRc (!Match) Style * !GrabFocus

Module FvwmEvent


/Viktor

Re: FVWM: GrabFocusOff

[Viktor Griph]

On Wed, 11 Jan 2006, Mikhael Goikhman wrote:


On 10 Jan 2006 23:03:07 -0500, Nathaniel H. Stickney wrote:


1) Style * GrabFocusOff does not seem to prevent Gaim from grabbing
focus, unsure about other applications.  I have tried just GrabFocusOff
and also Style * GrabFocusOff to no avail.


I can't reproduce this with Gaim 1.3.1. What is exactly the problem?

!GrabFocus is the default, so Style * GrabFocusOff will not normally
change things. You would possibly need Style Gaim !GrabFocusTransient,
but gaim does not use transient windows (my version at least).

Do you mean the Raise window on events option in Preferences, or maybe
auto-raising/focusing the chat window when double clicking a buddy item?

To prevent the last one, use Style Gaim !FPFocusByFunction in 2.5.x.



Does the conversation window get focused, is raised and have the 
pointer moved to it when you recive a new message?


In that case check if you are using the Message Notififier, and if it is 
set to set the URGENT hint. If you want custom message notification for 
gaim you may modify the UrgencyFunc in fvwm to do something else in case 
of the window being gaim. The trailing functions make gaim shake from side 
to side when the urgency hint is set. (If you use it you will want to make 
sure that gaim clears the urgency hint on focus.) I'm not using this 
myself, since I find it still too annoying. I really want a way to make 
gaim windows stand out in the pager. One thing that would be cool is if it 
would be possible to change the colorset a window use in the pager, or 
have it flash between two colorsets, but I don't think there is any 
support for that in the pager. The shaking window does show in the pager 
if the amplitude is high ennough compared to the pager scale, but I only 
tested it for a while before deciding I didn't like it. Right now I just 
use a different decor for all windows using the urgent hint. (I still have 
to come across any program but gaim that uses it.)


/Viktor

DestroyFunc Shake
AddToFunc Shake
+ I Move w$2$0p w$2$1p
+ I Move w$2$0p w$2$1p
+ I State 31
+ I Schedule $4 $[w.id] Function Shake $0 $1 $3 $2 $4

DestroyFunc StartShake
AddToFunc StartShake
+ I State 31 off
+ I Move w-$0p w-$1p
+ I Schedule $2 $[w.id] Function Shake $0 $1 + - $2

DestroyFunc StopShake
AddToFunc StopShake
+ I ThisWindow (State 31) Move w-$0p w-$1p
+ I TestRc (!Match) Move w+$0p w+$1p
+ I State 31 off
+ I Deschedule $[w.id]

DestroyFunc UrgencyFunc
AddToFunc UrgencyFunc
 + I ThisWindow (Gaim) StartShake 5 0 100
 + I TestRc (Match) Break
 + I Iconify off
 + I FlipFocus
 + I Raise
 + I WarpToWindow 5p 5p

DestroyFunc UrgencyDoneFunc
AddToFunc UrgencyDoneFunc
 + I ThisWindow (Gaim) StopShake 5 0

Re: FVWM: Remove labels from FvwmPager?

[Viktor Griph]

On Sun, 8 Jan 2006, Nathaniel H. Stickney wrote:


Howdy,

I've been recreating my setup, and as I only use one desktop, I would really 
like to be able to remove the desktop label from my FvwmPager module.  Is 
there any way I can accomplish this?  Thank you.


- N. H. Stickney



Hi,
simply add the following to your module config:

*FvwmPager: Font none


/Viktor

Re: EWMH Window Types

[Viktor Griph]

I've spent some time learning the way fvwm wors with styles, and looked 
into how to implement the EwmhWindowTypeStyle command I suggested. There 
are at least two possible ways to do it:


One is to make use of the style list, and add a window type field to the 
style id. That would require the ewmh_window_type value to be set before 
lookup_styles is called, which would make the style EWMHIgnoreWindowType 
hard to implement. However, the window tye stiles would be applied before 
other styles, and thus easy to override, so the ignore style wouldn't 
really be needed. On the other hand the styles would be in risk of 
accidental overriding by any Style * command in the user config.


Another way is to keep the window type styles in a separate array, and 
apply them at a fixed time, as done now. That would keep the window type 
settings applied late, and the need for the EWMHIgnoreWindowType style 
would stay.


I'm in favor of the first one, as it's more configurable, but I'd like 
some more input.


/Viktor

Re: TrianglesUseFore patch.

[Viktor Griph]

On Mon, 21 Nov 2005, Malcolm Still wrote:

Hello again,

I've now patched against the CVS version. Again I've uploaded
it to my webspace:
http://rv.sdf-eu.org/CVSTrianglesUseFore.patch

With the old patch I'd also found that it didn't paint with the
foreground colour when using TrianglesRelief, so I modified
the patch to do that.

I've also patched menustyle_copy() to copy the TrianglesUseFore
value to a new menustyle, which it didn't do before.

As requested you can use !TrianglesUseFore to negate the
option.

I've also patched the manpage, AUTHORS, and NEWS to
reflect the new option.

Hope thats all fine.



I've applied your patch, with lines shortened to less than 80 characters. 
If you write another patch in the future you should not use more than 79 
columns. Also when responding to this list you should write the reply 
after the quoted text.


/Viktor

matlab steals focus

[Viktor Griph]

I've encounted a strange, and undesired, behaviour with matlab 7.x 
(maybe eralier versions too), and I've tried all fvwm options available 
and I still can't get it to work right. My conclution is that matlab must 
break some rule. I write this in hope that someone knows of a way to go 
around that behaviour.


Now to a description of the problem: I always run matlab in a terminal 
(-nodesktop), and I want that terminal to stay focused, even If you issue 
a command like figure(1). The problem is that, despite that I have

FocusStyle * !GrabFocus, OverrideGrabFocus, !FocusByProgram
in my config, matlap gives the focus to figure 1 if I isseu the command. 
If a figure already is active it will focus and raise. Otherwise it will 
start up focused. Even if I do 'Style Figure * NeverFocus' the figure 
will be focused on the command figure(1) (or when clicking on the window 
(but I use EnterToFocus, !LeaveToUnfocus, and not ClickToFocus, so it's 
matlab doing that focusing too). I tried to look at the focus code myself 
to see if there was anything I could do to force matlab not to focus it's 
figures on itself, but wasn't able to make out how the code worked.


I did however find that when starting matlab with -nojvm it does not steal 
the focus at all. However I sometimes need the jvm, so it's not a good 
solution.


I need some help by someone who know the specification, and more of the 
X-protocol than I do. I have two major questions:

1. Is it possible to make fvwm not allow the said focus change to happen?
2. Is matlab breaking any standard (and in that case what), and do you 
think it's worth submitting a bug report to MathWorks about it?


/Viktor

Re: matlab steals focus

[Viktor Griph]

On Sat, 3 Dec 2005, Tavis Ormandy wrote:


On Sat, Dec 03, 2005 at 11:28:47PM +0100, Viktor Griph wrote:

I've encounted a strange, and undesired, behaviour with matlab 7.x
(maybe eralier versions too), and I've tried all fvwm options available
and I still can't get it to work right. My conclution is that matlab must
break some rule. I write this in hope that someone knows of a way to go
around that behaviour.


I've had a similar problem with a different proprietary application, it
used XSetInputFocus() whenever it wanted my attention, very annoying :)

If this is what it's doing, afaik there is no way around it. I solved
it with a preload library, for example, try this:

$ cat libmatlab.c
#include X11/Xlib.h
int XSetInputFocus(Display *d, Window w, int i, Time t) { return 0;}
$ gcc -shared -fPIC libmatlab.c -o libmatlab.so
$ LD_PRELOAD=`pwd`/libmatlab.so matlab -nodesktop

If it works, you could create a wrapper script to set LD_PRELOAD before
starting matlab (dont have matlab here to test).

Hope this helps, Tavis.

Thank you! It works perfectly. Of course it would be best not to have to 
do rappers, so I would still want to know what standard matlab breaks. (I 
guess it's ICCCM, but if anyone that knows more precise where matlab does 
wrong it would hale me write a good bug report.


/Viktor

Re: matlab steals focus

[Viktor Griph]

On Sun, 4 Dec 2005, Dominik Vogt wrote:


On Sat, Dec 03, 2005 at 11:28:47PM +0100, Viktor Griph wrote:

I've encounted a strange, and undesired, behaviour with matlab 7.x
(maybe eralier versions too), and I've tried all fvwm options available
and I still can't get it to work right. My conclution is that matlab must
break some rule. I write this in hope that someone knows of a way to go
around that behaviour.

Now to a description of the problem: I always run matlab in a terminal
(-nodesktop), and I want that terminal to stay focused, even If you issue
a command like figure(1). The problem is that, despite that I have
FocusStyle * !GrabFocus, OverrideGrabFocus, !FocusByProgram
in my config, matlap gives the focus to figure 1 if I isseu the command.
If a figure already is active it will focus and raise. Otherwise it will
start up focused. Even if I do 'Style Figure * NeverFocus' the figure
will be focused on the command figure(1) (or when clicking on the window
(but I use EnterToFocus, !LeaveToUnfocus, and not ClickToFocus, so it's
matlab doing that focusing too). I tried to look at the focus code myself
to see if there was anything I could do to force matlab not to focus it's
figures on itself, but wasn't able to make out how the code worked.

I did however find that when starting matlab with -nojvm it does not steal
the focus at all. However I sometimes need the jvm, so it's not a good
solution.

I need some help by someone who know the specification, and more of the
X-protocol than I do. I have two major questions:
1. Is it possible to make fvwm not allow the said focus change to happen?


No.  Every application can set the focus to any window or
subwindow at any time.  The window manager is not involved in this
process at all.  All the fvwm styles affect only applications that
try to cooperate with the window manager by honouring the ICCCM2
rules.


2. Is matlab breaking any standard (and in that case what), and do you
think it's worth submitting a bug report to MathWorks about it?


That depends on what type of focus policy matlab requests.  Use
FvwmIdent on the matlab window.  If the focus policy says locally
active or globally active, matlab is allowed to do that.  If it
says passive or no input matlab is breaking the ICCCM2 rules.


It says Passive.


I've never seen a company fixing a bug reported by someone from
the open source community, so I doubt filing a report would be
useful.
I had the idea that if I report it to the helpdesk at my university, and 
have them report it further it will be reported from a large customer of 
them and it would be in their interest to fix it. But you might be right 
that they won't care about it.


Thanks for your reply.

/Viktor

Re: resizing windows with root-transparent titles

[Viktor Griph]

On Sat, 26 Nov 2005, Dominik Vogt wrote:


On Sat, Nov 26, 2005 at 09:35:16PM +0100, Viktor Griph wrote:

It seems as if resizing of windows with root transparent titles doesn't
update the title. It will consist of the old pixmap, with the title text
on the same position as before, posible tiled, if the window grew. Anyone
that can give me a hint on where to start looking for the error?


I've no idea where to look (Olivier wrote that code), but it works
for me.  Do you have a minimal config to show your problem?


Colorset 1 RootTransparent
TitleStyle Colorset 1
Style * ResizeOpaque

To reproduce then resize the window, and keep it focused all the time. 
It's best noticed if you have a small window and resize it to more double 
size or more. During the resizing the title will be updateing, but when 
it's complete it will change to the previous title tiled. Once the window 
is unfocused the title is restored.


/Viktor

Re: FVWM: getting to root menu

[Viktor Griph]

On Mon, 21 Nov 2005, bashr wrote:

Probably a familiar question for experts:  Normally I click on the the root 
window to the root menu.  Sometimes the root window is completely covered. 
Is it possible to exclude all windows from a 1-pixel row at the top of the 
screen?  It is easy to click there.  How do other folks ensure quick access 
to the root menu?


Thanks.

If you aren't using edge scrolling to the north, and use 2.5.x you may use 
'EdgeCommand N Nop' to add a panframe on the top. It will work as the 
root window for clicks, but will not keep the windows from using that part 
of the screen.


/Viktor