Currently I believe the entry point for the GUI is the GUITest class, which obviously isn't where it needs to go eventually.
We will ultimately need several different entry points, the first being for the desktop Swing GUI we've been working on, but later we'll need an entry point for an Android app, a command-line app (for running seednodes on headless servers etc), and others. (In fact, I think the Android app may be a higher priority than we had previously contemplated).
There is a TrMain class, however I think this should be renamed to TrCmdMain and it should be used for the command-line version of Tahrir. It should be moved into it's own package also, which will contain any other classes specific to the command line interface.
We should create a new class, perhaps calling it tahrir.swingUi.TrSwingUi, and use this for the Swing UI entry point. Related classes should go in the swingUi package.
All of this should be a reminder that it's important to keep the business logic of Tahrir separate from the presentation layer (the GUI), since we will eventually have several GUIs each of which must share the business logic. The business logic must be agnostic to how Tahrir is interfacing with the user.
Currently I believe the entry point for the GUI is the GUITest class, which obviously isn't where it needs to go eventually.
We will ultimately need several different entry points, the first being for the desktop Swing GUI we've been working on, but later we'll need an entry point for an Android app, a command-line app (for running seednodes on headless servers etc), and others. (In fact, I think the Android app may be a higher priority than we had previously contemplated).
There is a TrMain class, however I think this should be renamed to TrCmdMain and it should be used for the command-line version of Tahrir. It should be moved into it's own package also, which will contain any other classes specific to the command line interface.
We should create a new class, perhaps calling it tahrir.swingUi.TrSwingUi, and use this for the Swing UI entry point. Related classes should go in the swingUi package.
All of this should be a reminder that it's important to keep the business logic of Tahrir separate from the presentation layer (the GUI), since we will eventually have several GUIs each of which must share the business logic. The business logic must be agnostic to how Tahrir is interfacing with the user.