[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4357

           Summary: GtkTreeView::expander-size determines minimum row
                    height size of new packet list records
           Product: Wireshark
           Version: 1.3.x (Experimental)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jyoung@xxxxxxx


Build Information:
$ svn info
Path: .
URL: http://anonsvn.wireshark.org/wireshark/trunk
Repository Root: http://anonsvn.wireshark.org/wireshark
Repository UUID: f5534014-38df-0310-8fa8-9805f1628bb7
Revision: 31363
Node Kind: directory
Schedule: normal
Last Changed Author: jake
Last Changed Rev: 31363
Last Changed Date: 2009-12-24 16:28:38 -0500 (Thu, 24 Dec 2009)
--
It has been noted that when choosing a smaller font size (e.g. 5, 6 or 7) or
when using Wireshark's "Zoom out" button with the new GtkTreeView derived
packet list (a.k.a. "new packet list") that the packet list records do not
shrink and zoom-out in the same manner as the older GtkCList based packet list
records do.   

Wireshark's "new" packet list portal as well as the packet details portal are
derived from the GtkTreeView object.   

It is now known that the GtkTreeView::expander-size property can be modified to
allow for smaller row heights.

Background:

Repeated clicks on the "Zoom out" button with the new packet list will decrease
the size of the font used for the packet list, packet details and the packet
hex portals.   But at some point (e.g. when font < 8?) the row heights for the
new packet list and the packet details will no longer shrink.   While the font
size used to display the data will continue to get smaller, the actual number
of displayed rows will not increase for the new packet list portal nor with the
packet details portal.  Yet the number of rows displayed in packet bytes portal
(the "hex view") will continue to increase as smaller font sizes are assigned.

This minimum row height issue appears to be caused by the size assigned to the
GtkTreeView expander which in the case of the packet list is NOT even
displayed.

Wireshark's gtk/packet_list_store.c module already has some code that globally
modifies some of the GtkTreeView properties.  Specifically the procedure
packet_list_class_init() includes the following:

<snip>
        /* XXX this seems to affect TreeView Application wide
         * Move to main.c ??? as it's not a bad thing(tm)
         */
        gtk_rc_parse_string (
                "style \"PacketList-style\"\n"
                "{\n"
                "  GtkTreeView::horizontal-separator = 0\n"
                "  GtkTreeView::vertical-separator = 1\n"
                "} widget_class \"*TreeView*\""
                " style \"PacketList-style\"");
<snip>

Perhaps augmenting this internal *TreeView* style string with something like
the following would be useful:

                "  GtkTreeView::expander-size = 0\n"

I experimented with various expander-size values on both RH Linux and Windows. 

A value of 0 is interesting in that it allows for maximum zoom-out.  But on
Linux when set to 0 the size of the TreeView expander appears to be smaller
than is necessary or preferable for many font sizes.   On Windows when set to 0
the expander graphic (Normally a + or - enclosed within a square) changes to
the text characters "+" and "-" which is not optimal.   

Perhaps a "better" way might be to dynamically assign the expander-size
property
value in proportion to the currently assigned font size.  Unfortuntaly I don't
know enough about GTK internals to know if the GtkTreeView::expander-size
property can be changed after a GtkTreeView is instantiated.

Hopefully someone can find a use for this info and perhaps get the New packet
list's "Zoom-out" to behave like the CList derived packet list does.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.