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: 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

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

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

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: 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: 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: 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: 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 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: 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: 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

EWMH Window Types

[Viktor Griph]

The way fvwm handles the _NET_WM_WINDOW_TYPE hint is very 
non-configurable currently. You can't even set other style options on the 
windows yourself.


There are several ways to improve this. In short term a style 
EWMHIgnoreWindowType would allow for users to set their own style on 
windows having a specific windowtype without being foced to also have the 
default options of that window type. While this is an easy-to-make 
solution, I think there is room for more improvment. It would be good with 
configurable styles on a window type level, also for the window types 
currently ignored by fvwm. A command EWMHWindowTypeStyle could be added, 
and when the Style command is changed according to the 3.0 todo Type could 
be made a option to match on.


I already got an implementation of the EWMHIgnoreWindowType which is ready 
for commit if agreed that such a style woud be useful (there might be 
other better solutions to the problem). I'd like to take a look at the 
implementation of an EWMHWindowTypeStyle command once I get a little more 
spare time.


/Viktor

Re: MenuStyle

[Viktor Griph]

On Thu, 20 Oct 2005, Dominik Vogt wrote:


On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote:

Hi

I am looking into the MenuStyle code trying to understand how some things
are done. I plan to enable negation of all on/off menu styles by prefixing
! to them. However looking at the code raise some questions:

First of all what exactly does FreeColors free up?


In certain modes, X colours are managed in so called colour cells.
There may be a limited number of available cells.  They are
reserved with XAllocColor and freed with XFreeColor.  Because
colours are used in many places inside fvwm (colour sets!), fvwm
keeps a reference counter for the allocated colours.  The
corresponding code may be a bit difficult to understand
(libs/PictureUtils.c).

FreeColors eventually decreases the reference counters and frees
the cells if the reference count drops to 0.  Actually the process
is more complicated.  I think Olivier has written most of the
code.


Answering this might
answe some of my other questions; at least if it has some special
functionality.



Second: The styles HilightBack and ActiveFore do free the colors if the
style have them. Howver the corresponding off-styles does not free them.
Is there any reason for this?


No, it's a bug.  Both must free these colours also.  Note that
nobody ever actually tested the code to free colours.  I'm sure
fvwm still has many colour leaks.


Last: This can't be right can it?:
-- from menustyle.c: menustyle_copy
/* HilightBack */
if (ST_HAS_ACTIVE_BACK(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).back, 1, True);
}
ST_HAS_ACTIVE_BACK(destms) = ST_HAS_ACTIVE_BACK(origms);
memcpy(ST_MENU_ACTIVE_COLORS(destms),
   ST_MENU_ACTIVE_COLORS(origms), sizeof(ColorPair));
ST_DO_HILIGHT_BACK(destms) = ST_DO_HILIGHT_BACK(origms);

/* ActiveFore */
if (ST_HAS_ACTIVE_FORE(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).fore, 1, True);
}
--
It looks to me as it frees the active fore color after having it copied
over, thus freeing the source's color instead of the overwritten.


Yes, without checking what the ST_MENU_ACTIVE_COLORS actually are,
I think you're right.

Furthermore I think the colour reference counts have to be
increased when a menustyle is copied.  Consider this:

 * Menustyle A has a colour x with reference count 1.
 * Copy menustyle A to some other menustyle B.  x still has a
   reference count of 1.
 * Copy A over b again.  The reference count of x is decreased to
   0 and never increased again.  Ouch.

We should have a CopyColor function somewhere in PictureUtils.c
that takes care of this situation, e.g.

 CopyColor(
   sometype* dest_color, sometype* src_color,
   int do_free_dest_color);

(where do_free_dest_color indicates whether the destination
colour should be freed).

I found Pixel fvwmlib_clone_color(Pixel p) in ColorUtils.c which can be 
used to reallocate a color. With that creating a CopyColor function is no

problem.


Ciao

Dominik ^_^  ^_^

--
Dominik Vogt, [EMAIL PROTECTED]

Re: CVS griph: reimplemented previous fix without breaking escape

[Viktor Griph]

On Mon, 17 Oct 2005, Dominik Vogt wrote:

On Sun, Oct 16, 2005 at 04:45:39PM -0500, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   05/10/16 16:45:39

Modified files:
.  : ChangeLog
fvwm   : move_resize.c

Log message:
reimplemented previous fix without breaking escape


Yes, that fix is fine.  Note that you can not just overwrite
members of an XEvent structure that do not match the event type -
you will inadvertedly overwrite members of the real event.  What
you thought to be a random mouse button was really the keycode
of the KeyPress event.


Sorry about that. I realized what was wrong the moment you reverted the 
patch. I had tested it, but not with escape. Strangely other keyboard 
controls still seemed to work.


/Viktor

Re: ManualPlacement/Move Patch

[Viktor Griph]

On Thu, 1 Sep 2005, Mikhael Goikhman wrote:


On 01 Sep 2005 07:10:25 +0200, Viktor Griph wrote:


On Wed, 31 Aug 2005, Mikhael Goikhman wrote:


On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote:


