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

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

Re: CVS domivogt: * Use flib_init_graphics().

[Viktor Griph]

On Sat, 27 Jan 2007, FVWM CVS wrote:


Log message:
* Use flib_init_graphics().



You only use it in the modules subdirectory. Did you miss to commit in 
bin and fvwm?


/Viktor

Re: CVS griph: * add fvwmlib.c to libfvwm_a_SOURCES

[Viktor Griph]

On Sat, 27 Jan 2007, Dominik Vogt wrote:


On Sat, Jan 27, 2007 at 07:18:45AM -0600, fvwm-workers wrote:

CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   07/01/27 07:18:45

Modified files:
.  : ChangeLog
libs   : Makefile.am

Log message:
* add fvwmlib.c to libfvwm_a_SOURCES


Hm?  I already added it.


You must have missed to commit it.

Last commit to Makefile.am was 11:33:16 with the headerfile split. The 
file fvwmlib.c was added 11:39:02 with the commit of flib_init_graphics().


At least it wasn't there when I updated the tree.

/Viktor

Re: cross-referenced FVWM documentation

[Viktor Griph]

On Mon, 22 Jan 2007, Scott Smedley wrote:


Hi all,

Latest HTML output can be seen at:

http://members.optusnet.com.au/~scott.fvwm/index.html

Any objections to commiting this? I've yet to convert all the other man pages
(mostly modules) but it should be pretty straight forward now.


Options to commands are not distinguisable from the commands and other 
syntactic components. There is a big FIXME in the middle of the Move page.


/Viktor

Re: StackTransientParent race condition

[Viktor Griph]

On Sun, 14 Jan 2007, Dominik Vogt wrote:


On Thu, Jan 11, 2007 at 03:59:58PM +0100, Viktor Griph wrote:

If an application itself tries to implement some kind of similar feature,
and does it in a simple (and bad) way it may result in a race condition
between fvwm and that app. I believe this is what Apple Shake is doing
based on some guesses, the face that IgnoreRestack solved it, and reading
the code. (Plus I've been able to make my own ill-behaved app to prove it
can happen.)

The following are the requirements for the race coondition to happen:
* the application is on the topmost used layer
* Style AllowRestack, StackTransientParent applies to the transient
window subject to the race condition.

