feat(all): login refactor for entry yaml build and account management

[OSXLich-Doug]

Lich 5 GUI Login Refactoring Plan

Proposed Refactoring Approach

Address code organization issues, avoid code redundancy (DRY), correct existing legacy naming convention issues, implement state management, and provide appropriately documented code.

1. File Structure (Maintained)

We will keep the three-file structure:

• gui-login.rb: Main entry point with the gui_login method
• gui-saved-login.rb: "Saved Entry" tab functionality
• gui-manual-login.rb: "Manual Entry" tab functionality
• ** gui_login.rb** replaces gui-login for proper snake_case convention

2. Code Organization Improvements

In gui-login.rb:

• Add proper module documentation
• Refactor the gui_login method to be more modular
• Extract configuration and state initialization to separate methods
• Add proper error handling

In gui-saved-login.rb and gui-manual-login.rb:

• Convert from sequential scripts to proper class-based structure
• Wrap functionality in classes that can be instantiated by gui-login.rb
• Add proper initialization methods

3. DRY Improvements

• Create shared utility modules for common functionality:

  • Lich::Common::GUI::Utilities: Common GUI utilities
  • Lich::Common::GUI::Authentication: Authentication logic
  • Lich::Common::GUI::Components: GUI Component builders
  • Lich::Common::GUI::State: Common state code

• Extract repeated code into reusable methods:

  • Game realm mapping
  • Launch data preparation
  • Button styling
  • Dialog creation

4. Naming Convention Standardization

• Rename variables to follow Ruby conventions (snake_case)
• Use more descriptive variable names
• Standardize method naming
• Use consistent naming patterns across files

5. Documentation Improvements

• Add comprehensive module and class documentation
• Document public methods with proper YARD-style comments
• Add inline comments for complex logic
• Include usage examples where appropriate

6. State Management Improvements

• Encapsulate state in proper classes
• Use accessor methods instead of direct instance variable access
• Clearly separate UI state from business logic
• Implement proper initialization and cleanup

7. Implement account management in GUI

• Managing existing accounts and characters
• Adding new accounts
• Adding characters to existing accounts

8. Implement entry.yml and retire entry.dat mechanisms

• Reorganize data structure to group by account first, then characters
• Move passwords to the account level to avoid duplication
• Implement backward compatibility to read legacy Marshal files

9. Implementation of accessibility features (supports Linux only)

• Experimental features for accessibility for screen reader support / keyboard navigation
• Not available on MacOS or Windows (yet)
• Provides anchors for future expansion when OS updates occur

10. Implementation of Favorites

• Favorites may be designated on any of the tabs for character input or launch
• A FAVORITES tab will be created on the Saved Entries tab that will display the current favorites

11. Modify CLI login to use new YAML structure

• Provides parity for existing CLI login capabilities
• Begins abstracting methods for enhanced CLI features (future delivery)
• Integrates gu_login.yaml structure for snake_case and extension naming conventions

---

Important

Refactor Lich 5 GUI login system for improved modularity, state management, and introduce YAML-based entry storage, account management, and accessibility features.

• Behavior:
  • Refactor login system in gui-login.rb, gui-saved-login.rb, and gui-manual-login.rb for better modularity and error handling.
  • Introduce YAML-based entry storage in yaml_state.rb, replacing entry.dat.
  • Add account management features in account_manager.rb and account_manager_ui.rb.
  • Implement accessibility features in accessibility.rb (Linux only).
  • Add favorites management in favorites_manager.rb.
  • Update CLI login to use new YAML structure in main.rb.
• Code Organization:
  • Convert sequential scripts to class-based structure in gui-saved-login.rb and gui-manual-login.rb.
  • Extract common functionality into utility modules: utilities.rb, components.rb, theme_utils.rb.
  • Standardize naming conventions to snake_case.
• Testing:
  • Add comprehensive tests for account management and authentication in account_manager_spec.rb and authentication_spec.rb.
  • Include tests for YAML state management in yaml_state_spec.rb.
• Misc:
  • Rename gui-login.rb to gui_login.rb for naming consistency.
  • Add experimental accessibility features for screen reader support.

^{This description was created by for 1c8f8d5. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed 4a69934 in 3 minutes and 14 seconds. Click for details.

• Reviewed 152 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. lib/util/login_helpers.rb:146

• Draft comment:
  Ensure that char_name is not nil before invoking casecmp? to avoid a potential NoMethodError.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The method documentation clearly states char_name is required. The comment suggests defensive programming that would hide bugs rather than catch them. If char_name is nil, that's a programming error that should fail fast. The suggested change would make the code more confusing by implying char_name could be nil when it shouldn't be. Perhaps there are edge cases where char_name could be nil that I'm not seeing? The method does accept nil as a valid value according to some documentation comments. Looking at the full context, while char_name can be nil in the method signature, in this specific block we're already past the point where we'd handle nil char_name cases - this is specifically for exact matches where we want char_name to be present. The comment should be deleted. The suggested change would add unnecessary defensive programming that could hide bugs rather than catch them.

2. lib/util/login_helpers.rb:175

• Draft comment:
  For consistent behavior, consider assigning the normalized game code (e.g. using game_code.to_s.upcase) to :_requested_game_code in the fallback block rather than the raw game_code.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While normalizing would be more consistent with other parts of the code, the current implementation doesn't seem to cause any actual issues since case-insensitive comparisons are used where needed. The suggestion is more about code style than fixing a real problem. The code works correctly as is. The code might be slightly more maintainable if all game codes were normalized at the point of storage rather than handling case sensitivity at each point of use. However, the current approach of handling case sensitivity at points of comparison is also valid and consistent. The code already works reliably. While the suggestion would improve code style slightly, it's not addressing a real problem and the current implementation is perfectly functional.

Workflow ID: wflow_eJN8xZFFL1QQysgP

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 1c8f8d5 in 1 minute and 17 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. lib/util/login_helpers.rb:283

• Draft comment:
  Removed debugging print. Consider using a proper logging call if debugging is needed.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

Workflow ID: wflow_b0xXvo8vmEYykwxc

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}