[texworks] WebKit (was: Script: Questions about the API)
Paul A Norman
paul.a.norman at gmail.com
Mon Apr 19 09:20:35 CEST 2010
Oh well its good you guys can work out what is best.
On 19 April 2010 17:46, Stefan Löffler <st.loeffler at gmail.com> wrote:
> 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
> 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
> 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.
More information about the texworks