Bug 1411165
| Summary: | GUI does not display correctly and locks up when scrolling down to make alternative mapsets visible in GRASS GIS d.vect and d.rast commands | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | rick <rg-ewc> | ||||
| Component: | wxGTK3 | Assignee: | Scott Talbert <swt> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 28 | CC: | alexjnewt, lemenkov, neteler, swt | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-05-28 20:51:01 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Can I have a little more description of how to reproduce this? When I open d.rast and open the "Name of raster map to be displayed:" drop down, I only see two items, Mapset: talbert and Mapset: PERMANENT, and they are both blue already. BTW, these errors: (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton? (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? are not likely related to the main problem you are reporting. These are likely widget sizing issues that will have to be fixed in GRASS. (In reply to Scott Talbert from comment #2) > Can I have a little more description of how to reproduce this? When I open > d.rast and open the "Name of raster map to be displayed:" drop down, I only > see two items, Mapset: talbert and Mapset: PERMANENT, and they are both blue > already. In the GRASS layer manager, click: Settings-->GRASS working environment-->Mapset access, then select additional mapsets to want to be able to access. Then when you open either d.rast or d.vect from the layer manager and in the first tab click on "Name of vector map" or "Name of raster map" to show the drop-down list of mapsets available, your signed-in mapset will be at the top (in blue and expanded), followed by PERMANENT mapset (in blue and expanded), followed by the additional mapsets that were made accessible (in blue but not expanded). The problem occurs most times when those additional accessible mapsets (in blue) become visible (without moving mouse over them) when scrolling down in the drop-down window. The problem happens every time when clicking on those additional mapsets. The problem is intermittent when double-clicking on an already brought up map layer in the layer manager, which opens say, d.vect, for a displayed vector map. Then often (but not always) the scroll bar does not display in the map selection drop-down window (must scroll using mouse wheel). When scrolled all the way to the bottom of the drop-down window to expose the additional mapsets (in blue, not expanded), all usually appears fine. However, sometimes little arrow (triangle) to the left of the mapset name appears and the mapset can be expanded, while other times the triangle does not appear and clicking on the additional mapset name locks up the GUI accompanied by 100% usage of one CPU core by Xorg until stopping GRASS with Ctrl-D in the terminal. Errors flooding terminal appears to be more related to d.vect than to d.rast. (In reply to rick from comment #4) > In the GRASS layer manager, click: Settings-->GRASS working > environment-->Mapset access, then select additional mapsets to want to be > able to access. Then when you open either d.rast or d.vect from the layer Where can I get additional mapsets? There are only two shown when I open Mapset access. (In reply to Scott Talbert from comment #5) > Where can I get additional mapsets? There are only two shown when I open > Mapset access. At GUI startup, you can use the "New" button to generate more mapsets (on the right side, see (3) on the screenshot in https://grass.osgeo.org/grass72/manuals/helptext.html). To have some maps within these mapsets, rather than downloading extra data you may just generate some random maps. Here the commands to run within a (new) mapset: # random raster map: g.region -d # https://grass.osgeo.org/grass72/manuals/r.surf.random.html#example r.surf.random out=random min=0 max=100 # https://grass.osgeo.org/grass72/manuals/v.random.html#generating-random-points-in-2d v.random output=binary_random npoints=20 zmin=0 zmax=1 column='binary' I was never able to get the maps created to properly reproduce this. Anyway, do you mind testing the current F26 to see if it resolves the issue for you? The F26 package has a new upstream snapshot. I've build the F26 package for F25 in a Copr: https://copr.fedorainfracloud.org/coprs/swt2c/wxGTK3-Testing/ To install it, you should just have to do: sudo dnf copr enable swt2c/wxGTK3-Testing sudo dnf update --refresh wxGTK3 To go back to the official packages: sudo dnf copr disable swt2c/wxGTK3-Testing sudo dnf distro-sync --allowerasing wxGTK3 Make sure during that last command that it is only changing wxGTK3 related packages. (In reply to Scott Talbert from comment #7) > I was never able to get the maps created to properly reproduce this. > Anyway, do you mind testing the current F26 to see if it resolves the issue > for you? The F26 package has a new upstream snapshot. I've build the F26 > package for F25 in a Copr: > https://copr.fedorainfracloud.org/coprs/swt2c/wxGTK3-Testing/ > > To install it, you should just have to do: > sudo dnf copr enable swt2c/wxGTK3-Testing > sudo dnf update --refresh wxGTK3 > > To go back to the official packages: > sudo dnf copr disable swt2c/wxGTK3-Testing > sudo dnf distro-sync --allowerasing wxGTK3 > > Make sure during that last command that it is only changing wxGTK3 related > packages. I updated and the problem appears to be gone. Scott, great job! No more 100% CPU issues when it should be just idle. I tested a series of wxGUI functionalities, both from cmd line as well as in g.gui. Unrelated, also this behaves now: cd /usr/share/doc/wxPython-docs/demo/ ; python Calendar.py Looks good! Some extra feedback on wxGTK3-3.0.3-0.8.gite4293e9.fc25.x86_64.rpm: .. in the terminal such messages are printed (a lot of them): (meld:7793): Gtk-WARNING **: Allocating size to DiffMap 0x55b9d8af37b0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? soffice (soffice:7861): Gtk-WARNING **: Allocating size to OOoFixed 0x55cbb8413510 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? --> to reproduce, open a CSV file and plot a diagram The wxGUI of GRASS GIS prints those messages as well. Could this message be suppressed? (In reply to markusN from comment #9) > Some extra feedback on wxGTK3-3.0.3-0.8.gite4293e9.fc25.x86_64.rpm: > > .. in the terminal such messages are printed (a lot of them): > > (meld:7793): Gtk-WARNING **: Allocating size to DiffMap 0x55b9d8af37b0 > without calling gtk_widget_get_preferred_width/height(). How does the code > know the size to allocate? > > > soffice > (soffice:7861): Gtk-WARNING **: Allocating size to OOoFixed 0x55cbb8413510 > without calling gtk_widget_get_preferred_width/height(). How does the code > know the size to allocate? > --> to reproduce, open a CSV file and plot a diagram > > The wxGUI of GRASS GIS prints those messages as well. Could this message be > suppressed? Those messages are from meld and soffice (libreoffice), which do not even use wxGTK. I don't know any easy way of suppressing those messages, aside from fixing the underlying problems. (In reply to Scott Talbert from comment #10) > Those messages are from meld and soffice (libreoffice), which do not even > use wxGTK. ah, sorry for the noise. > I don't know any easy way of suppressing those messages, aside from fixing > the underlying problems. Seems to be this one: https://bugzilla.gnome.org/show_bug.cgi?id=765700 --> https://github.com/GNOME/gtk/commit/ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a and here a fix I found for meld (https://bugzilla.gnome.org/attachment.cgi?id=335456&action=diff) but of course unrelated to this report. Back to this report: Do you plan to push the F26 wxGTK3 version to F25? (In reply to markusN from comment #11) > (In reply to Scott Talbert from comment #10) > > Those messages are from meld and soffice (libreoffice), which do not even > > use wxGTK. > > ah, sorry for the noise. > > > I don't know any easy way of suppressing those messages, aside from fixing > > the underlying problems. > > Seems to be this one: > https://bugzilla.gnome.org/show_bug.cgi?id=765700 > --> > https://github.com/GNOME/gtk/commit/ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a > > and here a fix I found for meld > (https://bugzilla.gnome.org/attachment.cgi?id=335456&action=diff) but of > course unrelated to this report. > > Back to this report: Do you plan to push the F26 wxGTK3 version to F25? 3.0.3 was just released, so yes, I don't see why not. We just avoided pushing the snapshots, as they could have possible regression on stable versions of Fedora. Update submitted for F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-901ccd6490 I updated to wxGTK3-3.0.3-1.fc25.x86_64 just now and did some testing on GRASS GIS. The occasional odd-looking cursor appears now to be working fine. The original problem regarding the gui locking up when scrolling down map lists in the map selection drop-down window in d.vect and d.rast (when additional mapsets appear in the list) still causes the gui to lock up. This happens intermittently. Perhaps this isn't a wxGTK3 problem after all? Also, the console still floods with: (wxgui.py:4072): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed (wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton (In reply to rick from comment #14) > The original problem regarding the gui locking up when scrolling down map > lists in the map selection drop-down window in d.vect and d.rast (when > additional mapsets appear in the list) still causes the gui to lock up. This > happens intermittently. Perhaps this isn't a wxGTK3 problem after all? That's possible. I still am unable to reproduce the problem myself, as I could never get the maps created. Maybe you could just send me some map files (if they are not proprietary) that would enable me to reproduce it? > Also, the console still floods with: > > (wxgui.py:4072): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion > '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed > > (wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size > >= 0' failed in GtkCheckButton The latter one is likely that there isn't enough space allocated for a check button widget - most likely has to be fixed in GRASS. The first one I'm not sure. (In reply to Scott Talbert from comment #15) > (In reply to rick from comment #14) > > Also, the console still floods with: ... > > (wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton > > The latter one is likely that there isn't enough space allocated for a check > button widget - most likely has to be fixed in GRASS. I have created a new bug report for this: https://trac.osgeo.org/grass/ticket/3348 (In reply to Scott Talbert from comment #15) > (In reply to rick from comment #14) > > The original problem regarding the gui locking up when scrolling down map > > lists in the map selection drop-down window in d.vect and d.rast (when > > additional mapsets appear in the list) still causes the gui to lock up. This > > happens intermittently. Perhaps this isn't a wxGTK3 problem after all? > > That's possible. I still am unable to reproduce the problem myself, as I > could never get the maps created. Maybe you could just send me some map > files (if they are not proprietary) that would enable me to reproduce it? > I will create a location with a few mapsets this weekend for you to test with. Please advise (I'm new to this), is the best way to deliver that zip file to you via the "add an attachment" link just below this page's header? (In reply to rick from comment #17) > I will create a location with a few mapsets this weekend for you to test > with. Please advise (I'm new to this), is the best way to deliver that zip > file to you via the "add an attachment" link just below this page's header? Sure. If the file is too large, you may have to put it somewhere else though. Created attachment 1280668 [details] Map location and mapsets for testing In response to request in Comment 15. (In reply to Scott Talbert from comment #18) > (In reply to rick from comment #17) > > I will create a location with a few mapsets this weekend for you to test > > with. Please advise (I'm new to this), is the best way to deliver that zip > > file to you via the "add an attachment" link just below this page's header? > > Sure. If the file is too large, you may have to put it somewhere else > though. I I have attached test_someplace_10m.tar.xz. Place it in any directory, unzip it, then start GRASS. In startup gui, 1. Select GRASS GIS database directory = directory the file was unzipped in; 2. Select GRASS location = test_someplace_10m; 3. Select GRASS Mapset= user-2; then click "Start GRASS session". In GRASS Layer Manager, click menu: Settings --> Grass working environment --> Mapset access and in the Manage access to mapsets gui, click user-1 thru 4 to make all accessible, then click OK. Then click 6th or 8th top icon to open either d.rast gui or d.vect gui and in either one, click on pulldown to display available mapsets (in blue) and maps (in black). In working mapsets with large numbers of maps, scrolling with the mouse wheel down to one of the mapsets (blue) will intermittently cause all GRASS gui's to lock up. In this test file and location in which there are only a few maps in each mapset, scrolling with the mouse wheel only rarely make that happen. However, gui lock up can be made to happen every time by clicking on the scroll bar inside the drop-down list and dragging down to when a different mapset (in blue) appears. I note a small delay in scroll bar motion also when this happens. I am not quite sure I am seeing the same problem, but I do seem to be able to make it lock up by clicking around a bit in that drop-down. I also see this message when I open the drop-down. Do you see this as well? (wxgui.py:24434): Gdk-WARNING **: Window 0x55bd0bb78b00 is already mapped at the time of grabbing. gdk_seat_grab() should be used to simultanously grab input and show this popup. You may find oddities ahead. I don't recall ever seeing that warning message and cannot seem to make it come up. The error messages (unrelated?) that I do see frequently are: (wxgui.py:27398): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton and (wxgui.py:7957): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed when opening and closing the d.vect gui, and also (wxgui.py:27398): Gtk-WARNING **: Allocating size to wxPizza 0x55a725ea4850 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? when resizing the display window by grabbing a corner of it (all map layers render correctly after window resizing). However, I suspect both of these would be GRASS-related issues? This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. (In reply to rick from comment #22) > I don't recall ever seeing that warning message and cannot seem to make it > come up. > > The error messages (unrelated?) that I do see frequently are: ... > (wxgui.py:27398): Gtk-WARNING **: Allocating size to wxPizza 0x55a725ea4850 > without calling gtk_widget_get_preferred_width/height(). How does the code > know the size to allocate? See bug 1488249. (In reply to rick from comment #22) > I don't recall ever seeing that warning message and cannot seem to make it > come up. > > The error messages (unrelated?) that I do see frequently are: > > (wxgui.py:27398): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion > 'size >= 0' failed in GtkCheckButton Reopening since the problem of Gtk-CRITICAL messages polluting the terminal persists in F28 (GRASS GIS 7.4.x): Update: we found a potential solution in the GRASS GIS wxPython GUI code, testing it at time: https://trac.osgeo.org/grass/ticket/3348#comment:8 This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
This was reported on the GRASS bug track and Markus Neteler suggested the bug be reported here. This is what I reported to GRASS: When scrolling down map lists in the map selection drop-down window in the first (Required) tab of d.vect and d.rast, the GUI locks up upon any of the additional mapsets that are made accessible (shown in blue in the GUI) being exposed in the GUI, except for the PERMANENT mapset, which appears already expanded and does not cause the problem. While so far as I can tell GUI lock-up may NOT occur about 5% to 10% of the time when only exposing the unexpanded additional mapsets, it appears to occur 100% of the time if the unexpanded mapsets are clicked upon. The additional mapsets only appear as unexpanded. The GUI also displays oddly on occasion, whereby when moved over GUI buttons the mouse pointer appears as a box with two arrows at 45 degrees, and the scroll bar in the above noted drop-down window fails to appear, such that scrolling can only be done using the mouse wheel. Once locked up, trying to shut down GRASS the normal way is impossible because while the "Do you want to quit GRASS" window opens after clicking on the GUI's x (top-right corner), that window is also non-responsive. When the GRASS GUI is locked up, Xorg uses 100% of one CPU core, but immediately drops to 0% after shutting GRASS down by typing Ctrl-D in the console. I am also experiencing the blacked-out check-boxes which were reported elsewhere and are being dealt with upstream by M. Neteler re. the wxGTK3 repeated "Gtk-CRITICAL" warning bug. This leads me to question whether what I am describe in the first paragraph above may not also be related to wxGTK3?? I experience the very same defects in GRASS 7.2.0svn (r70142), which I have compiled myself, as well as with GRASS 7.0.4-2.fc25.x86_64, which I am running as supplied directly from the GRASS Fedora repository. This problem became apparent only after upgrading from Fedora 21 to Fedora 25. All other computer functions seem to work correctly since the upgrade. I am running kernel 4.8.15-300.fc25.x86_64, AMD Phenom II X4 processor, 16 GiB memory, Gnome 3.22 on X server, Nvidia GeForce? GT 740 GPU with nvidia driver from rpmfusion. When Fedora pushed wxGTK3 to 3.0.2-31 and Xorg-Xserver to 1.19.0-13, that appeared to fix the blacked-out check-box issue. However, the problems with mouse pointer drawing and GUI lock up by the d.rast and d.vect map selection drop-down windows remain. These are the messages on the terminal when the problem occurs: (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton? (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? When asked by the GRASS team to test wxpython demo, specifically ComboCtrl, TreeCtrl Popup, as these should be the same widget as used in d.rast and d.vect, this is what I got on the terminal, following which M. Neteler suggested I report here: [rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeMixin.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic) (TreeMixin.py:520): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'height >= -1' failed (TreeMixin.py:520): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed (TreeMixin.py:520): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -8 Traceback (most recent call last): File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged oldTree = self.GetPage(event.OldSelection) File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage return _core_.BookCtrlBase_GetPage(*args, **kwargs) ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t' Traceback (most recent call last): File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged oldTree = self.GetPage(event.OldSelection) File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage return _core_.BookCtrlBase_GetPage(*args, **kwargs) ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t' [rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/ComboCtrl.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic) 17:36:36: ListCtrlComboPopup.Init 17:36:36: ListCtrlComboPopup.LazyCreate 17:36:36: ListCtrlComboPopup.Create 17:36:41: ListCtrlComboPopup.GetAdjustedSize: 250, 400, 934 17:36:41: ListCtrlComboPopup.OnPopup 17:36:41: ListCtrlComboPopup.SetStringValue 17:36:44: ListCtrlComboPopup.GetStringValue 17:36:44: ListCtrlComboPopup.SetStringValue 17:36:44: ListCtrlComboPopup.OnDismiss (ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed (ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed (ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed (ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed [rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeCtrl.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic) 17:37:27: OnItemExpanded: Item 3 17:37:29: OnItemExpanded: item 3-b 17:37:31: OnSelChanged: item 3-b-0 17:37:35: OnItemExpanded: item 3-d 17:37:38: OnSelChanged: item 3-d-1 17:37:41: OnSelChanged: The Root Item 17:37:44: OnItemExpanded: Item 0 17:37:46: OnSelChanged: item 0-b 17:37:47: OnItemExpanded: item 0-b 17:37:48: OnSelChanged: item 0-b-1 [rick@localhost ~]$ I will continue to coordinate with the GRASS team as it appears they may not yet have closed this bug.