Subject: CVS domivogt: * Removed key release bindings.

From: FVWM CVS <[email-masked]>
Date: Sun, 09 Mar 2003 17:16:26 -0600

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	03/03/09 17:16:25

Modified files:
	.              : ChangeLog NEWS 
	docs           : ChangeLog FAQ 
	fvwm           : bindings.c builtins.c events.c fvwm.1.in 
	                 placement.c 
	libs           : Bindings.h Colorset.c 
	modules        : ChangeLog 
	modules/FvwmTaskBar: FvwmTaskBar.c 

Log message:
* Removed key release bindings.
* Fixed FvwmTaskBar core dump when resizing the task bar.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Marcin Pawlik <[email-masked]>
Date: Tue, 11 Mar 2003 01:12:35 +0100

> 	fvwm           : bindings.c builtins.c events.c fvwm.1.in 

As a few things changed in the placement.c code I was once asking about,
I think repeating my question may be useful somehow.

The problem was (and still is) in iconification/deiconification of
windows followed by PlaceAgain command. If I iconify a window, move
(GotoDesk) to another desktop then deiconify the window and do
PlaceAgain for it, the window is moved to the desk where it was
iconified. It even prints "map on new desk:" on stderr now.

When I replace SGET_START_DESK(style) parameter in PlaceWindow
invocation in CMD_PlaceAgain function with 0, it behaves OK but this
hack is probably not a real solution.

Regards,

-- 
Marcin Pawlik

---

From: Marcin Pawlik <[email-masked]>
Date: Tue, 11 Mar 2003 01:52:13 +0100

> iconified. It even prints "map on new desk:" on stderr now.

A simple test:

- Create xterm window
- All (xterm) Iconify
- Change desk
- All (xterm) Iconify off
- All (xterm) PlaceAgain

Window is moved to the desk it was iconified and is not displayed. It
can be seen in FvwmPager, but on the screen is shown only after desktop
changing back and forth.

Regards,

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 11 Mar 2003 09:12:31 +0100

> hack is probably not a real solution.

That is why I was working in placement.c.  I haven't found a
satisfying solution yet.  It is surprisingly difficult to find out
the right value for the start desk.  I had already tried a patch,
but it did not work as it should, so I commented it out.  That is
the change you saw.

Bye

Dominik ^_^  ^_^

---

From: [email-masked]
Date: Tue, 11 Mar 2003 23:51:52 +0100

> can be seen in FvwmPager, but on the screen is shown only after desktop

You *really* should have mentioned that you use the StickyIcon
style (cost me about one houre to figure that out).  :-/  I have
fixed this particular and other PlaceAgain relateg problems.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Marcin Pawlik <[email-masked]>
Date: Wed, 12 Mar 2003 01:21:20 +0100

On Tue, Mar 11 at 23:51, [email-masked] wrote:
>> Window is moved to the desk it was iconified and is not displayed.
>> It can be seen in FvwmPager, but on the screen is shown only after
>> desktop changing back and forth.
> 
> style (cost me about one houre to figure that out).  :-/  

I'm sorry. I didn't realize it is important. Poor excuse, I know - it's
obvious but I just didn't think about this.

> I have fixed this particular and other PlaceAgain relateg problems.

Iconification works OK now, thanks.

Apropos - maybe there could be some "bug reporting configuration"?
I think about a file containing only the default fvwm settings, without
additional menus, bindings etc. Settings should be placed in the file so
there will be no confusion if they're changed in the code. This way,
when talking about a bug, one could say what's wrong and maybe what
should be modified to reproduce that behaviour. What do you think?

Regards,

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 12 Mar 2003 08:10:25 +0100

> should be modified to reproduce that behaviour. What do you think?

There is the fvwm-bug shell script, but that does not store any
configuration details.  At present, it's nigh impossible to
determine the configuration without user interaction or running
fvwm - but fvwm has no way to dump the config at the moment.

Bye

Dominik ^_^  ^_^

---

From: Marcin Pawlik <[email-masked]>
Date: Wed, 12 Mar 2003 13:54:09 +0100

On Wed, Mar 12 at 08:10, Dominik Vogt wrote:
>> Apropos - maybe there could be some "bug reporting configuration"?  I
>> think about a file containing only the default fvwm settings, without
>> additional menus, bindings etc. Settings should be placed in the file
>> so there will be no confusion if they're changed in the code. This
>> way, when talking about a bug, one could say what's wrong and maybe
>> what should be modified to reproduce that behaviour. What do you
>> think?
> 
> configuration details.  At present, it's nigh impossible to determine
> the configuration without user interaction or running fvwm - but fvwm
> has no way to dump the config at the moment.

That would be useful of course, but it's not exactly what I was talking
about. My config has now some 650 interpretable lines and its dump would
certainly consist many informations not relevant to the question.

I thought about a situation when after finding something suspitious I
could replace my own configuration with a simple "bug reporting" one
taken from the file in CVS tree. I could examine the problem and then
send you report saying "I found this. To reproduce it you have to change
A to B in well-known configuration, then do that. Is it a bug?". Config
should be written somewhere to be easy to see and modify and possible to
set even if fvwm defaults are changed.
With that approach you would know the whole situation, without
additional costs and not having to rely on my guesses about what's
important. Repeated in many reports simple configuration would probably
make communication clearer.

Regards,

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 12 Mar 2003 13:58:43 +0000

> make communication clearer.

How is this different from the following user report:

Here is a minimal rc file containing 3 lines (one Style, one Exec etc)
that when placed in ~/.fvwm/minimal-rc and called as "fvwm -f minimal-rc"
or directly "Restart fvwm -f minimal-rc" shows the problem. (Description
of the problem follows.)

Regards,
Mikhael.

---

From: Marcin Pawlik <[email-masked]>
Date: Wed, 12 Mar 2003 21:54:51 +0100

On Wed, Mar 12 at 13:58, Mikhael Goikhman wrote:
>> send you report saying "I found this. To reproduce it you have to
>> change A to B in well-known configuration, then do that. Is it a
>> bug?".  Config should be written somewhere to be easy to see and
>> modify and possible to set even if fvwm defaults are changed.  With
>> that approach you would know the whole situation, without additional
>> costs and not having to rely on my guesses about what's important.
>> Repeated in many reports simple configuration would probably make
>> communication clearer.
> 
> that when placed in ~/.fvwm/minimal-rc and called as "fvwm -f
> minimal-rc" or directly "Restart fvwm -f minimal-rc" shows the
> problem.
> (Description of the problem follows.)

User knows his (or her) config but probably doesn't know what are the
default settings. If I have two configs - my and the default one I can
almost imediatelly see and check the important differences and write you
about them. Of course settings are present in the code and described in
the manual but they consist many other informations and it's really hard
to extract only the defaults.

Even if the minimal config is created it is connected only to a
particular fvwm version. The same minimal config would behave
differently in different versions. This doesn't carry any informations
since you don't know if it's so because of changes in defaults or the
functionality. After some commits one can find out that an error
appeared. If the defaults were also changed, the behaviour could be
simply compared by running fvwm with both "bug configs". I can see no
easy way to do it without config files.

If you ask users to create the whole minimal configuration, they would
probably submit all the settings that they think are important. When
asked only for changes, they could see that most things are already set.
I think life could be easier with reports including only the
modifications of the configuration you know really well (because you
often see it). And the file with all the options and their settings
should be handy anyway.

Regards,