How it (doesn't) work:
The app want's to keep it's transients above itself, so whenever it
notice a stacking change on it's main window it will raise the transients.
(A real app would probably first make sure that the stacking change
really is an increas in stack level, but for the sake of this bug that
doesn't matter.) Fvwm will then see the raise of the transient and issue a
raise of the main window as a consequence. If this raise isn't to the
topmost layer events will be sent to the application about stacking
change, even if no change really occured. The application will then again
raise it's transients.

The solution as I see it would be to not make any changes if there would
be none. That is to make sure that no restacking takes place if the
transient already is at top, and all other transients are bellow it,
directly followed by the main window. I'm not quite sure how the
restacking code in fvwm works, and I don't have time right now to dwell
into it further.


Hm, I tried to proof read the patch you made, but it's too big to
understand by looking at it for five minutes.  Can you explain how
it is meant to work and point out the pieces of code you are
unsure about, please?


I'm not doing this in cronological order, but base the description on the 
diff between version-2_5_19 and version-2_5_20 tags in cvs, ignoring 
unrealated minor changes (unsigned int - int, modulestuff).


First there are some code move around that doesn't change anything:
* __mark_group_member was moved to the bottom f the local functions for 
consitency, and to not have to forward declare it.
* __mark_transient_subtree_test was created from the body of the for-loop 
in mark_transient_subtree. It is line to line equivalent with that 
for body except that if anywhere is_finished = False it returns True and 
if is_finished = True it returns False. That makes this function test if a 
window should belong to the current transient (and windowgroup) subtree 
and mark it if it isn't already. It returns True if the transient subtree 
is changed and False if not.


Then there is the main logic function is_transient_subtree_straight which 
tests if the traisients are lined up and sorted as they would be after
collect_transient_subtree and sort_transient_subtree. It also checks that 
the tree, for lower has the tree-root at the bottom of the window, and for 
raise that the tree-root is at the top of the layer.


It completely ignores other sstackmodes than raise or lower (returns False 
of these modes). This is becasuse I couldn't follow the logic for when 
other stack modes are used, and it didn't seem important for the race 
condition.


If mark_transient_subtree would do nothing due to the layersetup it 
returns True. An empty tree should be in no need to restack.


After these basic chacks it starts the real work:
Opposed to mark_transient_subtree it walks the tree bottom up. 
(stack_prev instead of stack_next) This is beacuse a sorted tree would 
be markable in one go if starting from bottom. If no transient window 
exists bellow the root window of the stack and from the root window and up 
the stack each window is a transient for a window lower in the stack the 
stack is straight.


Writing this I actually realize that there probably is a minor flaw in 
this algorithm: If any higher level transients are bellow the root window 
for a raise they will not be detected. This would be solved by changing 
the loops to start at the tree root at first and move up to the top of the 
layer marking all windows. And once that is done verify that there would 
be no windows marked from the bottom of the layer to the root window.
I'll not do this change now, but let you have a look at the code in the 
current state. Feel free to fix this minor bug when doing so, or I'll fix 
it sometime in the end of this week or in the next.


Then there is __is_restack_needed which tests if restacking is needed.
This returns True fro SM_RESTACK nad new windows unconditionally.

If do_restack_transients is set it will return the True of the tree is not 
straight. For lower and raise without do_restack_transients it will return 
true if the layer of the next/prevoius window is the same as the layer of 
the restacked window. And in other cases it will return True

Re: StackTransientParent race condition

[Viktor Griph]

On Wed, 17 Jan 2007, Viktor Griph wrote:


On Sun, 14 Jan 2007, Dominik Vogt wrote:
[snip]
It's not that I don't trust your code quality, but the stacking code is 
very difficult to understand and very easy to break.


Yes, I've noticed this. And as you see I actually found a bug while writing 
this. It's always good to reason through the changes made some time later and 
see that they still make sense. Sorry for the long essay.




I forgot one thing:
The tree is started to be marked in __is_transient_subtree_straight. This 
changes the screatch.i values. Thus it can not be entirely cleared later 
when mark_stansient_subtree is calles, but it has to continue from where 
the check failed. I'm not very happy with this, but I couldn't find out 
any simple way to do with except using the scratch.i value of Scr.FvwmRoot 
to indicate if a scan has been started or not. Improvments are welcome.


/Viktor

Re: CVS griph: * don't mangle $png_LIBS, use --with-png-library

[Viktor Griph]

On Tue, 16 Jan 2007, Dominik Vogt wrote:


On Tue, Jan 16, 2007 at 12:10:59AM +, seventh guardian wrote:

* remove NEWS about fixing pan frames. I did move the tag on stack.c and
ChangeLog and uploaded new tar-balls. The bug was simply too annoying.


I was hoping someone would say something about that soon enough :)


Hm??

Anyway, moving tags is not the thing to do.  If a release is
flawed, a new one can be built immediately, but if the tags are
changed we might end up with several tarballs bearing the same
release number.


I'll not do that again then. I only did it bacause the the tar balls 
hadn't been put in place yet (and they still haven't).


/Viktor

Re: cross-referenced FVWM documentation

[Viktor Griph]

On Sun, 14 Jan 2007, Scott Smedley wrote:


Hi all,

I have been working on converting the FVWM documentation into DocBook
format. You can view some preliminary HTML results on-line.

http://members.optusnet.com.au/~scott.fvwm/index.html



looking good.


The most interesting links, so far, are:

All Commands
Grouped Commands
Modules
FVWM man page

Comments/criticism/feedback most welcome.


ChangeMenuStyle is not deprecated.

/Viktor

Re: deiconify may loop forever

[Viktor Griph]

On Sun, 14 Jan 2007, Dominik Vogt wrote:


On Sun, Jan 14, 2007 at 04:42:23PM +0100, Viktor Griph wrote:

This loop is on line 2288 in icons.c:

for (ofw = NULL; fw != ofw  IS_ICONIFIED_BY_PARENT(fw); )
{
t = get_transientfor_fvwmwindow(fw);
if (t != NULL)
{
ofw = fw;
fw = t;
}
}

I'm not sure exactly what it is supposed to do, but if a non-transient
window is iconified by IconifyWindowGroups it will loop forever.


