enigma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] Lua API


From: Andreas Lochmann
Subject: Re: [Enigma-devel] Lua API
Date: Mon, 29 Oct 2007 23:34:47 +0100
User-agent: IceDove 1.5.0.14pre (X11/20071018)

Hi,

Ronald Lamprecht schrieb:
Is it neccessary to switch from "openclose" to "open_close" etc?

It is not necessary to switch. All namings of classes, attributes, messages and functions in the draft are preliminary and subject of common aggreement.

For all messages that toggle objects between two states like onoff, openclose,... we will introduce an additional common messages "toggle". This allows sending this most common message to groups mixed up of different objects.
We already have "trigger", which is used to toggle many objects ... ?

What does it mean to "toggle a fourswitch"?

When I listed all used messages and attributes a few weeks ago I noticed that we have a really mess concerning the messages names. And "trigger" is the worst case:

The message "trigger" is an internal message that occurs in pairs - with a raising and a trailing edge. It has an argument that describes the direction from which the trigger did take place. Currently the only "official" trigger source is the st-bolder (this may the reason for its name). Unfortunaly the target that has urgent need of the direction, the stoneimpulse, uses the inverted direction and due to a clear typo it pushes a bolder back instead of leaving it silent at its side.

Furtheron many authors of other objects did add a support for a trigger message because they thought it is a single message without argument that requests a toggle of the receivers state.

But we still have the "signal" that sets states and all the object specific messages like "onoff", "openclose",...

For this reason I try to separate the different usages. "trigger" as a message with raising and trailing edge, and "toggle" as a universal messages suited for the target-action paradigm that takes no argument and is a request to toggle to the receivers next state.

Thus "toggle" opens a closed door, closes an open door. It turns a mirror and a fourswitch.
Okay.

Particularly for the fourswitch, an "antitoggle" would be practical.
Or maybe allow a number for the second argument and use ("toggle", -1)
or ("toggle", 2 )?


[Using the old API]

Will it be possible to use old-API-libraries (with compatibility <= 1.0)
in new-API-levels (with compatibility 1.1) or vice versa?

Why is mixing the two APIs no good idea?

Greets,
Andreas






reply via email to

[Prev in Thread] Current Thread [Next in Thread]