wxGUI Refactoring

GrassInterface

GrassInterface is an interface to access basic wxGUI functionality. Read more about usage at ​GRASS wiki.

The level of generalization as well as the functionality can be determined when creating standalone GUI modules.

Implemented for:

• GConsole-LayerManager relation
  • it is unclear how to solve priorities/types of messages (log, warning, important message)
• querying
  • uses layers which needs to be improved
  • itself needs to be separated and possibly became part of the interface

Classes to be designed

• Layer
• LayerList/LayerManager/LayerController
• Region/Bounding box
  • to not transfer w, s, b, e, n, t + res...
• Command
  • it is possible to use pygrass or be pygrass compatible?

Map windows and friends

• Logic to control map window needs to be separated from Frame classes to separate controller class.
  • Result will be used in rlisetup

Actions

Action should contain various descriptions, icon and list of handlers to be called. Handlers are registered to the event on runtime.

Not in the SVN.

Suggestions for further refactoring

Using wx-like styles for module forms

There are several different usages of module forms. They may be distinguished by wx-like styles.

Standalone GUI modules

These GUI modules are available to user which has the possibility to run lightweight application only with particular functionality. The advantage for a developer is the quicker testing without the need to start main GUI (g.gui).

The relation with refactoring is obvious. Classes and places which needs refactoring will appear when you try to create and use some window in standalone application (i.e., without Layer Manager and Map Displays). In other words, only general classes can be reused in both a module and the main GUI application.

Open questions

How to document events in the Doxygen documentation?

Posted events are part of a interface of a class. There is wxWidgets Doxygen documentation when events are listed in class description in a list with description (​link).

Should event handlers be private?

According to wxWidgets documentation event handlers should be private: Notice that as the event handlers normally are not called from outside the class, they normally are private. In particular they don’t need to be public (​wxWidgets overview of events). Private method in Python usually starts with underscore. This is in collision with wxWidgets convention which is naming event handlers like OnSomethingHappened (in C++ these methods are private because they are in private section of class definition).

Is defining interface of map display on top of the existing class enough?

This text is unclear as well as the right answer.

Or would be better to define interface class (similar to GrassInterface) to ensure exclusive use of this interface? Private methods are probably mostly sufficient, however interface of particular class can be wider than defined GrassInterface.

For example, some class A which is not expected to use the wider interface, provided by class B, can use this wider interface when class A has direct access to class B. Consequently, the class A depends on class B instead of GrassInterface interface. Using GrassInterface layer ensures that class A depends on the GrassInterface, not the wider interface provided by the class B.

However, implementing the GrassInterface is little bit more difficult because beside the particular class (class B in example above), you have to implement also the GrassInterface class.