Improve gui resize policies.

application/gui/widgets/game_arguments_widget.py

@@ -50,7 +50,7 @@ def init_ui(self):
  QAbstractScrollArea.SizeAdjustPolicy.AdjustToContents
  )
 
- self.update_table()
+ self.update_arguments_table()
 
  self.setLayout(self._table_layout)
 
@@ -59,7 +59,17 @@ def init_ui(self):
  def get_args_dict(self) -> dict:
  return self._args_dict
 
- def update_table(self, game_arguments=None):
+ def disable_scroll_bars(self):
+ self.disable_horizontal_scroll()
+ self.disable_vertical_scroll()
+
+ def disable_horizontal_scroll(self):
+ self._table.setHorizontalScrollBarPolicy(Qt.ScrollBarAlwaysOff)
+
+ def disable_vertical_scroll(self):
+ self._table.setVerticalScrollBarPolicy(Qt.ScrollBarAlwaysOff)
+
+ def update_arguments_table(self, game_arguments=None):
  # Allow argument data to be updated by external caller.
  if game_arguments:
  self._arg_data = game_arguments
@@ -99,7 +109,7 @@ def update_table(self, game_arguments=None):
  # Value widget for the given row
  value_widget = None
 
- # TODO - This works... but its janky and can break.
+ # TODO - This works... but its not built very well and can break.
  # If someone disables required but not actions then c == 3 will equal the
  # self._ARG_ACTIONS_COL but its hard coded to 4. Change it to go back and hide the
  # columns later.
@@ -136,6 +146,7 @@ def update_table(self, game_arguments=None):
  c, QHeaderView.ResizeToContents
  )
 
+ self._table.horizontalHeader().setStretchLastSection(True)
  self._table.resizeRowsToContents()
  self._table.resizeColumnsToContents()
  self.adjustSize()

application/gui/widgets/game_manager_widget.py

@@ -197,7 +197,7 @@ def _refresh_on_timer(self):
  )
 
  self._install_games_menu.update_menu_list()
- self._current_arg_widget.update_table(game_arguments=game_arguments)
+ self._current_arg_widget.update_arguments_table(game_arguments=game_arguments)
 
  self._timer.setInterval(self.REFRESH_INTERVAL)
 

application/gui/widgets/new_game_widget.py

@@ -86,6 +86,7 @@ def _build_inputs(self, game_name):
  self._arg_widget = GameArgumentsWidget(
  self._client, args_list, input_frame, disable_cols=disabled_cols
  )
+ self._arg_widget.disable_horizontal_scroll()
 
  input_frame_main_layout.addWidget(self._arg_widget)
 
@@ -124,6 +125,7 @@ def _build_inputs(self, game_name):
  input_frame.setLayout(input_frame_main_layout)
  input_frame.setFrameStyle(QFrame.StyledPanel | QFrame.Plain)
  input_frame.setLineWidth(1)
+ input_frame.adjustSize()
 
  return input_frame
 
@@ -156,6 +158,9 @@ def init_ui(self):
 
  self.setLayout(self._layout)
 
+ self.adjustSize()
+ self.parentWidget().adjustSize()
+
  self.show()
 
  self._initialized = True
@@ -171,6 +176,7 @@ def _text_changed(self, game_pretty_name):
  self._current_inputs = self._build_inputs(game_pretty_name)
  self._layout.replaceWidget(old_inputs, self._current_inputs)
  self.adjustSize()
+ self.parentWidget().adjustSize()
 
  def _install_game(self, game_pretty_name):
  logger.info(f"Installing Game Name: {game_pretty_name}")

docs/developer.md

@@ -95,7 +95,10 @@ to set this up properly.
 
 This software uses the coverage and pytest python packages for a testing framework. All tests are in the "tests" folder,
 and are split up by unit tests and functional tests. Any unit test is a simple test of a singular function or independent
-object. A functional test is
+object. A functional or system test would be a test that covers and end-to-end function; eg installing a game server and
+seeing that the game shows up in the quick action menu, for example.
+
+For more information about testing, [please read here](./testing.md)
 
 # Software Development Process
 

docs/testing.md

@@ -0,0 +1,43 @@
+# Testing
+
+Testing an application is imperative as it grows because as new features and fixes are introduced,
+the potential for creating more issues than get solved increases.
+
+## Test Plan
+
+The goal is to first, implement unit testing and then system testing with the PyQt GUI. In the end,
+all testing (or as much as possible) should become a part of CI/CD checks.
+
+A word about code coverage - In my experience people associate code coverage with an in-fallable
+system. That is, if the code coverage is 95% then the system cannot have any bugs in it, certainly!
+The author disagrees with this mentality. Instead, the author belives its best to use code coverage
+metrics as a guidline and instead focus on test case coverage. In a perfect world, test driven
+development would drive test case coverage, but in reality code gets written and tests are added
+both as one can plan for and as issues are found.
+
+### Desired Unit Testing
+
+1. Testing API Endpoints.
+2. Testing the Token authentication mechanisms.
+3. Testing all isolated functions.
+
+### Desired System Testing
+
+1. Testing that the GUI can install a game server properly.
+2. Testing that the GUI can startup, shutdown and restart an installed game server properly.
+3. Testing that the GUI can update a game server properly.
+4. Testing that the GUI can uninstall a game server.
+5. Testing that installing a new game results in the quick action menu being updated.
+6. Testing that uninstalling a game results in the quick action menu being updated.
+
+### Other testing.
+
+Other testing might consist of load testing, erroneous input testing, fault testing which is to mean
+intentionally causing an error, and much more.
+
+Ideas:
+
+1. Try to break API endpoints with usupported HTTP request types and inputs.
+2. Run game servers for days on end and then check basic functionality.
+3. Try to do odd things like uninstall a game while its running or delete a database record and see
+ how the system reacts.