This is not enough, To emulate the current logic you should also add:

 Mouse 1 P N CancelPlacement
 Mouse 2 P N CancelPlacement

I.e. if you started the Move using button 1, then button 2 cancels it and
vice versa. Since you can't press button 1 again while dragging using
button 1, these binding would be ok although not immediately intuitive.


Well, actually these will not be ok if the Move is started on mouse click
(not drag) or on key press. So either we conclude your idea can't work or
we may try to somehow save it using, say, this extension:

Mouse 0 P N PlaceWindow
Mouse 1 P(d0) N CancelPlacement
Mouse 2 P(d0) N CancelPlacement
Mouse 1 P(d1) N PlaceWindow
Mouse 2 P(d2) N PlaceWindow
Mouse 2 P(c)  N CancelPlacement

Where dN means dragging using button N and c means mouse click or key
press.  No, I am not a big fan of such idea, but I am not against either.

(I think the current logic about Move cancelation is good.)


I've not changed the logic for dragging of windows. IT's only the
interactive movment that my patch affects. I maybe should make that more
clear in the manual page. I did see no need to try to change the drag
logic, as all feeling on how it should work matches with how it currently
does. I.e you hold down the button the drag started with and calcel the
movement by pressing any other button.


Well, this is not exactly what happens now. If you drag using mouse
button 1 or 2, then button 3 places the window, rather than cancels.
I suppose Dominik intentionally did it to allow PlacedByButton3 using
dragging too.
Yes, you are right. I missed that while rewriting the logic. It shouldn't 
be that hard to handle.





If you want to be able to use some buttons for placing the window evenif
it is being dragged it could probably be conficured by also changing
PlaceWindow to always place the window and add PlaceWindowInteractive and
PlaceWindowDrag as well as CancelPlacementDrag/CancelPlacementInteractive,
and maybe also add CancelPlacement for completness, even if it would be
the same as -. However, I think that just would comlicate things. But if
you think it would be better to be able to define that you want to be able
to place a window you are dragging by clicking on another button as well I
can try to add that.


You see, this is not enough. There should be at least the special notion
of the same button that started the drag. The bindings quoted above
should be implemented in one or another way (either configurable or
hard-coded).
I see no reason to ever want to have the button that started the drag to 
cancel a move. (And it would require new tests in the ButtonRelease even 
handling to implement) What seems to be the spimplest to solution is to 
hardcode (actually not handle specially) that if you release the button 
the move started with the window is placed - regardless of whatever 
bindings you have set up for Pressing the button during the move.


Then I would only need for one more binding action. And possible some 
deactivating actions. The only thing that would have to be defined, in one 
way or another, is buttons pressable without movement cancelation while 
dragging. That together with buttons that can be used to place 
interactivly moved windows also defins buttons canceling movement.


Mouse 0 P N PlaceWindow
Mouse 1 P N CancelPlacementDrag
Mouse 2 P N CancelPlacement

Would then match the current default
Suggested allowed Actuiions would be
PlaceWindow / PlaceWindowInteractive / PlaceWindowDrag
CancelPlacement / CancelPlacementInteractive / CancelPlacementDrag
With - being equvalint of CancelPlacement

PlaceWindow equvalent of PlaceWindowInteractive and PlaceWindowDrag
with the CancelPlacement counterparts. If you see any case where that 
wouldn't be enough (given that the check is for button press and not 
release, and you can't press a button being held).




I am not sure the flexibility you want to add is either needed or easy to
implement (if possible at all). It is like to allow a user to create a
new menu feel (key and mouse bindings) using a configuration. The menu
code is messy and there are many actions and special cases already
without configurable bindings. I don't know whether users want or have
the ability to replace the placement feel with some usable alternative.
Can you partition the exact current feel into configurable commands and
estimate the work needed to implement this? Something along lines:

 Key Return P A PlaceWindow
 Key Space  P A PlaceWindow
 Key Escape P A CancelPlacement
 Key Right  P A MoveWindow +10p 0
 Key Right  P S MoveWindow +100p 0
 Key Right  P C MoveWindow +1p 0
 Key AltP C ToggleSnapAttraction  # well, this is a modifier, not a key

If you show this is possible, then we may think to add a half-hardcoded
command like

Move question

[Viktor Griph]

I'm working on a patch to allow windows to be placed with buttons 3. 
However, I run into some strangeness with the way Move is supposed to work 
according to the Man page, compared to what it actually does:


The man page states that Move can be canceled with MB2. This is currently 
only true if Emulate is set to MWM. In other case MB2 places the window, 
and does nothing more (unless when __move is called from placement.c 
where it will continue with a resize operation). With Emulate not MWM the 
only way to cancel a non-drag-move with the mose is any button 3, which 
won't be possible with the patch I'm writing either.


So, to come to the question: How should non-drag-movment be aborted by 
mouse?


I also have two code-related questions:
1. Is there a way to see if a FvwmWindow never have been placed?
(i.e to know if the return True for resize has any meaning)

2. What is the reason for windows dropped by button 1 to not fall over to 
button release, as windows dropped by button three. I know that not doing 
so allows to keep moving the window until you release the button, but why 
different behaviour for different buttons?