This loop looks for the top window of the transient tree.
Actually, your fix broke that logic because it climbs only one
level up the tree.  The right fix is to break the loop if
get_transientfor_fvwmwindow returns NULL.  The comparison
(ofw == fw) is there to catch windows that are their own
transients.


My fix did still climb the tree. What it did was to always assign ofw=fw, 
and as long as t wasn't null assign fw = t. Which mean that only if t was 
the same as fw or t was NULL would ofw == fw, and the loop would end.


It changed the value of ofw after the loop, but it wasn't used anyway.

However I'm still not convinced that this is the right fix. That code was 
written without the IconifyWindowGroups option in mind, shouldn't it 
really try to climb to the head of the windowgroup as well? Maybe it is 
ennoug to use the mark_transient_subtree result. That function doesn't 
care about if it's called with the head of a tree or not.


The only effect the loop has is that deiconifying raises, not the window 
selected for deiconify, but the root of the transient tree. Isn't it 
better to raise the window selected, and let the 
styles StackTransientParent and RaisTransient control which windows 
actually are raised.


/Viktor

Re: CVS domivogt: * Use resize_inc hint even with ResizeHintOverride style.

[Viktor Griph]

On Sun, 14 Jan 2007, FVWM CVS wrote:


Log message:
* Use resize_inc hint even with ResizeHintOverride style.


Does this make ResizeHintOverride do nothing?

/Viktor

Re: CVS domivogt: * Use int instead of unsinged int in many places.

[Viktor Griph]

On Sat, 13 Jan 2007, FVWM CVS wrote:

* Use int instead of unsinged int in many places.


but gcc4.1 complains on passing wrongly signed types to function taking 
pointers as arguments:


Graphics.c:849: warning: pointer targets in passing argument 5 of 
XQueryBestTile differ in signedness


/Viktor

Re: CVS domivogt: * Use int instead of unsinged int in many places.

[Viktor Griph]

On Sat, 13 Jan 2007, Dominik Vogt wrote:


On Sat, Jan 13, 2007 at 05:41:43PM +0100, Viktor Griph wrote:

On Sat, 13 Jan 2007, FVWM CVS wrote:

* Use int instead of unsinged int in many places.


but gcc4.1 complains on passing wrongly signed types to function taking
pointers as arguments:

Graphics.c:849: warning: pointer targets in passing argument 5 of
XQueryBestTile differ in signedness


Does it also bug out with -Werror?  In any case, it's okay to cast
ints to unsigned ints before passing them to X functions, but I
don't want any more unsingned arithmetics in the fvwm code.

Well, as I don't have a gcc version that throws errors, I can't
fix the warnings.


I've found that it's possible to add -Wno-pointer-sign to surpress the 
specific warning. I still don't like it. I'd rather have the arithmetic 
fixed. But seeing the trouble it introduced I undertand it isn't easy to 
do at the current stage. Maybe we can do it after 2.6 and take it slowly 
to not introduce any bugs.


/Viktor

Re: StackTransientParent race condition

[Viktor Griph]

On Thu, 11 Jan 2007, Viktor Griph wrote:

...If this raise isn't to the topmost layer...


I mean is to the topmost layer

/Viktor

Re: CVS griph: * don't warp on popdown if triggered by motion

[Viktor Griph]

On Wed, 10 Jan 2007, Dominik Vogt wrote:


CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   07/01/09 16:18:10

Modified files:
fvwm   : menus.c
.  : ChangeLog

Log message:
* don't warp on popdown if triggered by motion


Can you describe the problem please?



I introduced the problem with the menu bindings, when allowing an action 
by mouse to do MoveCursorLeft/MoveCursorRight, and in the same time warp 
the pointer back. That was the intended change. However it also changed it 
so that when you moved from a popup back to it's parent it would warp back 
to the parent item. That was what I fixed by requiring it to be a button 
release for mouse events to do a warp.


/Viktor

Re: CVS griph: * don't warp on popdown if triggered by motion

[Viktor Griph]

On Wed, 10 Jan 2007, Viktor Griph wrote:


On Wed, 10 Jan 2007, Dominik Vogt wrote:


CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   07/01/09 16:18:10

Modified files:
fvwm   : menus.c
.  : ChangeLog

Log message:
* don't warp on popdown if triggered by motion


Can you describe the problem please?



