Re: menu bug solved? --- "restart" failing & other mysterious bugs

[mmc maruska dyndns org (Michal Maruška)]

mmc maruska dyndns org (Michal Maruška) writes:

>  * sawfish/wm/menus.jl (popup-menu): synchronize with the server
>     after ungrabbing, just to be sure, instead of flushing
>
>
> and i disagree with "just to be sure" formulation. My email explains what can
> (and does) happen without it. 


"just to be sure," has remained in the lisp/Changelog (for the menus issue). I claim, that the exact
same error (implicit Xflush instead of Xsync) is behind the occasional failure of
"restart" command, with the error message "You may only run one window manager".

that is src/display.c
sys_kill (void):

+ XSync(dpy,TRUE);
XCloseDisplay (dpy);

I repeat/insist that these 2 bug-fixes don't merit "just to be sure" label.





* src/frames.c

> /* XXX This assertion has been reported to trigger (when opening
> ddd and acroread -- both motif apps?). I don't see how this
> happens but since fp->id is zero and fp->win will get gc'd,
> we're not going to leak any resources, so.. */

> assert (fp->win == 0);


I have re-enabled this assertion in my development version, and the failure is due to
"hidden" frame parts; when build_frame_part  returns FALSE, the "bit weird
loop"  in list_frame_generator has to discard the fp. in some way (i still don't
know exactly how).


When building (for the 1st time), i use
     fp->win = 0;

and when re-building, since i don't understand all the frame code, i use:


+   struct frame_part **prev = &(w->frame_parts);
while (fp != 0)

if (build_frame_part (fp))
{
....
        prev = &(fp->next);
} else {
         
                  DB(("%s: skipping over %x\n", __FUNCTION__, fp));
                  *prev = fp->next; /* skip over this one */
                  /* prev = &(fp->next); */
                  {
                     /* mmc: fixme:  I am not sure, if this is the right action
                      *  to take. */
                     if (fp->id)
                        XDestroyWindow (dpy, fp->id);
                     fp->id = 0;
                     if (fp->gc)
                        XFreeGC (dpy, fp->gc);
                     fp->gc = 0;
                  }
                  fp->win = 0;
                  fp->next = 0;
               }


I have no idea, if the frame part list is recreated on window state change. Or if
my code will simply loses the part forever.





* with the following patch one might happen to have:
** the same window focused after quit
** the same stacking order after a restart.

stacking-list.c

Lisp_Window*
bottom_window()
{
   return  lowest_window;
}

(and to sawfish_subrs.h)

windows.c:

void
windows_kill (void)
{


   /* i would like to XReparent them in the order of stacking order! */
   while (w = bottom_window())
      {
         Fcall_window_hook (Qremove_window_hook, rep_VAL (w), Qnil, Qnil);
         remove_window (w, False, False);
      }
....






* maximized windows cause troubles on restart.
1/  Iconified maximized lose their iconified status
2/  maximized (in general) lose their
  position, if one uses multi viewport workspaces.


fix for the issue 1/ might be: 
 wm/state/maximize.jl
(open  
+  sawfish.wm.state.iconify



and 
  (define (maximize-window w #!optional direction only-1d)
     "Maximize the dimensions of the window."
    (if (window-iconified-p w)
        (DB "maximize-window: the window is iconified! not displaying. %s\n" (window-name w))
      (progn
      ... the rest)))


i know it's dirty hack, but no time now.