/Viktor

ManualPlacement/Move Patch

[Viktor Griph]

This is the ManualPlacement/Move patch I'm currently working on. Right now 
I've done as mush as possible without knowing how placments are intended 
to be aborted.


This patch makes placement of windows using any button possible. The 
button used to place the window is stored, and can be checked for with the 
new window condition PlacedByButton.


Left to be done is to add a way to cancel placment with the mouse. One 
thing that has come to my mind is the allow some sort of mouse binding 
(ala the tearoff button for menus) Or another configure command that 
controls which buttons are valid for placing, and which that cancel 
placment. Jsut doing it by button numbers, ignoring any modifiers wouldn't 
be that hard. But I'm open to suggestions here.


/Viktor

placement_button.patch.gz
Description: GNU Zip compressed data

New Test conditions: EdgeHasPointer and EdgeIsActive

[Viktor Griph]

I needed a way to tell waether the pointer is on an edge or not, and since 
non of the current conditionals were able to do that I wrote my own. I 
also included an EdgeIsActive since I thought that could be useful too, 
and they were to have similar syntax.


Both are conditions to the Test command, and both take one direction 
argument. The direction argument can be any major direction or Any if no 
argument is given Any is assumed.


EdgeHasPoiner is true if the pointer is over the pan frame specified by 
direction, and EdgeIsActive is true if the panframe in the given direction 
is mapped.


/Viktor
Index: AUTHORS
===
RCS file: /home/cvs/fvwm/fvwm/AUTHORS,v
retrieving revision 1.103
diff -u -r1.103 AUTHORS
--- AUTHORS 29 Jun 2005 17:15:18 -  1.103
+++ AUTHORS 12 Aug 2005 22:33:30 -
@@ -4,6 +4,7 @@
 
 Viktor Griph:
 Patch for Perl modules on 64 bit machines.
+EdgeHasPointer and EdgeIsActive test conditions.
 
 Bjoern Steinbrink:
 Patch for FvwmScript tasks running too often.
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2612
diff -u -r1.2612 ChangeLog
--- ChangeLog   12 Aug 2005 15:50:38 -  1.2612
+++ ChangeLog   12 Aug 2005 22:33:32 -
@@ -1,3 +1,9 @@
+2005-08-13  Viktor Griph  [EMAIL PROTECTED]
+
+   * fvwm/conditional.c (CMD_Test):
+   * fvwm/fvwm.1.in: 
+   added test conditions EdgeHasPointer and EdgeIsActive
+
 2005-08-12  Dominik Vogt  [EMAIL PROTECTED]
 
* fvwm/virtual.c (raisePanFrames):
Index: NEWS
===
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.565
diff -u -r1.565 NEWS
--- NEWS12 Aug 2005 16:12:54 -  1.565
+++ NEWS12 Aug 2005 22:33:32 -
@@ -8,7 +8,8 @@
 * New features:
 
- Fvwm now officially supports 64-bit architertures.
-   - New Test conditions IsEnvSet and MatchEnv.
+   - New Test conditions IsEnvSet, MatchEnv, EdgeHasPointer
+ and EdgeIsActive..
 
 * New module features:
 
Index: fvwm/conditional.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/conditional.c,v
retrieving revision 1.105
diff -u -r1.105 conditional.c
--- fvwm/conditional.c  12 Aug 2005 11:39:58 -  1.105
+++ fvwm/conditional.c  12 Aug 2005 22:33:32 -
@@ -47,6 +47,7 @@
 #include stack.h
 #include commands.h
 #include decorations.h
+#include virtual.h
 
 /*  local definitions -- */
 
@@ -1913,6 +1914,113 @@
error = 1;
}
}
+   else if (StrEquals(cond, EdgeIsActive))
+   { 
+   direction_t dir= DIR_NONE;
+   char *dirname;
+   char *next;
+   next = GetNextSimpleOption(flags_ptr, dirname);
+   if (dirname)
+   {
+   dir = gravity_parse_dir_argument(dirname, 
+   NULL, DIR_NONE);
+   if (dir == DIR_NONE)
+   {
+   if (!StrEquals(dirname, Any))
+   {
+   next = flags_ptr;
+   }
+   }   
+   else if (dir  DIR_MAJOR_MASK)
+   {
+   error = 1;
+   }
+   free(dirname);
+   }
+
+   if (!error)
+   {
+   if (((dir == DIR_W || dir == DIR_NONE) 
+   Scr.PanFrameLeft.isMapped) || 
+   ((dir == DIR_N || dir == DIR_NONE) 
+   Scr.PanFrameTop.isMapped) ||
+   ((dir == DIR_S || dir == DIR_NONE) 
+   Scr.PanFrameBottom.isMapped) ||
+   ((dir == DIR_E || dir == DIR_NONE) 
+   Scr.PanFrameRight.isMapped))
+   {
+   match = 1;
+   }   
+   else
+   {
+   match = 0;
+   }
+   }
+   flags_ptr = next;
+   }
+   else if (StrEquals(cond, EdgeHasPointer