[texworks] Scripting: Any Windowed Application that Can Write to the Console

[Paul A Norman]

No worries Stefan,

Absolutley!

I am also keen on open-source coding and IDEs - Delphi which once used
to release a FREE fully functional entry level IDE (but no longer) is
apparently becoming exclussive through product packaging, development
cycle releasees and  other pricing policies - many of us have been
thorugh a major public dialogue over this with represntatives of the
current main stakeholder, and it looks like it will be as you describe
-- in its effect to base anything on it from now on, which was not the
case in the past. The current Delphi stakeholder is looking to
eventually service Mac and Linux - but comercially obviously, and
possibly with the same marketing strategy as many are finding a
detrerenet to continue using it now.

I was all fired up when your initial QTwebkit patch arrived out of the
blue. Seemed like the answer to a range of things for me.

So when that appeared to fall over for incorporation in Tw, Jonathan's
reasons in the Issues List were very sound, being all fired up I
trialed this alternative approach in Delphi but only for proof of
concept (ease of doing such a trial in Delphi- immeadite native
support for windowed environments from console) and it was not yet
clear how to do it in the open source alternative, but mentioned it
for Mac Linux and Win as it would actually be implemented if I were to
continue down that line, in Lazarus and FreePascal, opesource IDE and
Open Source implementation in all of those OSs (Mac Linux Win ... BSD
etc ), write cross-platform code once -- compile OS specifically.

The one benefit I kept thinking of in putting effort in through
Lazarus (or more particualry the console 'interface' - development
environment-independant in concept) was that the effort put in would
help any other opensource LaTeX editors as well, no matter what
environement they were written in.

A console connection is genreally the most vanilla and useful, being
no respector of developent environments in either direction, and not
being an OS dependant technology like COM. And only exchanging plain
text through a specifically opened and filtered pipe has a nice secure
/ security  feeling about it. And JSON, also plain text, even helps us
with transfering whole data structures to the Tw scripting back ends.
No hiddens possible if the Tw (or whatever) auxialary helper's code is
opensource!

My preference would obviously have been for a 'natively available' css
html DOM Js interface and js/python/lua Tw backend approach as this
really opens things up for an even greater (ginormous) range of folk
to contribute.  But can see that this understandibly may obviously
have overheads in various directions that Jonathan well views as too
costly.

You are correct in sying that Python may be a help here. I have looked
at a Qt for it in the past and that looked very promising as well.
Some one is even doing a Qt one for php - again a wider range of
people with skills.

And including Qtwebkit as a plugin idea, as was floated by someone,
sounds very sensible as an optional download "add-in".

Reading in the Issues area that the Qt ui generator is being
considered for direct use with Js and Tw objects, that also sounds
great -- even with the additional learning curve of some Qt specific
commands for people, and may provide as good an opening and  the same
oppertuniy for the same range of people who wish to put the effort in
to up-skill themselves, as a css html DOM Js approach would have.

 It feels appealing to me for some reason, and may be less complicated
for Tw development in the long run.

In that case, whjile still weighing up the merits of availablility of
functiuonality to other OpenSource LaTeX projects,  I would genreally
look to a Lazarus -> Tw console uptake, or simllar type approach,
primarily to accomplish things that may not be possible or available
in any other provided approach in Tw or Qt ui.

Thanks for directly expressing your concerns, I really admire what you
are saying - be assured I also want to avoid any elitist approaches,
or even splintering in this project!

Paul


On 22 April 2010 05:30, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> Am 2010-04-20 15:13, schrieb Paul A Norman:
>> Ive been looking at some of the recent html and like issues from a
>> different perspective.
>>
>> And came to the somewhat obvious  conclussion that with the work that
>> has already gone into providing scripting in Tw and the availablilty
>> of the system function, anything that could write to the console under
>> its OS could provide capturable text for Tw to us, and this may hep in
>> the current discussion.
>>
>> What I was not sure about esp for MS Windows was that a windowed
>> application (forms application)  could readily do this in a thread
>> safe manner and not hit name-space issues.
>>
>
> I would urge some caution here. As exciting as you solution may sound,
> one of the basic principles of Tw is that it's cross-platform. Scripting
> was also designed to work in an interpreted language, i.e. on all
> supported platforms. What you're proposing now is inherently
> system-dependent. While this can be done for all supported systems in
> principle (see the python and lua scripting plugins), it's a tremendous
> effort. I don't think that this can reasonably be achieved from outside
> the "official" codebase.
>
> Don't get me wrong: it's a great idea. I just want to avoid the creation
> of a two (or more) class society where a few people write some awesome
> scripts/apps that only work for a fraction of the users of Tw. Instead,
> there is still some work into bringing (more or less) full UI design
> capabilities to scripting, and there's still the other languages (I know
> that python can do an awesome lot of stuff - I suppose it's the same for
> lua). So my plead is to consider those before heading off writing Delphi
> applications.
>
> -Stefan
>