After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 540909 - Size request of unrealized GtkTextView
Size request of unrealized GtkTextView
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.24.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-06-30 12:08 UTC by Till Harbaum
Modified: 2018-05-02 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Short demo program demonstrating the problem (1.44 KB, application/x-compressed)
2008-06-30 12:11 UTC, Till Harbaum
Details
Extracted C program (2.33 KB, text/plain)
2008-06-30 12:26 UTC, Owen Taylor
Details

Description Till Harbaum 2008-06-30 12:08:15 UTC
I see this bug on a different ubuntu x86 desktops as well as all maemo version (the hildon/gtk based desktop of the nokia internet tablets).

The GtkTextView's content isn't sized properly if there are several gtktextviews in a table (or vbox) on one of multiple gtknotebook pages. Once the user clicks into one of the malformed textviews, the entire screen is being reformatted and everything gets displayed correctly. This doesn't happen if only one textview is being used or if those vbox of textviews is not part of a gtknotebook. A similar problem can be seen with gtkhtmlviews (when placed in the same arrangement).

Find attached a program that seems to be the minimum complete code snippet triggering this odd behaviour.
Comment 1 Till Harbaum 2008-06-30 12:11:37 UTC
Created attachment 113685 [details]
Short demo program demonstrating the problem

Do untar, make, ./texttest. The prgram will launch. Select the second notebook page and fine the malformatted textviews. Click any of them once and see everything getting cleaned up.
Comment 2 Owen Taylor 2008-06-30 12:26:37 UTC
Created attachment 113686 [details]
Extracted C program

Thanks for the test case. It turns out that a single standalone C file
is the most convenient form of test case; you can just click on it 
to examine it, and the GTK+ maintainers know how to compile it if
necessary :-)
Comment 3 Owen Taylor 2008-06-30 12:44:19 UTC
Some notes from playing around with the test case a little:

 - I definitely see the problem; it appears that there is a missing
   call to gtk_widget_queue_resize() somewhere.

 - The reason that the notebook is relevant is that the problem only
   occurs if the textview is unrealized (it won't be realized until
   the page in the notebook is set active)

 - The multiple text views aren't necessary, you can get the same
   effect with a single textview if you change pack_start_defaults() to 
   pack_start(FALSE, FALSE, 0).

   The relevant factor here here is whether the GtkTextView
   is being allocated just its requisition or something more than
   that

The actual problem isn't obvious from a quick inspection of gtktextview.c



Comment 4 Till Harbaum 2008-06-30 19:51:51 UTC
I am actually using this construct in gpxview for maemo. So i'd appreciate any workaround or any modification in the setup that avoids the problem.

I have played around with gtk_widget_queue_resize, gtk_widget_show etc myself. The only thing preventing this problem was to call gtk_widget_show for the notebook page in question. But this makes that page the "front" one which i don't want as another page is the main page to be visible initially.

Is gtkhtml based on gtktextview? gtkhtmlviews show the same symptom, although clicking it doesn't fix things. Perhaps gtktextview is not the culprit.
Comment 5 Owen Taylor 2008-06-30 20:32:56 UTC
I suspect gtk_widget_realize(page_child) will work around the problem.

No relationship at all between the GtkHtml and GtkTextView code bases.
Comment 6 Till Harbaum 2008-07-01 09:27:31 UTC
I've tried such things, but e.g. calling gtk_widget_realize right after the contents are created or the notebook is created results in:

(texttest:7035): Gtk-CRITICAL **: gtk_widget_realize: assertion `GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed

Calling it later (after e.g. the notebook has been added to the main window) has no visible effect. On what exactly do you think should i use this function? The entire scrolled window being the page widget?
Comment 7 Daniel Boles 2017-08-30 14:58:03 UTC
This still occurs in latest GTK+ 2.24 (even on Windows), though not 3.22.
Comment 8 GNOME Infrastructure Team 2018-05-02 14:33:20 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/295.