[GRASS-dev] [GRASS GIS] #3502: v.proj location not set in dialog

[GRASS GIS]

#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.

 The wxPython documentation at https://docs.wxpython.org/wx.ComboBox.html
 seems inconclusive about what events should be generated for each action.

 * 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.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3502#comment:6>
GRASS GIS <https://grass.osgeo.org>