Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement] Implement a command line parser #113

Open
GoogleCodeExporter opened this issue Mar 14, 2015 · 6 comments
Open

[enhancement] Implement a command line parser #113

GoogleCodeExporter opened this issue Mar 14, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

Suggested options that should be recognized:
{{{
--help
  displays a help text including command line options, maintainer, website,
etc.
--inipath path/to/ini (see issue 95)
--libpath path/to/lib (see issue 95)
--debug [level]
  enables output of debugging information
--use-editor <prog> (see issue 36)
}}}

Original issue reported on code.google.com by st.loeffler on 5 Mar 2009 at 3:07

@GoogleCodeExporter
Copy link
Author

Original comment by st.loeffler on 22 Aug 2009 at 3:56

  • Added labels: Type-Enhancement

@GoogleCodeExporter
Copy link
Author

Additional options:
--line (see issue 195)
--use-viewer <prog>
  use another pdf viewer. Probably needs program-dependent code, so should be
implemented as plugins/scripts

Original comment by st.loeffler on 24 Sep 2009 at 11:44

@GoogleCodeExporter
Copy link
Author

The attached patch implements a simple command line parser. Supported options:
 * --help, -? (displays available options)
 * --version, -v (displays version information)
 * --position, -p (opens file at given line (.tex) or page (.pdf))

inipath and libpath are more difficult as they are used during TWApp::init(), 
but the
command line parser uses QCoreApplication::arguments which is not available 
before
TWApp is initialized.

Original comment by st.loeffler on 22 Apr 2010 at 6:56

Attachments:

@GoogleCodeExporter
Copy link
Author

The attached (new) version should handle already opened windows correctly 
(i.e., it
passes the files to open to the existing instance of TW).

Notes:
* I had to move the creation of the TWApp instance to the beginning of main(). 
This
is necessary because the commandline parser requires an active QCoreApplication
object. If, for some reason, it should be a problem that the TWApp object is 
created
before the windows code for handling multiple instances of Tw is run, we'd have 
to
separate the TWApp::init() call from the TWApp constructor.
* I modified the windows code to pass data as utf8 instead of local8bit between
instances of Tw. This should not change the general behavior, though.

Original comment by st.loeffler on 10 May 2010 at 2:38

Attachments:

@GoogleCodeExporter
Copy link
Author

I've checked this in, though we may want to think further about options - e.g. 
it might be nice to allow the 
command line to specify PDF viewing mode (zoom level, etc) in addition to just 
choosing a page.

Also note that this does not really work well on OS X, as we don't have "single 
instance" code there - but users 
don't normally start GUI applications with command lines, so it isn't a major 
issue. It would be more interesting 
to see how TW could be integrated with AppleScript and Automator workflows....

Original comment by jfkth...@gmail.com on 16 May 2010 at 1:32

@GoogleCodeExporter
Copy link
Author

Thanks. Yes, we can add whatever options we want ;).

Re. Mac OS X: How are files passed to the app, then? And what happens if a user 
has
an open Tw and opens another tex file (through a file manager)? Would issue 195 
work
on Mac?

Original comment by st.loeffler on 17 May 2010 at 5:52

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants