Re: COVID-19: Hope everyone's well

[Viktor Griph]

Den ons 20 maj 2020 03:22Thomas Adam  skrev:

> On Sat, Mar 21, 2020 at 03:20:06PM +, Thomas Adam wrote:
> > Hi everyone.
> >
> > Just emailing to check that everyone's OK and not suffering too much at
> the
> > moment.  I know different countries are largely doing the same things as
> one
> > another -- and I'm working from home for the foreseeable.
> >
> > I really do hope no one's suffering and feeling unwell.  Let's keep in
> touch,
> > please.
>
> Hello all,
>
> Replying to myself... I know, it's weird!
>
> I'm glad folks are OK.  It's been a few months later since I sent this
> email
> and in a way a lot has changed for some, and yet a lot still stays the
> same.
>
> One thing that has been popular with myself and others is an increase (or a
> start, for some!) in the use of video conferencing.  It's even become a
> tired
> advertising cliche from the likes of Microsoft and Google on television.
> I've
> been making use of video conferencing each lunchtime to solve cryptic
> crosswords with a friend.
>
> One idea I had which I'd thought I'd ask is if anyone here is interested in
> holding a video conference -- say, on Zoom or Google Meet?  I'd be very
> happy
> to host that.
>
> I know that in the ~20 years since I appeared interested in FVWM. I've
> spoken
> to so many of you via email (including those who've moved on to other
> projects), but I don't believe anyone here has necessarily had a
> conversation.
>
> So... I'm putting that idea out here.  If you're interested, let me know
> and
> I'll set something up.
>
> Thanks everyone, and as always I hope you're all safe and keeping well.  Do
> please keep in touch, won't you?
>
> Thomas
>

Hi all, it's been a long time since I did anything fvwm related. I don't
use Linux at work, and have not been that interested in coding on my spare
time when I code during daytime.

Maybe things will change, I don't really know for sure. At least I'm well
and wotking partly from home and partly in the office.

Regarding some kind of video conference I think it could be cool to join.

Regards
Viktor

>

Re: FVWM: deprecated? placing firestorm windows?

[Viktor Griph]

Den mån 27 aug. 2018 00:27hw  skrev:

> With Firefox, I think using FixedPPosition, !UsePPosition fix it as
> well, but the problem is that for some reason, fvwm does not place the
> windows according to the placement policy.

As you describe it it sounds as if Firefox maps the new window before
restroing the size of the window, so Fvwm will do it's placement logic
based on whatever sixe firefix has put on the windows when they are
displayed, and once placed, Firefox rezises the windows to the old
size. (It should be obvious from the ExplainWindowPlacement option if
that's the case.)
You can also try to use the "PlaceAgain" comman on the Firefox windows
once they are all restored and see if they pace as you expect then. If
so, you might be able to do some magic with FvwmEvent to trigger a
PlaceAgain automatically on Firefox windows, but I'm not certain it is
possible, or how to configure the module to do it.

//Viktor

Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]

[Viktor Griph]

2018-03-03 7:03 GMT+10:30 Thomas Adam :
> However, we're not out of the woods yet, as there's the following
> complications:
>
>  * Copyright 1996, Romano Giannetti.
>  * Romano Giannetti - Dipartimento di Ingegneria dell'Informazione
>  *via Diotisalvi, 2  PISA
>  * mailto:rom...@iet.unipi.it
>  * http://www.iet.unipi.it/~romano

http://www.rgtti.com
Cross referened with Linked In. Worked as researcher at the University
of Pisa in 1996 when the copyright notice was written.

> /*  Copyright 1994,  Mike Finger (mfin...@mermaid.micro.umn.edu or
>  *   mike_fin...@atk.com)

https://www.linkedin.com/in/michaelsfinger
(Only Mike Finger (on Linked In) that studied at University of Minnesota.)

>
> /* Copyright 1994, Robert Nation and Nobutaka Suzuki. */

Nobutaka Suzuki seems to have been involved in many modules. (Google
for Nobutaka Suzuki fvwm, and you find that he is referenced in many
man pages, and some other (older?) sources). Found an email-address in
one of those comments, which lead me to his master thesis at NARA
Institute of Science and Technology.
That theses led me to
http://nslab.slis.tsukuba.ac.jp/~nsuzuki/

>
> So I need to track down these additional people as well before I can remove
> the full clause.

I think I found them for you.

Re: FVWM: IconBox an De-Iconify + Maximize

[Viktor Griph]

Hi,

2018-03-01 21:28 GMT+10:30 Michelle Konzack :
> I have setup a function
>
> [ ~/.fvwm/Functions.d/IconifyOffAndMaximize.conf ]--
> DestroyFunc IconifyOffAndMaximize
> AddToFunc   IconifyOffAndMaximize
> + I Iconify Off
> + I Maximize
> 
>
> Which alredy de-Iconify the Icon but Maximize has not the right  effect,
> because if the Window was maximized before it was iconified,  it  become
> De-Maximized, which is not what I want.

That's right. Just add the argument True to the Maximize command and
you will be fine:
+ I Maximize True

//Viktor

Re: FVWM: FvwmTaskbar autohide strange behaviour

[Viktor Griph]

2018-03-01 5:32 GMT+10:30 Michelle Konzack :
> OK guys,
>
> I have this config:
>
> [ ~/.fvwm/Functions/AutoHide.conf ]-
> DestroyFunc autohide
> AddToFunc autohide
> + I ThisWindow ("$0") Deschedule $[w.id]
> + I ThisWindow ("$0") ThisWindow (Shaded) WindowShade off
> + I TestRc (!Match) All ("$0", !Shaded) autohide_hide $1 $2
>
> DestroyFunc autohide_hide
> AddToFunc autohide_hide
> + I Schedule $0 $[w.id] WindowShade $1
> + I Schedule $0 $[w.id] Deschedule $[w.id]
>
> AddToFunc StartFunction
> + I Module FvwmAuto FvwmAutohide -menter enter_handler
>
> DestroyFunc enter_handler
> AddToFunc enter_handler
> + I autohide FvwmTaskbarPanel 500 S
> 
>
> and the result is a strange behaviour:
>
> 1) The "FvwmTaskbarPanel" is only shown, if I was on  "FvwmTaskbar"  and
>move a little bit up.
>
>From the manpage:
> In -menter mode, FvwmAuto raises the window under the
> pointer when the pointer enters a window.
>
>In my case, it should act, if I enter "FvwmTaskbar" and then
>unhide "FvwmTaskbarPanel". It seems, I have to modify something
>because the above 4 functions are universal. I think, in the
>case of "FvwmTaskbar" I have to write them explicit for it.
>
>Now it looks like:
>
> [ ~/.fvwm/Functions/AutoHide.conf ]-
> DestroyFunc FvwmTaskbarAutohide
> AddToFunc   FvwmTaskbarAutohide
> + I ThisWindow ("FvwmTaskbarPanel") Deschedule $[w.id]
> + I ThisWindow ("FvwmTaskbarPanel") ThisWindow (Shaded) WindowShade off
> + I TestRc (!Match) All ("FvwmTaskbarPanel", !Shaded)
> FvwmTaskbarAutohide_hide 500 S
>
> DestroyFunc FvwmTaskbarAutohide_hide
> AddToFunc   FvwmTaskbarAutohide_hide
> + I Schedule $0 $[w.id] WindowShade $1500
> + I Schedule $0 $[w.id] Deschedule $[w.id]
>
> AddToFunc StartFunction
> + I Module FvwmAuto FvwmAutohide -menter FvwmTaskbarAutohide
> 
>
> ...and it works the same way as before!

Do you mean it's no different from the one where you pass
FvwmTaskbarPanel as a parameter? Because it shouldn't be, unless
something in your command reading pipeline cause parameters to be
expanded when the functions are built rather than at execution. In
that case you could expand them, or try the - command prefix. To see
what actually gets passed around, it might be good to add an Echo at
the start of the function printing all parameters used in that
function.

>
> 2) Sometimes, the "FvwmTaskbarPanel" hide, even the pointer is on focus.
>

I think this might have to do with that on a normal mouse enter you
schedule two commands with the same id, and possibly only deschedule
one, so unless you go in and out twice of the window it would be
shaded anyway. You should remove the + I Schedule $0 $[w.id]
Deschedule $[w.id] from the *_hide functions. And since it will only
consist of a single command then, you could inline Schedule command to
use one function less, and get the logic in one place.

Not, that I'm not entirely sure of how fvwm handles the case where you
schedule multiple commands with the same command id, and then
deschedules that command id, to the above is a best guess at
explaining the behaviour you are seeing.

Regards
//Viktor

Re: [SOLVED] Re: FVWM:

[Viktor Griph]

2018-02-28 8:06 GMT+10:30 Michelle Konzack :
> The "Use comma" érror is now gone!
>
> However, it does not what I want to archive and I do not realy
> understand how it works.  Still trying to figure out, how functions
> are working, since I have never used it in the last 19 years!

Use FvwmIdent to figure out how to match the taskbar. Then update the
event_handler function and replace FvwmTaskbarPanel with something
that match your taskbar.

//Viktor

Re: FVWM:

[Viktor Griph]

2018-02-28 6:14 GMT+10:30 Michelle Konzack :
> ...but I found this file is guilty:
>
> [ ~/.fvwm/Functions.d/AutoHide.conf ]---
> DestroyFunc autohide
> AddToFunc autohide
> + I ThisWindow ($0) Deschedule $[w.id]
> + I ThisWindow ($0) ThisWindow (Shaded) WindowShade off
> + I TestRc (!Match) All ($0, !Shaded autohide\_hide $1 $2)

That's the line giving the warning. You are trying to use
autohide\_hide $1 $2 as a condition without commas.
Try to change it to
+ I TestRc (!Match) All ($0, !Shaded) autohide\_hide $1 $2

I'm not sure why you need to escape _ in the above code. If it doesn't
work still, try to remove the escape as well.

/Viktor

Re: [SOLVED] Re: FVWM: Jumping cursor

[Viktor Griph]

2018-02-27 21:02 GMT+10:30 Michelle Konzack :
> OK, the cursor does not more jump, but now I get with every
> click in an application tonns of error message like:
>
> DestroyFunc EWMHActivateWindowFunc
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> [fvwm][__execute_function]: <> No such command
> 'EWMHActivateWindowFunc'
> 
>
> which is not, what I expected...

Just create an empty EWMHActivateWindowFunc after you destroyed the
built-in one.
AddToFunc EWMHActivateWindowFunc
+ I Nop

Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]

[Viktor Griph]

2018-02-13 0:44 GMT+10:30 Thomas Adam :
> If no one objects, I'll go ahead an start making the relevant changes?

I say go ahead. Good that the email found its way to him in the end.

//Viktor

Re: FVWM: Code Licence

[Viktor Griph]

2018-02-11 8:24 GMT+10:30 Thomas Adam :
> Hence, the only known email address is:
>
> robert.j.nat...@baesystems.com
>
> I'd be amazed if he still worked for BAE.  Meh.  I could try phoning him based
> on the information you've given, Viktor.  It's certainly a help, thanks!

I think he might actually do. I just searched Linked In, based on the
information that he used to work on BAE, and found a profile[1] which
matches with the background given in an interview in the Linux Journal
1997[2].

[1] https://www.linkedin.com/in/robert-nation-7598034a/
[2] http://www.linuxjournal.com/article/2164

Re: FVWM: Code Licence

[Viktor Griph]

2018-02-11 7:35 GMT+10:30 Thomas Adam :
> On Sat, Feb 10, 2018 at 09:50:23PM +0100, Dominik Vogt wrote:
>> Hi Thomas,
>
> Hello, old friend.  How are you?  Keeping well, I trust?
>
>> On Sat, Feb 10, 2018 at 04:32:51PM +, Thomas Adam wrote:
>> >   Robert Nation
>> >   8 Huckleberry Lane
>> >   Merrimack, NH
>> >   03054
>
> Ths is interesting.  I even took a look on Google Maps, it seems like a nice
> place.  I could always send a postcard to find out.  But 2003 was a while ago
> now.
>
>> I'm neither sure whether this information is still valid nor
>> whether it's a good idea to call him if it is.  Maybe a letter
>> would be better.  And I cannot remember him actually sending a
>> message to fvwm-workers in 2003 (he said he would) - I definitely
>> never sent an email to him personally.
>
> That's a shame as it would have mase things easier.  Thank you for the
> information though -- much appreciated!

I think he has moved from the above address. At least there is a
Robert J Nation who has that address listed as a previous address:
https://www.whitepages.com/name/Robert-J-Nation/Deerfield-NH/2i6uza7

Re: FVWM: Code Licence

[Viktor Griph]

2018-02-11 7:00 GMT+10:30 Thomas Adam :
> On Sat, Feb 10, 2018 at 01:23:28PM -0700, Jaimos Skriletz wrote:
>> On Sat, Feb 10, 2018 at 12:05 PM, Thomas Adam  wrote:
>> > On Sat, Feb 10, 2018 at 12:02:04PM -0500, Dan Espen wrote:
>> >> Seems like a reasonable approach to me.
>> >
>> > I have collated a list of known authors of fvwm to date, and put it here:
>> >
>> > https://github.com/fvwmorg/fvwm/wiki/List-of-all-FVWM-Authors
>> >
>>
>> There is also this list
>>
>> http://www.fvwm.org/authors/
>
> Yes, but many of those names have no email addresses associated with them,
> which is why I've largely ignored it.  Unfortunately, we need a pragmatic
> approach to this.
>
> -- Thomas Adam
>

I think some of them are still subscribed to the fvwm-workers list. I
know that Simon Griph has not changed his e-mail address since he
submitted his patches.

//Viktor

Re: regression from 2.6.5 to 2.6.6 ?

[Viktor Griph]

