[texworks] Script: Questions about the API

[Jonathan Kew]

Dear Paul,

Before you rush into WebKit-specific authoring, I think we need to pause and consider whether this is the right direction for the TeXworks application to be moving. Maybe so, but I'm a bit hesitant. Adding WebKit to TW will *hugely* increase the size of the application (and presumably its memory footprint when in use), as well as adding a major dependency that may be tricky to maintain across all platforms and build environments. Do the benefits justify the cost?

There are two major proposed "use cases" for this feature, as I see it: (a) presenting various kinds of documentation such as the reference materials you have been preparing; and (b) enabling scripts to present full-featured user interfaces such as dialogs with various types of controls.

Both of these are laudable goals, but neither of them necessarily require embedding a complete web browser engine in the TW application. For presenting documentation to the user, I think it should be possible to create resources in such a form that the user's default browser can be used, rather than requiring an embedded browser. I realize that browser idiosyncrasies make that a little more challenging than writing for only one specific engine, but this shouldn't be an insuperable issue. Most of the World Wide Web manages to work across multiple browsers; I don't believe the requirements of presenting TeX documentation should go beyond what can be done in a portable manner. Leveraging the user's normal browser rather than providing a separate one seems a much more efficient overall use of resources.

As for allowing scripts to present richer UI than the few simple dialogs that are currently available, there is an alternative approach we could explore. This is to use Qt's user interface classes, so that Qt Designer can be used to create a .ui file defining the interface (just like TW's own "native" windows and dialogs). Because all the Qt GUI code is already present in the application, this would add very little "bloat"; we'd just need a thin layer of "glue" code connecting the UI loader and widgets to scripts, rather than pulling in an entire multi-megabyte Web browser engine in order to present a dialog box.

So.... nothing is decided at this point. Embedding WebKit is certainly possible, but I am not convinced it's the right approach. TeXworks aims to be a simple integrated TeX environment; it does not aim to be a full-featured web browser that happens to be able to run TeX! :)

I'd welcome other people's thoughts on this, too.

Jonathan

On 19 Apr 2010, at 01:31, Paul A Norman wrote:

> Dear Stefan,
> 
> I was very encouraged to just read your last posting.
> 
> Thank you very much for your great effort there and especially with
> this last major improvement!
> 
> This should now reopen other possibialities which have been stalled.
> 
> The issue of different web engines handling of css and script has held
> me up for now, as some people (perhaps even Alain), depending on their
> browser  (and particualrly the version) could not even see the opening
> page on my first main big trial!
> 
> Gecko or WebKit would have been great, but TeXWorks now having a
> definite web browser engine (WebKit) to focuss on, will enable many
> things for different developers and users to progress really well.
> 
> When I first started profiling intergrating LaTeX help, Jonathan Kews
> correctly pointed out that the NASA module I was working with was
> potentially outdated.
> 
> Well, Karl Berry contacted me after viewing the original trial (that
> ginormous thing including many different aspects) and suggested using
> a replacement, for the NASA module, that he had taken over the
> maintainence of.  It endeavours to cover all the main LaTeX commands
> and environments, and a few other key aspects as well.
> He has invited any one to add and to and improve that module, so that
> could happen as well along the way.
> 
> So I am thinking with what you have done, I could try to intergrate (a
> cut down version of my first main trial) using Karl's html module to
> generate context sensative help for LaTeX commands with the TeXWorks
> editor, and give the oppertunity to the user to choose a command or
> environment, and return the necessary mark-up to the Tw editor.
> 
> Also I am looking to produce a summary of the often used packages in
> html form (which can also return any chosen command to the editor).
> This could dynamically point to the pdfs for deeper information for
> MiTeK and TeXLive using the texdoc command from script in the new
> webkit forms.
> 
> First, a few of us hope to help update the hyperref package
> documentation and Karl Berry and Heiko Oberdiek have established a new
> repository for the hyperref package and made an alpha docs space for
> work to be done in.  So a spin-off of that should provide better html
> help for at least hyperref at first.
> 
> Two quick question please,
> 
> 1.  When you write ">There are a few limitations (no file uploads, for
> example), ", is there a XMLHttpRequest(); type object available (used
> for Ajax type functions for reading in purposes)?
> 
>        (If not, no doubt a File reading workaround through TW
> functions will work well.)
> 
> 2. Can Tw Script return particualry the word, or line contents?
> 
>  I see line number as  __LINE__ , is there an array of lines
> corresponding to that number,
>  or a function to return  the line of text (and or word?) where the
> user has the cursor?
> 
>        (If not hopefully I can fashion it all from the TW.target.text
> property and the selection
>        functions and regular expressions, but thought I should see if
> the wheel has
>        been invented first!)
> 
> Many many thanks again, I am sure that along with everything else that
> Jonathan and you and every one else is doing, this QtWebkit
> integration will longterm prove to be a big step forward for Tw users!
> 
> I look forward to exploring it more fully soon!
> 
> Paul