#3502: v.proj location not set in dialog
-----------------------------+-------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxGUI | Version: 7.4.0
Keywords: v.proj location | CPU: OSX/Intel
Platform: MacOSX |
-----------------------------+-------------------------
In the Source tab for the v.proj dialog are three entry fields - location,
mapset and name. The pulldown list for location seems appropriate and you
can select an item, however, this does not update the dialog. You can
tell because 1) the status dialog at the bottom still shows
"location=<required>" and the subsequent entry field pulldown lists are
not populated as you would expect. A workaround is to type the location
name in manually in the text box. Then everything works as expected.
The other pulldowns, mapset and name, in this dialog seems to work
properly and update the dialog when an element in the pulldown is
selected.
This is a new behavior for me in 7.4.0. It worked as I expected in 7.2.2.
#3502: v.proj location not set in dialog
------------------------+-----------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.4
Component: wxGUI | Version: 7.4.0
Resolution: | Keywords: v.proj location
CPU: OSX/Intel | Platform: MacOSX
------------------------+-----------------------------
Comment (by balagates):
I believe I found what caused this change. In
./gui/wxpython/gui_core/forms.py 7.2.2 (71322) vs 7.4.0 (71217)
{{{
elif prompt == 'location':
win =
gselect.LocationSelect(parent=which_panel,
value=value)
win.Bind(wx.EVT_COMBOBOX,
self.OnUpdateSelection)
win.Bind(wx.EVT_COMBOBOX, self.OnSetValue)
}}}
changed to
{{{
elif prompt == 'location':
win =
gselect.LocationSelect(parent=which_panel,
value=value)
win.Bind(wx.EVT_TEXT, self.OnUpdateSelection)
win.Bind(wx.EVT_TEXT, self.OnSetValue)
}}}
There were a large number of other changes that appear unimportant for
this. I do not understand why the 7.2.2 is a higher revision than the
7.4.0 but it must be due to different branches.
I am not confident enough to make a change to the source. Is there some
other case where the change made sense? Which branch is the right one to
make the change in?
After changing to EVT_COMBOBOX the selection from the pulldown list
appears to work as I expect but then typing in the location no longer
appears to work. In my use the former seems more important but there
might be cases where the later is more important.
#3502: v.proj location not set in dialog
------------------------+-----------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.4
Component: wxGUI | Version: 7.4.0
Resolution: | Keywords: v.proj location
CPU: OSX/Intel | Platform: MacOSX
------------------------+-----------------------------
Comment (by balagates):
I now have access to Grass 7.4.0 with wxPython 3.0.2.0 on Ubuntu 18.04. In
this version v.proj location works as expected. Therefore, this problem is
likely due to some difference in OS (macOS vs Linux), likely in the
wxPython implementation. I verified the source on Ubuntu is
win.Bind(wx.EVT_TEXT,...). The older code still makes more sense to me.
Not sure if there is some benefit to the newer change.
#3502: v.proj location not set in dialog
------------------------+-----------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.4
Component: wxGUI | Version: 7.4.0
Resolution: | Keywords: v.proj location
CPU: OSX/Intel | Platform: MacOSX
------------------------+-----------------------------
Comment (by hellik):
Replying to [comment:3 balagates]:
> I now have access to Grass 7.4.0 with wxPython 3.0.2.0 on Ubuntu 18.04.
In this version v.proj location works as expected. Therefore, this problem
is likely due to some difference in OS (macOS vs Linux), likely in the
wxPython implementation. I verified the source on Ubuntu is
win.Bind(wx.EVT_TEXT,...). The older code still makes more sense to me.
Not sure if there is some benefit to the newer change.
there is now GRASS 7.6 released; any chance to test it there?
#3502: v.proj location not set in dialog
------------------------+-----------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.4
Component: wxGUI | Version: 7.4.0
Resolution: | Keywords: v.proj location
CPU: OSX/Intel | Platform: MacOSX
------------------------+-----------------------------
Comment (by balagates):
On my Mac running macOS 10.12.6 I installed the pre-built Grass 7.6.0 app
linked on the Grass download page. Within the Grass app it reports Python
2.7.15 and wxPython 4.0.3. The GUI for v.proj still seems to have the
same problem and maybe an additional new problem. From the main GUI menu
I select "File -> Import Vector Data -> Reproject vector map from
different GRASS location [v.proj]". A window appears with the Source tab
selected and 3 combo boxes (Location, Mapset, Name). The pull-down for
the Location ComboBox is populated with values I expect. Selecting one
from the pull-down does not set the location. At the bottom of the
windows is the assembled command line and after making a selection from
the pull-down is says "v.proj location=<required>". If instead of
selecting the value from the ComboBox pulldown I type in location (or do
some manual edits on the one I pulled down, the location gets set.
So my guess is when selecting a ComboBox on macOS wxPython is generating a
wx.EVT_COMBOBOX event but not a wx.EVT_TEXT event. Since Grass 7.2 there
have been several changes in forms.py changing bindings from
wx.EVT_COMBOBOX to wx.EVT_TEXT with resulting loss of functionality on
macOS. Since it appears to work on my Ubuntu machine the events generated
for a ComboBox must be different. I haven't studied wxPython to see what
events we expect when a ComboBox selection is made. To me it does make
more sense that when making a ComboBox selection a wx.EVT_COMBOBOX would
be generated. It is not so obvious that a wx.EVT_TEXT would get
generated...but maybe it will? I do not know enough now to know what
should be robust.
Note also that some changes in Grass 7.4.3 forms.py appear to have caused
similar problems with the Mapset ComboBox selection. I am still studying
that but the symptoms are the same. Selecting a value from the ComboBox
pulldown does nothing, but typing in a Mapset name in the field sets it
values and populates the Name ComboBox.
#3502: v.proj location not set in dialog
------------------------+-----------------------------
Reporter: balagates | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.4
Component: wxGUI | Version: 7.4.0
Resolution: | Keywords: v.proj location
CPU: OSX/Intel | Platform: MacOSX
------------------------+-----------------------------
Comment (by balagates):
I created a small test program in Python to examine wx.ComboBox() events
(attached). This confirms my suspicions that on my macOS system changing
the value of the ComboBox value through the pulldown menu only generates a
wx.EVT_COMBOBOX event. It does not generate a wx.EVT_TEXT event. On my
Ubuntu system changing the value of the ComboBox value through the
pulldown menu generates both a wx.EVT_COMBOBOX event and wx.EVT_TEXT
event. When the text is manually edited by typing both systems generate a
wx.EVT_TEXT for each keypress.
* EVT_COMBOBOX: Process a wxEVT_COMBOBOX event, when an item on the list
is selected. Note that calling GetValue returns the new value of
selection.
* EVT_TEXT: Process a wxEVT_TEXT event, when the combobox text changes.
I could interpret this both ways. The fundamental question is whether
these two events should be interpreted as:
* EVT_COMBOBOX_CHANGE and EVT_TEXT_EDIT_CHANGE
or
* EVT_COMBOBOX_CHANGE and EVT_VALUE_CHANGE
It is unclear if the wx intention was to generate a 1:1 mapping between
change method and event. Neither system generates any events when you use
the ComboBox pulldown and select the element that is already selected.
It would be interesting to see how this behaves on a Windows system,
however, majority behavior probably doesn't imply correctness.
In the Grass v.proj case I cannot see a common use for manually editing
the values. Sure, it might be quicker for someone with a long list of
similarly named elements to manually edit, but I think the idea of
populating the ComboBox is to avoid typing mistakes.
Potentially this could affect the Grass Python GUI other places so it
probably deserves more investigation.
* wx.EVT_COMBOBOX - When the user selects something.
* wx.EVT_TEXT - Capture events every time the user hits a key in the text
entry field.
* wx.EVT_TEXT_ENTER - Capture events when the user types something into
the control then hits ENTER.
This functionality seems to match what I see on macOS. The ComboBox
implementation in wxWidgets for Linux GTK is complicated and appears to
have compile or configuration options that affect how events are handled.
I had difficulty following so I could not explain the behavior on Linux.
For robustness I do not think I would depend solely on wx.EVT_TEXT
messages being generated when a user selects a new value through the
pulldown.