I introduced the problem with the menu bindings, when allowing an action by 
mouse to do MoveCursorLeft/MoveCursorRight, and in the same time warp the 
pointer back. That was the intended change. However it also changed it so 
that when you moved from a popup back to it's parent it would warp back to 
the parent item. That was what I fixed by requiring it to be a button release 
for mouse events to do a warp.




I've noticed a related issue which needs some decision on how to handle. 
This is mouse clicks inside a menu, not on an item. Before the 
menubindings they used to close the menu. Now they warp to the closest 
item, which is not good.


I see a few possibilities to resolve this:

* Possible add more contexts recognized by menu bindings.

or

* Make it so that clicks outside of items are hardwired to MenuClose.

I favor the first option, but it requires more thought on what context 
specifiers to use with menus. The second option would solve the issue for 
now, and leave open for additional menu contexts later.


/Viktor

Re: CVS griph: * don't warp on popdown if triggered by motion

[Viktor Griph]

On Wed, 10 Jan 2007, Dominik Vogt wrote:


On Wed, Jan 10, 2007 at 05:04:46PM +0100, Viktor Griph wrote:

On Wed, 10 Jan 2007, Viktor Griph wrote:


On Wed, 10 Jan 2007, Dominik Vogt wrote:


CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph   07/01/09 16:18:10

Modified files:
fvwm   : menus.c
.  : ChangeLog

Log message:
* don't warp on popdown if triggered by motion


Can you describe the problem please?



I introduced the problem with the menu bindings, when allowing an action
by mouse to do MoveCursorLeft/MoveCursorRight, and in the same time warp
the pointer back. That was the intended change. However it also changed it
so that when you moved from a popup back to it's parent it would warp back
to the parent item. That was what I fixed by requiring it to be a button
release for mouse events to do a warp.



I've noticed a related issue which needs some decision on how to handle.
This is mouse clicks inside a menu, not on an item. Before the
menubindings they used to close the menu. Now they warp to the closest
item, which is not good.

I see a few possibilities to resolve this:

* Possible add more contexts recognized by menu bindings.

or

* Make it so that clicks outside of items are hardwired to MenuClose.

I favor the first option, but it requires more thought on what context
specifiers to use with menus. The second option would solve the issue for
now, and leave open for additional menu contexts later.


I prefer an additional context too.  But can you give me a menu
and a menustyle to demonstrate this?  I can't make it happen out
of the box.


Either you need some sidepic, or you have to make the borders large 
ennough to click on:


MenuStyle * SidePic someimage.png

MenuStyle * BorderWidth 10

/Viktor

Re: Commit in FScreen.c

[Viktor Griph]

On Tue, 9 Jan 2007, Dominik Vogt wrote:


I'd prefer to leave the blank lines before return statements in
place because they are there on purpose.


That newline was removed by misstake. I normally don't remove newlines, or 
touch other spacing. If I do large changes to an incorrectly indented 
function I'll reindent and respace it, but if I make small local changes 
withing such a function I normally leave the original formatting intact.


/Viktor

Re: CVS domivogt: * Reindented and cleaned up FvwmConsole code.

[Viktor Griph]

On Sun, 7 Jan 2007, FVWM CVS wrote:

* Added library files fio.c and fio.h to provide wrappers for the io functions
that filter EINTR for the caller.


You have not added fio.[ch] to the CVS.

/Viktor

Re: focus when between pages

[Viktor Griph]

On Thu, 4 Jan 2007, Thomas Adam wrote:


On Thu, Jan 04, 2007 at 07:11:58PM +0100, Viktor Griph wrote:

Is it intended that focusing a fully visible window shall change page
to the page containing most of the window?


I should nope not; especially when you consider the fact that some
people like the ability to Scroll -10 +0 (for instance) continually.
The fact that some window(s) might gain focus that way should not mean
the viewport is automatically switched to it.  This would lose the
ability to keep the viewport off-kilter.

The only time the viewport should be switched fully is if one does
something like:

Next (foo) Focus

From within a location where the viewport was between pages, for
instance.  And current this is what happens anyway.


I think that changing the viewport only should be done if more of the 
Window would be visible that way. If a window is fully visible at an 
inbetween pages position and it is focused with Next (foo) Focus, there is 
no need to move the viewport and possible the window too to make it 
vissible, while the result might actually be a less visible window.


