Gnash - The GNU Flash player - Tasks: task #10817, Sort out options parsing
You are not allowed to post comments on this tracker with your current authentication level.
task #10817: Sort out options parsing
Submitter: | Sandro Santilli <strk> | ||
Submitted: | Mon 20 Dec 2010 10:31:27 AM UTC | ||
Should Start On: | Sun 19 Dec 2010 11:00:00 PM UTC | Should be Finished on: | Sun 19 Dec 2010 11:00:00 PM UTC |
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Percent Complete: | 0% |
Open/Closed: | Open | Effort: | 0.00 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-758e.
Corresponding source code
Option parsing in gnash is kind of broken atm.
In particular, we had a concept of Gui classes having
a chance to parse some commandline args (they get argc/argv)
and gtk gui actually passes argc/argv over to gtk libs.
But, we fail when we encounter an unknown option, so
it'll be impossible to pass anything down the line.
This blog post gives example of accepting unknown:
http://cxwangyi.blogspot.com/2010/06/boost-program-options-library.html
The remaining problem is that we can't register "positional"
parameters until all components had a chance to parse
the commanline, and drop what they parsed, or we won't be
able to tell what's a switch argument and what's a positional
parameter.