Skip to content

De-wx'ing #190

@Utumno

Description

@Utumno

All wx code must eventually end up in balt gui. This does not simply mean that one must create wrappers for wx classes/constants and drop them into gui - it means that gui must export an API - so gui should not return wx items on which wx methods will be called - must wrap those methods into class methods it exports - in other words we must not only eliminate wx imports but also wx calls on wx objects returned by gui functions (such as Bind). This (apart its obvious, I hope, value vis a vis code quality) will also make it easier to move to later versions of wxPython / offer an entirely different backend. There is already a great deal of it done (edited out of this issue). But there is also an awful lot left to be done. So:

  • sizers - that's the biggest one. According to what I wrote above, defining say wxEXPAND = wx.EXPAND in gui is not the way to go. Rather the usage patterns of sizers in Bash must be explored from someone who groks the wx sizers API and an API be crafted in gui which defines what one wants (as opposed to how to achieve it).
    • wx.LEFT etc, 0 does make any cense ?
    • I would like to go through the uses of sizers a bit and see what is left out - the wx.TOP etc stuff for instance - I have a plan for adding them in the LayoutOptions
    • rename default_border etc to item_border etc - this is confusing (and much too verbose)
  • an Images API is also badly needed - I hacked up a couple classes but that's exactly that - a hack - see 36e7f89. -> new issue Rework internal image API to account for change of size icons (and general maintainability) #366
  • rest of functions in balt to classes (like checkBox, v/hsizer etc)
  • A single package with wx imports. Single and as small as possible -> gui. Files that currently import wx (and they shouldn't) are:
    • basher/__init__.py: 7 usages left (mostly wx.Notebook but also wx.EVT_CONTEXT_MENU, wx.NOT_FOUND, wx.Platform, wx.EVT_NOTEBOOK_PAGE_CHANGED)
    • constants.py: nasty, our settings defaults depended on wx constants
    • dialogs.py: sizers, wx.TE_RICH2, wx.ColourPickerCtrl, wx.Icon
    • frames.py:
      • this needs attention. wx.lib.iewin --> this must go! Also a lot of classes in need of wrapping
      • wx.ArtProvider_GetBitmap (icons API !)
      • wx.FlexGridSizer
      • One random usage of wx.NOT_FOUND
    • gui_fomod.py: same problem as belt below
    • gui_patchers.py: sizers, wx.Window
    • patcher_dialog.py: sizers, event binding
    • settings_links.py: sizers
      And outside basher:
    • belt.py: the wizard dialog
    • id parameters from balt functions/constructors must be dropped
    • balt functions such as button must become classes and be inherited by OkButton, CancelButton etc

Some newer TODOs:

  • where did the tracebacks go? -> fixed in 6f121cb
  • the issue with warnings on booting still allowing the user to interact with main frame -> fixed on wx4 yey! -> https://trac.wxwidgets.org/ticket/17816
  • the progress dialog - ugh. Our whole CancelError stuff is not working anymore (and I never liked that exception control flow anyway). More importantly, there is the strange issues of losing focus and I think it's the progress window again. -> wx bug, fixed by switching to GenericProgressDialog -> see Investigate Progress events focus #728
  • related to the above - make sure we don't refresh twice - we must follow a bit the events (with good old prints) and make sure they are processed once - I am thinking also of cases we display dialogs and such, is RefreshData triggered? More @balt.conversation ? We could maybe add an _is_shown attribute and use the evt_activate argument to only refresh when the _is_shown becomes True from False -> seems working ok but keep an eye open!
  • not sure about properties yet - sometimes it's ok but sometimes methods are preferred - more explicit - WIP but stabilizing - current code is fine
  • events - it seems wx did not doubly register a handler - see notes on 4766e10. We do and we skip by default which means we have to go through the previous uses and carefully evaluate if skip is needed. Seems it's not the default because it is not meant to be used often. So there are system handlers that might need to be skipped - could not really understand their docs: https://wxpython.org/Phoenix/docs/html/events_overview.html#how-events-are-processed - I guess system handlers run after user ones
    • revisit event handling during boot - especially size events need be handled after setting sizes before maximizing apparently etc - see 4d70274 (Attempt to fix installers tab positions not being set)
  • balt will no longer serve a purpose once we're done - all balt code should either go into basher (highly specific Wrye Bash code) or into gui (pure abstractions over wx). Useful rule of thumb: if you think the class / method could be easily copied into another project without dragging core Bash code along while still being useful, it's gui
  • revisit locale handling - see> wxWidgets/Phoenix#1702 from wxPython 3 Upgrade #15 (comment)

Under #163

Metadata

Metadata

Labels

A-guiArea: GUI (The wx wrapper classes in the gui package)A-linksArea: Links (Options shown in right-click menus, in basher/*_links.py and basher/links_init.py)A-wxArea: wxPython interactions (the gui package, balt.py and the basher package)C-goalCategory: Long term goal. May be code-related or a meta goal.C-internalCategory: Keep track of internal refactoring. Implies the C-todo label except if it is a full C-goal

Type

No type

Projects

Status

Active

Relationships

None yet

Development

No branches or pull requests

Issue actions