2016-10-23 17:05 GMT+02:00 Dominik Vogt <dominik.v...@gmx.de>:
> On Sun, Oct 23, 2016 at 04:39:53PM +0200, Viktor Griph wrote:
>> Den 23 okt. 2016 14:36 skrev "Dominik Vogt" <dominik.v...@gmx.de>:
>> > void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
>> > {
>> > if (cr->value_mask & CWX)
>> > {
>> > cr->x = (((int)cr->x) & 0x);
>> > }
>> > ...
>> > if (cr->value_mask & CWHeight)
>> > {
>> > cr->height = (((unsigned int)cr->height) &
>> 0x);
>> > }
>> > ...
>> > }
>> >
>> > This tries to deal with an inconsistency between the X protocol
>> > and the Xlib structures:  In the X protocol, in the
>> > ConfirureWindow request, X and Y are signed "INT16" quantities and
>> > WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
>> > Xlib structures they are "int" or "unsigned int".
>> >
>> > The code tries to cut off the excess bits from X and Y and does it
>> > wrong.  With 32-bit integers, if cr->x is -1:
>> >
>> >  ((int)-1) & 0x = 0x & 0x
>> > = 0x
>> > = 65535
>> >
>> > I'm not sure how to fix this.  The easiest approach would be to
>> > cast these values to int16_t or uint16_t from stdint.h, but I
>> > vaguely remember there are some portability issues with the
>> > inttypes.s/stdint.h headers.
>>
>> Instead of setting the excess bits to 0 we need to set them to 1 for the
>> negative case.
>>
>> What about
>> if (cr->x & 0x8000)
>> {
>> cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
>> }
>> else
>> {
>>  cr->x = (((int)cr->x) & 0x);
>> }
>>
>> The negative case could be simplified to
>>
>> (((int)-1) ^ 0x7fff) | ((int)cr->x)
>>
>> Or
>>
>> ((int)-1)<<16|((int)cr->x)
>
> I never can remember this; is it safe (in C) to assume that
> negative integers are stored in two-complement format?  (Of course
> the old code makes the same assumtion, but it's broken and I want
> to fix it.)

