On Mon, 8 Apr 2024 14:46:32 -0000 (UTC), Ben Collver wrote:

> On 2024-04-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> You’ve got FFmpeg in there, the universal multimedia “sonic
>> screwdriver”, that should already be able to do nearly all the
>> necessary conversions/encoding.
>
> I wanted to produce a video showing the tracker interface as it scrolled
> through the score while playing the song, using the same tracker that
> was used to compose the song.

I suspect it would have been less effort to just fake it.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 8 Apr 2024 13:31:33 -0000 (UTC), Rich wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> That is inherent in the nature of the problem it is trying to solve:
>>> automate an interface--the GUI--which was never designed for automatic
>>> operation. No matter how you slice and dice it, that kind of thing
>>> inherently turns out to be fiddly and fragile.
>>
>> But that part wasn't the problem. AutoHotKey included function calls to
>> do that, and once one found the function call to perform "step x" that
>> one wanted, it worked.
>
> In my experience, that is very much part of the problem. I have done this
> sort of thing in the past--thankfully, not lately.

Yes, that can be problematic.

> E.g. bring up a dialog box to enter a number. I have a template for the
> event sequence, to do the initial menu selection, then have my code insert
> the (variable) sequence of keystrokes for the number, then end with the
> sequence for clicking the OK button.
>
> Only if you do it a little too fast, the text field or the OK button might
> not actually be enabled yet, and so some part of the sequence gets ignored
> and the whole thing goes badly wrong. So you stick in a tenth-of-a-second
> delay somewhere, entirely through trial-and-error, until it seems to work.

None of which is AutoHotKey's fault. All of which is directly caused
by the GUI not ever having been intended to ever be automated in any
way.

> Then later on somebody reports that it sometimes fails in a different
> place. But of course it works for you. So you then have to try the
> sequence multiple times, until you see it fail that one time, and then you
> have to figure out why and come up with another tweak to the sequence to
> fix it.
>
> All this take programming skills--which ordinary users don’t have.

Yup. My complaint, however, was with the syntax irregularities of
the AutoHotKey script language. The actual language syntax looks like
it was designed by a group of drunken monkey's after a night of bar
hopping, with an LSD trip added at the end for good measure. No two
functions used similar calling conventions, and for those that required
some of the same parameters it looked like the language designer
intentionally randomized the order of the parameters for each function
call.

> So who are these macro-recorder thingies aimed at?

I suspect their aim might be twofold:

1) folks who want to use it to change keystrokes (i.e., make their
keyboard be Dovrak but their OS does not have a Dovrak layout); or

2) folks who literally just want to "record" a macro sequence, without
any conditionals and no error checking of any form.

The actual rest that provides a seemingly Turing complete language
looks to have been randomly bolted on using parts from plural
different bodies. It felt like a language that took the worst parts of
Perl, Javascript, Java, Python, C, COBOL, Ada, etc. and combined it all
into a new ugly monster.

> They seem designed to pretend that there is no programming involved
> in using them, but on the other hand it can take a lot of work to use
> them reliably. And so you end up with the worst of both worlds.

That indeed. Maybe their 'recording' part inserts delays equal to what
time it took the user to move/click through things, which would, for
the most part, create an appearance of working most of the time.

On Tue, 9 Apr 2024 00:59:10 -0000 (UTC), Rich wrote:

> None of which is AutoHotKey's fault.

My point exactly.

> All of which is directly caused by
> the GUI not ever having been intended to ever be automated in any way.

My point exactly.

> My complaint, however, was with the syntax irregularities of the
> AutoHotKey script language.

OK, so that looks weird as well. My double condolences. ;)

> Maybe their 'recording' part inserts delays equal to what
> time it took the user to move/click through things, which would, for the
> most part, create an appearance of working most of the time.

That may very well work, if you are repeating a set of GUI actions
exactly. But how often would you, for example, perform the same set of
edits on the same file? You will more likely want to repeat the actions on
a set of files, one after the other. And like it or not, that gets into
actual programming, with variables and loops and all the rest of it.

And this programming is trying to automate something (a GUI) which was
never designed to be automated.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:30 this Tuesday (GMT):
> On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday (GMT):
>>
>>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>>
>>>> The problem happens when there's no way to access the underlying
>>>> functions, or it requires bad workarounds like the GUI scripting.
>>>
>>> That kind of thing seems less common in the Open Source world. Perhaps
>>> because it is more likely to be seen as a bug and fixed.
>>
>> Of course, the opposite is usually more true. A lot of stuff is
>> terminal-only.
>
> Feel free to offer examples.

Installing things?
--
user <candycane> is generated from /dev/urandom

