On Thu, Jan 05, 2012 at 04:11:40PM -0400, Jim Diamond wrote: > On Thu, Jan 5, 2012 at 20:08 (+0100), Emanuele Giaquinta wrote: > > > On Thu, Jan 05, 2012 at 04:03:11PM +0000, Thomas Adam wrote: > >> On 5 January 2012 15:06, Jim Diamond <[email protected]> wrote: > >>> "Correct"? It would seem to me that there should not be unusable > >>> space at the bottom of the window, and some change between 9.12 and > >>> 9.14 has caused this to appear, at least on my system ("urxvt -pe > >>> tabbed" in both cases). This seems much more like a regression than > >>> something which is "correct". > > >> This is the problem (main.C): > > >> // When the size of the vt window is not a multiple of the cell > >> // size, i.e., when the wm does not honour our size hints, there are > >> // extra areas not covered by the terminal screen. Such gaps, when a > >> // bg pixmap is set, would have to be cleared manually to properly > >> // refresh the background. We take the simpler route and shrink the > >> // vt window so as to avoid creating gaps. > >> width = ncol * fwidth; > >> height = nrow * fheight; > > >> Setting width/height like this is just bogus; when tabbed changes the > >> window size via XMoveResizeWindow() the resize increment hints are > >> honoured *because* the resultant window with tabbed drawn falls within > >> the boundaries. > > > Bogus why? Note that width and height are the dimensions of the terminal > > (vt) window, not of the main (parent) window. However, looking at the > > tabbed extension, I see that it uses $term->{width,height} in > > 'configure' to resize the main window, and $term->{width,height} > > (bogusly?) map to the corresponding dimension of the terminal window. > > This is possibly the reason of the bug. I think the fix is to have > > $term->width and $term->height return the corresponding dimension of the > > main window. Does the attached patch solve the problem? > > Your patch also solves the problem (in the sense that it also makes my > tabbedex work-arounds work in 9.14 + your patch). > > The tabbed extension still opens the window at the wrong size. I > don't have the perspective on the overall system to know whether that > indicates a problem with the perl interface or the tabbed extension.
Hmm, so it's the same in tabbed with or without my patch? Can you provide a screenshot? > However, since my version of tabbedex now works with either your or > Thomas' patches to 9.14, I'm happy for now. > > While we are on this topic... one of the reasons my version of > tabbedex (probably) won't work for everyone is that I hard-coded some > numbers which are related to the difference between the parent window > width and the terminal window width. When I looked a week or so ago I > didn't see any nice way of knowing how wide the scroll bar is. I > suppose one way would be to add yet another functions which provides > this information. Then, knowing the total window width, the scrollbar > width and the border widths, one can calculate what size the parent > window should be and reset it. A function that returns the width of the scrollbar can be easily added. But I don't understand exactly what you want to do. > Having said that, it still seems to me there is something more > fundamentally wrong. If you comment out the XMoveResizeWindow() in > tabbed and start up a tabbed and a non-tabbed terminal, the tabbed one > starts smaller. This seems odd to me. (But maybe if I knew more it > wouldn't, admittedly.) That is expected. The size of embedded terminals is set to the size of the window in which they are embedded. The first tabbed terminal is created before the main urxvt window receives the first ConfigureNotify event, so it uses its initial size, namely (80 * fwidth) (24 * fheight). Emanuele _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
