GNOME Bugzilla – Bug 92458
long last line gets hidden by horizontal scrollbar
Last modified: 2016-06-08 02:16:06 UTC
In gtk-demo, Text Widget, I delete almost all the text so that the scrollbars in the lower pane disappear. Then I press Enter until I am at the bottom of the pane and start typing (without Enter). Just when the line gets too long, a horizontal scrollbar appears and hides the current line. Typing another character scrolls the text up so that the line is above the scrollbar once more.
*** Bug 92459 has been marked as a duplicate of this bug. ***
Going to be hard to fix - the problem is that GtkTextView has no information that the appearance of the scrollbars was related to the character just typed; basically GtkTextView tells GTK+ that it has a new size, and then GTK+ some time later decides to add the scrollbars. So, GtkTextView doesn't have any information to distinguish this from the window just being resized smaller by the user. The only thing I can imagine is to do something like: - If size_allocate() is received less than 1 second after the last text was entered into the buffer by the user, then make sure that the cursor is visible after the resize. A bit of a hack, but probably would work fine.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
I have the similar problems with a vertical scrollbar its print the text force it to go to the end to show the text but if vertical scrollbar has to appear it makes more space, so it's throw some text in a second line that becomes invisible and you have to scroll manually to the end to see it I would like to see signals: 'vertical-scollbar-visible' 'horizontal-scrollbar-visible' and similar attributes to the scrolledwindow
(In reply to comment #2) > Going to be hard to fix - the problem is that GtkTextView has > no information that the appearance of the scrollbars was > related to the character just typed; basically GtkTextView > tells GTK+ that it has a new size, and then GTK+ > some time later decides to add the scrollbars. > The widget could resize itself (expand downwards) so that adding the horizontal scroll bar below does not affect the text pane.
*** Bug 519717 has been marked as a duplicate of this bug. ***
text view lets you set margins to avoid this overlap, nowadays