So use (~(int)0) instead of -1 and it should work for both
one-complement and two-complement numbers. The MSB would still mark
the sign. (If what the code is trying to fix is that there may be
extra bits beyond the 16 bits that are defined in the X-server, then
those bits could be anything, and maybe wouldn't guarantee that
negative numbers are correctly 1-padded above bit 16, in fact they may
not even have the int MSB set. If that is the case then I don't think
casting to int16_t or uint16_t would be feasible. The standard
mandates the int16_t to be in two-complement form even if the hardware
is using one-complement so casting from int to int_16t on a
one-complement platform would change the bit pattern in order to
maintain the value, but if the value is out of range for the 16-bit
number due to the excess bits you are trying to correct. I'm not sure
if the handling of overflow at a cast to xxx16_t is well-defined cross
all platforms.

>
> If it's really portable, the cleanest way is casting to int16_t
> and uint16_t from stdint.h.

Definitely. I just don't know if it is.

Re: regression from 2.6.5 to 2.6.6 ?

[Viktor Griph]

Den 23 okt. 2016 14:36 skrev "Dominik Vogt" :
>
> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
> > On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote:
> >
> > > On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca
wrote:
> > >> On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:
> >
> > >>> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca
wrote:
> >  On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:
> >
> > > On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca
wrote:
> > >> I recently upgraded a computer from Slackware64 14.1 to 14.2,
which
> > >> bumped by fvwm version from 2.6.5 to 2.6.6.
> >
> > >> With the new system, when I ask Adobe reader 9.5.5 to go
full-screen,
> > >> I get a window with no decorations, but it only occupies about
3/4 of
> > >> the screen, off to the lower right.
>
> I've found the problem but I don't know how to fix it in a proper,
> i.e. portable way.  In FEvent.c we have this function
>
> void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
> {
> if (cr->value_mask & CWX)
> {
> cr->x = (((int)cr->x) & 0x);
> }
> ...
> if (cr->value_mask & CWHeight)
> {
> cr->height = (((unsigned int)cr->height) &
0x);
> }
> ...
> }
>
> This tries to deal with an inconsistency between the X protocol
> and the Xlib structures:  In the X protocol, in the
> ConfirureWindow request, X and Y are signed "INT16" quantities and
> WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
> Xlib structures they are "int" or "unsigned int".
>
> The code tries to cut off the excess bits from X and Y and does it
> wrong.  With 32-bit integers, if cr->x is -1:
>
>  ((int)-1) & 0x = 0x & 0x
> = 0x
> = 65535
>
> I'm not sure how to fix this.  The easiest approach would be to
> cast these values to int16_t or uint16_t from stdint.h, but I
> vaguely remember there are some portability issues with the
> inttypes.s/stdint.h headers.

Instead of setting the excess bits to 0 we need to set them to 1 for the
negative case.

What about
if (cr->x & 0x8000)
{
cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
}
else
{
 cr->x = (((int)cr->x) & 0x);
}

The negative case could be simplified to

(((int)-1) ^ 0x7fff) | ((int)cr->x)

Or

((int)-1)<<16|((int)cr->x)

>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: Removing libstroke support?

[Viktor Griph]

Den 18 okt. 2016 7:23 PM skrev "Dominik Vogt" <dominik.v...@gmx.de>:
>
> On Tue, Oct 18, 2016 at 06:29:59AM +0200, Viktor Griph wrote:
> > Den 17 okt. 2016 11:56 PM skrev "Dominik Vogt" <dominik.v...@gmx.de>:
> > >
> > > Does anybody really use libstroke support?
> >
> > I've been using it in my configs since I started using fvwm.
> >
> > > It's resonsible for
> > > quite some hardly readably code, and I suspect nobody uses it
> > > anymore.  If there's a need for mouse gesture or touchpad support,
> > > there must certainly be some other library around that does a
> > > better job.
> >
> > I haven't looked for alternatives, but it feels like the functionality
> > really should live in a separate application. It's not about managing
> > windows, but being able to execute commands on gestures.
>
> So, for what kind of actions do you use it?  Somthing window
> manager related like, say iconifying windows etc., or something
> else that could be done without the WM?
>
For the uses that I actually use is mainly launching applications, but I
have a few to launch or find a running instance and bring that window into
view. But that should still be possible with FvwmCommand. Apart from that I
have a few stokes defined for the title bar to resize, move and shade
windows, but I can't say I'm using them.

//Viktor

Re: Removing libstroke support?

[Viktor Griph]

Den 17 okt. 2016 11:56 PM skrev "Dominik Vogt" :
>
> Does anybody really use libstroke support?

I've been using it in my configs since I started using fvwm.

> It's resonsible for
> quite some hardly readably code, and I suspect nobody uses it
> anymore.  If there's a need for mouse gesture or touchpad support,
> there must certainly be some other library around that does a
> better job.

I haven't looked for alternatives, but it feels like the functionality
really should live in a separate application. It's not about managing
windows, but being able to execute commands on gestures.

//Viktor

Re: Deprecation: Let's talk once more about removing $STUFF...

[Viktor Griph]

2016-05-19 17:18 GMT+02:00 Thomas Adam :
> As I understand it, FVWM was written with extensibility in mind, and hence
> could be extended through the use of modules.  Although the core of FVWM is
> quite a bit larger now (read: some of the things ther could be modules, but
> hey-ho, one for another time), there are at least quite a few modules which
> change FVWM's behaviour.
>
> Long ago when developers were more active, getting the code into FVWM was
> easier, and perhaps more importantly, the maintainability was easier, since
> the author(s) of the code had a vested interest in keeping it alive.
>
> But those days have ended, as far as I am concerned.  People have lives, and
> have moved on, or simply don't use FVWM anymore.  That's OK, and that's what
> happens with software over time.  But the hole it leaves is almost always
> *somebody else's* mess.  In this case, right now, that mess is mine.

I definitely see you point - and agree that what FVWM should do is to
provide a stable module interface that could support modules. The
modules themselves would not have to be maintained by FVWM developers
and should neither have to follow the release cycle of FVWM. If
someone has an urge to see one of the modules you are removing to
survived it is no problem for that person to set up a separate
repository and maintaining that module outside of the core FVWM.

I'm one of many only FVWM developers who lurk in the shadows. I follow
the mailing lists, but have not been using FVWM myself for some time
since I'm stuck with Windows development at work, and mostly use my
home PC for surfing or gaming, so I've drifted away from X
development. If I'm ever getting back I'm sure I'll need to spend some
time at updating my config files since I'm quite sure Ive been using
FvwmTabs.

Re: FVWM: [fvwm] fltk window origin and fvwm

[Viktor Griph]

2014-05-26 6:23 GMT+02:00  szukw...@arcor.de:
 If this is not enough I give up. Because I now do know now it has to
 do with my configuration of fvwm.

Can you test and see if using the style MoveByProgramMethod UseGravity
on your windows helps?

/Viktor

Re: FVWM: window move issue

[Viktor Griph]

2014-04-22 20:09 GMT+02:00 Martin Cermak marti...@gmail.com:
 [...]
 Any further ideas or thoughts?

Does using the style OpaqueMoveSize 0 also leave artifacts on the
screen when moving windows, or is it just opaque move that is
affected?

/Viktor

Re: FVWM: wine / fvwm focus bunfight

[Viktor Griph]

2013/1/2 luke.leighton luke.leigh...@gmail.com

 it was too much to expect that they'd actually listen.  so, perhaps
 one for the FAQ?  known bug in wine, which the developers of wine
 don't understand and do not wish to acknowledge, so you, the fvwm
 user, are forced to put Style * Leniency in the .fvwm2rc config file.

 [...]
 --- Comment #1 from Alexandre Julliard julli...@winehq.org
 2013-01-02 05:54:18 CST ---
 Setting the input hint to False is correct, along with WM_TAKE_FOCUS it
 specifies that we use the Globally Active model. Whatever the bug may be,
 that's not it.


Does fvwm send the WM_TAKE_FOCUS client message as described in
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7?

/Viktor

Re: FVWM: WM_NAME versus _NET_WM_NAME

[Viktor Griph]

2012/9/17 Tom Horsley horsley1...@gmail.com:
 I found a thread in the archives from back in 2009 saying
 this issue was fixed:

 http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01957.html

 Yet in fedora 17, GIMP sets WM_NAME and _NET_WM_NAME to
 utterly different strings, and I'm getting the (useless)
 WM_NAME string rather than the (useful) _NET_WM_NAME
 string.

 Did this revert in later versions? I have:

Make sure that you have a font that can display all characters in the
_NET_WM_NAME. Gim uses a unicode dot in the title if I remember
correctly.

/Viktor

Re: FVWM: HEADS UP: Releasing 2.6.4 end of January

[Viktor Griph]

2012/1/27 Harry portobello harryportobe...@gmail.com:
 we have lots of patches like adding round corners and fluxbox handels
 which have not been added to fvwm in long time - and why is this? why
 isnt the maintainer - thomas - adding these?

There is no single maintainer of fvwm. It is maintained by
fvwm-workers. Thomas has been putting a lot of time and effort into
releasing 2.6, when no other fvwm-worker really has had the time to do
so. There are several reasons as of why certain patches aren't
accepted. Some of the patches affect areas of fvwm which in the long
term goal should be replaced by modules. Others are unclean, and no
one has been willing to clean up the code and write documentation for
the patches.

 so a new maintainer should listen more to this i hope

And what makes you think that another fvwm-worker will have more time
now, when Thomas have been mostly alone doing the all hard work for
quite some time. Just because he no longer have the time either, it
doesn't mean that other fvwm-workers will have more time.

/Viktor

Re: .po files of locale zh_TW

[Viktor Griph]

2011/4/18 Thomas Adam tho...@fvwm.org:
 Hello,

 On Mon, Apr 18, 2011 at 03:09:14PM +, Wei-Lun Chao wrote:
 Still not accepted in fvwm 2.6.x

  here are .po files of the locale
  zh_TW (Traditional Chinese)
  for fvwm 2.5.12

 Can you provide more context, please?  I have no idea what you're talking
 about here -- and still not accepted implies someone (not I) was aware of
 this issue in the past.  But this is the first I can recall of it.


The file was sent directly to me and Dominik at a time where I myself
at least was very busy, and I didn't notice it was not directed to
fvwm-workers until last year, when I replied and asked for the files
to be resent to fvwm-workers.

/Viktor

Re: FVWM: Google Summer of Code 2011

[Viktor Griph]

2011/3/9 Thomas Adam tho...@fvwm.org:
 On Thu, Mar 03, 2011 at 07:27:31PM +, Thomas Adam wrote:
 Hi all,

 Last year I was unsuccessful in applying for the GSoC deadline.  This year,
 I might improve upon that, assuming there's interest from folks here.

 The deadline for submissions is Friday 11th March, so I would need to know
 by end of tomorrow at the absolute latest so I can have time to prepare
 something.

 But given the response so far, maybe it's just the wrong time for FVWM to be
 considering this.

I hope to get back into workng actively on fvwm, but I don't want
tocomitt as a mentor before I know that I have the time. Maybe next
year.

/Viktor

Re: PATCH: lost window patch

[Viktor Griph]

2011/3/1 Dominik Vogt dominik.v...@gmx.de:
 I can vaguely remember that the existing code was meant to
 suppress some windows that would pop up and down in an infinite
 loop, but I can't recall the details.

If I remember correctly the existing code is a result of trying to get
something that works both with QT applications and some GTK
applications (e.g. GNU cash) as well as some windows that would get
into an infinite manual placement loop. (I think other placemnt
strategies worked for the window, only during manual placement they
were poping up and down forever.

/Viktor

Re: FVWM: lockup when moving/resizing windows

[Viktor Griph]

2010/12/19 Jason Timrod jtim...@yahoo.com:

 sometimes for no reason i get fvwm lockups when moving or resizing windows. i 
 think its fvwm??? if i resize a window the cursor changes and stays like it 
 and i can do nothing until fvwm unfreezes

Sounds like a module read/write timeout

 does fvwm log to a file so i can see if theres a ptoblem there?

Fvwm logs to standard error. You may redirect it to a file when
starting fvwm. Depending on how you start fvwm it may already be
redirected.

/Viktor

Re: Google Summer Of Code 2010

[Viktor Griph]

2010/3/7 Thomas Adam tho...@xteddy.org:
 The poignant things any prospective mentors are going to need to know
 [3] are covered in question 2 -- which I am happy to fill out, but note
 that this won't and cannot get off the ground without a *backup* mentor.
 That's critical, and one of the failings from last year's proposal.

 So -- anyone from fvwm-workers wanting to step up to that?  To be clear
 again -- I am offering to be main point of contact, etc., etc., the role
 of a backup mentor is to supplement my role should I die, or have no
 Internet access, etc.  Hopefully something unlikely!


I could probably serve as a backup mentor, but I will be on vacation
sometime this summer (I'm not sure of the timeline currently), at
which point I would not be able to step in as a mentor, should the
needs appear.

/Viktor

Re: FVWM: Per application urgency handling

[Viktor Griph]

2010/3/4 - Tethys tet...@gmail.com:
 Is it possible to have different behaviours for handing urgency hints
 depending on the application that set the hint? For example, I might want
 my instant messanger to do one thing, and my web browser to do something
 different. Specifically, firefox is raising itself to the top of the
 window stack every so often, which is *really* annoying. I'm assuming
 (although I haven't verified it) that this is because of an urgency
 hint. Currently, I can configure UrgencyFunc to do what I want when the
 hint is set, but it seems to be on a global level. Ideally, I'd want to
 be able to do:

        Style Pidgin UrgencyFunc IMUrgencyFunc
        Style Xchat UrgencyFunc IMUrgencyFunc
        Style Firefox UrgencyFunc BrowserUrgencyFunc

 or something along those lines. Any ideas?

You may use ThisWindow in UrgencyFunc to achieve this. It will work as
long as you don't need it to not even try to run a function for some
applications (because there is a grab from that application, so that
fvwm can't grab the pointer as needed to run a function.

/Viktor

Re: FVWM: Very slow when moving audacious window by dragging it

[Viktor Griph]

2009/6/23 Thomas Adam thomas.ada...@gmail.com:
 This isn't a bug in FVWM, and I would imagine awesome have commited
 the sin of assuming all bugs in applications are circumventable in a
 window manager.

 The XMMS1 folks didn't like this approach by us, and Audacious clearly
 won't either.  ;)


Of course, this bug is caused by the use of  and EWMH activate
window request before the EWMH move is initiated. And because of the
implementation in fvwm to call a complex function, fvwm will try to
grab the pointer, which won't work since the client still holds a
grab, and thus there will be a timeout (the reported delay) before
fvwm gives up on trying to activate the window. There is a workaround:
to destroy the EWMHActivateWindowFunc.

/Viktor

Re: FVWM: fvwm forum completly down?

[Viktor Griph]

2010/2/12 Thomas Adam tho...@xteddy.org:
 I've asked for help, but no one's yet come forward -- not surprising when
 the problem is rather PhpBB-specific, and those folks haven't gotten back to
 me either.  :P

Do you have any link to a mail conversation where you describe the
problem? Or could you describe what the problem is briefly?

/Viktor

Re: FVWM: FVWM and beep-media-player woes

[Viktor Griph]

2005/9/3 David Wu zeo33x-f...@introspector.net:
 Hi all.

 I use beep-media-player (bmp) as my music player since it supports GTK2.
 I have the following problem when I use it under fvwm 2.5.14-1

 Whenever I drag the main bmp window from point A to point B quickly, the
 window is instantly teleported from point A to point B without
 actually showing the window being dragged. However, i can fix this if I
 mouse click the bmp window and hold without moving, and wait
 approximately 3 seconds, the window will behave just fine being dragged.

 Im inclined to think that this has something to do with fvwm since both
 default windows manager used by KDE and gnome has no such issue with
 beep-media-player.

 I understand bmp like xmms both handle their own window, but I've taken
 look at the bmp move code and it seems all that its doing is calling
 gtk_move_window() which supposedly asks the window manager to do the
 moving. I've also tried the stable version of fvwm and it works fine,
 but its missing some much desired features.

 Does anyone know what could cause this type of problem?

 Thanks all in advance!

First of all. Sorry for this being a very late reply. I've started to
go through old mail which I intended to reply to, that have
accumulated over long time.

From my experience with applications that want to handle their own
movement, they generally do an EWMH activate window request before the
move request. With fvwm this is bad, because that request will trigger
the function EWMHActivateWindowFunc, and because of the way function
invocations are handled in fvwm, fvwm will try to grab the pointer
before invoking the function. A possible workaround for this is to
destroy the EWMHActivateWindowFunc. This will generate warnings that
the function does not exist, but fvwm will not try to grab the
pointer. (It is not enough to redefine the function empty)

/Viktor

Re: FVWM: 2.4 = 2.5 upgrade breaks xcuckoo

[Viktor Griph]

2010/1/8 Jim Kalb jimk...@gmail.com:
 I just tried upgrading to 2.5.28 and both stopped working.

 [...]

 So I assume that there's some generally-used window manager
 modernization that breaks xcuckoo and probably nothing can be done about
 it short of modifying xcuckoo (not something I'm competent to do).

Can you give fvwm 2.5.27 a try? I think what you are seeing is the
result of the Fvwm now retains utf8 window names when the WM_NAME
changes, and the utf8 name converted to the default charset match the
old WM_NAME bug fix in 2.5.28.

/Viktor

Re: FVWM: 2.4 = 2.5 upgrade breaks xcuckoo

[Viktor Griph]

2010/1/8 Jim Kalb jimk...@gmail.com:
 Don't know if that rings any bells. If not, I'll look at wmctrl. A
 quick google suggests it might be used in a script that can do the
 same thing, although scripting isn't my long suit.

You can probably do it with Fvwm's Schedule command with the Periodic
option together with wmctrl.

/Viktor

Re: FVWM: 2.4 = 2.5 upgrade breaks xcuckoo

[Viktor Griph]

2010/1/8 Thomas Adam thomas.ada...@gmail.com:
 On Fri, Jan 08, 2010 at 05:25:38PM +0100, Viktor Griph wrote:
 2010/1/8 Jim Kalb jimk...@gmail.com:
  I just tried upgrading to 2.5.28 and both stopped working.
 
  [...]
 
  So I assume that there's some generally-used window manager
  modernization that breaks xcuckoo and probably nothing can be done about
  it short of modifying xcuckoo (not something I'm competent to do).

 Can you give fvwm 2.5.27 a try? I think what you are seeing is the
 result of the Fvwm now retains utf8 window names when the WM_NAME
 changes, and the utf8 name converted to the default charset match the
 old WM_NAME bug fix in 2.5.28.

 Hmm.  I am not so sure.  The condition SET_HAS_EWMH_WM_NAME(fw, 1) for
 that fix was just shifted up -- but it has always been set in
 fvwm/ewmh_names.c::EWMH_WMName() to True.

The difference is that before, it would not be set if the EWMH name
matched that of the classic WM_NAME exactly, which meant that it was
possible to chnage the WM_NAME and have that override the name
specified in _NET_WM_NAME. [1]

/Viktor

[1] http://www.mail-archive.com/fvwm-work...@fvwm.org/msg01954.html

Re: Recent change to read.c

[Viktor Griph]

2010/1/7 Thomas Adam thomas.ada...@gmail.com:
 On Thu, Jan 07, 2010 at 11:25:29AM -0500, des...@verizon.net wrote:
 I don't think using CWD is part of documented behavior...

 Hmm -- Do What I Mean (DWIM) approach here.  It doesn't say it isn't part of
 documented behaviour either.  :P

 Making CWD the new default...hmm.

 Not the default unless specified as such, see below.

I think that a better approach would be to add the CWD to the begining
of the search path when processing command line arguments, but not
from the config files. From config files, the DWIM approach would be
to have it look for files relative to the curently read file, and not
for the CWD of fvwm, but for that we have $., so it's not really
needed.

/Viktor

Re: fvwm-convert-2.6: Testing needed.

[Viktor Griph]

2010/1/2 Paul Vojta vo...@math.berkeley.edu:
 However, if xsltproc is to be required for building fvwm, I don't see where
 this is documented.  It's not mentioned on the otherwise excellent web page
 http://www.fvwm.org/documentation/dev_cvs.php , and ./configure doesn't
 print a warning when it finds that xsltproc is absent.  Instead, it just
 says

        checking for xsltproc... no

 and later

        Build man pages?                    no: No xsltproc found in PATH

 This suggests that fvwm is supposed to build (w/o building man pages) in
 the absence of xsltproc.

 So, either way there's a bug, either in the documentation or in the
 build process.

It is supposed to depend on the build target. xsltproc should only be
required for building a distribution, since the man pages will be
prebuilt and shipped with the tarball. However the way it is setup, if
the man pages are missing, as in the case with a fresh cvs checkout,
they will be built anyway. I consider that a bug in the build system.
I'm not sure if the best solution is to allow building from CVS
without documentation, or requiring xsltproc when building from CVS.

/Viktor

Re: Any outstanding issues/bug-fixes? (FVWM 2.6.0)

[Viktor Griph]

2010/1/2  des...@verizon.net:
 des...@verizon.net writes:

 I bring up a menu, pin it with button 2 on the title bar, then
 click on a pixmap on the title bar with an X.

When I was trying to reproduce this I ran int another bug:

When invoking a menu with the mouse over the title and clicking with
button 2 on the title, without moving the mouse, the menu will only
tear off if it was the first invocation of the menu. Otherwise it will
just close the menu

The simplest way to test this is probably to issue the menu command
from FvwmConsole with some menu with a title.

As far as I can tell this is due to the XFindContext-if statement in
find_entry in menus.s, but I don't know for sure what the right fix
is.

/Viktor

Removing focus from a module

[Viktor Griph]

I'm looking for a way to ensure that no window has focus under certain
conditions for a module I'm working on, and I've figured that there is
no good way to forcefully move the focus to the nofocus window. It is
possible by something like Current WindowStyle NeverFocus, but then
the module would have to know what to restore the focus policy to.
Would adding a DeleteFocus command be a good solution, or is there
some other preferred way to achieve this?

/Viktor

Re: FVWM: Meta: Reply-To header (Was: question about FvwmButtons config)

[Viktor Griph]

2009/10/7 John Meissen j...@meissen.org:


 ti...@math.uh.edu said:
 The list doesn't control where replies go; the person sending the reply does.
 And in any case, correct depends on the nature of the reply; it's 
 completely
 up to the sender to make sure that the message destination is as intended.  
 It
 is only a sign of negligence to abdicate that to some piece of software.

 The list can't control the sender's actions, but it can set the default. WRT
 correct, I expect replies to go back to where the message came from. If
 I'm replying to an exchange in a mailing list I expect the reply to go
 to the list. If I'm replying to a private correspondence I expect the
 reply to go to the individual I'm corresponding with. These aren't
 difficult concepts.

 If you want something done a certain way you should make it easier, not
 more difficult. The way the list is configured now you have to remember to
 edit the recipient addresses every time you reply to a list email. That
 will almost guarantee that occasional replies will go out as private
 emails and not to the list.

Then the right way would not be to set Reply-To headers in the list,
but to provide a List-Post header. Using that allows email clients to
offer the option reply to list without removing the options to reply
to the sender or to reply to all recipients.

/Viktor

Re: FVWM: [OT] (semi-transparent) cursors

[Viktor Griph]

2009/9/2 Lucio Chiappetti lu...@lambrate.inaf.it:
 Not strictly an fvwm question, but there are surely lot of X competent
 persons on this mailing list, so please forgive (and eventually redirect me
 to more appropriate places).

 Is there a way to define (or emulate via another x application ?) an X
 cursor which (will run in a fvwm session and) :

  - is rather large (say an ellipse surrounding a word in a typical size
   font)

  - is semi-transparent (say the outline of an ellipse but let shine
   through what is behind the interior)

  - can be forced to override any cursor defined by other applications

 My purpose is to present in a videoconf a PDF document and a set of web
 pages, and being able to highlight parts of it moving the mouse (like a
 laser pointer in a local presentation). The typical cursors are not that
 visible after all.

You probably have best luck overriding XDefineCursor for the
application using LD_PRELOAD. For a simple implementation using fvwm,
and not caring about if other courses change as well you could do as
follows:

1. draw a png-image with an alpha channel for use as your cursor.

2. Add CursorStyle DEFAULT your_image.png X_hotspot Y_hotspot
(probably good to have in the center of your circle) to your fvwm
configuration.

3. Create a small C-file with contents similar to this:

nocursor.c:
#include X11/Xlib.h
int  XDefineCursor (Display* display, Window w, Cursor cursor) {
return Success;
}

4. complie this file as a shared library:
 gcc -fPIC -shared -o nocursor.so nocursor.c

5. start the application you don't want to be able to set its own
cursor with LD_PRELOAD set to the absolute path to nocursor.so
compiled above.

The result of that will be that your shared function will override any
call to XDefineCursor made by the program. (Not that this won't work
if the program takes special measures to bind to the X-libraries
dynamically at runtime (SDL does that) in which case you would have to
overrride some other function in order to be able to intercept the
define cursor calls.

/Viktor

Re: Firefox annoyances, once more

[Viktor Griph]

2009/8/28 Jesús Guerrero i92gu...@terra.es:
 On Fri, August 28, 2009 09:52, Viktor Griph wrote:
 2009/8/28 Jesús Guerrero i92gu...@terra.es:

 News,


 I compiled fvwm-2.5.27, restarted, and it works without a hitch.
 So, it seems that, whatever the problem is (and I am not saying
 it's in fvwm), it only happens with the current cvs.

 I don't know when did this start, I noticed it a couple or three
 days ago.

 I am using pure cvs, no extra patches, not even the menu translucency
 stuff.

 Test to reverse ewmh.c to the previous revision and see if the problem
 goes away. If so, please post the output of xprop for the firefox window
 with and without that commit.

 Eureka.

 With revision 1.77 of ewmh.c it works ok, all the dialogs come in
 when invoked and the tab-bug doesn't exist.

 With revision 1.78 of that same file the dialogs doesn't come up,
 and the bug exist.

 I attach xprops for both, as well as for 2.5.27, in case you have
 some use for it.

I've made some quick look into this, and it is conflicting 64-bit
fixes. (Double conversion to long from values assumed to be CARD32.)
The change I made was to make  ewmh_ChangeProperty operate in reverse
of ewmh_AtomGetByName, which seems desirable. However most functions
setting properties send long values to ewmh_ChangeProperty, but some
don't (the _NET_WM_ICON updater for instance.)

I'll look into and see how many properties which are both read (with
ewmh_AtomGetByName) and updated (with  ewmh_ChangeProperty) in which
case conversion is needed before updating the properties. For those
properties just set by fvwm the different approaches to the handling
of 32 bit properties have no importance. I believe that it should be
possible to set a property with ewmh_ChangeProperty to a value
retrieved from ewmh_AtomGetByName, which means that either the
conversions should stay, or they should be removed and the internal
types should be changed to long values instead of CARD32.

Just fixing the issue is simple, but doing it right requires some
though. Any input on how to best handle this is welcome. I'll
implement a fix for the current issue, but I don't want the discussion
to end with that.

Re: CVS griph: * fix setting of 32 bit ewmh properties on 64 bit machines

[Viktor Griph]

2009/8/26 Thomas Adam thomas.ada...@gmail.com:
 2009/8/26 FVWM CVS fvwm-workers@fvwm.org:
 CVSROOT:        /home/cvs/fvwm
 Module name:    fvwm
 Changes by:     griph   09/08/25 18:27:08

 Modified files:
        fvwm           : builtins.c ewmh.c ewmh_icons.c

 Changelog?  Possibly NEWS?


Sorry about that. I commited in the wrong directory. That's what I get
for fixing stuff just before going to bed. I've committed all files
now.

/Viktor

Re: Segfault when changing the mini-icon (was Re: FVWM: fvwm crash when setting the mini-icon)

[Viktor Griph]

2009/8/25 Gautam Iyer gau...@math.cmu.edu:
 On Tue, Aug 25, 2009 at 04:52:15PM +0200, Viktor Griph wrote:

 I'll follow Viktor's suggestion next and send a backtrace to
 fvwm-workers. Any other suggestions on how to fix this are more than
 welcome,

 Do you have any progress on getting a backtrace? I would like to look
 into this issue before releasing 2.5.28 to at least make sure that the
 issue is not a major one, but hopefuly to be able to locate and fix
 the issue directly as well.

 Hi Viktor (and everybody else),

 Thanks for checking -- I did the backtrace over the weekend (attached to
 this message), and I couldn't fix things myself. The semester started on
 Monday, so I put hacking on hold. (However I'm happy to test/share my
 findings in the meantime.)

 For others on the fvwm-workers mailing list, here's a brief description
 of the problem I had: Fvwm (26,27,CVS) segfaults when I change a windows
 mini-icon (e.g. via Pick WindowStyle MiniIcon vim.png). This happens
 on my work computers (Quad core, 64bit, OpenSuse 11.1), however does not
 happen on my Gentoo laptop (dual core, 32bit).

 fvwm --version gives

    [fvwm][main]: DEBUG Entered, about to parse args
    fvwm 2.5.28 (from cvs) compiled on Aug 21 2009 at 23:37:43 with
    support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi
    text, Xinerama, XRender, XCursor, XFT, NLS

 and the backtrace is attached. I'll be happy to send config files / any
 other info you need. (I just won't be able to hack myself for a few
 weeks.)

The crash is a 64 bit issue with the EWMHDonate*Icon styles. A
workaround is to disable those styles on 64 bit machines. fvwm seems
to put garbage in the _NET_WM_ICON property on the first mini icon
donation, and fails to read that garbage back and crashes next time
the icon is set.

/Viktor

Re: releasing 2.5.28

[Viktor Griph]

2009/8/18 Yann Dirson ydir...@linagora.com:
 There have been several bug fixes since 2.5.27 was released in
 February, and I think it's time to release 2.5.28. Are there any
 pending patches, or bugs that has to be considered before a release?

 Hi,

 I have not seen any feedback from my second version of the patch adding a
 layer_change event.  Would there be anything to change to get it included
 ?

I've looked at your patch, and replied to that thread, but I feel more
comfortable about changing the module interface just after a release
than just before one. Adding event types have proven to cause errors
before so don't rush updating the patch to get it included. Right now
I'm waiting for a stack trace from Gautam Iyer which I will consider
before making a release.

/Viktor

Re: FVWM: Some fvwm functions quitting after a bit

[Viktor Griph]

2009/8/18 Thomas Adam thomas.ada...@gmail.com:
 2009/8/18 John H. Moe john...@optushome.com.au:
 The only thing I can add is that it *seems* to happen after I launch my
 first KDE app (like KNetwalk, Kopete, K3B), but only sometimes.  And if
 the first one doesn't cause it, then it seems none do.  From what I
 understand, KDE apps have a few libs and/or programs that need to run in
 the background to work properly, and once they're loaded they stay

 I suppose it's possible that some components of KDE are being loaded
 which are intercepting key events -- GNOME can do this for instance
 with its key-binding manager for multimedia keys which also let you
 bind other keys -- FVWM never gets the event for this, and so the
 effect is as you describe.  Perhaps KDE do something similar?  I
 wouldn't know, nor care.

I suspect that KDE remaps the keyboard on start.
Compare the output of xmodmap -pm before and after you start KDE
apps. If there are any changes at all to the output then that might
explain the issue. There may also be other changes to the keyboard
mapping that's going. FVWM does not respond to changes in the keyboard
mapping after it has been launched.

/Viktor

Re: FVWM: fvwm crash when setting the mini-icon

[Viktor Griph]

2009/8/19 Gautam Iyer gau...@math.cmu.edu:
 Ok, I just checked with the CVS version. (I also noticed that the error
 message I get after resetting the MiniIcon is a friendly Segmentation
 fault). So I can confirm the crash on 2.5.26, 27 and 28CVS. Here's my
 version info:

    fvwm 2.5.28 (from cvs) compiled on Aug 18 2009 at 22:33:07 with
    support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi
    text, Xinerama, XRender, XCursor, XFT, NLS

 I myself am baffled by this, since on my Gentoo box, no matter what I do
 I can't crash it. Any suggestions?

Enable core dumps on your system (ulimit -c unlimited), and compile
with gdb support (-ggdb to gcc). Then when fvwm crashes you will get a
file core or core.$PID. Use gdb to obtain a backtrace from it (gdb
fvwm corefile -ex bt full) and send that to the fvwm-workers list.

/Viktor

releasing 2.5.28

[Viktor Griph]

There have been several bug fixes since 2.5.27 was released in
February, and I think it's time to release 2.5.28. Are there any
pending patches, or bugs that has to be considered before a release?

/Viktor

Re: FVWM: EWMH - remove title

[Viktor Griph]

2009/7/30 Fernando Silveira fsilve...@gmail.com:
 Hi.

 I'm writing an application that needs to be absent of window
 decorations. What do I need to do to tell FVWM to remove its window
 title bar just using EWMH, ICCCM or any other standard feature? I
 don't want to use FVWM settings to do that, like 'style *something*
 notitle'.

You may use MWM decor hints[1] to do that.


 PS: My application could successfully remove its window decorations
 and title bar in Gnome and KDE just by using EWMH, but not its title
 bar in FVWM.

What are you doing to make it work with Gnome and KDE?

[1] http://www.ist.co.uk/motif/books/vol6A/ch-20.fm.html#963517

Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME

[Viktor Griph]

2009/7/10 Vincent Lefevre vinc...@vinc17.org:
 On 2009-07-09 23:33:04 +0100, Thomas Adam wrote:
 I think part of the problem is your continued assertion that WM_NAME
 is used in preference of _NET_WM_NAME, and it's being blind-sighted a
 little.  So please, I'd like you to detail step-by-step here, exactly
 what it is we would need to do to reproduce your problem -- then I'll
 take a look and try and verify it.

 OK.

 1. Open a uxterm and select utf8-title.
 2. printf \\033]0\;abc\\xc3\\xa9\\007
 3. xprop -id $WINDOWID -set WM_NAME abcdef
 4. xprop -id $WINDOWID | grep WM_NAME

 Step 4 shows:

 _NET_WM_NAME(UTF8_STRING) = 0x61, 0x62, 0x63, 0xc3, 0xa9
 WM_NAME(STRING) = abcdef

 _NET_WM_NAME corresponds to abcé. But fvwm shows the title abcdef,
 i.e. the value of WM_NAME instead of _NET_WM_NAME.

 This is on a Debian/unstable machine with fvwm 1:2.5.27.ds-6.

I've committed a fix for this to CVS. The problem was that fvwm didn't
set the flag that _NET_WM_NAME was present, if that name was set to
expand to the same name as WM_NAME, and _NET_WM_NAME was not present,
or couldn't be converted to the default charset, on the inital mapping
of the window. The same was true for _NET_WM_ICON_NAME with
WM_ICON_NAME.

/Viktor

Re: *FvwmEvent: toggle_paging metal.au causes FvwmEvent to crash

[Viktor Griph]

2009/6/30 Manoj Srivastava sriva...@acm.org:
 Hi,

        This was reported by a Debian use. Please retain the CC to
        438132-forwar...@bugs.debian.org so that the Dewbian BTS has a
        copy of your contribution.

        I have not been able to reproduce this crash, but I am passing
  it along in case  someone here has a better view into this.

        Originally reported for version 2.5.21; and most recently
  reconfirmed for version: 2.5.23 and 2.5.25.


 --8---cut here---start-8---
 EvwmEvent segfaults every time. I get this in my dmesg:

 FvwmEvent[3014]: segfault at  rip 2af1873cfcdc rsp 
 7fff240ad048 error 4

 I found out that if the following line exists in my config-file,
 FvwmEvent seg-faults at startup:

 *FvwmEvent: toggle_paging metal.au

 Also, after trying several modifications to the config-file, both
 FvwmEvent and fvwm seg-faults very easily. The config-file parser
 seems to be broken, at least on amd64.

I've committed a fix for this to CVS. The introduction of a new module
message in 2.5.19 made the event table off by one for the trailing
events (breaking startup, shutdown and unknown), and if a config name
didn't match a known event would cause deference of a uninitialized
static array element. (gcc sets them to null)

The patch is one line, but is just as unrouboust as before, and will
break again with the introduction of new Module messages. A proper
patch would change the handling of the module messages to skip
messages not dealt with in the module.

/Viktor

FvwmEvent configuration issues

[Viktor Griph]

While reading the FvwmEvent source code I've noticed several issues
with it's configuration system that needs fixing. However I'm not sure
what the best fix is for all the issues, so I'll start by listing the
issues:

* RPlayVolume and RPlayPriority is not honored at all. They are
defined in handle_config_line, and chnges to the values are not stored
at all.
There are two possibilities for fixing this: Either let the values set
the volume for all sounds, or let them be changable from top to bottom
in the configuration. Since FvwmEvent doesn't support dynamic
reconfiguration the differenc isn't that big, but in the later case it
would be possible to set different priorities and volumes for
different events, while in the former that won't be possible. On the
other hand, the later will require the volume and priority to be
specified before any events in the config, while the later could have
it anywhere.

* Tied to the above issue is also the interpretation of the Cmd
option. Right now it is only applied at the end of the configuration
process, which would be similar to select that volumes and priorities
only should be applied at the end of the configuration. However I
still think that in a sane configuration it should be specified before
the actual events, but changing that might break configs which define
a Cmd after the events. (But there is still no dynamic reconfiguration
possible, so if you have a bunch of sound events specified you can't
not change the command used to play the sounds for a running FvwmEvent
anyway.

Appart from thet there is the basic issue that the configuraion
parsing system is fragile with respect to the module protocol, and I
would like to fix that by reimplementing parts of the configuration
parsing and event handling to not break if there isn't an event
defined fo all messages. I can't descide what the best approach to the
options Cmd, RPlayVolume and RPlayPriority should be. Cmd can be left
as is, and only the most recently specified Cmd applies, however
builtin-rplay and other Cmd:s are handled in so different ways, that
it would be good to know if an event is for rplay or from a standard
Cmd at the time it is parsed, and especially not have to be able to
change between to two types as the user sends a new module
configuration command to fvwm. Any input on this would be good.

/Viktor

Re: FVWM: FVWM 2.5.25 and Skype: Profile Window won't show

[Viktor Griph]

2008/10/29 Philipp Kolmann kolm...@zid.tuwien.ac.at:
 Viktor Griph wrote:

 On Tue, 21 Oct 2008, Viktor Griph wrote:

 Question is now, is it a problem on Skype's side (according to the
 comments, they draw a window and set the withdaw state) or is it some bug 
 on
 your side?

 That particular diff is related to a fix for gtk-windows disappearing
 when using some new GTK praxis.
 (See http://www.mail-archive.com/fvwm-work...@fvwm.org/msg01359.html)

 It's hard to say exactly what Skype does since it's closed source. I'll
 try to debug it some to see if I'm able to reproduce the issue using bare
 X-calls, and see if those calls are right or not. I still belive that the
 above diff is right in accordance with the ICCCM2 specification, but without
 knoing what Skype does it's hard to say if it is fvwm or Skype that breaks
 the rules.

 After som preliminary debuging, it seems as if Skype does a
 XWithdrawWindow() call, and then waits for some event to happen before it
 maps the window again. I'm not sure what it wat's for, but obviously the dif
 you posted prevents that event from being sent, since Skype doesn't try to
 remap the window. I'll do some more debugging trying with the aim to find
 out which event Skype waits for, and once I know that I should be able to
 say if it should be able to expect that event or not based on the sequence
 of oprations that has been going on.


 Sorry, if I do bother you. Just wanted to check back, if you had any success
 in this issue. If needed maybe I can get some contact with skype, to help
 you solve this issue.

Well, I finally had time to look into this issue at depth and it
turned out to be QT that waited for the removal of the WM_STATE
property of the window before mapping it again, after unmapinging it
while skype was setting up the size hints, and the qt considered the
geometry invalid. I've committed a fix to CVS.

/Viktor

Re: fvwm fails to find certain icon files, ImagePath directive seems broken.

[Viktor Griph]

2009/6/30 Manoj Srivastava sriva...@acm.org:
 Hi,

        This was reported by a Debian user. Please retain the CC to
        449248-forwar...@bugs.debian.org  so that the Debian BTS has a
        record of your contribution.


 --8---cut here---start-8---
 Some menu files in /usr/share/menu specify icons without giving their full 
 path.
 Apparently, /usr/share/pixmaps is the default location for these icon files.
 fvwm fails to find them and floods ~./xsession-errors with messages:
 [...]

I belive this is a bug with the debian packaing of fvwm. Debian
patches the builtin configuration to read menudefs.hook:
+   { Read /etc/X11/fvwm/menudefs.hook Quiet, ,  },
+   { Read menudefs.hook Quiet, ,  },

Thus the code is run before any user defined Image paths are added.

 fvwm creates individual messages multiple times, which might be a bug on it's
 own. In the example above, e.g. pcb.xpm is reported twice, camera 4 times.

Rgis is probably beacues the same icon is used several times. It looks
as if the menidefs.hook may be read from other places as well, and
then ther error would come from each time the file is read.


 I have tried to fix this by appending /usr/share/pixmaps to fvwm's image path,
 which didn't work:

Obviously that won't work when the icons are loaded before the image
path is set. A soluton could be to set the compile time image path to
include /usr/share/pixmaps ( --with-imagepath configure argument )


/Viktor

Re: FvwmProxy keyboard handling

[Viktor Griph]

2009/3/24 Jason Weber baboon.im...@gmail.com:
 The left/top sensitivity has me suspecting
 something related to a negative pixel coordinate.  Hmm, is there
 some relative encoding with negative numbers?

If you are using the Move command, then yes. negative coordinates
are distance from right/bottom. You may prefix any number with a
plus to use the top left corner as reference always.

/Viktor

Re: Event type MX_REPLY sent by Send_Reply command

[Viktor Griph]

2009/3/22 Mikhael Goikhman m...@homemail.com:
 I don't remember a discussion when the new event type MX_REPLY was
 added, so I will tell my observations now.

There was no discussion. I introduced it to get rid of the extreme delay in
motion when moving around the viewport by dragging button 2 in FvwmPager.


 At the very first I thought, why do we need this event type when we
 already have M_STRING. But of course the answer is clear. When a module
 requests SendToModule back, then the event is sent to 0 upto N modules,
 and when it requests Send_Reply instead then it is sent exactly to one
 module, to itself.

Exactly. When I added Send_Reply I were using a config with two pagers, so
using SendToModule would have required the modules to be able to identify
SendToModule replies issued by themselves, or my other modules using the
same name. While this can be done by adding some instance unique
identification string, the modules would still have to deal with any
string sent
to them, since SendToModule can be used by anyone be it another module,
or the user. MX_REPLY messages on the other hand are known to originate
from the same module, and may therefore be parsed in a less tolerant way by
the module.


 So a module should usually avoid the SendToModule technique in favor of
 Send_Reply. Of course, anywhere outside the module, SendToModule is
 still currently the only way to communicate.

 There are several interesting use cases for Send_Reply:

 1) To ask fvwm to expand internal fvwm variables or translations:
 [...]
 2) To ask fvwm to select a window for a module to operate on:
 [...]

Don't forget the case it was implemented for:
3) To let the module know when fvwm has processed commands sent to it.
(FvwmPager sends Scroll commands to fvwm followed by a
Send_Reply ScrollDone, and while waiting for the ScrollDone reply it will
aggregate any additional Scroll requests internally and send them when the
ScrollDone is received.


 However, there is still one case when the module can't avoid
 SendToModule, when it asks fvwm to alarm itself in 10 seconds:

  Schedule 1 898989 SendToModule ModuleNameOrAlias alarm

 Unfortunately this does not currently work:

  Schedule 1 898989 Send_Reply alarm

 I think this is quite useful and may be considered as a bug. I'll see
 how to fix this use case in Schedule.

Yes, it could be useful to allow for that. Of course using a schedule id from
within the module might be a bad idea, since it would introduce a collision
risk with user configs and other modules. (Or other instances of the same
module.)


 Maybe later we should have a module context just like a window context,
 anywhere, not only in Schedule. So even if there are several modules of
 the same name running, it would be still possible to target the correct
 one. Think ModuleId (WindowId), $[module.id] ($[w.id]), NextModule
 (Next), AllModules (All) and so on. Then SendToModule ModuleName
 would be just another way to say AllModules (ModuleName) Send_Reply.
 This is not a complete proposal, just a material to think. After 2.6.

I like the idea of a module context, but not before 2.6.

/Viktor

Re: Google summer of code

[Viktor Griph]

On Tue, 10 Mar 2009, Thomas Adam wrote:


2009/3/9 Viktor Griph gr...@dd.chalmers.se:

I think it would be great if fvwm could apply as a mentoring organization in
this year's GSOC. I would be interested in working as a student on fvwm if
anyone has the time to mentor me. This will most likely be the last summer
I'll be eligible to participate as a student, and I'd really like to work
with fvwm full time this summer.


And so to go back to roots...

Assuming no one else on this list objects, I am going to step up to
this and nominate myself as an official point of contact for this --
including writing a proposal for FVWM -- at least I assume that's what
I would have to do.  I actually have the time to devote to this which
is nice, and something I'd like to do.


Sounds great.



Viktor, do you have information I would need to fill out to support
FVWM's chances for GSOC this year?


I'm not sure what kind of information you are after. I take it that you 
have seen the GSoC FAQ[1].


The critical point of the application as I see it is to have a backup 
administrator, and at least an additional mentor to have some plan on what 
to do if you disappear. Other than that most questions should be 
relativley straight forward to answer. I'd like all contributions to be 
licensed GPL2+ so that any code produced by GSoC can be used both before 
and after an upgrade to GPL3 without getting additional permissions from 
the students.


We should flesh out a preliminary ideas page and put somewhere on fvwm-web 
as well, since that is needed for the application.


/Viktor

[1] http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs

Google summer of code

[Viktor Griph]

I think it would be great if fvwm could apply as a mentoring organization 
in this year's GSOC. I would be interested in working as a student on fvwm 
if anyone has the time to mentor me. This will most likely be the last 
summer I'll be eligible to participate as a student, and I'd really like 
to work with fvwm full time this summer.


There are several items that can be added to an ideas list for fvwm. Here 
are just a few ideas from the top of my head. Some need refinement, and 
some are probably not good at all.


* style/state rewrite
  - unify the syntax for styles and states of windows, and make all states
matchable with conditionals

* fine grained style matching.
  - continue the work on the CVS branch with contaiing stlye matching by
reasource, class or name specified.

* help finalizing fvwm 2.6
  - write a fvwm-convert-2.6 script
  - update test cases
  - fix bugs

* add support for RANDR

* add support for some other XExtention/library

* move advanced decorations to a module
  - add a style DecoratedByModule
  - change to module interface to allow window decorations to be handled
by a module (Should be able to have more than one decor module
running, so there must be a way to control which windows are
decorated by which module.)
  - move the deprecated decor stuff to a separate module

I think that the primary focus should be on 2.6, but it does not hurt to 
to have some ideas for post 2.6 in there as well. I'm most interested 
in working on the two first points on the list, but would like to see 2.6 
released this year, and there are still several things things to do.


/Viktor

Re: Google summer of code

[Viktor Griph]

On Mon, 9 Mar 2009, Thomas Adam wrote:

* style/state rewrite
 - unify the syntax for styles and states of windows, and make all states
   matchable with conditionals


This is *huge* -- not something I would recommend as an undertaking of GSOC.


You are probably right. I think that trying to combine this with the 
matching against calss/reasource/name was the reason why the CVS branch on 
that kind of died. That and a sudden increase in work load. It might be 
possible to refine the task into several smaller tasks. Splitting the 
stlye command into an InitialStyle and a State command, keeping Style 
Wired a both of them for backwords compatibility, could maybe be more 
doable task to start with, While adding matching on window states sould be 
a different task.





* fine grained style matching.
 - continue the work on the CVS branch with contaiing stlye matching by
   reasource, class or name specified.


This is better -- and self-contained enough that it would be possible,
but bear in mind it's still a stop-gap measure for the much larger
ideals of applying styles, those styles having states (based on the
window) etc.  Perhaps this could form one piece of that puzzle.





 - update test cases
 - fix bugs


I don't see there being sufficient work for a student to work on this
myself.  I might be wrong though.


It's hard to say, but I think you are probably right. 2.6 isn't that far 
away. The testcases need a big overhaul, which is boring work, but 
probably not enough to occupy a student a full summer. (Even though it 
probably would take a week just to figure out what changes that have been 
done that have no tests, and then there is the question of writing the 
tests for them.)



* move advanced decorations to a module
 - add a style DecoratedByModule
 - change to module interface to allow window decorations to be handled
   by a module (Should be able to have more than one decor module
   running, so there must be a way to control which windows are
   decorated by which module.)
 - move the deprecated decor stuff to a separate module


This needs a lot of discussion and is something I'd always planned to
see post 2.6 as I have a number of opinions/ideas on this myself.
(Changing the module communication is one *large* facet itself, and is
perhaps a separate task in its own right.)


Yes. This one really needs discussion, and it should probably be split 
into smaller tasks. Just making it possible for a module to decorate a 
window, with all wat is means for dealing with user interaction needs is 
probably lare enough for a single task. Not having thought a lot about it 
I can think of two ways to deal with it. Either the module is responsible 
for sending commands when a user interacts with a button/frame in the 
decor, or the module should provide fvwm with window ids for all 
interactable components that are included in the decoration. The former 
has the advantage of allowing decor modules to rethink the interaction 
model, but it will pose problems on execting compex functions based on the 
click on a decoration part. The latter has the advantage of leaving most 
of the frane interaction code as it is, by having fvwm process the events 
of the decoration parts, and also keeps the module communication at a 
lower level.


Needless to say this one need lots of discussion, and design descitions, 
and probable is hard to mentor.






I think that the primary focus should be on 2.6, but it does not hurt to to
have some ideas for post 2.6 in there as well. I'm most interested in
working on the two first points on the list, but would like to see 2.6
released this year, and there are still several things things to do.


The requisite for all of these useful suggestions you've outlined here
come at a price:  no one here has really fleshed them out fully -- and
ideally, I'd like a proposal feature to have been mapped out in
sufficient enough detail for a prospective GSOC student such as
yourself, if only because it saves time; to introduce a topic and then
not know what it is really supposed to do is wasteful.


They were just ideas, all open for discussion. GSoC deadline for mentor 
organization submissions is this Friday, and if fvwm should apply we need 
a list of ideas. Might be tahat it only contains a few well defined ones, 
but seeing the short timespan I thought I'd start some discussion.


Another possble addition to the list is:
* Add/change to communication channel of FvwmCommand.
  - possible channels include a UNIX socket, ICE protocol

This is an isolated task, but I'm not sure of the size of it. If it's just 
to change the FIFOs used today to a socket, then it probably isn't big 
enough, but if it also is to add an alternative channel (i.e ICE) to allow 
communication with FvwmCommand over X rather than on the machine running 
fvwm.


/Viktor

Re: Some questions about dependencies

[Viktor Griph]

On Wed, 7 May 2008, Jesús Guerrero wrote:


They are the following:
# XXX:  gtk2 perl bindings require dev-perl/gtk2-perl, worth a dependency?
# XXX:  gtk perl bindings require dev-perl/gtk-perl, worth a dependency?
# XXX:  netpbm is used by FvwmScript-ScreenDump, worth a dependency?

I can clearly see the netpbm dependency. So, that's not a problem.

However, I am not sure about the gtk{,2}-perl stuff.

[...]

If you enable gtk, then fvwm looks for gtk+-1.x. If I am not mistaking, to
make these bindings of any use, you would still need to push as dependencies
gtk-perl and gtk2-perl respectively (whatever they are called on your distro
of choice). Am I right?


If I recall correctly the configure option about gtk only controls wether 
FvwmGtk will be built or not. The perl bindings are only runtime 
dependencies, when specific modules or parts of the perllib are used.




I also want to know if these perl/gtk bindings are used on any official
script or module shipped on with fvwm. My guess it that they are not, and
with grep, I can't find any refference to Gtk.pm or Gtk2.pm on any file
shipped with fvwm.


perl-gtk is used by the module FvwmGtkDebug. I don't think that perl-gtk2 
is used by anything but the perllib.



[...]
Another doubt, do you need gtk+-2.x for Gtk2.pm to be functional? I guess
yes, but in that case, that dependency has been overlooked on the ebuild
forever. If this is true, that means that if I enable perl and gtk, then
the ebuild should have all of these as dependencies, which, in my humble
opinion is something insane for fvwm:


The ebuld should not depend directly on gtk+-2.x. That is a dependency of 
gtk2-perl, and would thus be pulled when installing that. gtk+-1.x is 
needed for FvwmGtk, which links against gtk, and dus depend directly on 
gtk, and not via gtk-perl.


/Viktor

Re: FVWM: xmodmap and fvwm's rootmenu

[Viktor Griph]

On Sat, Apr 5, 2008 at 1:17 PM, michel Junger [EMAIL PROTECTED] wrote:
 Hello,

  First of all I use fvwm for a long time and each time I tried to use
  another wm I always came back to fvwm.

  This said, my current laptop has no keys page up and page Down,
  so I've put the following lines in my .Xmodmap :

  keycode  64 = Mode_switch
  keycode  98 = Up Up Prior Prior
  keycode 104 = Down Down Next Next

  This done Alt+Up generates page up and Alt+Down generates page down.
  It works fine in emacs, vi, and all other applications that I use,
  but unfortunately in fvwm root-menu and sub-menu each time I press Down
  I jump five lines below and each time I press Up I jump five lines above.

  I use fvwm 2.5.24, I've tried version 2.5.25, I've tried keys command(115) 
 rather
  than Alt(64), no change, is there a solution ?
  (Change my laptop is not an option!)

You can remove the menu bindings that interfere.

Key KP_Prior M A -
Key Page_Up M A -
Key KP_Next M A -
Key Page_Down M A -

should probably do it. (Since the default bindings are for any
modifier it's enough that the key can generate the correct symbol with
some modifier.)

You might want to add bindings to page up/down with no modifiers to do
MenuMoveCursor -/+5.

/Viktor

Re: FVWM: 2.5.25: problem with VirtualBox seamless windows

[Viktor Griph]

On Mon, 17 Mar 2008, Harald Dunkel wrote:


Hi folks,

Since fvwm 2.5.25 there seems to be a problem running VirtualBox in
seamless windows mode: On moving a Windows window the background
or other windows are not refreshed.

The current snapshot of today (20080317) does not work. But moving
back to fvwm 2.5.24 makes the problem go away.


Can you try to pinpoint a CVS date where it changes from working to not 
working?


/Viktor

Re: New Menustyle: VerticalMargins, is there any interest on it?

[Viktor Griph]

On Tue, 11 Mar 2008, Dominik Vogt wrote:


On Tue, Mar 11, 2008 at 07:31:40AM +0100, Jesús Guerrero wrote:


MenuStyle * VerticalMargins 2 3

This defines a margin of 2pix from the top border of the menu, and
3pix on the bottom. In my opinion, this improves the look of the
menu when you have selected the last/first item. I attach a picture
with some notes on it so you can compare.

[...]


Ah, I see.  It may (or may not) be good to have a similar syntax
like for the horizontal menu layout, although there probably isn't
much to configure.


That would add nothing that can't already be configured by tweaking the 
ItemFormat.


/Viktor

bug: menu defenition stacking

[Viktor Griph]

This is something I noticed a while back, but put aside fixing it since 
it's not very severe, and I couldn't think of what the solution should 
be.


The issue is that it is possible to create several menus with the same 
name, the latest definition being used inplace of earlier definitions, but 
the earlier definitions coming back to like when the menu is destroyed.


This is done by (ab)use of the menu specific sidepic feature:

AddToMenu looks for an existing menu matching the exact string given for 
the menu name, but creates a menu whe the name has had the side pic 
component removed. My initial thought of a solution was to just parse the 
name, and rid it of the sidepick info when looking for what menu to add 
to. But then I thought: What would the user want by specifying a sidepic 
when adding ot an existing menu? I couls not answer that, and still 
can't, that's why I start this thread. What should fvwm do in this case?


My thoughts were:
A. ignore the sidepic info and add to the original menu as if no sidepic
   were specified
B. give an informative error to the user and do nothing
C. Combine A with B as a warning
D. A if the sidepic matches the one in the menu already else B
E. Set/change the sidepic of the menu to the sidepic specified and
   continue
F. something else

I still don't know which of these options that is the correct solution.

Test case:

AddToMenu TestMenu Foo DestroyMenu TestMenu
AddToMenu [EMAIL PROTECTED]@ Bar DestroyMenu TestMenu
Menu TestMenu
Menu TestMenu

And another test case:

AddToMenu TestMenu@@some_image@@ Foo DestroyMenu [EMAIL PROTECTED]@
AddToMenu [EMAIL PROTECTED]@ Bar DestroyMenu [EMAIL PROTECTED]@
AddToMenu TestMenu@@some_image@@ Baz DestroyMenu [EMAIL PROTECTED]@
Menu [EMAIL PROTECTED]@
Menu [EMAIL PROTECTED]@


In the above test cases some_image may be replaced with an existing image, 
but that is not required for the bug to be reproduced.


/Viktor

Re: CVS domivogt: * FIxed drawing of background pictures in menu items.

[Viktor Griph]

On Sun, 9 Mar 2008, FVWM CVS wrote:

* FIxed drawing of background pictures in menu items.


Did you test the change with Pixmap backgrounds (especially TiledPixmap)?

I don't have time to test anything today, but using a TiledPixmap, for 
items and another one with the same pattern, but different color should 
the pattern look good in the highlighted items (i.e continue the 
background pattern with a different color). I believe that might need 
special treatment.


/Viktor

Re: FVWM: fvwm and patches

[Viktor Griph]

On Thu, 6 Mar 2008, Ingo Wardinski wrote:

I'm sure there are profound reasons not to include such features as
menutranslucency, topborder, inactivefont, round corners , etc. into
fvwm. Which are these??


In most cases the patches have not been submitted to the fvwm-workers 
list, and in the cases where they have they mostly lack proper 
documentation of the features. Also some patches add stuff without adding 
configuration options to control their behaviour.


Appart from that patches require quite some proof reading and some patches 
tend to be relatively large. I've personally checked on the 
menu translucency patch a while back, and I think it is mature enough for 
inclusion. But it lacks documentation, and still has to be checked against 
the latest CVS to see that there haven't come any new issues since I last 
checked and updated the patch. There is also the issue of if Translucent 
really should be a colorset-option, or if the translucent menus should be 
a menu style, to avoid confusing users that tries to make a colorset 
translusent, only to see that it doesn't work (for anything but menus). 
That should probably be discussed. There is a thread about it from a few 
weeks ago somewhere.


I don't know of the state of any other patches. I know that there are some 
patches that have been sent to the workers list, wich I intend to take a 
look at once I get a little more time. But I believe that most of the 
patches that are included with the Gentoo live ebuild have never been 
submitted to the workers list.


/Viktor

Re: FVWM: Icon frames

[Viktor Griph]

On Sat, 1 Mar 2008, Dan Espen wrote:

I just looked at the code for a few minutes and this
doesn't seem right:

add_window.c:

setup_icon_background_parameters(...

if (SHAS_ICON_BACKGROUND_RELIEF(pstyle-flags))
{
fw-icon_background_relief =
SGET_ICON_BACKGROUND_RELIEF(*pstyle);
}
else
{
fw-icon_background_relief = ICON_RELIEF_WIDTH;
}


Changing ICON_RELIEF_WIDTH to zero makes the issue go away.

Why is it setting the relief width to the default of
2 pixels when the icon isn't supposed to have a relief?


The man page specifies that the default relief is 2. But that it only 
applies to icons with a background picture. I'm not sure what that mean 
and don't have time to look at the logic in the code to see what it does.


/Viktor

Re: FVWM: Icon frames

[Viktor Griph]

On Fri, 29 Feb 2008, Dan Espen wrote:



I'm running a fairly recent CVS version of Fvwm.
I use root window icons, many of them shaped,
some of them titled.

Recently, some of my icons started to show a 3d frame around them:

http://mysite.verizon.net/despen/icons.gif

The second from the top has a frame,
the third from the top doesn't.

They both use png's with a transparent area around them.

I think I like the effect.
What causes some of have the frame and other no frame?


That would be your Style settings. The effect comes from the Style 
IconBackgroundRelief in conjunction with IconBackgrouondColorset.


According to the manpage it is only drawn around icons with a background. 
I'm not sure why some icons are considered to have backgrounds, and some 
not. But if you use an IconBackgrouondColorset all icons will get the 
relief.


/Viktor

Re: FVWM: no auto-raise, auto-focus

[Viktor Griph]

On Mon, 18 Feb 2008, Chris Rouch wrote:


Some applications, particularly openoffce and firefox have a habit of
automatically raising their window or forcing it to have focus. Is
there anyway to prevent this? I already have

Style *   SkipMapping
Style * DontRaiseTransient, DontLowerTransient
Style * DontStackTransientParent
Style * GrabFocusTransientOff

but I still see this unwanted behaviour.


There are a few possible reasons for this behavior. Most of them can be 
disabled by fvwm styles, or function modifications. Howeverr if the 
program uses X-requests to focus the window diectly (as for example Matlab 
does with figures) the only way is to intercept the call on application 
level.


You will want to look at the functions UrgencyFunc and 
EWMHActivateWindowFunc. These may be activated by programs setting 
specific hints, and have defaults provided by fvwm that will focus and 
rais the window affected.


You may also be interested in the style EWMHIgnoreStackingOrderHints, and 
possible other styles related to EWMH.


/Viktor

Re: module_list_remove segfault and patch

[Viktor Griph]

On Sat, 9 Feb 2008, Adam Goode wrote:


Hi,

FVWM segfaults under certain conditions described here:
https://bugzilla.redhat.com/show_bug.cgi?id=382321 and especially here:
https://bugzilla.redhat.com/show_bug.cgi?id=382321#c12

This happens even in the CVS version.

It is a problem with an error case that calls module_list_remove when
module_list is empty.

A patch is here:

http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/fvwm/fvwm-2.5.24-module_list_remove.patch



I've commited a different fix for this to the CVS. (I changed to code to 
make no special treatment of the first module in the list.)


/Viktor

Re: module_list_remove segfault and patch

[Viktor Griph]

On Sat, 9 Feb 2008, Adam Goode wrote:


Hi,

Am I missing something or are you forgetting to update a -next pointer
somewhere? (It looks like you are leaving the previous next pointing to
the freed structure.)

The old code, while uglier, I think handled that case.



I do update it. The position pointer is either the list head (first 
iteration) or the previous next pointer (subsequent iterations), so
the statement *position = (*position)-next does update the next 
pointer.


/Viktor

Re: updating the html docs in fvwm-web?

[Viktor Griph]

On Mon, 7 Jan 2008, Dan Espen wrote:


Dominik Vogt [EMAIL PROTECTED] writes:

Hi Scott,

On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote:

Now that we have the html docs, someone has to write down detailed
instructions in docs/DEVELOPER how to get the html files into
fvwm-web during the release process.  I can't do that.


I *really* need instruction in the docs/DEVELOPER file if we want
the man pages on the web page to be up to date.  I don't have the
slightest idea what I have to do.  Help!


There does seem to be an issue.
I was able to build with --enable-htmldoc.

That gave me some pretty nice man pages in
fvwm/share/2.5.25/doc/fvwm/fvwm.

Then I looked in fvwm-web and was surprised to see
the manpages2php script was still in there.
Then I looked at the Fvwm web site and I see we still have
the old web pages online at fvwm.org.

I think it's time to put the new pages in place.

I'll take care of this if you want.
I think we need to change the manpages2php script so it doesn't
do anything for the unstable branch.


There are currently two places with online manpages. And the manpages2html 
does still work on the generated manpage. (But all links are lost.)




Document the new procedure which should just be:

build with --enable-htmldoc
then copy the whole hierarchy created in /share over to
fvwm-web/documentation/manpages/unstable.

Then update/commit.


In theory that is good. But right now the documentation seems to be 
missing some files in the installed directory. (Which is a bug.) And it 
also adds the need to actually install the source once except from within 
the distcheck in order to update the documentation.


Files currently not properly installed are:
modules/FvwmTabs.html
commands/WindowsDesk.html
modules/images/FvwmTabs/*.png

/Viktor

Re: updating the html docs in fvwm-web?

[Viktor Griph]

On Mon, 7 Jan 2008, Dan Espen wrote:


Viktor Griph [EMAIL PROTECTED] writes:

On Mon, 7 Jan 2008, Dan Espen wrote:


Dominik Vogt [EMAIL PROTECTED] writes:

Hi Scott,

On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote:

Now that we have the html docs, someone has to write down detailed
instructions in docs/DEVELOPER how to get the html files into
fvwm-web during the release process.  I can't do that.


I *really* need instruction in the docs/DEVELOPER file if we want
the man pages on the web page to be up to date.  I don't have the
slightest idea what I have to do.  Help!


There does seem to be an issue.
I was able to build with --enable-htmldoc.

That gave me some pretty nice man pages in
fvwm/share/2.5.25/doc/fvwm/fvwm.

Then I looked in fvwm-web and was surprised to see
the manpages2php script was still in there.
Then I looked at the Fvwm web site and I see we still have
the old web pages online at fvwm.org.

I think it's time to put the new pages in place.

I'll take care of this if you want.
I think we need to change the manpages2php script so it doesn't
do anything for the unstable branch.


There are currently two places with online manpages. And the manpages2html
does still work on the generated manpage. (But all links are lost.)



Document the new procedure which should just be:

build with --enable-htmldoc
then copy the whole hierarchy created in /share over to
fvwm-web/documentation/manpages/unstable.

Then update/commit.


In theory that is good. But right now the documentation seems to be
missing some files in the installed directory. (Which is a bug.) And it
also adds the need to actually install the source once except from within
the distcheck in order to update the documentation.

Files currently not properly installed are:
modules/FvwmTabs.html
commands/WindowsDesk.html
modules/images/FvwmTabs/*.png


So, are you recommending we just continue with generating the
php files from the generated man pages until the problem is fixed?
Are the FvwmTabs etc. man pages still OK?


I recommend that we keep generating the manpages using man2php until we 
have removed that section of the homepage, or made the new gtenerated 
manpage appear in there. (Preferrable using the homepage theme.) As long 
as outdated manpages are deleted from the tree the manpages2php script 
will find the man pages generated from docbook when updating.


I've fixed the installation issues and added a script to update the html 
documentation without having to install the documentation.


/Viktor

Re: GTK and fvwm do not always play nice together

[Viktor Griph]

On Sun, 2 Dec 2007, Tom Horsley wrote:


Judging from the test program source, it is apparently
(God knows why) some sort of GTK convention to write this
sequence when bringing up a window:

   gtk_widget_show_all(window);
   gtk_widget_hide(window);
   gtk_widget_show(window);


I've commited a fix for the dissappearing Windows. What happened was the 
following:


1. Application requests it's Window to be mapped.
2. Before the MapRequest is processed by fvwm the application requests to 
be movn to the withdrawn state, by sending a synthetic UnmapNotify even.

3a. Fvwm maps the window
3b. The application sends another MapRequest to be mapped again.
4. Fvwm recieves the synthetic UnmapNotift event and Unmaps the window.
5. Fvwm recieves the second MapRequest, followed by a real UnmapNotify 
from when fvwm unmapped the window previously, so it does not map the 
window again.


Now fvwm will ignore the initial MapRequest if it is followed by a 
synthetic UnmapNotify. Which solves the problem for the above testcase, as 
well as the similar Xlib only testcase posted on the user list.


/Viktor

Re: FVWM: using fvwm bug reporting?

[Viktor Griph]

On Sun, 2 Dec 2007, Thomas Adam wrote:


On 02/12/2007, Tom Horsley [EMAIL PROTECTED] wrote:

There is a link to bug reporting on the fvwm home page
and when I followed it and reported a bug, my bug didn't show
up in the incoming list.

Is there some secret handshake I don't know about? Or is
the incoming list moderated and it takes a while for bugs
to show up?


I believe that only Jason can answer that. It used to be instant, vut 
there haven't been any new messages or followups since October 15, so 
something might be broken. It would be good to know what happened, 
especially if follow ups are lost (or stuck somewhere on the mail server).




I was trying to go ahead and get an official bug report
going on the gnucash and virt-manager problems where
some windows just disappear when they try to popup.


I don't think anyone uses that as much as they do the fvwm-workers
mailing list.  That is where even this email should have been sent to.


It's true that the fvwm-workers list probably is the best place to report 
bugs, but I at least try to check the bug tracker semi-regulary, and there 
is the fvwm-bug script that sends bug reports to the bug-tracker, so it 
should work.


/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/28/07, Dominik Vogt [EMAIL PROTECTED] wrote:
 On Tue, Aug 28, 2007 at 01:57:22PM +0100, seventh guardian wrote:
  On 8/28/07, Dominik Vogt [EMAIL PROTECTED] wrote:
   On Tue, Aug 21, 2007 at 11:34:55AM +0200, Dominik Vogt wrote:
By the way, there's another issue with the build process:
   
 * The documentation has a build error when building on a multi
   core machine with -j 2.
   
I think there are some dependencies missing.
  
   Fixed.  Multiple targets were using the same temporary files.  I
   think we can release 2.5.22 now.  Any volunteers?
 
  Hum I guess I can do it this time.. But I need to do it slowly :)

 That's the best way to do it anyway :-)

Yes, hold it for a little longer. I want to investigate bug #4405.

I think it's crashing on windowlist.c:753 (If I follow the diffs from
version 2.5.21 correctly).  Which would mean that wthe window list
contains a NULL window. I want to try to reproduce it using the
supplied minimal config before you release anything.

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/29/07, seventh guardian [EMAIL PROTECTED] wrote:
 Ok, everything is done except putting the tarballs in the ftp dir (I
 seem to have forgotten my password.. already emailed Jason about
 this).

there is no password for the incoming folder.

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/29/07, seventh guardian [EMAIL PROTECTED] wrote:
 On 8/29/07, Viktor Griph [EMAIL PROTECTED] wrote:
  On 8/29/07, seventh guardian [EMAIL PROTECTED] wrote:
   Ok, everything is done except putting the tarballs in the ftp dir (I
   seem to have forgotten my password.. already emailed Jason about
   this).
 
  there is no password for the incoming folder.

 oh.. but it doesn't work with username renato and pass ..

 $ ftp ftp.fvwm.org
 Connected to ftp.fvwm.org (129.7.128.20).
 220 UH Math FTP server
 Name (ftp.fvwm.org:renato):
 530 Please login with USER and PASS.
 SSL not available
 331 Please specify the password.
 Password:
 530 Login incorrect.
 Login failed.
 ftp 221 Goodbye.

 or for any other username (tried guest and fvwm)

use anonymous

/Viktor

Re: Compilation warnings in Flocale.c

[Viktor Griph]

On Tue, 28 Aug 2007, Dominik Vogt wrote:


On Tue, Aug 28, 2007 at 02:55:26PM +0100, seventh guardian wrote:

On 8/28/07, seventh guardian [EMAIL PROTECTED] wrote:

On 8/28/07, Dominik Vogt [EMAIL PROTECTED] wrote:

On Tue, Aug 28, 2007 at 02:13:20PM +0100, seventh guardian wrote:

On 8/28/07, seventh guardian [EMAIL PROTECTED] wrote:

OOPS:

$ make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror

make  all-recursive
make[1]: Entering directory `/home/renato/apps/cvs/fvwm'
Making all in libs
make[2]: Entering directory `/home/renato/apps/cvs/fvwm/libs'
Flocale.c:1464: warning: comparison with string literal results in unspecified b
ehaviour



I'm not sure of how severe this warning is.. Is it a show-stopper?


It is a show-stopper. There were some nasty char* == foo bar tests.
Jeez.. I'll fix them.


I think the idea is that for every string literal there is only
one actual instance in the executable, so the code is safe.  But
instead of using macros we should rather have

  Flocale.c
  -
  static const char *fft_fallback_font = FLOCALE_FFT_FALLBACK_FONT;

  ...

  if (fn != fft_fallback_font)
  ...


Makes sense. I was using strcasecmp, but that should be faster.


Hum but now gcc complains about the const char * vs. char *:

(...)
cc1: warnings being treated as errors
Flocale.c: In function 'FlocaleGetFftFont':
Flocale.c:1079: warning: assignment discards qualifiers from pointer target type


I guess we have to remove the const then.  That's better than
casting it away every time.


There are so many places in the code where one would want to use 
const strings, but it's not possible because there are other functions 
which don't use const.


It would be a good thing to add some const where possible in order to make 
it possible to wrtie new code using const specifiers. Having correctly 
specifired const where functiond don't change on the input is a good thing 
for code readablity. I'm not sure exactly where the deadend is for 
changing stuff to const, but I believe it's somewhere in the parsing 
functions.


But right now removing the const is best.

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/19/07, Dominik Vogt [EMAIL PROTECTED] wrote:
 On Sun, Aug 19, 2007 at 12:42:15AM +0200, Dominik Vogt wrote:
  On Sat, Aug 18, 2007 at 10:09:46PM +0200, Viktor Griph wrote:
   On 8/18/07, Dominik Vogt [EMAIL PROTECTED] wrote:
Can you eliminate the use of tables then?  I think we just have a
couple of them.

 Allright, with your latest commit there is one table left in
 doc/commands/Menu.xml and four more tables in
 doc/modules/FvwmTabs.xml.

The one in Menu.ml is now replaced, as is the keybindings in
FvwmTabs.xml. The other three tables inFvwmTabs.xml are slightly more
complicated. Also FvwmTabs.1 is not set to be installed (or even
built) from the xml source. The old FvwmTabs.1 man page will be
installed with the current setup.

 Also, some acronyms use arconym ... /acronym and some use
 emphasis remap='SM' ... /emphasis.  The old man page had two
 uses of .SM: Acronyms and key names.  But cleaning this up is not
 necessary before the release.

I think there are more of the imila stuff out there. I've been
changeing countless emphasis tags into more specific tags, and they
never seem to get to an end.

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/18/07, Dominik Vogt [EMAIL PROTECTED] wrote:
 On Fri, Aug 17, 2007 at 06:13:49PM +0200, Viktor Griph wrote:
  On Fri, 17 Aug 2007, Dominik Vogt wrote:
 
  On Fri, Aug 17, 2007 at 05:26:30PM +0200, Viktor Griph wrote:
  On Fri, 17 Aug 2007, Dominik Vogt wrote:
  Yes.  I'm now looking at the issues brought up by requiring sed,
  perl and tbl for building the docs.
  
  So, is everything ready for release?
  
  And is it really helpful to have tables in the man page?  What's
  the benefit of
 
  Other than the table with visuals and depth info I  don't really see any
  use for them. I've been changing informaltable to variablelist in
  several places already.
 
  
 +--++
 |  Formatting Directive| Description|
 +--++
 |%l, %c  %r   | Insert the next item   |
 |  | label.  Up to three labels |
 |  | can be used.  The item |
 |  | column is left-aligned |
 |  | (%l), centered (%c) or |
 |  | right-aligned (%r).|
 +--++
 |%i| Inserts the mini icon. |
  
  over
  
 %l, %c, %r
 Insert the next item label.  Up to three labels can be
 used.  The item column is left-aligned (%l), centered
 (%c) or right-aligned (%r).
 %i
 Inserts the mini icon.
  
  I find the table harder to read, but t's easier to find an entry
  you are looking for.  It is also very uncommon to have man pages
  with ASCII tables.
 
  I also find the variablelist better than tables for describing meaning of
  certain directives. They use the space more efficient and they don't have
  an ugly frame.

 Can you eliminate the use of tables then?  I think we just have a
 couple of them.

The only remaining table it the one in the description of the
color-limit option. That is a legimate table. I'm not sure exactly how
to eliminate it. (Thst'd the only tsble that existed in the old man
page.)

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/17/07, Dominik Vogt [EMAIL PROTECTED] wrote:

   * Single quotes are written ' not \'
   * A line must not begin with a single quote

Both these fixed.

 Has this been doen?

  * The boolean arguments section is still missing from the new
manpage.


Yes, booleanArgs.xml is put there. Maybe we should crosslink all
boolean arguments to commands to it in the html output, but that can
wait.

Shall the ItemFormat and CursorStyle context tables be changed to
variable lists?

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On Thu, 16 Aug 2007, Dominik Vogt wrote:


On Mon, Aug 13, 2007 at 10:58:09PM +0200, Viktor Griph wrote:

On Mon, 13 Aug 2007, Dominik Vogt wrote:

On Mon, Aug 13, 2007 at 11:08:57AM +0100, seventh guardian wrote:

On 8/6/07, Dominik Vogt [EMAIL PROTECTED] wrote:

On Mon, Aug 06, 2007 at 02:02:35PM +0100, seventh guardian wrote:

The NEWS file is getting long, so I believe a new release would be
good.


Yes.


Ok, so where do we stand now?

* The new module code should be safe [done]

* Is everything related to the manpage fixed?


No, not at all.  The only thing fixed is that building the docs
does not require GNU make anymore.  All other points on the list
remain.


The fixmes are gone. Perl isn't needed for building but it's unconvinient
to add commands, but that can be fixed after release. Were there any other
points?


Most important: the generated man page is still broken.  For
example:


 allbox tab(:); lB lB lB.  T{   T}:T{ depth 8 (256 colors) T}:T{
 depth 4 (16 colors) T} l l l l l l l l l.  T{ PseudoColor T}:T{ 68
 (4 cc + 4 grey) T}:T{ 10 (2 cc + 2 grey) T} T{ GrayScale T}:T{ 64
 regular grey T}:T{ 8 regular grey T} T{ DirectColor T}:T{ 32 (3 cc
 + 5 grey) T}:T{ 10 (2 cc + 2 grey) T}

There are three other places with similar broken formatting in fvwm.1.


I'll look into it if you can give me some hint on how to fix automake for 
the doc directory on my macbook.


/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

yOn Thu, 16 Aug 2007, Viktor Griph wrote:


On Thu, 16 Aug 2007, Dominik Vogt wrote:


On Thu, Aug 16, 2007 at 07:42:36PM +0200, Viktor Griph wrote:


I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.


What's the problem?



doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition TRUE, 
which implies condition FVWM_BUILD_HTMLDOC_TRUE

 BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
 {
   TRUE =
 }
doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition TRUE, 
which implies condition FVWM_BUILD_MANDOC_TRUE


 BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
 {
   FVWM_BUILD_HTMLDOC_TRUE = $(HTML_FILES)
   TRUE =
 }
+ exit 3



This is with automake 1.6.3 and autoconf 2.59.

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On Thu, 16 Aug 2007, Dominik Vogt wrote:


On Thu, Aug 16, 2007 at 09:08:51PM +0200, Viktor Griph wrote:

yOn Thu, 16 Aug 2007, Viktor Griph wrote:


On Thu, 16 Aug 2007, Dominik Vogt wrote:


On Thu, Aug 16, 2007 at 07:42:36PM +0200, Viktor Griph wrote:


I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.


What's the problem?



doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition
TRUE, which implies condition FVWM_BUILD_HTMLDOC_TRUE
BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
{
  TRUE =
}
doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition
TRUE, which implies condition FVWM_BUILD_MANDOC_TRUE

BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
{
  FVWM_BUILD_HTMLDOC_TRUE = $(HTML_FILES)
  TRUE =
}
+ exit 3



This is with automake 1.6.3 and autoconf 2.59.


I tried to fix it without understanding the problem. Does it work
now?



yes, thanks

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On Fri, 17 Aug 2007, Dominik Vogt wrote:


On Thu, Aug 16, 2007 at 10:13:19PM +0200, Viktor Griph wrote:

On Thu, 16 Aug 2007, Viktor Griph wrote:

On Thu, 16 Aug 2007, Dominik Vogt wrote:

Most important: the generated man page is still broken.  For
example:


allbox tab(:); lB lB lB.  T{   T}:T{ depth 8 (256 colors) T}:T{
depth 4 (16 colors) T} l l l l l l l l l.  T{ PseudoColor T}:T{ 68
(4 cc + 4 grey) T}:T{ 10 (2 cc + 2 grey) T} T{ GrayScale T}:T{ 64
regular grey T}:T{ 8 regular grey T} T{ DirectColor T}:T{ 32 (3 cc
+ 5 grey) T}:T{ 10 (2 cc + 2 grey) T}

There are three other places with similar broken formatting in fvwm.1.


I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.


Does that formatting show up in your processed output?


Yes, that's from the formatted man page.


It is formatting
for tbl(1), which seems to be used by docbook for tables. Is it feasable
to require tbl for building fvwm.1? I think it has been around for a long
time, but I don't know for how long. GNU roff runs preprocessors
automatic, but for compatibility it has to be done at build time.


I really don't know what you are talking about, but gnu tbl is
installed on my machine.  Are you saying that tbl is required for
generating the man page or for viewing it?  And when I run


tbl was required for viewing it until my latest commt. Now it should only 
be required for generating it. I'm not sure exactly why your version of 
man doesn't process tbl input, but it didn't work on a solaris 9 machine I 
have access to either, so I igured it has to be done at build stage for 
compatibility.




 $ nroff fvwm.1 | col -bx

manually, I still have that markup in the output.



Does it work with the latest Makefile?

/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On Mon, 13 Aug 2007, Dominik Vogt wrote:


On Mon, Aug 13, 2007 at 11:08:57AM +0100, seventh guardian wrote:

On 8/6/07, Dominik Vogt [EMAIL PROTECTED] wrote:

On Mon, Aug 06, 2007 at 02:02:35PM +0100, seventh guardian wrote:

The NEWS file is getting long, so I believe a new release would be
good.


Yes.


Ok, so where do we stand now?

* The new module code should be safe [done]

* Is everything related to the manpage fixed?


No, not at all.  The only thing fixed is that building the docs
does not require GNU make anymore.  All other points on the list
remain.


The fixmes are gone. Perl isn't needed for building but it's unconvinient 
to add commands, but that can be fixed after release. Were there any other 
points?


/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On Tue, 7 Aug 2007, Scott Smedley wrote:


The documentation:

 * There are several FIXME comments in the generated
   documentation.  Try this:

 $ cd doc
 $ find . -type f | xargs grep -I FIXME


All the FIXME stuff in the docbook-xsl/ subdirectory can be safely ignored.

A better check:

$ cd doc
$ find . -name '*.xml' | xargs grep -i FIXME

There are only 2 matches. Both minor  not a reason to preclude a
2.5.22 release.



* The boolean arguments section is still missing from the new manpage.


On a separate issue:

I am keen to implement Viktor's suggestion to build the documentation
on 'make dist'. See:

http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/3173

(It doesn't have to happen before 2.5.22) I think this is a very good
idea. Among other things, it would alleviate some of DV's concerns about
slow build times.

DV: As you have a much better grasp of the build system than I, is this
   something you might like to tackle? If not, some implementation
   advice would be very helpful.



The manpage is currently built on make dist. Maybe the configure uption 
for controlling man output should be removed. Html output is not built on 
make dist yet.


/Viktor

Re: New 2.5.22 release?

[Viktor Griph]

On 8/7/07, Scott Smedley [EMAIL PROTECTED] wrote:
  I'm not going to release fvwm with a big fat FIXME

 I didn't realise Viktor had already made a change to install the new
 man page. The old man page is still around.

 VG: any reason for installing the new man page  still building the old one?

No reason in particular I think it can sefely be deleted from CVS, but
I'm not sure how fvwm-web works with the new manpage (Ok, it's a
separate page, but the old man2html generated page still exists, and
the new man page doesn't blend into the style of that page). The old
documentation is outdated, and couldn't be used for a release. That's
why I changed to install the new one. The fixmes should be gone now.

/Viktor

Re: crash caused by FreeConditionMask()

[Viktor Griph]

On Tue, 7 Aug 2007, Daniel Vrcic wrote:


Hi list.

I've following condition that I'm using in some of my conditional
commands

(CurrentPage, !Iconic, !ktray)

that is causing the crash due the free'ing of invalid pointer that is
triggered on

free(p-name - (pp-invert ? 1 : 0));

line.

In the previous snapshot I used - 20070630, p-name - 1 would point to
!ktray string, but in the recent one it's just non valid address
probably due the changes in CreateConditionMask().


That's correct. With the changes in CreateConditionMask() the name will 
always be allocated, and not the full condition.



Please, fix this.


fixed

/Viktor

Re: CVS renato: moved linked list mechanism from fmodule struct to fmodule_store struct

[Viktor Griph]

On Sun, 5 Aug 2007, FVWM CVS wrote:


CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: renato  07/08/05 15:49:11

Modified files:
.  : ChangeLog
fvwm   : events.c modconf.c module_interface.c
 module_list.c module_list.h stack.c

Log message:
moved linked list mechanism from fmodule struct to fmodule_store struct
changed the functions accordingly


This change reintroduces the error where the structure containing the next 
pointer is read after the next pointer is read on module error during IO.


For instance module_recieve can call module_kill, which calls 
module_list_remove, which frees the fmodule_store that is looped over in 
outer code. These structures must not be freed until nothing points to 
them. To be on the safe side that is only in the module_cleanup function.


/Viktor

Re: CursorStyle triggers a segmentation fault

[Viktor Griph]

On Tue, 17 Jul 2007, seventh guardian wrote:


On 7/16/07, Dominik Vogt [EMAIL PROTECTED] wrote:

On Mon, Jul 16, 2007 at 05:03:59PM +0100, seventh guardian wrote:
 Oh my... this is bad..

 In current cvs, this causes a segmentation fault:

 Open FvwmConsole
 Type cursorstyle ROOT 10
 (repeat the style if necessary)
 Close the FvwmConsole

 Boom, segmentation fault. Any ideas?

I don't get any crashes.  Do you have a stack trace and an minimal
config file?


I've experienced some random segmentation faults on module termination, 
that seem to happen on amd64, but not on i686 (I'm not sure why that is). 
I've committed a fix, check if it solves your problem.




No stack trace, just a simple Segmentation fault message...


run ulimit -c unlimited before starting fvwm to enable core dumps.

/Viktor

Re: Documentation for new command?

[Viktor Griph]

On Thu, 12 Jul 2007, seventh guardian wrote:


About the doc page creation, it seemed simple at first, but I had to
search hard for the relevant info. Maybe a clearer how-to should be
created? This is the first time I'm creating a manual entry, so here
are my steps:

1. enter doc/commands
2. copy a similar command like Echo.xml to EchoFuncDefinition.xml

3. change the section id, title and cmdsynopsis to the correct name
4. change the arg in cmdsynopsis from 'string' to 'function'

5. change the para section according to the previous menu entry,
noting that the reference to the 'Echo' command should obey the
convention in README in order to generate an appropriate link. It
would become like this:

[...]

6. now it's time for adding it to doc/fvwm/userFunctions.xml, which
seems the most relevant group for it.

7. then add it to the Makefile.am COMMANDS variable.
8. finally it's a matter of creating a changelog entry and adding it to cvs

This seems fairly simple now, but took me some time to figure out. I
believe there should be a how-to somewhere.. Maybe I'll do it, as soon
as I get in the mood ( now is time for lunch :)



I believe you vate to add it to groupedCommands.html and there seems to be 
some script to run to have it added to allCommands.html.


/Viktor

Re: GPLv3?

[Viktor Griph]

On Fri, 6 Jul 2007, Dominik Vogt wrote:


Should we upgrade to the GPLv3?



I have no objection.

/Viktor

differences between the docbook manpage and the old manpage

[Viktor Griph]

On Thu, 7 Jun 2007, FVWM CVS wrote:

* use more precise docbook tags in many places
* use variablelist for the fvwm variable list instead of table
* make environment variables and keysyms typeset as before


I've started to compare the generated man page with the old hand written, 
and the above changes are some small changes that makes the generated 
manpage look more likte the original in some aspects. There are still 
several differences, some which are good, some which doesn't matter, and 
some which are bad. I'm not sure how many of the are intended and how 
many are a result of bad automatic conversion.


* alignment:
- The old manpage is justified, the generated man page is
left-aligned.
My opinion: don't care

* tables:
- The old manpage use manually written tables where needed,
the new use docbook generated tbl code for tables.
There is a docbook limitation that the entire table must either be
in borders or without them.
My opinion: tables look better with only iner borders, but it's
not worth hacking docbook to get around the limitation.

* section spacing:
- In the old manpage most sections had an extra line at the end.
(Some sections had more, some had less.) The generated manpage
have all one line between sections.
My opinion: don't care

* examples:
- keywords in programlistings are marked up (since they are links)
but used to be displayed in plain text in the manpage.
My opinion: It's a lot of formatting in an example. Maybe fvwmrefs
in programlistings shouldn't add extra markup in manpage output.

* sentence spacing:
- sentences in the old manpage are separated with two spaces.
Docbook uses single spaces everywhere. It should be possible to
somehow add extra spaces between sentences.
My opinion: don't care, seems to be a lot of work

* url markup:
- Urls are marked up with italic instead of bold.
My opinion: italic looks better for urls than bold did

- Urls are not split over lines with docbook.
My opinion: don't care, leaves a lot of white space on the line
before. With justified alignment they have to break.

* lists:
- list take up more space in docbook.
My opinion: case to case basis. Most lists have sort items, so
they will never split over multiple lines, so it will just be lots
of extra whitespace as a result.

- itemized lists use bullets instead of hyphens
My opinion: don't care

* indentation:
- Some items are indented one level less than the original manpage
My opinion: as long as it looks OK I don't care

* sections:
- Subsections are typeset withoutupper case in docbook. The old
man page used uppercase for both sections and subsections.
My opinion: don't care

- Subsubsections and subsubsubsection are typeset as subsections.
My opinion: should be fixed

* commands:
- used to have their own synapsis on the title line, now on its
own line.
My opinion: the old way looks better

* missing sections:
- The sections AUTO-RAISE, BOOLEAN ARGUMENTS and
CONDITIONAL COMMANDS AND RETURN CODES are missing in the docbook
man page.
My opinion: The sections should be restored, unless a motivation
for not including them can be given.

/Viktor

generating the manpage on make dist?

[Viktor Griph]

I've been thinking some of this docbook documentation, and I think that it 
would be better to generate the man-page during make dist, or when asked 
for.


The generation process takes quite some time, and requires extra tools. It 
will however still be the same for everyone that builds it, so there 
should be no reason for having all users generating the man page during 
compilation.


Is there any reason for not doing this?

/Viktor

Re: Problems building snap-20070430

[Viktor Griph]

On Tue, 1 May 2007, seventh guardian wrote:

rm -f fvwm.sv_SE.gmo  /usr/bin/msgfmt -c --statistics -o fvwm.sv_SE.gmo 
fvwm.sv_SE.po

fvwm.sv_SE.po:56:2: parse error
fvwm.sv_SE.po:56: keyword fvwm unknown
fvwm.sv_SE.po:61:2: parse error
fvwm.sv_SE.po:63: duplicate message definition
fvwm.sv_SE.po:59: ...this is the location of the first definition
fvwm.sv_SE.po:66:2: parse error
/usr/bin/msgfmt: found 5 fatal errors
make[1]: *** [fvwm.sv_SE.gmo] Error 1
make[1]: Leaving directory `/home/tibbs/fvwm/po'
make: *** [distdir] Error 1



I'm sorry but I can't reproduce this:

$ cd fvwm/po/
$ make fvwm.sv_SE.gmo
rm -f fvwm.sv_SE.gmo  /usr/bin/gmsgfmt -c --statistics -o
fvwm.sv_SE.gmo fvwm.sv_SE.po
67 translated messages.



It seems as if the build directory has files locally modified, which has 
resulted in a cvs-conflict.


/Viktor

Re: MouseFocus doesn't work for Java GUIs

[Viktor Griph]

On Sun, 4 Mar 2007, Harald Dunkel wrote:


Hi folks,

It seems that MouseFocus doesn't work with Java GUIs sometimes.
If I move the mouse into the Java window (e.g. tv-browser, or
the Accurev GUI), then the Window doesn't become active. Even
if I click on the header the title bar gets selected for a
second (it seems to be waiting for something), but after that
the Java Window is not selected.

???

Platform is native amd64. fvwm is the CVS head of 2 days ago.
Java is 1.5.0-11.


Any help would be highly appreciated.




Use the lenient focus policy.

/Viktor

Re: FvwmScript patch

[Viktor Griph]

When sending a message to this list, please post replys below quoted text. 
Also don't send HTML to this list.


On Fri, 16 Feb 2007, julio teca wrote:


Hi Victor,

I have noticed that my entry has been removed from the
ChangeLog in the last snapshot. Could I ask what was wrong
about it?


It's still there, in the modules/ChangeLog.



It would be great If you could include my name in the list of
authors of FVWM. The entry would be:

Julio J. Teca Nemesio


You are already listed.

/Viktor

Re: FvwmScript patch

[Viktor Griph]

On Sun, 4 Feb 2007, julio teca wrote:


Hi Victor,

I am terribly sorry for the unexpected delay. Lately I have had a lot
of work.

The changelog and the man-page patch can be found at:

http://usuarios.lycos.es/staufway/FvwmScript.1.in.patch
http://usuarios.lycos.es/staufway/ChangeLog

If you have any problems with the patch, full version of
the file can be found at:

http://usuarios.lycos.es/staufway/FvwmScript.1.in



I've applied your patch with some minor changes. Most notably some fixes 
in the handling of unexpected strings sent by SendToModule.


If you reply in future, please reply ot the list, and reply with quoted 
text above the reply.


/Viktor

more issues with shaded resize

[Viktor Griph]

Shaded resize works well with interactive operation. However there are 
multiple issues with resizing a shaded window by arguments.


* The code assumes that any shaded window is shaded in N or S direction. 
(it allows for change of the width of the window, but not the height.)

Resizing a E or W shaded window gives a very bad result.

* The code bases relative resizing on frame.g and not the unshaded (or 
normal) gemoetry (Which should it be?).


/Viktor