You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
freakboy3742 opened this issue
Dec 5, 2024
· 1 comment
Labels
bugA crash or error in behavior.linuxThe issue relates Linux support.macOSThe issue relates to Apple macOS support.windowsThe issue relates to Microsoft Windows support.
If an app declares document types, any command line argument that isn't a document will result in a Don't know how to open documents with extension ... error.
Steps to reproduce
Run the testbed with a test specifier:
briefcase run --test -- tests/app/test_app.py
results in an error because the testbed doesn't know how to handle documents of type .py.
Expected behavior
Functionally, Testbed shouldn't raise an error or warning for any "normal" operation.
More generally, it should be possible for a document-based app to handle arguments that aren't documents. It might be helpful for this list of arguments to be processed using standard argparse handling, with the argparse instance being configured using a standard interface (with a default implementation).
Screenshots
No response
Environment
Operating System: Any desktop platform
Python version: All
Software versions:
Toga: 0.3.19+
Logs
Additional context
There may be an argument that this is a quirk of testbed - that testbed is a document-based app by necessity, but not representative of "real" document-based apps, and the API contract of document-based apps is "the command-line arguments can only be documents". This would be an extreme option, but not a completely indefensible one.
For GTK and Windows, this should be relatively straightforward - replace the sys.argv[] reference in App._create_initial_windows with something based on an argparse definition.
For cocoa it's a little more complex, because the document handling is managed by Cocoa (so as to enable "drop document onto app" handling). We either need to separate "first launch" argument handling from the application:openFiles: handler, or we need a strategy for how document names are handled in the context of a full list of arguments.
The text was updated successfully, but these errors were encountered:
freakboy3742
added
bug
A crash or error in behavior.
linux
The issue relates Linux support.
macOS
The issue relates to Apple macOS support.
windows
The issue relates to Microsoft Windows support.
labels
Dec 5, 2024
freakboy3742
changed the title
Improve handling of command line arguments
Improve handling of command line arguments (esp for document-based apps)
Dec 5, 2024
bugA crash or error in behavior.linuxThe issue relates Linux support.macOSThe issue relates to Apple macOS support.windowsThe issue relates to Microsoft Windows support.
Describe the bug
If an app declares document types, any command line argument that isn't a document will result in a
Don't know how to open documents with extension ...
error.Steps to reproduce
Run the testbed with a test specifier:
results in an error because the testbed doesn't know how to handle documents of type
.py
.Expected behavior
Functionally, Testbed shouldn't raise an error or warning for any "normal" operation.
More generally, it should be possible for a document-based app to handle arguments that aren't documents. It might be helpful for this list of arguments to be processed using standard
argparse
handling, with the argparse instance being configured using a standard interface (with a default implementation).Screenshots
No response
Environment
Logs
Additional context
There may be an argument that this is a quirk of testbed - that testbed is a document-based app by necessity, but not representative of "real" document-based apps, and the API contract of document-based apps is "the command-line arguments can only be documents". This would be an extreme option, but not a completely indefensible one.
For GTK and Windows, this should be relatively straightforward - replace the
sys.argv[]
reference inApp._create_initial_windows
with something based on an argparse definition.For cocoa it's a little more complex, because the document handling is managed by Cocoa (so as to enable "drop document onto app" handling). We either need to separate "first launch" argument handling from the
application:openFiles:
handler, or we need a strategy for how document names are handled in the context of a full list of arguments.The text was updated successfully, but these errors were encountered: