[texworks] WebKit (was: Script: Questions about the API)

[Stefan Löffler]

Hi,

time for me to chime in, too. I didn't realize that the footprint of
WebKit was as large as it is (I do dynamically linked builds). I didn't
see any significant memory problem, but then again I only used small
test cases. But a doubling of the size of the executable is really
something we should not do (lightly, anyway). As it looks to me, WebKit
essentially embeds a Mozilla-type browser...

Am 2010-04-19 05:51, schrieb Paul A Norman:
> 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".
>   

Hm, not exactly (at least not in my patch). In principle, it is possible
of course to intercept just about every click of the user, but passing
this back to the script is quite difficult. So with the patch I posted,
you can only either show some document (without getting any further
notifications) or show a form (which blocks until the user clicks
"submit" and then returns the data). This is not useful for wizards or
any kind of sophisticated interaction, yet.

> 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, 

If Tw comes with a browser, admins should treat it as a browser - with
all the security issues involved. They probably wouldn't know that, but
that doesn't increase security. People tend to use whatever works
(including using MS Word as file browser, because it's just so simple to
delete files from the "Open" dialog; I've seen it), without worrying too
much about security. So we have to.

> 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).

AFAIK, there is a Qt help system (which is also based on html). I have
no experience with it, so I don't know how much additional dependencies
it pulls in. But from the first looks, it uses either an external app
(Qt Assistant) or internal GUI elements, so it shouldn't be too big. So
this may be worth investigating (for displaying conventional help files,
i.e. no interactive help).

> ">> 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.
>   

Maybe we could use WebKit in some form of plugin? This is just an idea,
I haven't thought this through from a feasibility POV. But it would keep
the 'bloat' in the plugin, but still provide the functionality - should
the user choose to install it.

> 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.
>   

There is currently no possibility to get direct feedback from webkit,
either (other than retrieving some form data from a window that is then
closed).
With Jonathan's idea of QUILoader, wizards could theoretically be
constructed in QtDesigner with the normal Tw "look&feel". But in any
case, there are still a few obstacles to overcome before something like
this works (keywords are signal/slot and asynchronous script execution).

> 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?
>   

Same problem as above, and I'm not sure if I want to give Tw specific
ports to monitor just yet. This is always a huge endeavor with many
potential security risks, and it's quite an advanced feature where there
are still a couple of basic ones unresolved (project support, print,
parsing the command line, etc.). So this may be a dream for the future,
but I think not something that will realistically be implemented soon.

> ">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++?
>   

The idea would be to expose this to scripts. So you could do the
interface in Qt Designer (a graphical UI design application), distribute
the .ui file with your script, and just call it from the script.

>   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?
>   

As I mentioned above, I believe it's a mozilla-type browser fully embedded.

-Stefan