[texworks] Script: Questions about the API

[Paul A Norman]

Thanks for that quick response Jonathan, (puts the breaks again on
what I was doing before - and potentially keeps me from wasting time
which is truly a great help.)

I can see that there is two things I have not explained well.

1. AsQTWebkit allows incredible interaction back from a webpage in a
Tw form, I mention this as I  have always been conceiving of
interactive help - responses back from the user (especially new ones)
to the editor as they read the help info and learn what to do. Even in
the form of step through "wizards".

2. I had hoped QTWebkit would let people leverage their current css,
DOM, and Js skills, bringing more people in to make  customisable
features.

Then there is the question of who are these new users on the Windows
system that Tw has a mission to win as was done for Mac previously?
What is their level of IT savyness - and as I mention below, are they
all even in a position to update their workstation(s) browser?  Admins
will allow things like Tw onto systems, especially when they come as
part of other distributions. We found some intersting results when we
looked at a higher level of LaTeX user as I explain below.

I can see what both of you, Bruno and Jonathan, are saying, and fully
appreciate what you are saying about disk size bloat Jonathan, may I
suggest that bloat may be less of a problem in terms of
delivery/installation than things were viewed a few years ago?

 I do not know how Qt handles memory - This is where I am coning from
- I am used to memory being fully utilised as forms are first shown,
with a smaller memory footprint during application startup and form
initialisation. As I say I have no knowledge of Qt handling of these
things and appreciate what you have pointed out.

But would it be more additional memory than additionally
calling/running their borwser any way?

Dear Bruno,

">Same for Windows using the default Windows Help Viewer *** if
there's any ***."

This is the problem - for MS Windows,  for a number of 'genreations'
now there has been nothing simple since they moved on from .chm (for
which there is no guaranteed future support/development as far as I
know).  .chm can be read on Linux (if set up) not sure about Mac (not
standard I guess), but the current Windows help system is alien to
other OS as far as I know.
Regettably .chm is time fixed at an earlier level of HTML not much
above 3.2 (with additional propriety MS features - non-standard) as
far as I can recall.

">> And (sorry if I'm sounding like a broken record) please please
keep TeXworks simple, don't let it turn into another Emacs or WinEdit
by the addition of feature after feature."

Perhaps this could be viewed as a uniquely useful feature in that it
opens up the door for creative customisation that does not itself
clutter up the plain interface - and does not bloat apparent
inherent/native features.

Jonathan, I do believe that this is the problem: ">Leveraging the
user's *normal* browser "

When we did the 'private' trial release of the earlier stand alone
help system - this was the big issue. I was using contemporary
standards of css, DOM, and coding.

However it turned out there is no "normlative browser" or what people
are using as their normal personal/workstation browsers was only a
cross over of HTML 3.2 to 4.0, while the actual current browsers
themselves are now offering significant portions of HTML 5.0

---We privately polled people from a wide LaTeX background with the
trial private release of the help system - LaTeX book writers, package
designers - however it was not a representative sample of the people
we are trying to encourage on the WIndows system to use TeXWorks and
LaTeX, but probably one which comprised people who we would consider
or expect to be more up with the play than the potential  target new
LaTeX users.

We learnt that many of those more advanced users are not updating
their browsers (some it is undoubtedly beyond their control, and
others for very good reasons no doubt), even IE6 is still being used
in significant enough numbers to create security and design problems
(hence the campaign to get people to dump it). But some MS Windows
people in many organisatoins have to use IE6 at thier work stations as
the IP administrators have coded whole intranets and backends around
browser embeded objects at the IE6 technology level.

As far as I know (allowing for the suggestion below) we have no way of
getting direct feedback from the OS browsers to Tw editor, in that I
have always been conceiving of interactive help - responses back from
the user (especially new users) to the editor as they read the help
info and see what to do, and then even sarwe stepped through "wizards"
if they wish.

It might be possible if Tw, under the network modules,  monitored
localhost on a specific port to listen for Ajax ( XMLHttpRequest(); )
requests from a browser which could then call a Js/Python/Lua script
with passed variables?

I had hoped QTWebkit would let people leverage their current css, DOM,
and Js skills, bringing more people in to make customisable features.

">so that Qt Designer can be used to create a .ui file defining the
interface (just like TW's own "native" windows and dialogs). "

Could we code that in Js/Python/Lua, or would we have to learn/use C/C++?

">a full-featured web browser that happens to be able to run TeX! :)"

What a great idea!

This may well be the killer point you raise Jonathan---

  Jonathan: ">as well as adding a major dependency that may be tricky
to maintain across all platforms and build environments"

Is the browser natively embeded (C wise) in QTWebkit or is it like a
Windows ActiveX control that relies on the whole specific browser
actually being installed on the OS?

Or in my ignorance of C type programming, am I missing something
relevent here (as I suspect)?

I'll might probaly still do an example of an intergratedd interface
based on Stefan's patch (if it is still available)  say for choosing
shown named colours, if you would like to see it :)

Paul

On 19 April 2010 14:03, Bruno Voisin <bvoisin at me.com> wrote:
> Le 19 avr. 2010 à 03:11, Jonathan Kew a écrit :
>
>> I'd welcome other people's thoughts on this, too.
>
> Ideally (IMHO) TW should use the OS facilities as much as possible:
>
> - Doc and help files open on OS X in Apple's Help Viewer, otherwise (if formats incompatible with this viewer) in the default PDF preview application for PDF files and in the default web browser for HTML files.
>
> - Same for Windows using the default Windows Help Viewer if there's any.
>
> - Same for Linux.
>
> And (sorry if I'm sounding like a broken record) please please keep TeXworks simple, don't let it turn into another Emacs or WinEdit by the addition of feature after feature.
>
> Bruno Voisin
>