Example:

In a FvwmCommand do
Current Stick on
GotoPage 0 0
Scroll 50 50
Current Move 50 50
Current Move w-$[w.width]p w+0
Current Move w+25p w+0
Current Stick
Current focus

Result: The viewport will change to 0 1, and the previously fully visible 
FvwmCommand will now have 25 pixles to the right of the viewport, and thus 
be less visible than before the focus command.


The most annoying thing is ofcource applicartions that trigger this 
behaviour by gaining focus in other ways.


/Viktor

Re: focus when between pages

[Viktor Griph]

On Thu, 4 Jan 2007, Thomas Adam wrote:


On Thu, Jan 04, 2007 at 08:02:06PM +0100, Viktor Griph wrote:

Result: The viewport will change to 0 1, and the previously fully visible
FvwmCommand will now have 25 pixles to the right of the viewport, and thus
be less visible than before the focus command.


I don't actually consider this a problem.  After all, it is doing
exactly what you asked of it.  :)  I would find it more annoying that
decisions such as that were made on the user's behalf, when it could
conceivably be not what the user wanted in the first place.


Well, there is nothing in the manpage that say that focusing without 
NoWarp must bring the viewport to a true page. Otherwise it also moves

the viewport or window as needed to  make  the  selected window visible.
But if the window already is fully visible no such move should be needed.




The most annoying thing is ofcource applicartions that trigger this
behaviour by gaining focus in other ways.


Anything that has UrgencyHint in it, for instance, yes.  And other ways
too.  But again, that's doing what is asked of it too.



Do you by any chance know what java AWT transient windows do to gain focus 
when displayed? I want an ExplainFocus BugOpts option...


/Viktor


I'm not playing devil's advocate here -- I just don't see what it is
changing the way it currently works accomplishes.  Windows shouldn't
impose themselves entirely on an exact bounds of the viewport anyway --
if the user so wishes that a window is placed between two pages, then so
be it.  The fact that viewport could be inbetween pages at a time when
focus was given to an application (and hence warped) then sobeit,
although one could accomplish switching pages fully with something like:

DestroyFunc MyFunc
AddToFunc   MyFunc
+ I Current (Visible) GotoPage $[page.nx] $[page.ny]

(Crude at best, but you get the idea.)

-- Thomas Adam

Re: todo-2.6: C.23 XForms sliderall demo

[Viktor Griph]

On Sun, 31 Dec 2006, Viktor Griph wrote:


On Sun, 31 Dec 2006, Dominik Vogt wrote:


On Sat, Dec 30, 2006 at 06:03:55PM +, seventh guardian wrote:

On 9/1/06, Viktor Griph [EMAIL PROTECTED] wrote:
I've been doing some tests, and the problem is partly fixed in the 
current
version. Keybindings no longer stop working as in the bug description, 
but

the focused window decorations are still incorrect in the same way as
reported.

sliderall is an unmannaged window that takes focus on EnterNotify, and
keeps the focus until any other window takes focus, or the wm gives focus
away to some other window. When fvwm detects an unmannaged window 
stealing

focus it does not change the decoration of the focused window, and if the
unmanaged window gives away the focus fvwm sends it back to the window
that had focus before. With SloppyFocus, as in the case of the report the
focus will not be taken by fvwm if the mouse enters the root window, but
fvwm will still show the earlier focused window as focused.

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


Revisiting this topic,

The most consistent way would be to defocus the previously focused
window. With Sloppyfocus, if the mouse enters the root window the
unmanaged window should keep the focus, only giving it away if the
pointer enters another window. This is a) I believe.

In any case, a window should only appear as focused if it has in fact the
focus.


I think it's (b) + (c):

 If the focus was stolen by an unmanaged window (i.e. we got an
 FocusOut even but no FocusIn event)

 AND

 If the pointer enters the root window or any other managed
 window afterwards

 THEN

 reinstall the focus to the proper window, if necessary (i.e. if
 the focus does not change anyway).

Rationale

 What is happening is exactly what the man page says for the
 FlickeringQtDialogsWorkaround option.

 Therefore, the real bug in fvwm is that the window does not get
 the focus back when the pointer goes back to one of our windows.

Of course we can think about disabling
FlickeringQtDialogsWorkaround by default, but I think that effect
is much worse than the xforms problem.

