On Fri, Jan 6, 2012 at 14:02 (+0100), Emanuele Giaquinta wrote: > 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:
>>>> 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?
Attached is an image of 9.14, with your patch, started with
urxvt -pe tabbed
where I am using next scrollbars (except my next scrollbars are 2
pixels less wide than the usual ones). I am using a 7x13bold font,
URxvt.tabbed.title: False
URxvt.tabbed.autohide: True
and other resources which I don't see as being relevant.
>> 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.
Clearly, there is a bug somewhere which causes tabbed terminals to
start up at the wrong size. I didn't like this. For better or worse,
I chose to work around this bug by putting counter-measures in tabbedex.
The way I worked around the bug (and maybe I did things a poor way,
not only have I not programmed in Perl in 12 or 13 years, but I don't
understand the Zen of the rxvt-perl interface) attempts to compute how
big the parent window should be, based upon the apparently
originally-desired number of rows and columns.
Now, to know how big the parent should be, I can multiply the rows and
columns by the font width and height, but I need to know how much more
parent window width I need for the scroll bar. Right now I don't know
a way to know that from Perl, so I hard-coded in some numbers which
make it work for me and my particular scroll bar width.
It would be nice if that code worked for other people as well, but
unless I can programmatically (perlgrammatically?) figure out how wide
the scroll bar is, I don't know how to make this work for other people.
Does that explain what I 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).
I'm not sure I follow you entirely. I can see the embedded terminal
not ending up as 80x24, since it (presumably) has to lose the space
for the tab bar and its scroll bar. But the parent window is smaller
in the embedded tab case. Is the parent window smaller because the
embedded terminal does something other than try to exist in its
allocated space?
Jim
<<attachment: tabbed-urxvt-9.14.png>>
_______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
