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

[Paul A Norman]

HI,

On 19 April 2010 17:46, Stefan Löffler <st.loeffler at gmail.com> wrote:
> 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...

I think bicbw there are three main engines Trident - IE, Gecko -
Mozilla/Fiorefox, and WebKit - Google Chrome/Safari


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

You may have put up just about all that is needed at mo.
Forms can have hidden inputs which the QTWebkit forms Js can control
on user interaction.
And areas can be displyed/ not displayed creating the illusion of a
static wizard.

Can the data = TW.webForm( html [, parent [, title [, width, height ] ] ] )

Be called consequitively from script? I assume there would be no
problem with that?

">form (which blocks until the user clicks  "submit" and then returns the data

Would do it all.

Any way I'll wait from looking further at it  until it is all sorted out.

Paul






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

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


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