Bug129 Editing
For instance: - documentation for -R should list possible options (possibly this will be solved when neiljp's patch lands), and mention the default - same for -d and -c - -r should list the default locations that will be searched I nominate this for milestone1
njs: confirmed that my current bug80 patch fixes the -R issue, including checking if invalid values are passed in. I was considering adding a discovery mechanism for the console modules, to enable having something like a --list-available-consoles option and to allow determination of whether the console name is valid before we try to open it, and that could also be useful (and probably necessary) for the -c option; Same for -d. At the worst this could be hardwired to begin with, based on the configure options used eg. if GGI & SDL are built, then assume that they are avilable to load.
bug80 has landed, and the help option is now more helpful. What exactly do we want done for this bug?
nicholas: I see this in three parts: - implement available kit/.so listing, similar to in bin/kits but more generic (add to console interface); this can be used to check -d options. - implement available console/.so listing; same as with -c, but for kits. - modify -r in some way...not sure how exactly? (njs?) I'd quite like server-options such as --list-available-consoles, --list-available-drawingkits ...and these should really work in-line with each other. For example, if we have '-d GLDrawingKit --list-available-consoles', then we'd only show consoles supporting the GLDrawingKit. In a similar way it'd be useful to be clearer when trying to run with an unsupported combination that this is not possible, eg. by doing the equivalent of --list-available-consoles. Hmmm, maybe --list-available-[consoles,drawingkits] should just display the same output, ie. columnar listing with |Console|Supported DKs|file-name/location|.` [/braindump] OK, what about: --list-all-consoles (always outputs columnar as above) --list-matching-consoles/drawingkits (checks -d/-c options and outputs available ones) --list-configuration-paths (for -r) The alternative is to automatically update the getopt strings according to which modules/paths are present, ie. parse that before doing getopt. While that avoids option-explosion, it means parsing a lot of things even if you just want to know the version ;) Thoughts?
I've added a -C/--list-available-consoles option. Note that this does not list the possible options directly, when you do -h, but the -c option now contains help text to suggest using the -C option to get possible values. No mention of what the default is atm - the help strings are too long ;) [We can't list possible options directly in -h, since those strings are (currently) hardcoded, and available options may change at runtime] We should add a similar entry which does the same for -d, if we wish to complete this bug as originally intended. This would be very useful on its own, but there is also the dependency of the GLDrawingKit on the GL extension being available in the related console. Also not all drawingkits can be used in the server directly - at least currently - eg. the PSDrawingKit. Maybe instead of extending the -d behaviour, we might for now change it into a --gl-accelerated option? It might pick libartdrawingkit if it is "no", GLdrawingkit if it is "yes", with suitable error-checking and fallback if either don't exist for the console being used. All we might need is a check for get_extension<GLContext>("GLContext"), if the option is set. Anyway I'm looking at -r next, so extensions/changes to the -d option can be put on hold for now until someone appraises my comments :)
With the fix to task58, the RC management can be centralised in the same way as the server-resolution (albeit not for fresco clients). If the paths to search are embedded in RCManager.cc, the help text can be set using those strings, perhaps?. Either way I'd like to get this bug further/finished soon - for some definition of that (v. busy atm!)
5XBNaO <a href="http://shuzlacabywr.com/">shuzlacabywr</a>, [url=http://gpiervvdiqwk.com/]gpiervvdiqwk[/url], [link=http://eqkbfiqjrbth.com/]eqkbfiqjrbth[/link], http://cnqcyxbgfhgk.com/
tn7kJq <a href="http://sltmlszlycds.com/">sltmlszlycds</a>, [url=http://nacyoustizsf.com/]nacyoustizsf[/url], [link=http://nxpbticwuciy.com/]nxpbticwuciy[/link], http://ijcsiavbelpg.com/
not logged in
register
Home