Font/window sizes odd when using zoom + tabs

Bug #531177 reported by JP Vossen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
roxterm (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: roxterm

Description: Ubuntu 9.10

roxterm:
  Installed: 1.18.0+svn13-1
  Candidate: 1.18.0+svn13-1

Note this is on the beta I'm testing per wishlist bug 509544. I also tried testing using stock ROXTerm 1.0.8 on Hardy, but in that case View > Zoom in had no effect at all.

Problem: Font and window sizes get odd fast when using zoom and tabs.

To reproduce: Open ROXTerm, CTRL++ a few times to zoom in, open a new tab. The font in the new tab will be significantly larger than the tab we just left. Opening a new tab again makes it even worse. Yet, using a 'roxterm --tab' command from within a zoomed tab opens a new tab with the default font. Also, I had some cases where the window size changed wildly (presumably to try to keep X rows and Y columns with a larger font), but now I can't reproduce that. It may have been because I changed the default size and then zoomed without having restarted the terminal.

Use case: hooked up a media PC and was debugging something, but I can't see the terminal at 1900xwhatever from the couch. I made the font much larger, then opened some more tabs and things got odd.

Expected: I would personally prefer that all tabs in a given window have the same zoom setting (i.e., font size), period, and that the window never change size unless I drag it or change it in the Prefs > Edit Current Profile > Appearance > Size dialog.

I also understand that zoom setting and window size can easily conflict and/or become too large to fit on the desktop. However, all of that is because window size is specified in rows and columns, but zoom makes those relative. Personally, on a zoom operation, I'd leave the window size alone, and just change the font within that given window (keeping the font the same in all tabs in that window). If the user wants to change window size they can drag the frame or use the size dialog box. That seems to me to be the principle of least surprise, but it may lead to confusion about the window size setting due to relative font sizes. Possible solutions there are to add a note that row/columns refer to the default font size (AKA zoom setting) only, and that perceived rows/columns may differ based on zoom. Or a different unit, such as pixels, could be used instead. I actually don't like that idea, since other terminals use row/column units and pixels make much less sense than rows/columns in this context.

Revision history for this message
Tony Houghton (h-realh) wrote :

I've fixed the main problem. Please check out the latest svn. You'll probably need to delete your existing debian subdirectory first because I've merged it into the main repository.

Forcing all tabs in a window to have the same font settings (including zoom) was always my intention. If you explicitly change the font or zoom it will change the window size, keeping the same number of rows and columns if possible. If it didn't change the window size at all you would usually be left with extra margins because the widget size would no longer be an exact multiple of character cell sizes, so I think it is preferable to resize the window.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

With very preliminary testing, that half-works. It seems to fix the size when creating tabs the normal way though the GUI, but tabs created by running 'roxterm --tab' are still off. It's odd, because the new (--tab) tab is kind of synced, but it's off by a few sizes.

To reproduce:
1) Open a new ROXTerm window
2) Zoom in a few steps
3) Open a new tab via File > New tab = the font/zoom is now the same
4) Open a new tab by typing 'roxterm --tab' in one of the existing tabs = the new tab has the wrong font/zoom.

Revision history for this message
Tony Houghton (h-realh) wrote : Re: [Bug 531177] Re: Font/window sizes odd when using zoom + tabs

On Thu, 04 Mar 2010 06:13:08 -0000
JP Vossen <email address hidden> wrote:

> With very preliminary testing, that half-works. It seems to fix the
> size when creating tabs the normal way though the GUI, but tabs created
> by running 'roxterm --tab' are still off. It's odd, because the new
> (--tab) tab is kind of synced, but it's off by a few sizes.
>
> To reproduce:
> 1) Open a new ROXTerm window
> 2) Zoom in a few steps
> 3) Open a new tab via File > New tab = the font/zoom is now the same
> 4) Open a new tab by typing 'roxterm --tab' in one of the existing tabs = the new tab has the wrong font/zoom.

I can't reproduce that, but I've made some changes that might fix it.

--
TH * http://www.realh.co.uk

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

In preliminary testing on the same machine; yup, that worked. That also fixed a sort-of inverse problem I didn't think to mention, CTRL+0 wasn't consistent across all tabs. Now it is...

Revision history for this message
Tony Houghton (h-realh) wrote :

On Fri, 05 Mar 2010 09:21:10 -0000
JP Vossen <email address hidden> wrote:

> In preliminary testing on the same machine; yup, that worked. That also
> fixed a sort-of inverse problem I didn't think to mention, CTRL+0 wasn't
> consistent across all tabs. Now it is...

Was it just font settings you were having a problem with, or window
sizing as well? Getting the window sizes to behave themselves when
adding tab bars etc is a bit of a nightmare and there's one thing I just
haven't been able to fix after trying all last evening:

If you run roxterm --tab from a window with no other tabs and a new tab
is added to that window, adding the tabs and border doesn't make the
window grow to accommodate them, and instead the terminals are made
slightly smaller. The bizarre thing is there's hardly any difference in
the code path for that and adding a new tab from the menu, which does
allow the window to grow, and what seems to make the difference is
sending a D-BUS reply from the first roxterm to tell the one which was
launched by "roxterm --tab" that it's succeeded, which shouldn't have
anything to do with window sizing! I've had to conclude it isn't worth
wasting my time on any more :-(.

--
TH * http://www.realh.co.uk

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

Window sizing was really odd as well, but I'm not sure if it was a problem or just that I didn't quite grok the behaviour and was thus surprised. Either way, the latest version seems much better behaved.

I tried to reproduce the 'roxterm --tab' no-grow thing, but it seems OK to me. I opened a new ROXTerm window and:
$ echo $LINES $COLUMNS
46 102
$ roxterm --tab

And in the new tab:
$ echo $LINES $COLUMNS
46 102

Then I used the GUI to open a new tab. In no case did I notice the window get larger to accommodate tabs. Oh, wait... I got it. I always have "always show tab bar" checked [1]. In that case there is no issue. Without that, I do see the behaviour you describe. My suggestion for a "fix" is to set "always show tab bar" checked by default for a new install, and document the glitch. :-) Otherwise I agree not to waste time on it.

_____________________________
Soapbox

[1] For principles of obviousness and least surprise I would argue that any window capable of tabs should default to always showing a tab bar. First, it should be obvious just by looking at it what an interface can do and hidden tab bars violate that. Second, when a significant part of the interface changes "randomly" (where "randomly" is described by the user as "I didn't do anything" or "I have no idea why it does that") that's annoying and frustrating to the user. Yeah, most of us are pretty used to this by now (I'm looking at you Firefox). Not all of us... Like my Mom...

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

roxterm_1.18.0+svn728 (2010-03-05) has been working flawlessly on LPIA (using i386) Jaunty and AMD-64 Karmic.

I see that Lucid only has: Version: 1.17.1-1, it'd be great to bump this up ASAP!!!

Changed in roxterm (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.