>From high level it seems strange that Qt initialization (and failure if it fails) happens before options processing takes place. Any errors during this stage effectively prevents --help from being displayed. That also means --debug option don't have any effect during initialization stage.
I'd propose the following initialization order (sorry for not being able to draw a diagram - time is really limited ATM). 01. Parse command line options 02. Setup application debug and logging config according to defaults and parsed options 03. Set default app flags and settings (explicitly made a separate step for debugging) 04. Parse config files and alter flags and settings accordingly 05. Alter flags and settings according to parsed options # low level state configuration is done 06. Check requirements 07. Initialize components/modules independent from Qt (start threads, etc.) 08. Initialize Qt # low level app initialization is done (thread counter is active, all components respond ok) 09. Load user level data 10. Configure components using user level logic (layout, contents, etc.) 11. Process logic rules according to post-initialization state # user level initialization is done 12. Start usual work cycle I can't say how close this description to the way Spyder or other big Python apps work. This list probably need enhancements, but for me having such description is much better then without it. It gives several entry point for people not familiar with app internals and may serve as a roadmap if some useful parts are not implemented yet. -- You received this message because you are subscribed to the Google Groups "spyder" group. To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/ymsIUxoIXHcJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
