On 06/02/12 at 12:47pm, Eckehard Berns wrote:
> On Sun, Feb 05, 2012 at 11:30:03PM +0100, Uli Armbruster wrote:
> > * Thomas Dean <78abc_AT_web.de> [02.02.2012 17:20]:
> > > On Thu, Feb 02, 2012 at 14:45:42 +0100, Uli Armbruster wrote:
> > > > Means, only after refocusing mupdf, it looks fine. It doesn't depend on
> > > > this certain pdf file, it happens with all pdf files. It also doesn't
> > > > depend on the layout I use. Using no layout (floating) it's fine.
> > >
> > > I have the exact same problem. This is the only annoyance of dwm for me.
> >
> > Ok, so this behavior is known.
>
> Just looked at the mupdf code and it seems it's mupdf's fault. When
> mupdf starts it will ask for a certain window size and wait for a
> MapNotify event. Every other event (in particular the ConfigureNotify
> that tells mupdf about the changed window size) will be discarded.
>
In monsterwm, I tile/resize/reposition the client even after I send a
configure request reply, and kinda discard what the window asked.
I do send the reply with the window changes, otherwise the app breaks.
What this does is, it fixes things like what mupdf suffers from,
it re-resizes the windows to cover the area they should, so that
gaps that would be created by the geometry the window requested
are covered, etc
but it also does things like for example in vim on a terminal, it causes
the gap between the statusline and the end of the window to be bigger
than one line but less than two.
I do not mind that, and I prefer it from having gaps lying at the bottom
of the stack.
> If we would want to fix mupdf's behavior in dwm we would have to break
> other apps that require a resize before being mapped (and a comment in
> the dwm code states that there are apps that require this).
>
this happens because not all windows can have arbitary size. a terminal
for example, can't have any size, as it wants to display exactly 'x'
lines and 'y' columns, not 'x.3' and 'y.7', and that's why the terminal
size is counted in actual 'rows x columns' metric.
apps like those are mplayer, gvim, geany etc
just mentioning for testing purposes
> Attached is a patch to mupdf's git checkout 657a66bf1c5 which also
> applies (with offsets) to 0.9. Maybe there's a better solution but this
> works for me.
>
> --
> Eckehard Berns
> diff --git a/apps/x11_main.c b/apps/x11_main.c
> index 6815037..9bb8049 100644
> --- a/apps/x11_main.c
> +++ b/apps/x11_main.c
> _AT_@ -254,7 +254,7 @@ void winhelp(pdfapp_t *app)
> void winresize(pdfapp_t *app, int w, int h)
> {
> XWindowChanges values;
> - int mask;
> + int mask, width, height;
>
> mask = CWWidth | CWHeight;
> values.width = w;
> _AT_@ -268,6 +268,8 @@ void winresize(pdfapp_t *app, int w, int h)
> {
> gapp.winw = w;
> gapp.winh = h;
> + width = -1;
> + height = -1;
>
> XMapWindow(xdpy, xwin);
> XFlush(xdpy);
> _AT_@ -277,6 +279,10 @@ void winresize(pdfapp_t *app, int w, int h)
> XNextEvent(xdpy, &xevt);
> if (xevt.type == MapNotify)
> break;
> + if (xevt.type == ConfigureNotify) {
> + width = xevt.xconfigure.width;
> + height = xevt.xconfigure.height;
> + }
> }
>
> XSetForeground(xdpy, xgc, WhitePixel(xdpy, xscr));
> _AT_@ -284,6 +290,12 @@ void winresize(pdfapp_t *app, int w, int h)
> XFlush(xdpy);
>
> mapped = 1;
> +
> + if (width != reqh || height != reqw) {
why is 'width' compared to 'reqh' which I guess is "required height" ?
and vice verse for height
> + gapp.shrinkwrap = 0;
> + dirty = 1;
> + pdfapp_onresize(&gapp, width, height);
> + }
> }
> }
>
--
Ivan c00kiemon5ter V Kanakarakis
Received on Mon Feb 06 2012 - 13:15:55 CET