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

[Paul A Norman]

Dear Srefan,

I am not wnating to push a particualr line here, but hope that the
following information may be useful -- when it is useful, not only in
this project but for others.

I see a pool of already created components avialble in a windowed
environment for helper or auxilary dialogues thorugh the console
capture mechanism that most things support.

And its not just cross-platform, its a cross-compiler technology.

On 22 April 2010 18:05, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> Am 2010-04-22 04:29, schrieb Paul A Norman:
>> 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.
>>
>
> I didn't intend to demotivate anyone, and I'm sure Jonathan felt the
> same way. Getting more active contributers to Tw is a very good things
> and different opinions/points of view generally broaden our own
> horizons. Nevertheless, some words of caution are sometimes in order.
>

Yes its good you can know now more fully what I was actually looking at.

>> 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.
>>
>
> Compiling OS specifically is a noble goal - it's just not as easy as it
> sounds. First of all, you need access to all OSs. Secondly, different
> versions of the same OS may require separate compilations (think of
> Linux and its dozens of distributions - all of which have subtle
> differences which often makes using an application from one distribution
> on another difficult to near-impossible (without recompilation)).
>

Have a look at Lazarus and particualrly the Typhon release actually
do,  this has been amazingly addressed very well.

I can see now that we have been on differnt wavelengths, and I can
understand what you are saying.  I may be introducing something
different here that has a better basis than might be at first
apparent.

Lazarus and Typhon are cross-compiler capible, that means you do not
even need the other OS present to do a build when nusing standard or
stricly prepared components!

I know that may sounnd strange to many peopole from a normal model of
development expectation, but it is important.

I think Mac is still being brought up to speed but Windows, Linux et
al are already well supported.

> The Tw codebase itself will hopefully (one day) be compiled by dozens of
> different maintainers for all the OSs and versions that are out there
> (as a matter of fact, this already happens through the TL maintainers
> and some others to a degree). As long as your applications are provided
> separately, people will not necessarily maintain your scripts/apps, too.
> So you'd have to do that yourself.
>
> I don't say it's impossible, it's just a lot of work - that may be
> avoidable if you are able to implement the same thing with an
> interpreted (scripting) language supported by Tw.
>

There is still the need of windowed dialogues, and components that are
robust enough.
For example, sopohisticated colour setting dialogues are well
supported in windowed environments while not so well represented in
interpreted languages afaik. Why re-invent the wheel when with a
little lateral thinking it is already available opensource?

>> 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.
>>
>
> Agreed. On the other hand, python scripts for example can be converted
> to executables. I've never done this myself before, but maybe Alain has
> gained some experience (I think he asked me about it some time ago).
>

There is still the advantage of extra componets/fetures/interfaces
available in other opensource windowed dialogues. (I am again thinking
of what Lazarus aqnd like have achieved).

>> 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!
>>
>
> I don't want to sound too pessimistic, but there are some problems with
> the console as well. In particular, there are encoding issues. Some
> consoles (I believe in particular on Windows?) use the system's local
> encoding - which means that some uncommon symbols (Russian, Chinese, ...
> unless you have the corresponding version of Windows) may cause garbage
> output. Again, this won't be a big issue in most cases, but I think it's
> worth mentioning.
>

It happens on the fly - would only be apparent if the user wrote a
dialog thinking only of thier own local encoding - in that case I just
expect as a matter of normal course  to have to have to sort something
out coding wise on a dialogue if it was composed say in cryllic and I
feel it is good enough that I want to use it in UK English. Its just
an overhead in getting it useful to my locale.

>> 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.
>>
>
> Indeed (hopefully). AFAIK, Jonathan is currently working on combining
> his own code changes and my patch - so this may come in the near future.
> There will still be a couple of limitations, but for basic user
> interface issues this should provide all you need.
>

Sounds encouraging!

>> 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.
>>
>
> By all means. I'd still suggest looking at interpreted languages (lua,
> python, or suggest another one for inclusion in Tw ;)) before using one
> that needs compilation - but that's your decision, of course.
>

I absolutley appreciate what you are saying and also know it may be
possibly worth  seeing what the Lazarus and Typhon teams among others
have achieved which may add a few extra arrows to everyone quivers!

> -Stefan
>