Il 05/05/2011 22:40, venom00 ha scritto:
My idea was to issue commands to LyX via LFUNs, which are
quite stable, even because they're associated with
customizable shortcuts. I think this is a very uninvasive approach.
For the language I prefer Python because _a lot_ of people
uses it and I think this is fundamental if we want to hope in
third party cooperation.
I had a similar idea to record/replay such LFUNs series,
especially for reproducing bug it could be useful.
Sure, scripting and macro are strictly related. Record a macro would be very
simple as each user interaction with LyX goes through a LyX user command. We
need several new LFUNs to have a useful and complete scripting envinronment but
I think that's the way to follow.
I think I have quite an uncommon opinion (among LyX developers) about
what LFUNs are causing (perhaps as a side effect) in the LyX code.
Basically, many classes use this machinery to invoke operations, with
the result that sometimes the class does not get a properly designed
interface that users of that class can use. You may say "you have the
LFUN interface", however it's not a "binary interface" (it involves
stringifying/parsing of the arguments), and it has no way to return
anything whatsoever (except for a boolean, maybe).
I find recurrently myself in searching how to do something with an
object, then I follow the LFUN path that achieves a similar/related
effect, then I see there's no method call to do that, but the LFUN is at
the same time tied to a specific GUI interaction, so it's just more
complex that what I need. Normally, I copy some code from the LFUN
implementation in other parts of the code, because I don't fell
comfortable in breaking the "no-interface" pattern currently used in
LyX. But I know copying code is bad as well.
I can still remember the time when I proposed first the Advanced F&R
patch: it used no LFUNs, but simply straightforward calls from the
dialog to the objects I needed. Somebody told me "in LyX, GUI<->model
interactions happen through this command pattern, so please use it", and
I did. However, just digging into the past e-mail archive, you can
easily find:
-) all the places where this LFUN creates me problem due to its inherent
limitations;
-) my vein attempts to suggest a kind of "binary" LFUN interface, as
opposed to the string-based current one (you can keep some string-based
serialization of arguments, for when the user uses "[A-x]whatever", but
I see the stringification/parsing in the software components when
talking to each other that resembles me some XML-RPC "bloatware" (but
who cares on nowadays CPUs, right ?)
-) a few vein attempts to introduce LFUN return values.
As I said, probably just a side effect, and LFUNs (and string-based
dispatching) and are certainly useful. However, let's pay attention when
we say that we can do everything by LFUNs.
Comments are welcome of course.
T.
