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

[Paul A Norman]

Oh well its good you guys can work out what is best.

Paul

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