Coding my suggested solution should be fairly easy:

(1) If FlickeringQtDialogsWorkaround is enabled, store the
is_unmanaged_focused somewhere (in the Scr structure?).

(2) If the pointer enters a managed window (or the pan frames,
root window etc.) and the focus does not change anyway,
reinstall the focus.

(2) might be tricky.



What it does now (after my attempt to fix it in September) is that it does 
steal back to focus if the pointer reenters any managed window that would 
normally gain focus based on the current focus policy, or if the pointers 
enters the window that shows as focused regardless of focus policy.


Before it would not refocus the window displayed as focused unless another 
window was focused inbetween. I'll see if I can make it give the focus back 
on the pan frames and root window as well as steal it back when entering 
other managed windows in ClickToFocus mode.


/Viktor



It was actually quite easy to test for this case. The variables needed 
were already there:

sf = get_focus_window()
(Scr.UnknownWinFocused != None  sf != NULL
  FW_W(sf) == Scr.StolenFocusWin)

/Viktor

Re: CVS griph: * added menu context mouse and key bindings

[Viktor Griph]

On Sat, 30 Dec 2006, Serge (gentoosiast) Koksharov wrote:


Hello,

I tested new menu bindings config and noticed some problems. Attached
patch fixes them.



I've applied the patch.


The only problem remaining is:
When I start FVWM I get this message in ~/.xsession-errors:

[FVWM][ParseBinding]: ERROR No such key: KP_Separator

And it is true. I use fairly standard russian PC104 keyboard and
pressing key with Delete label on keypad generates KP_Decimal 
KP_Delete depending on NumLock state. Either Viktor was wrong when he
created config or his keyboard differs from mine. Your opinions how this
situation should be handled?


I changed all KP_ bindings to Silent, since there may be keyboards without 
a numpad. I also added KP_Decimal as a binding for MenuClose. That should 
ensure functionality regardless of the name of the key.


/Viktor

Re: todo-2.6: C.23 XForms sliderall demo

[Viktor Griph]

On Sat, 30 Dec 2006, seventh guardian wrote:


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

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

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

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



Revisiting this topic,

The most consistent way would be to defocus the previously focused
window. With Sloppyfocus, if the mouse enters the root window the
unmanaged window should keep the focus, only giving it away if the
pointer enters another window. This is a) I believe.

In any case, a window should only appear as focused if it has in fact the 
focus.




I remember solving this in some way. Not sure what step I took. But it is 
a very rare case (probably only shoing in example code) that conflicts 
with a bugopts option (FlickeringQtDialogsWorkaround) which defaults to 
on.


/Viktor

Re: todo-2.6: C.23 XForms sliderall demo

[Viktor Griph]

On Sun, 31 Dec 2006, Dominik Vogt wrote:


On Sat, Dec 30, 2006 at 06:03:55PM +, seventh guardian wrote:

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

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

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

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


Revisiting this topic,

The most consistent way would be to defocus the previously focused
window. With Sloppyfocus, if the mouse enters the root window the
unmanaged window should keep the focus, only giving it away if the
pointer enters another window. This is a) I believe.

In any case, a window should only appear as focused if it has in fact the
focus.


I think it's (b) + (c):

 If the focus was stolen by an unmanaged window (i.e. we got an
 FocusOut even but no FocusIn event)

 AND

 If the pointer enters the root window or any other managed
 window afterwards

 THEN

 reinstall the focus to the proper window, if necessary (i.e. if
 the focus does not change anyway).

Rationale

 What is happening is exactly what the man page says for the
 FlickeringQtDialogsWorkaround option.

 Therefore, the real bug in fvwm is that the window does not get
 the focus back when the pointer goes back to one of our windows.

Of course we can think about disabling
FlickeringQtDialogsWorkaround by default, but I think that effect
is much worse than the xforms problem.

Coding my suggested solution should be fairly easy:

(1) If FlickeringQtDialogsWorkaround is enabled, store the
is_unmanaged_focused somewhere (in the Scr structure?).

(2) If the pointer enters a managed window (or the pan frames,
root window etc.) and the focus does not change anyway,
reinstall the focus.

(2) might be tricky.



