Re: REWRITE: Bugs in the master branch
On Fri, Sep 12, 2014 at 12:33:14AM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 11:51:50PM +0100, Dominik Vogt wrote: > > I don't see any garbage at the moment. But it's possible that > > this only happens on the other box that does not have XRandR. I'll > > check that tomorrow. > > It seems I've never really explained the butchery that went on in > swapping out Xinerama for XRandR and why I did that. > > Partly, the move was out of anger, and that Xinerama has been deprecated > for ages. In doing this, I tried to keep the behaviour of screens as > best I could in fvwm. > > To that end, the changes I've done are this: > > - Each monitor reported by XRandR is a discrete entity from the other > monitor. (i.e., unlike Xinerama, it's not one big screen divided into > n monitors) Does that mean that each monitor have its own root window? Can you still place windows halfway between multiple monitors? > o Special geometry handling in the form: > > 100x100+100@0 > > Now had to s/0/$MONITOR_NAME > > Where $MONITOR_NAME is either "global" / XRANDR_MONITOR_NAMES Well, if we can still list all monitors in some consistent order, it should be trivial to tanslate the old numbers to the new monitor names. The numbers are just predictable, guaranteed names. In my config I have Read .fvwm2rc.$[screen] and it would be very cumbersome to rename the config files every time the names of the monitors change for some reason. > On the plus-side, I've wanted this separation of monitors to desks for > an eternity, and the above can be changed bit-by-bit along with > everything else. Fine with me for now. Eventually, I guess the whole virtual desktop layout needs to be rewritten some day. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Fri, Sep 12, 2014 at 12:19:04AM +0100, Dominik Vogt wrote:
> On Fri, Sep 12, 2014 at 12:03:13AM +0100, Thomas Adam wrote:
> > On Thu, Sep 11, 2014 at 11:44:30PM +0100, Dominik Vogt wrote:
> > > I'll push a partial fix for this shortly, but you should take a
> > > look at it and implement the missing bit.
> >
> > Would you mind testing the following? Thie seems to work OK for me, but
> > just want to check:
>
> At the moment I don't know how to reproduce it, but the patch
> looks good. Since I'm not using unmanages windows I suspect that
> fw *and* exc->w.w were unset. I'm not sure why WarpToWindow was
> called at all in that situation, but if exc->w.w is none,
> XgetGeometry will now fail and exit the function.
>
> The crash was triggered by my Alt-Down binding:
>
> --
> AddToFunc RaiseAndWarp
> + I Focus
> + I Raise
> + I WarpToWindow 95 $[cw.height]p
>
> AddToFunc DirectionOrThis
> + I Direction $0 (!Iconic, CurrentPage) RaiseAndWarp
> + I TestRc (nomatch) ThisWindow (!Iconic, CurrentPage) RaiseAndWarp
>
> Key Down A M DirectionOrThis South
> --
>
> So this somehow managed to call WarpToWindow without a context
> window. I'll look into this.
>
> I've pushed your patch and another one to git.
Ah. Yes. That was it. Before our fixes this crashes mvwm. After the
fixes they don't, and I'm still able to warp to unmanaged windows as
well.
Thanks!
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: CVS tadam: Update passive grabs tracking modifiers
On Fri, Sep 12, 2014 at 12:17:44AM +0100, Thomas Adam wrote: > On Tue, Sep 02, 2014 at 10:58:30PM +0100, Dominik Vogt wrote: > > On Tue, Sep 02, 2014 at 04:19:33PM -0500, c...@math.uh.edu wrote: > > > Log message: > > > Update passive grabs tracking modifiers > > > > > > In the case of GTK's link widget which doesn't handle passive grabs > > > following FVWM's window bindings (which assumes the underlying > > > application can handle a PointerReplay), update the grabs in this > > > context by always ungrabbing the button and grabbing it for modifiers > > > other than ALL_MODIFIERS. > > > > > > I've had this in testing for three years and recently dusted it off for a > > > bug report I received for another application with this problem, called > > > darktable. > > > > Can you please explain the problem in even more detail? Grabbing > > is a crucial part of fvwm that I want to understand completely. > > (A diff would also be nice for convenience; they're so difficult > > to get from CVS.) > > I'm so sorry, Dominik. I have no idea why I didn't see this reply > sooner. No problem at all; sooner or later I would have asked again. > The specifics of the changes can be found here: > > https://github.com/ThomasAdam/mvwm/commit/46213db4892ea00cfcd5fd421ac82b9a32c074b5 I haven't read that yet, but ... > The problem (as I can see it) is that fvwm grabs everything. What I > noticed with some recent GTK applications is that mouse bindings > assigned in general to windows were interferring with them in that the > application couldn't respond to certain things, such as clicking on > links, etc. I haven't looked at the binding grab code for ages, but I remember that I've spent lots of time to minimize the impact of buttons grabs on the client window. The code should be like this: IF Winodw has ClickToFocus AND Window is not focused grab everything ELSE IF Window has MouseFocusClickRaises and window may be raised* grab everything ELSE grab only the specific bindings *: I'm not sure whether any logic is implemented to determine whether a window is raisable. I guess MouseFocusClickRaises is actually the culprit here. > So when I looked into this, I tried to change fvwm to only grab the > things it needed based on the modifiers in use, etc. But this clearly > broke a few other things (which I don't use). > > Looking into this further still, it seems Compiz have a similar fix to > my proposal above: > > http://git.compiz.org/compiz/core/commit/?id=cf2117be87040f5f19be6b688d481f7369b0f7b5 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:51:50PM +0100, Dominik Vogt wrote:
> I don't see any garbage at the moment. But it's possible that
> this only happens on the other box that does not have XRandR. I'll
> check that tomorrow.
Thank you.
It seems I've never really explained the butchery that went on in
swapping out Xinerama for XRandR and why I did that.
Partly, the move was out of anger, and that Xinerama has been deprecated
for ages. In doing this, I tried to keep the behaviour of screens as
best I could in fvwm.
To that end, the changes I've done are this:
- Each monitor reported by XRandR is a discrete entity from the other
monitor. (i.e., unlike Xinerama, it's not one big screen divided into
n monitors)
- Monitors as reported by XRandR have actual names, not numbers as they
were in Xinerama. This meant:
o A bunch of assumptions from window placement to geometry parsing
had to be undone;
o A special name of monitor "global" can be used to treat both
XRandR screens as one entity (the old behaviour with Xinerama);
o Special geometry handling in the form:
100x100+100@0
Now had to s/0/$MONITOR_NAME
Where $MONITOR_NAME is either "global" / XRANDR_MONITOR_NAMES
- The APIs from libs/FScreen.[ch] needed changing, and because each
monitor is now a discrete entity, that naturally expands to allowing
per-monitor desks/pages.
o This has been completely shoe-horned in by me;
o It's not perfect;
o The API sucks where I've tried to keep it the same as the one
Xinerama provided to reduce code-churn; leading to three/four
different ways of finding a monitor, etc.
o I dislike the whole: fw->m ? fw->m : monitor_get_current() stuff.
o FvwmPager is completely broken by this change (as noted in the
TODO)
- I am not reacting to XRROutputChangeNotifyEvent/XRRUpdateConfiguration
and hence plugging/unplugging monitors means nothing to mvwm.
Likewise, how would we handle rotating windows with rotating displays?
On the plus-side, I've wanted this separation of monitors to desks for
an eternity, and the above can be changed bit-by-bit along with
everything else.
But you're starting to see where my changes are having a more invasive
impact on the previous status-quo, unfortunately. Whilst I appreciate
the testing and the quick fixes, I do hope there's not many more of
them. :)
> The message looks like this:
>
> [mvwm][__explain_placement]: placed new window 0x1c6 'XMessages':
> initial size 500x246
> desk 0 (current desk)
> current page
> screen: : 0 0 1600x1200 (current screen)
OK. I think I've fixed this, but if not, I'd like to hear about it. :)
It's entirely possible you're using the "global" screen, or still have
geometry strings in the fooxbar@screenname form, and "screenname" is
still a number and unresolvable.
> > Fixed by reverting. Will need to sync from fvwm's CVS repo.
>
> If there is a problem with the grabs, we need to look at it again.
I've just seen an older mail from you on my CVS commit which I've
responded to. You should have proded me harder, that specific email got
lost in the noise of others...
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Fri, Sep 12, 2014 at 12:03:13AM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 11:44:30PM +0100, Dominik Vogt wrote: > > I'll push a partial fix for this shortly, but you should take a > > look at it and implement the missing bit. > > Would you mind testing the following? Thie seems to work OK for me, but > just want to check: At the moment I don't know how to reproduce it, but the patch looks good. Since I'm not using unmanages windows I suspect that fw *and* exc->w.w were unset. I'm not sure why WarpToWindow was called at all in that situation, but if exc->w.w is none, XgetGeometry will now fail and exit the function. The crash was triggered by my Alt-Down binding: -- AddToFunc RaiseAndWarp + I Focus + I Raise + I WarpToWindow 95 $[cw.height]p AddToFunc DirectionOrThis + I Direction $0 (!Iconic, CurrentPage) RaiseAndWarp + I TestRc (nomatch) ThisWindow (!Iconic, CurrentPage) RaiseAndWarp Key Down A M DirectionOrThis South -- So this somehow managed to call WarpToWindow without a context window. I'll look into this. I've pushed your patch and another one to git. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: CVS tadam: Update passive grabs tracking modifiers
On Tue, Sep 02, 2014 at 10:58:30PM +0100, Dominik Vogt wrote:
> On Tue, Sep 02, 2014 at 04:19:33PM -0500, c...@math.uh.edu wrote:
> > Log message:
> > Update passive grabs tracking modifiers
> >
> > In the case of GTK's link widget which doesn't handle passive grabs
> > following FVWM's window bindings (which assumes the underlying
> > application can handle a PointerReplay), update the grabs in this
> > context by always ungrabbing the button and grabbing it for modifiers
> > other than ALL_MODIFIERS.
> >
> > I've had this in testing for three years and recently dusted it off for a
> > bug report I received for another application with this problem, called
> > darktable.
>
> Can you please explain the problem in even more detail? Grabbing
> is a crucial part of fvwm that I want to understand completely.
> (A diff would also be nice for convenience; they're so difficult
> to get from CVS.)
I'm so sorry, Dominik. I have no idea why I didn't see this reply
sooner. The specifics of the changes can be found here:
https://github.com/ThomasAdam/mvwm/commit/46213db4892ea00cfcd5fd421ac82b9a32c074b5
The problem (as I can see it) is that fvwm grabs everything. What I
noticed with some recent GTK applications is that mouse bindings
assigned in general to windows were interferring with them in that the
application couldn't respond to certain things, such as clicking on
links, etc.
So when I looked into this, I tried to change fvwm to only grab the
things it needed based on the modifiers in use, etc. But this clearly
broke a few other things (which I don't use).
Looking into this further still, it seems Compiz have a similar fix to
my proposal above:
http://git.compiz.org/compiz/core/commit/?id=cf2117be87040f5f19be6b688d481f7369b0f7b5
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
mvwm: master branch updated
The mvwm repository's master branch has been updated. The following shows the diffstat and patchsets between the merged result and HEAD. commit 2876928e4ca35b9062d3a97857271af536933715 Author: Dominik Vogt Date: Fri Sep 12 00:15:09 2014 +0100 Double chack that exc->w.w is != None in CMD_WarpToWindow. --- mvwm/focus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mvwm/focus.c b/mvwm/focus.c index 645a2e8..8ce7ac0 100644 --- a/mvwm/focus.c +++ b/mvwm/focus.c @@ -1258,7 +1258,7 @@ void CMD_WarpToWindow(F_CMD_ARGS) int ww; int wh; - if (!XGetGeometry( + if (exc->w.w == None || !XGetGeometry( dpy, exc->w.w, &JunkRoot, &wx, &wy, (unsigned int*)&ww, (unsigned int*)&wh, (unsigned int*)&JunkBW,
mvwm: master branch updated
The mvwm repository's master branch has been updated.
The following shows the diffstat and patchsets between the merged result
and HEAD.
commit 14856f2891498237e38d768ab0c8a56abdcf25a5
Author: Thomas Adam
Date: Fri Sep 12 00:03:13 2014 +0100
Rewrite fix of WarpToWindow.
---
mvwm/focus.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/mvwm/focus.c b/mvwm/focus.c
index 3c9f093..645a2e8 100644
--- a/mvwm/focus.c
+++ b/mvwm/focus.c
@@ -1212,22 +1212,11 @@ void CMD_WarpToWindow(F_CMD_ARGS)
{
int val1_unit, val2_unit, n;
int val1, val2;
- MvwmWindow * const fw = exc->w.fw;
struct monitor *m;
int do_raise;
char *next;
char *token;
- if (fw != NULL)
- {
- m = fw->m;
- }
- else
- {
- /*!!!used on an unmanaged window, we need to determine that
-* window's monitor here instead of using the default */
- m = monitor_get_current();
- }
next = GetNextToken(action, &token);
if (StrEquals(token, "!raise"))
{
@@ -1277,6 +1266,16 @@ void CMD_WarpToWindow(F_CMD_ARGS)
{
return;
}
+
+ /* TA: 2014-09-11: This window is unmanaged. Since
+* mvwm won't have created a window for this, fw will be
+* NULL and hence no monitor information will be
+* present. Since we already know the coordinates of
+* the unmanaged window, use those in determining the
+* monitor to use.
+*/
+ m = monitor_by_xy(wx, wy);
+
if (val1_unit != m->coord.w)
{
x = val1;
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:44:30PM +0100, Dominik Vogt wrote:
> I'll push a partial fix for this shortly, but you should take a
> look at it and implement the missing bit.
Would you mind testing the following? Thie seems to work OK for me, but
just want to check:
diff --git a/mvwm/focus.c b/mvwm/focus.c
index 3c9f093..5ff2859 100644
--- a/mvwm/focus.c
+++ b/mvwm/focus.c
@@ -1212,22 +1212,11 @@ void CMD_WarpToWindow(F_CMD_ARGS)
{
int val1_unit, val2_unit, n;
int val1, val2;
- MvwmWindow * const fw = exc->w.fw;
struct monitor *m;
int do_raise;
char *next;
char *token;
- if (fw != NULL)
- {
- m = fw->m;
- }
- else
- {
- /*!!!used on an unmanaged window, we need to determine that
-* window's monitor here instead of using the default */
- m = monitor_get_current();
- }
next = GetNextToken(action, &token);
if (StrEquals(token, "!raise"))
{
@@ -1277,6 +1266,16 @@ void CMD_WarpToWindow(F_CMD_ARGS)
{
return;
}
+
+ /* TA: 2014-09-11: This window is unmanaged. Since
+* mvwm won't have created a window for this, fw will be
+* NULL and hence no monitor information will be
+* present. Since we already know the coordinates of
+* the unmanaged window, use those in determining the
+* monitor to use.
+*/
+ m = monitor_by_xy(wx, wy);
+
if (val1_unit != m->coord.w)
{
x = val1;
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:47:55PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 11:44:30PM +0100, Dominik Vogt wrote: > > I guess we need some plan how to test this new code systematically. > > Are you thinking of some kind of test harness for this, or something > less involved? Whis is just an expression of being worried about that feature. It's very complicated and changes a lot of code that is difficult to get right. Therefore more problems are to be expected. I'd rather hunt them down systematically than just running into them by accident. There are too many code paths. :-/ Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:34:14PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > 4) With "bugopts explainwindowplacement" the screen identifier that > > is printed to the console is a string of random garbage > > Can you give me an example of this output? I've just pushed a fix to > master which tried to address what I think you're seeing, although I > don't see any garbage myself. I don't see any garbage at the moment. But it's possible that this only happens on the other box that does not have XRandR. I'll check that tomorrow. The message looks like this: [mvwm][__explain_placement]: placed new window 0x1c6 'XMessages': initial size 500x246 desk 0 (current desk) current page screen: : 0 0 1600x1200 (current screen) position 1100 954 (used user specified position) > > 5) Style * MouseFocusClickRaises works only once after a window is > > created and then never again. This means that the grab on the client > > window is not done when the window loses focus. Is this related to the > > grab patch that was committed some days ago? > > Fixed by reverting. Will need to sync from fvwm's CVS repo. If there is a problem with the grabs, we need to look at it again. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:41:17PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 11:30:40PM +0100, Dominik Vogt wrote: > > Yes, this looks good now. With that fix I can now debug the > > buttons placement problem. It turns out that the module window > > ends up at y = -61 instead of y = screen height - 61. That sounds > > like with the XRandR patch, negative coordinates are now taken > > literally. Coordinates actually schould mean: > > > > x/+x-> 0 + x > > +-x -> 0 - x > > -x/-+x -> screen size - window size - x > > --x -> screen size - window size + x > > > > Since the Move command works fine, it's possibly caused by > > MvwmButtons' parsing of the geometry option. > > Are you looking into this, or would you like me to? ISTR that > MvwmButtons will try calling libs/FScreen.c:FScreenParseGeometry() -- > it's entirely possible that's returning a slightly different value now. I'm not looking into it because you know that new code better. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:44:30PM +0100, Dominik Vogt wrote:
> Another core. fw is a NULL pointer; you use it before checking
> that. Note that WarpToWindow also works on unmanaged windows,
> hence fw may be NULL. WarpToWindow is the only function that needs
> a window but also works on unmanaged windows.
Oops. That's a very good point about unmanaged windows.
> #0 0x080b4544 in CMD_WarpToWindow (cond_rc=0xbfbdd308, exc=0x9e3de08,
> action=0x9e2965d "-20p -20p") at focus.c:1216
> 1216 struct monitor *m = fw->m;
> (gdb) bt
> #0 0x080b4544 in CMD_WarpToWindow (cond_rc=0xbfbdd308, exc=0x9e3de08,
> action=0x9e2965d "-20p -20p") at focus.c:1216
> #1 0x080ac08d in __execute_function (cond_rc=0xbfbdd308, cond_rc@entry=0x20,
> exc=exc@entry=0x0, action=0x9e29650 "WarpToWindow -20p -20p",
> action@entry=0x0, exec_flags=32 ' ', args=0x0, has_ref_window_moved=0)
> at functions.c:643
>
> I'll push a partial fix for this shortly, but you should take a
> look at it and implement the missing bit.
Okey dokey, will do. Thanks.
> I guess we need some plan how to test this new code systematically.
Are you thinking of some kind of test harness for this, or something
less involved?
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
Another core. fw is a NULL pointer; you use it before checking that. Note that WarpToWindow also works on unmanaged windows, hence fw may be NULL. WarpToWindow is the only function that needs a window but also works on unmanaged windows. #0 0x080b4544 in CMD_WarpToWindow (cond_rc=0xbfbdd308, exc=0x9e3de08, action=0x9e2965d "-20p -20p") at focus.c:1216 1216struct monitor *m = fw->m; (gdb) bt #0 0x080b4544 in CMD_WarpToWindow (cond_rc=0xbfbdd308, exc=0x9e3de08, action=0x9e2965d "-20p -20p") at focus.c:1216 #1 0x080ac08d in __execute_function (cond_rc=0xbfbdd308, cond_rc@entry=0x20, exc=exc@entry=0x0, action=0x9e29650 "WarpToWindow -20p -20p", action@entry=0x0, exec_flags=32 ' ', args=0x0, has_ref_window_moved=0) at functions.c:643 I'll push a partial fix for this shortly, but you should take a look at it and implement the missing bit. I guess we need some plan how to test this new code systematically. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:30:40PM +0100, Dominik Vogt wrote:
> On Thu, Sep 11, 2014 at 11:10:38PM +0100, Thomas Adam wrote:
> > On Thu, Sep 11, 2014 at 11:07:57PM +0100, Dominik Vogt wrote:
> > > On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote:
> > > > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote:
> > > > > 3) Expansion of variables does not work as expected:
> > > > >
> > > > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk]
> > > > >
> > > > > yields x=0, y=4 and desk=1024 which is all nonsense.
> > > >
> > > > Indeed. I've a fix for this, will push it shortly.
> > >
> > > If you have a fix, please push it as soon as possible. It makes no
> > > sense for me to debug my new-parser branch without that fix, and I
> > > already know that I've broken some things.
> >
> > Literally just pushed a fix for this: 19b835676
> >
> > Please check this; it should solve the weird expansion problems you've
> > been having.
>
> Yes, this looks good now. With that fix I can now debug the
> buttons placement problem. It turns out that the module window
> ends up at y = -61 instead of y = screen height - 61. That sounds
> like with the XRandR patch, negative coordinates are now taken
> literally. Coordinates actually schould mean:
>
> x/+x-> 0 + x
> +-x -> 0 - x
> -x/-+x -> screen size - window size - x
> --x -> screen size - window size + x
>
> Since the Move command works fine, it's possibly caused by
> MvwmButtons' parsing of the geometry option.
Are you looking into this, or would you like me to? ISTR that
MvwmButtons will try calling libs/FScreen.c:FScreenParseGeometry() --
it's entirely possible that's returning a slightly different value now.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote:
> I've just tried to get mvwm working on my desktop and run into some
> problems (linux-x86_64):
>
> 1) SnapAttraction does not work
>
> No idea what's wrong.
I need to debug this further.
> 2) MvwmButtons is started off screen.
>
> This is the config line that places MvwmButtons:
>
> *MvwmButtonsGeometry 513x59+0-0
This is broken due to how MvwmButtons is looking at the geometry. I'll
take a look if you like?
> 3) Expansion of variables does not work as expected:
>
> All (MvwmButtons) $[w.x] $[w.y] $[w.desk]
>
> yields x=0, y=4 and desk=1024 which is all nonsense.
Fixed (on Master).
> 4) With "bugopts explainwindowplacement" the screen identifier that
> is printed to the console is a string of random garbage
Can you give me an example of this output? I've just pushed a fix to
master which tried to address what I think you're seeing, although I
don't see any garbage myself.
> 5) Style * MouseFocusClickRaises works only once after a window is
> created and then never again. This means that the grab on the client
> window is not done when the window loses focus. Is this related to the
> grab patch that was committed some days ago?
Fixed by reverting. Will need to sync from fvwm's CVS repo.
> 6) There's a core generated when I start some Lotus application. I'll
> debug this later.
Fixed (on Master).
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:10:38PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 11:07:57PM +0100, Dominik Vogt wrote: > > On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote: > > > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > > > 3) Expansion of variables does not work as expected: > > > > > > > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk] > > > > > > > > yields x=0, y=4 and desk=1024 which is all nonsense. > > > > > > Indeed. I've a fix for this, will push it shortly. > > > > If you have a fix, please push it as soon as possible. It makes no > > sense for me to debug my new-parser branch without that fix, and I > > already know that I've broken some things. > > Literally just pushed a fix for this: 19b835676 > > Please check this; it should solve the weird expansion problems you've > been having. Yes, this looks good now. With that fix I can now debug the buttons placement problem. It turns out that the module window ends up at y = -61 instead of y = screen height - 61. That sounds like with the XRandR patch, negative coordinates are now taken literally. Coordinates actually schould mean: x/+x-> 0 + x +-x -> 0 - x -x/-+x -> screen size - window size - x --x -> screen size - window size + x Since the Move command works fine, it's possibly caused by MvwmButtons' parsing of the geometry option. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 11:07:57PM +0100, Dominik Vogt wrote:
> On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote:
> > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote:
> > > 3) Expansion of variables does not work as expected:
> > >
> > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk]
> > >
> > > yields x=0, y=4 and desk=1024 which is all nonsense.
> >
> > Indeed. I've a fix for this, will push it shortly.
>
> If you have a fix, please push it as soon as possible. It makes no
> sense for me to debug my new-parser branch without that fix, and I
> already know that I've broken some things.
Literally just pushed a fix for this: 19b835676
Please check this; it should solve the weird expansion problems you've
been having.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
mvwm: master branch updated
The mvwm repository's master branch has been updated. The following shows the diffstat and patchsets between the merged result and HEAD. commit 19b8356761228441668f90ca68266d67327abe3f Author: Thomas Adam Date: Thu Sep 11 23:07:12 2014 +0100 Expand: Fix token <-> variable name mapping Remove literal token names from the expansion string array list, so the corresponding enum tokens match, and are expanded correctly. --- mvwm/expand.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mvwm/expand.c b/mvwm/expand.c index 49b0eb7..c0538e1 100644 --- a/mvwm/expand.c +++ b/mvwm/expand.c @@ -120,8 +120,6 @@ static char *function_vars[] = "w.iconname", "w.iconfile", "w.miniiconfile", - "w.iconfile.svgopts", - "w.miniiconfile.svgopts", "w.id", "w.name", "w.resource",
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > 3) Expansion of variables does not work as expected: > > > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk] > > > > yields x=0, y=4 and desk=1024 which is all nonsense. > > Indeed. I've a fix for this, will push it shortly. If you have a fix, please push it as soon as possible. It makes no sense for me to debug my new-parser branch without that fix, and I already know that I've broken some things. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:47:55PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 10:45:38PM +0100, Dominik Vogt wrote: > > Please note that I have *not* revived any of the myriad of removed > > gui modules, none of the scripts and not Xpm and Svg support (I'm > > not comfortable with thee image formats being removed, but I'd > > give it a try and maybe think about an on-the-fly converter > > later). And I also agree that eventually removen FvwmCpp is a good > > thing if we find another way to provide its functionality. > > > > In other words: I'm not adding back just every random stuff I am > > using, and I can think of some more stuff to remove (e.g. the > > Repeat command). > > Absolutely. Feel free to tell me if I'm being too "anal". :) No, no, it is important that you argue about reviving any of the removed stuff and remind me and others why they were removed. After all we do want to get rid of the obsolete things, and if necessary it's always possible to add things back later. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:45:38PM +0100, Dominik Vogt wrote:
> On Thu, Sep 11, 2014 at 10:37:48PM +0100, Thomas Adam wrote:
> > > > Why do you want to continue to use it, out of interest? Have I
> > > > overlooked some critical piece of functionality?
> > >
> > > Well, I think it required no maintenance whatsoever in the last
> > > fifteen years, it's nicely integrated with the graphics library of
> > > fvwm (i.e. it can do all the image manipulation that fvwm can do),
> > > and I'm not sure xsetroot is able to deal with Ewmh desktop
> > > windows(?).
>
> > I'm just really keen to try to avoid adding in more and more
> > code. I know in this case the example is fairly
> > benign, but it's always easier to add things than it is to remove them,
>
> I agree to everything, ...
>
> > and I consider things like image/wallpaper setters the job of external
> > tools.
>
> ... but as far as I know, fvwm-root is simply the best tool to set
> a wallpaper that exists. As long as nobody is going to take it
> over as a separate project, we shouldn't remoe if from the distro.
>
> Please note that I have *not* revived any of the myriad of removed
> gui modules, none of the scripts and not Xpm and Svg support (I'm
> not comfortable with thee image formats being removed, but I'd
> give it a try and maybe think about an on-the-fly converter
> later). And I also agree that eventually removen FvwmCpp is a good
> thing if we find another way to provide its functionality.
>
> In other words: I'm not adding back just every random stuff I am
> using, and I can think of some more stuff to remove (e.g. the
> Repeat command).
Absolutely. Feel free to tell me if I'm being too "anal". :)
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:37:48PM +0100, Thomas Adam wrote: > > > Why do you want to continue to use it, out of interest? Have I > > > overlooked some critical piece of functionality? > > > > Well, I think it required no maintenance whatsoever in the last > > fifteen years, it's nicely integrated with the graphics library of > > fvwm (i.e. it can do all the image manipulation that fvwm can do), > > and I'm not sure xsetroot is able to deal with Ewmh desktop > > windows(?). > I'm just really keen to try to avoid adding in more and more > code. I know in this case the example is fairly > benign, but it's always easier to add things than it is to remove them, I agree to everything, ... > and I consider things like image/wallpaper setters the job of external > tools. ... but as far as I know, fvwm-root is simply the best tool to set a wallpaper that exists. As long as nobody is going to take it over as a separate project, we shouldn't remoe if from the distro. Please note that I have *not* revived any of the myriad of removed gui modules, none of the scripts and not Xpm and Svg support (I'm not comfortable with thee image formats being removed, but I'd give it a try and maybe think about an on-the-fly converter later). And I also agree that eventually removen FvwmCpp is a good thing if we find another way to provide its functionality. In other words: I'm not adding back just every random stuff I am using, and I can think of some more stuff to remove (e.g. the Repeat command). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:22:22PM +0100, Dominik Vogt wrote:
> On Thu, Sep 11, 2014 at 10:12:03PM +0100, Thomas Adam wrote:
> > On Thu, Sep 11, 2014 at 10:03:08PM +0100, Dominik Vogt wrote:
> > > I'm almost done converting my config to the new code. If you take
> > > care of the bugs I'll look into re-adding fvwm-root. :-)
> >
> > Oh, I removed fvwm-root because xsetroot(1), feh(1), etc., do those jobs
> > rather well, and I didn't want to have to maintain something as trivial
> > as that.
> >
> > Why do you want to continue to use it, out of interest? Have I
> > overlooked some critical piece of functionality?
>
> Well, I think it required no maintenance whatsoever in the last
> fifteen years, it's nicely integrated with the graphics library of
> fvwm (i.e. it can do all the image manipulation that fvwm can do),
> and I'm not sure xsetroot is able to deal with Ewmh desktop
> windows(?).
Pass. I guess resurrect it. I'm just really keen to try to avoid
adding in more and more code. I know in this case the example is fairly
benign, but it's always easier to add things than it is to remove them,
and I consider things like image/wallpaper setters the job of external
tools.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
mvwm: master branch updated
The mvwm repository's master branch has been updated. The following shows the diffstat and patchsets between the merged result and HEAD. commit 4c9108edd61157e8e11355c2e48ca80495f1bb0a Author: Dominik Vogt Date: Thu Sep 11 22:09:46 2014 +0100 Re-add bin/mvwm-root --- Makefile.am| 6 +- bin/Makefile.am| 11 ++ bin/mvwm-root.1.in | 110 + bin/mvwm-root.c| 346 + configure.ac | 2 + 5 files changed, 472 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index cf1fe1e..f65e7de 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,13 +6,13 @@ AUTOMAKE_OPTIONS = 1.4 SUBDIRS = \ libs \ + bin \ mvwm \ modules \ $(MVWM_PERLLIB) \ ## TA: Ignore things in bin/ for now. - #bin \ - doc \ - $(POSUB) + #doc \ + #$(POSUB) ## --- ## Manage bzip2 archive together with gzip archive diff --git a/bin/Makefile.am b/bin/Makefile.am new file mode 100644 index 000..218e7c7 --- /dev/null +++ b/bin/Makefile.am @@ -0,0 +1,11 @@ +## Process this file with automake to create Makefile.in + +bin_PROGRAMS = mvwm-root + +mvwm_root_SOURCE= mvwm-root.c +mvwm_root_DEPENDENCIES = $(top_builddir)/libs/libmvwm.a + +LDADD = -L$(top_builddir)/libs $(X_LIBS) -lmvwm $(Xcursor_LIBS) \ + $(X_PRE_LIBS) -lXext -lX11 -lm $(X_EXTRA_LIBS) $(Xrender_LIBS) \ + $(Xcursor_LIBS) $(png_LIBS) +AM_CPPFLAGS = -I$(top_srcdir) $(X_CFLAGS) $(png_CFLAGS) diff --git a/bin/mvwm-root.1.in b/bin/mvwm-root.1.in new file mode 100644 index 000..9540bfc --- /dev/null +++ b/bin/mvwm-root.1.in @@ -0,0 +1,110 @@ +'\" t +.\" @(#)@PACKAGE@-@VERSION@ @RELDATELONG@ +.TH fvwm-root 1 "@RELDATELONG@ (@VERSION@)" Fvwm "Fvwm Modules" +.UC + +.SH NAME +fvwm-root \- Sets the root window of the current X display to image + +.SH SYNOPSIS +.B fvwm-root +.RB [ "--retain-pixmap" | "-r" ] +.RB [ "--no-retain-pixmap" ] +.RB [ "--dummy" | "-d" ] +.RB [ "--no-dummy" ] +.RB [ "--dither" ] +.RB [ "--no-dither" ] +.RB [ "--color-limit" +.RI [ ncolors "] ]" +.RB [ "--no-color-limit" ] +.RB [ "--help" | "-h" | "-?" ] +.RB [ "--version" | "-V" ] +.I image_file + +.SH DESCRIPTION +.I fvwm-root +reads the image file specified in the command line and displays it in the +root window. The supported image formats are +.IR " PNG " +if appropriated libraries are compiled in. + +SVG rendering options +.RB " (as described in the " " ICONS AND IMAGES " +section of the main fvwm documentation) can be utilized. + +.SH OPTIONS +These command line options are recognized by fvwm-root: +.TP +.BR "--retain-pixmap" " | " "-r" +Causes fvwm-root to retain and publish the Pixmap with which the background +has been set (the ESETROOT_PMAP_ID and _XROOTPMAP_ID properties are used). +This is useful for applications which want to use the root +Pixmap on the background to simulate transparency (for example, +Eterm and Aterm use this method). This option should also be used for the +RootTransparent colorset option, refer to the COLORSETS section of fvwm(1). +If this option is not used, fvwm-root sets the _XSETROOT_ID property to +None, and some programs, like fvwm modules, may use this to update their +background if the background is transparent (Transparent colorset). + +Note, a well behaved program, like fvwm, should listen to both _XSETROOT_ID +and _XROOTPMAP_ID property changes and update itself correspondingly. +However some programs listen only to one of them, so you should either use +this option or not depending on what part is implemented by these programs. +You should also use this option to get fast root-transparent menus in fvwm. +.TP +.BI "--no-retain-pixmap" +This is a default. May be useful to explicitly force the default even +if "--retain-pixmap" is specified earlier. +.TP +.BR "--dummy" " | " "-d" +Causes fvwm-root NOT to set the background, but to only free a memory +associated with the ESETROOT_PMAP_ID property (if any). +In any case the _XSETROOT_ID property is set to None. +.TP +.BI "--no-dummy" +This is a default. May be useful to explicitly force the default even +if "--dummy" is specified earlier. +.TP +.BI "--dither" +Causes fvwm-root to dither images for "smoother" rendition on displays +with color depth of 16 or lower. This the defaut with color depth less +or equal to 8. +.TP +.BI "--no-dither" +Causes fvwm-root NOT to dither images. This is the default with color depth +greater than 8. +.TP +.BI "--color-limit " ncolors +Causes fvwm-root to limit its color use to +.I ncolors +(if specified). This option is taken in account only with color depth less +or equal to 8 (and a TrueColor or GrayScale visual). The default is +to use the same color limit as fvwm. So in normal situation this option +is not useful. However, if fvwm use a private colors map, as fvwm-root +always use the default colors map you should
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:12:03PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 10:03:08PM +0100, Dominik Vogt wrote: > > I'm almost done converting my config to the new code. If you take > > care of the bugs I'll look into re-adding fvwm-root. :-) > > Oh, I removed fvwm-root because xsetroot(1), feh(1), etc., do those jobs > rather well, and I didn't want to have to maintain something as trivial > as that. > > Why do you want to continue to use it, out of interest? Have I > overlooked some critical piece of functionality? Well, I think it required no maintenance whatsoever in the last fifteen years, it's nicely integrated with the graphics library of fvwm (i.e. it can do all the image manipulation that fvwm can do), and I'm not sure xsetroot is able to deal with Ewmh desktop windows(?). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
CVS tadam: Revert "Update passive grabs tracking modifiers"
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 14/09/11 16:19:32 Modified files: . : Tag: branch-2_6 ChangeLog docs : Tag: branch-2_6 COMMANDS fvwm : Tag: branch-2_6 bindings.c bindings.h events.c functable.c Log message: Revert "Update passive grabs tracking modifiers" Need a slightly better approach; removed for now.
CVS tadam: Revert "Update passive grabs tracking modifiers"
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 14/09/11 16:19:32 Modified files: . : Tag: branch-2_6 ChangeLog docs : Tag: branch-2_6 COMMANDS fvwm : Tag: branch-2_6 bindings.c bindings.h events.c functable.c Log message: Revert "Update passive grabs tracking modifiers" Need a slightly better approach; removed for now.
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 10:03:08PM +0100, Dominik Vogt wrote:
> I'm almost done converting my config to the new code. If you take
> care of the bugs I'll look into re-adding fvwm-root. :-)
Oh, I removed fvwm-root because xsetroot(1), feh(1), etc., do those jobs
rather well, and I didn't want to have to maintain something as trivial
as that.
Why do you want to continue to use it, out of interest? Have I
overlooked some critical piece of functionality?
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 09:42:52PM +0100, Thomas Adam wrote: > On 11 Sep 2014 21:41, "Dominik Vogt" wrote: > > On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote: > > > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > > > 5) Style * MouseFocusClickRaises works only once after a window is > > > > created and then never again. This means that the grab on the client > > > > window is not done when the window loses focus. Is this related to > the > > > > grab patch that was committed some days ago? > > > > This is also present in the latest fvwm code. > > OK, I've buggered that up as well. I'll revert that in a bit. Don't worry, grabbing is one of the most difficult parts of fvwm. I'd hardly be able to change anything without breaking something else. I'm almost done converting my config to the new code. If you take care of the bugs I'll look into re-adding fvwm-root. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Bugs in the master branch
On 11 Sep 2014 21:41, "Dominik Vogt" wrote: > > On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote: > > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > > 5) Style * MouseFocusClickRaises works only once after a window is > > > created and then never again. This means that the grab on the client > > > window is not done when the window loses focus. Is this related to the > > > grab patch that was committed some days ago? > > This is also present in the latest fvwm code. OK, I've buggered that up as well. I'll revert that in a bit. Thomas
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote: > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > > 5) Style * MouseFocusClickRaises works only once after a window is > > created and then never again. This means that the grab on the client > > window is not done when the window loses focus. Is this related to the > > grab patch that was committed some days ago? This is also present in the latest fvwm code. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
mvwm: master branch updated
The mvwm repository's master branch has been updated.
The following shows the diffstat and patchsets between the merged result
and HEAD.
commit 8c03e344b121be191495b6f64b45671869c03b30
Author: Thomas Adam
Date: Thu Sep 11 14:30:07 2014 +0100
StartsOnPage: Fix monitor segfault
When using StartsOnPage with SkippMapping, add extra checks to acquire the
monitor correctly.
---
mvwm/placement.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/mvwm/placement.c b/mvwm/placement.c
index f81ff5a..b9f6e34 100644
--- a/mvwm/placement.c
+++ b/mvwm/placement.c
@@ -610,8 +610,10 @@ static int __pl_minoverlap_get_next_x(const pl_arg_t *arg)
x = arg->place_g.x;
y = arg->place_g.y;
+ m = monitor_by_xy(x, y);
- m = monitor_by_xy(x, y);
+ if (m == NULL)
+ m = monitor_get_current();
if (arg->flags.use_percent == 1)
{
@@ -754,6 +756,9 @@ static int __pl_minoverlap_get_next_y(const pl_arg_t *arg)
y = arg->place_g.y;
m = monitor_by_xy(x, y);
+ if (m == NULL)
+ m = monitor_get_current();
+
if (arg->flags.use_percent == 1)
{
start = 0;
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 01:36:23PM +0200, Dominik Vogt wrote: > > 6) There's a core generated when I start some Lotus application. I'll > > debug this later. > > The monitor structure is a NULL pointer. XRandR related? Note that the > window starts on a different page (StartsOnPage style). Thanks. Will fix. -- Thomas Adam
Re: REWRITE: Bugs in the master branch
On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote: > I've just tried to get mvwm working on my desktop and run into some > problems (linux-x86_64): > > 1) SnapAttraction does not work > > No idea what's wrong. I broke it when I added XRandR support. Will fix. > 2) MvwmButtons is started off screen. > > This is the config line that places MvwmButtons: > > *MvwmButtonsGeometry 513x59+0-0 I'll check that. > 3) Expansion of variables does not work as expected: > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk] > > yields x=0, y=4 and desk=1024 which is all nonsense. Indeed. I've a fix for this, will push it shortly. > 4) With "bugopts explainwindowplacement" the screen identifier that > is printed to the console is a string of random garbage Fixed. Will push it shortly. > 5) Style * MouseFocusClickRaises works only once after a window is > created and then never again. This means that the grab on the client > window is not done when the window loses focus. Is this related to the > grab patch that was committed some days ago? I'll check. -- Thomas Adam
Re: REWRITE: Bugs in the master branch
> 6) There's a core generated when I start some Lotus application. I'll > debug this later. The monitor structure is a NULL pointer. XRandR related? Note that the window starts on a different page (StartsOnPage style). Program terminated with signal 11, Segmentation fault. #0 __pl_minoverlap_get_next_x (arg=0x72bf2de0) at placement.c:633 633 xtest = arg->page_p1.x + m->Desktops->ewmh_working_area.x; (gdb) p m $1 = (struct monitor *) 0x0 (gdb) bt #0 __pl_minoverlap_get_next_x (arg=0x72bf2de0) at placement.c:633 #1 __pl_minoverlap_get_next_pos (ret_p=0x72bf2f70, ret=, arg=0x72bf2de0, hint_p=...) at placement.c:891 #2 0x0044eb76 in placement_loop (arg=0x72bf2de0, ret=0x72bf2f40) at placement.c:1195 #3 __place_get_wm_pos (pdeltay=, pdeltax=, reason=0x72bf2e60, screen_g=..., flags=..., attr_g=0x72bf3930, pstyle=, exc=0x25965a0, start_style=..., mode=, win_opts=) at placement.c:1399 #4 __place_window (reason=0x72bf2e60, win_opts=, mode=79, attr_g=0x72bf3930, pstyle=, exc=0x25965a0, start_style=...) at placement.c:1878 #5 setup_window_placement (fw=0x25a00d0, pstyle=, attr_g=0x72bf3930, win_opts=, mode=79) at placement.c:2297 #6 0x0044180e in AddWindow (ret_initial_map_command=, exc=0x2565e60, ReuseWin=, win_opts=) at add_window.c:2431 #7 0x00428b93 in HandleMapRequestKeepRaised (ea=0x72bf3d50, KeepRaised=0, ReuseWin=0x0, win_opts=0x72bf3ba0) at events.c:2988 #8 0x0042b9d3 in dispatch_event (e=0x72bf3d90) at events.c:4111 #9 0x0042ba78 in HandleEvents () at events.c:4154 #10 0x00409d7d in main (argc=, argv=) at mvwm.c:2546 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
REWRITE: Bugs in the master branch
I've just tried to get mvwm working on my desktop and run into some problems (linux-x86_64): 1) SnapAttraction does not work No idea what's wrong. 2) MvwmButtons is started off screen. This is the config line that places MvwmButtons: *MvwmButtonsGeometry 513x59+0-0 3) Expansion of variables does not work as expected: All (MvwmButtons) $[w.x] $[w.y] $[w.desk] yields x=0, y=4 and desk=1024 which is all nonsense. 4) With "bugopts explainwindowplacement" the screen identifier that is printed to the console is a string of random garbage 5) Style * MouseFocusClickRaises works only once after a window is created and then never again. This means that the grab on the client window is not done when the window loses focus. Is this related to the grab patch that was committed some days ago? 6) There's a core generated when I start some Lotus application. I'll debug this later. I think we should start fix these things so that it's possible to work with mvwm and not just write new code without testing it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [OT]: Using Emacs
Hi Thomas, Thomas Adam writes: > Hi all, > > I know this is slightly off-topic, but for various reasons I'm having to use > Emacs, and was wondering what others on this list do to make their lives > easier > with things like: I'll assume you're using GNU Emacs as that's by a very large margin the most widely used Emacs currently. > * C development; > * GDB; Even though I a not a C programmer myself it seems most in emacs-devel use GUD[1] for debugging. > * Make/compilation > > Anything fvwm-specific as well would be welcomed. Assuming you don't mean fvwm-development: I'm still actively maintaining fvwm-mode[2], though I'm not quite sure it will work with XEmacs anymore. It's available from Emacs' package manager if you add the melpa repository. Kind regards, Bert Geens [1] http://www.emacswiki.org/emacs/GrandUnifiedDebugger [2] https://github.com/theBlackDragon/fvwm-mode -- Fortuna vitrea est; tum cum splendet, frangitur.