On Tue, 9 Apr 2024 15:10:10 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:30 this Tuesday (GMT):
>> On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday (GMT):
>>>
>>>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>>>
>>>>> The problem happens when there's no way to access the underlying
>>>>> functions, or it requires bad workarounds like the GUI scripting.
>>>>
>>>> That kind of thing seems less common in the Open Source world.
>>>> Perhaps because it is more likely to be seen as a bug and fixed.
>>>
>>> Of course, the opposite is usually more true. A lot of stuff is
>>> terminal-only.
>>
>> Feel free to offer examples.
>
> Installing things?

Scriptable.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 05:39 this Wednesday (GMT):
> On Tue, 9 Apr 2024 15:10:10 -0000 (UTC), candycanearter07 wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:30 this Tuesday (GMT):
>>> On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday (GMT):
>>>>
>>>>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>>>>
>>>>>> The problem happens when there's no way to access the underlying
>>>>>> functions, or it requires bad workarounds like the GUI scripting.
>>>>>
>>>>> That kind of thing seems less common in the Open Source world.
>>>>> Perhaps because it is more likely to be seen as a bug and fixed.
>>>>
>>>> Of course, the opposite is usually more true. A lot of stuff is
>>>> terminal-only.
>>>
>>> Feel free to offer examples.
>>
>> Installing things?
>
> Scriptable.

Yes? That was my point, that more options are available in the
terminal.
--
user <candycane> is generated from /dev/urandom

On Wed, 10 Apr 2024 14:40:05 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 05:39 this Wednesday
> (GMT):
>> On Tue, 9 Apr 2024 15:10:10 -0000 (UTC), candycanearter07 wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:30 this Tuesday
>>> (GMT):
>>>> On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:
>>>>
>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday
>>>>> (GMT):
>>>>>
>>>>>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>>>>>
>>>>>>> The problem happens when there's no way to access the underlying
>>>>>>> functions, or it requires bad workarounds like the GUI scripting.
>>>>>>
>>>>>> That kind of thing seems less common in the Open Source world.
>>>>>> Perhaps because it is more likely to be seen as a bug and fixed.
>>>>>
>>>>> Of course, the opposite is usually more true. A lot of stuff is
>>>>> terminal-only.
>>>>
>>>> Feel free to offer examples.
>>>
>>> Installing things?
>>
>> Scriptable.
>
> Yes? That was my point, that more options are available in the terminal.

No, you said “the opposite is usually more true”, in reply to my saying
that lack of scriptability is “more likely to be seen as a bug and fixed”.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 7 Apr 2024 16:51:22 -0000 (UTC), Rich wrote:
>
>> AutoHotKey is the most absymal "programming" languge ...
>
>That is inherent in the nature of the problem it is trying to solve:
>automate an interface--the GUI--which was never designed for automatic
>operation. No matter how you slice and dice it, that kind of thing
>inherently turns out to be fiddly and fragile.

Apple did a pretty good job of this with AppleScript by building the GUI
with automation in mind. That fell by the wayside long ago, however.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 03:07 this Thursday (GMT):
> On Wed, 10 Apr 2024 14:40:05 -0000 (UTC), candycanearter07 wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 05:39 this Wednesday
>> (GMT):
>>> On Tue, 9 Apr 2024 15:10:10 -0000 (UTC), candycanearter07 wrote:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:30 this Tuesday
>>>> (GMT):
>>>>> On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:
>>>>>
>>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday
>>>>>> (GMT):
>>>>>>
>>>>>>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>>>>>>
>>>>>>>> The problem happens when there's no way to access the underlying
>>>>>>>> functions, or it requires bad workarounds like the GUI scripting.
>>>>>>>
>>>>>>> That kind of thing seems less common in the Open Source world.
>>>>>>> Perhaps because it is more likely to be seen as a bug and fixed.
>>>>>>
>>>>>> Of course, the opposite is usually more true. A lot of stuff is
>>>>>> terminal-only.
>>>>>
>>>>> Feel free to offer examples.
>>>>
>>>> Installing things?
>>>
>>> Scriptable.
>>
>> Yes? That was my point, that more options are available in the terminal.
>
> No, you said “the opposite is usually more true”, in reply to my saying
> that lack of scriptability is “more likely to be seen as a bug and fixed”.

Oh, sorry.
--
user <candycane> is generated from /dev/urandom

On 11 Apr 2024 14:30:07 -0000, Scott Dorsey wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>On Sun, 7 Apr 2024 16:51:22 -0000 (UTC), Rich wrote:
>>
>>> AutoHotKey is the most absymal "programming" languge ...
>>
>>That is inherent in the nature of the problem it is trying to solve:
>>automate an interface--the GUI--which was never designed for automatic
>>operation. No matter how you slice and dice it, that kind of thing
>>inherently turns out to be fiddly and fragile.
>
> Apple did a pretty good job of this with AppleScript by building the GUI
> with automation in mind. That fell by the wayside long ago, however.

As someone who was a champion of AppleScript back in the day, made a point
of supporting it in my own apps, and even made a living creating scripts
for others, let me just say that, in retrospect, it was the solution to
the wrong problem.