What it does now (after my attempt to fix it in September) is that it does 
steal back to focus if the pointer reenters any managed window that would 
normally gain focus based on the current focus policy, or if the pointers 
enters the window that shows as focused regardless of focus policy.


Before it would not refocus the window displayed as focused unless another 
window was focused inbetween. I'll see if I can make it give the focus 
back on the pan frames and root window as well as steal it back when 
entering other managed windows in ClickToFocus mode.


/Viktor

Re: [bug] fvwm -r is broken

[Viktor Griph]

On Fri, 29 Dec 2006, seventh guardian wrote:


Hello.

fvwm -r when used to replace fvwm by itself is broken, or at least
seems like so. It crashes both versions and gets me to the qingy login
screen..

I've tested with current cvs, replacing another current cvs instance.


If the original fvwm process is in foreground, blocking the xsession from 
termnation feplacing it will indeed terminate any X session. -r should 
work if you have something else controling the termination of your 
X-session other than the termination of fvwm.


It's possible to test by doing a Restart xterm, thten starting fvwm from 
the xterm, and from within the fvwm, start another xterm and run fvwm -r. 
The fvwm in the first xterm should then pack up and leave for the other 
fvwm, but the display should still be blocked by the xtrerm so nothing 
should crash.




Cheers
 Renato

Re: Changing from module arrays to module structure

[Viktor Griph]

On Fri, 29 Dec 2006, seventh guardian wrote:


On 12/29/06, Dominik Vogt [EMAIL PROTECTED] wrote:

On Fri, Dec 29, 2006 at 09:43:23PM +, seventh guardian wrote:
 On 12/29/06, Dominik Vogt [EMAIL PROTECTED] wrote:
 On Fri, Dec 29, 2006 at 02:42:16PM +, seventh guardian wrote:
 
  OOPS it's not safe yet. There's a segmentation fault right in the
  beggining. I'll try to find it.
 
 For such a dangerous change it would be good if you could split
 the diffs into a series of self-contained patches that add/change
 some of the functionality.  It would help to proof read the
 changes.

 You're right.

 First, we are not dealing with module numbers, but pointers to a type
 fmodule. So execcontext.c/h needed changing. Here's the patch.

Okay, that patch looks safe.

Is there any chance to make bigger patches that compile when
applied and can actually be used?  This way we could validate the
code step by step.  For example, you could temporarily put the
modnum into the module struct and use module-modnum instead of
modnum for the moment.


It wouldn't be easy..

The position of a module inside the linked list keeps changing as we
add/remove modules. So the only way for the code to work is dealing
with module pointers instead of indexes.. Keeping an index within each
module would be a nightmare (keeping track of used/ free indexes..),
but could be done..

What I did for now to avoid a mess was to avoid the problem with the
cmd line modules fdsets. I've typecasted the module address to int, so
it should be fairly unique, and it works with the fdset lists.


Pointers should be cast to unsigned long if anything, or it won't work on 
64-bit systems.


/Viktor

Re: FVWM: How to use StippledTitleOff

[Viktor Griph]

On Mon, 17 Jul 2006, seventh guardian wrote:


On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote:

On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote:
 On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote:
 On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote:
 
  Thomas Adam [EMAIL PROTECTED] writes:
 
   On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote:
  
   However it seems it does nothing at all. All the icons still
   have sticky title. Any ideas?
  
   Of course -- the style StippledTitleOff is only applicable to
   non-sticky windows which have been told to use StippledTitle --
   it doesn't work for sticky windows.

 Humm first of all this now should be a flag StippledTitle vs
 !StippledTitle. I will correct 

the man page.


Most commands should be using !Foo in the negatory sense.

 Style only works with window/class names. So there's no easy way of

Name, Class, Resource.

 telling fvwm just to stipple sticky windows. (Like Style Sticky
 !StippledTitle). Perhaps this could be done with conditional
 commands, but it's not an easy thing.

How do you mean?  It's perfectly simple to add something like:

Style * StickyStipples
Style * !StickyStipples

... Which might apply to windows which have been declared as sticky.



Yes, but then you'd end up with lots of equal styles applying to
different situations..



 The imediate solution would be
 to add another style to set/reset the StippledTitle flag only on the
 sticky windows, or globally (like Style * NeverStipple) but in my
 oppinion this is wrong..

Maybe it is, but then you can turn that around and say that stippling
sticky windows in the first place is also wrong.


