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 112812 - pan takes too long to toggle "tabbed layout"
pan takes too long to toggle "tabbed layout"
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.14.0
Other Linux
: Normal normal
: 0.14.1
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2003-05-12 05:08 UTC by stonin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description stonin 2003-05-12 05:08:52 UTC 
Hi,

When toggling "tabbed layout" by using the "z" accelerator or choosing
'view' > 'tabbed layout', pan 0.14.0 gets stuck and takes much longer than
previous versions. I can see pan consuming 100% cpu and displaying 'Sorting
Articles', 'updating header pane, and 'filtering articles'.

To reproduce, load a large binary group with more than 50,000 articles.
Press 'z'.  Pan should not need to sort, update, or filter headers when
toggling the layout.

Thank you for pan,
Michael
Comment 1 Charles Kerr 2003-05-13 19:24:36 UTC 
This appears to be due to the style being reset when we
change layout modes.  I'm not sure how to fix it, hmm...

+ Trace 36844

  • #0 articlelist_refresh
    at articlelist.c line 2388
  • #1 articlelist_reset_style_nolock
    at articlelist.c line 1946
  • #2 style_set_cb
    at articlelist.c line 1957
  • #3 g_cclosure_marshal_VOID__OBJECT
    from /usr/lib/libgobject-2.0.so.0
  • #4 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #5 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #6 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #7 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #8 gtk_widget_set_style_internal
    at gtkwidget.c line 4279
  • #9 gtk_widget_reset_rc_style
    at gtkwidget.c line 3961
  • #10 reset_rc_styles_recurse
    at gtkwidget.c line 4438
  • #11 gtk_bin_forall
    at gtkbin.c line 164
  • #12 gtk_scrolled_window_forall
    at gtkscrolledwindow.c line 774
  • #13 gtk_container_forall
    at gtkcontainer.c line 1253
  • #14 reset_rc_styles_recurse
    at gtkwidget.c line 4441
  • #15 gtk_box_forall
    at gtkbox.c line 700
  • #16 gtk_container_forall
    at gtkcontainer.c line 1253
  • #17 reset_rc_styles_recurse
    at gtkwidget.c line 4441
  • #18 gtk_widget_reset_rc_styles
    at gtkwidget.c line 4451
  • #19 gtk_widget_set_parent
    at gtkwidget.c line 3839
  • #20 gtk_notebook_insert_page_menu
  • #21 gtk_notebook_append_page
    at gtknotebook.c line 3872
  • #22 gui_notebook_construct
    at gui-notebook.c line 58
  • #23 gui_layout_refresh
    at gui.c line 674
  • #24 gui_layout_set_mode
    at gui.c line 700
  • #25 zoom_page_cb
    at gui.c line 1691
  • #26 gtk_item_factory_callback_marshal
    at gtkitemfactory.c line 230 






Comment 2


Charles Kerr





          2003-07-23 06:39:16 UTC
        



The reason we rebuild the header pane when the widget's style changes
is so that we can pick up new gtk+ themes when the user's changing
from bluecurve to lighthouse to whatever.

Since the reparent signal is emitted _after_ the widgets' styles are
reset in gtk_widget_set_parent(), I don't think we can use clever
signal registering to take care of this.

Two possibilities: we could make the header pane's refresh lazy,
so that the style changes will be applied the next time the user
refreshes the header pane -- I don't like this -- or we could put
an ugly hack into gui-notebook to temporarily turn off the header
pane's style change listener when it's being added to the tabbed pane.