Yes, I did say that :) but it's just my opinion..



Bringing this topic back to life. I too think that a style StickyStipples 
isn't the best solution, but is something that is needed until a better 
solution can be decided on and implemented.


Thomas' patch on http://starshine.org/xteddy/thomas/fvwm/patches.html 
add the styles StickyWindowStipples and IconStickyStipples. In order to 
make the syntax somewhat normalized I purpose the use of the names
StickyStippledTitle and StickyStippledIconTitle instead. The later 
suggests that StippledIconTitle also should be added for completeness.


/Viktor

Re: Extending the ways for modules to request information back

[Viktor Griph]

On Wed, 9 Aug 2006, Viktor Griph wrote:

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




I've been giving this idea some thought recently, and seen places where it 
would be useful. I'd like to implement a M_REPLY message, generated to 
modules asking for it with a Send_Reply command. This is the most flexible 
implementation.


It would be useful for modules requireing some syncronization, but not 
needing full synchronious operation. FvwmPager now uses a SendToModule 
construction to be able to not flood fvwm with Scroll commands faster than 
fvwm can handle them. This should really be a Send_Reply instruction.


Another useful thing would be to request specific info back via a
FvwmCommand interface. It seems natrural to extend the information level 0 
to include replys as well as error messages, since they would have to be 
asked for.


If there is no voice aginst this being implemented I'll go ahead and add 
it when I get the time, which probably will be just before Christmas.


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

Send_Rc token command

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




I'm leaving the above suggestions open since I have not yet figured out 
what the best way to achive what I want is. I like the idea of keeping a 
return code per module channel in extent to per function better than 
adding a Send_Rc prefix, but I've not seen use for it in any existing 
modules.



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

/Viktor



/Viktor

Re: FvwmScript patch

[Viktor Griph]

On Wed, 4 Oct 2006, julio teca wrote:


Hi,

I have made a patch for FvwmScript. Now It's possible to change the window
title by means of
a new set of instructions or using the SendToModule command.

The new instructions are:

ChangeWindowTitle {string}:  Changes the window title to the string
passed as argument.
ChangeWindowTitleFromArg numarg: Changes the window title to the value of
the numarg
   argument of the script.

The new functionality added to SendToModule:

SendToModule fvwmScriptName ChangeWindowTitle newTitle [oldTitle]

The optional argument oldTitle makes sense when you have several instances
of
the same script. It permits you to avoid the change of the name of all that
instances
by specifying the name of the window associated to the target script (see
the examples
below).

With that functionalities you can reuse a fvwmscript, doing things like
this:


DestroyFunc StartFvwmScriptAndMove
AddToFunc StartFvwmScriptAndMove
+ I FvwmScript $3
+ I Wait $0
+ I All ($0) Move $1 $2

AddToFunc StartFunction
+ I StartFvwmScriptAndMove FwmStorageHda -0 -0 FvwmStorage FvwmStorageHda
/dev/hda
+ I StartFvwmScriptAndMove FwmStorageHdb -0 -30p FvwmStorage FvwmStorageHdb
/dev/hdb

Where FvwmStorage takes the new name of the window from its first argument
and looks
like this:

WindowTitle {FvwmStorage}
...

Init
 ChangeWindowTitleFromArg 1
...


or something like this:

+ I Module FvwmScript /root/fvwm25/FvwmStorageSend /dev/hda6
+ I Wait FvwmStorageSend
+ I SendToModule /root/fvwm25/FvwmStorageSend ChangeWindowTitle HDA6
+ I Module FvwmScript /root/fvwm25/FvwmStorageSend /dev/hda1
+ I Wait FvwmStorageSend
+ I SendToModule /root/fvwm25/FvwmStorageSend ChangeWindowTitle HDA1
FvwmStorageSend

Without the FvwmStorageSend argument in the last case, the SendToModule
command would
have changed to HDA1 the name of the two instances of FvwmStorageSend.

I want to thank Thomas Adam for suggesting me to add the SendToModule stuff
and
his help.

The patch can be downloaded from
http://usuarios.lycos.es/staufway/patch-fvwmscript-2.5.18.gz



Can you please provide ChangeLog entries for functions added and modified, 
and also a patch to the man-page that documents the new functionality.


/Viktor