Event System

[birkelbach]

Hey guys. What do you think about this little feature...

events

What it boils down to is a way to send global signals in the program with strings instead of having to program them into a module (i.e. hooks) or eval() code like the menu module does. I needed a global event dispatching system for the EGT monitor for setting leaning modes and sending commands to normalize and reset, etc. I worked up a few methods and this is where I am so far. The nice thing about using the strings is now we can let the user setup key bindings with configuration like this...

[Keys] A = Show Prev Screen S = Show Next Screen P = Show Screen, PFD E = Show Screen, EMS M = Set Airspeed Mode, TAS ...

It would also let us replace...

"self.myparent.change_asd_mode_event (QEvent(QEvent.ActionAdded))"

... in the menu configuration with...

"Set Airspeed Mode, Next"

...or something similar.

What do y'all think? It still needs some work on how it's imported and I still need to figure out how to handle the key bindings but this is the direction that I'm headed. This pretty much replaces the "hooks" module and I'll probably recommend that we delete that unless you guys can think of a reason to keep it.

[makerplane-jnicol]

I guess it would allow folks to use programmable usb keyboard interfaces like this one?:https://www.ultimarc.com/ipac1.htmlThis kind of thing has been used for flight simulators to bind switches and buttons to key presses.Not sure if this is where you were headed, or if it is something that you would use through pi GPIO?On Jan 31, 2019 9:49 PM, Phil Birkelbach notifications@github.com wrote:Hey guys. What do you think about this little feature... events What it boils down to is a way to send global signals in the program with strings instead of having to program them into a module (i.e. hooks) or eval() code like the menu module does. I needed a global event dispatching system for the EGT monitor for setting leaning modes and sending commands to normalize and reset, etc. I worked up a few methods and this is where I am so far. The nice thing about using the strings is now we can let the user setup key bindings with configuration like this... [Keys] A = Show Prev Screen S = Show Next Screen P = Show Screen, PFD E = Show Screen, EMS M = Set Airspeed Mode, TAS ... It would also let us replace... "self.myparent.change_asd_mode_event (QEvent(QEvent.ActionAdded))" ... in the menu configuration with... "Set Airspeed Mode, Next" ...or something similar. What do y'all think? It still needs some work on how it's imported and I still need to figure out how to handle the key bindings but this is the direction that I'm headed. This pretty much replaces the "hooks" module and I'll probably recommend that we delete that unless you guys can think of a reason to keep it.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[birkelbach]

It could be either. It could also be fired from external data. The main thing about this event module is not so much about "why" to fire the events but "how." All it really does at this point is convert strings to PyQt Signals. This just seems easier from a configuration standpoint.

[spaschke64]

That board looks like an easy way to hook up a rotary encoder

Stephen Paschke 720-236-8717

On Jan 31, 2019, at 2:21 PM, John Nicol notifications@github.com wrote:

I guess it would allow folks to use programmable usb keyboard interfaces like this one?:https://www.ultimarc.com/ipac1.htmlThis kind of thing has been used for flight simulators to bind switches and buttons to key presses.Not sure if this is where you were headed, or if it is something that you would use through pi GPIO?On Jan 31, 2019 9:49 PM, Phil Birkelbach notifications@github.com wrote:Hey guys. What do you think about this little feature... events What it boils down to is a way to send global signals in the program with strings instead of having to program them into a module (i.e. hooks) or eval() code like the menu module does. I needed a global event dispatching system for the EGT monitor for setting leaning modes and sending commands to normalize and reset, etc. I worked up a few methods and this is where I am so far. The nice thing about using the strings is now we can let the user setup key bindings with configuration like this... [Keys] A = Show Prev Screen S = Show Next Screen P = Show Screen, PFD E = Show Screen, EMS M = Set Airspeed Mode, TAS ... It would also let us replace... "self.myparent.change_asd_mode_event (QEvent(QEvent.ActionAdded))" ... in the menu configuration with... "Set Airspeed Mode, Next" ...or something similar. What do y'all think? It still needs some work on how it's imported and I still need to figure out how to handle the key bindings but this is the direction that I'm headed. This pretty much replaces the "hooks" module and I'll probably recommend that we delete that unless you guys can think of a reason to keep it.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[makerplane-jnicol]

Hey Steve, welcome.These boards are also used for mame cabinets as well as simulators, so you can hook up a lot of things.  If Phil implements key bindings then I guess it will open up a lot of different hardware solutions like this if they are not implemented directly in an SBC like a raspberry pi.JohnOn Feb 1, 2019 1:13 AM, Steve Paschke notifications@github.com wrote:That board looks like an easy way to hook up a rotary encoder

Stephen Paschke

720-236-8717

On Jan 31, 2019, at 2:21 PM, John Nicol notifications@github.com wrote:

I guess it would allow folks to use programmable usb keyboard interfaces like this one?:https://www.ultimarc.com/ipac1.htmlThis kind of thing has been used for flight simulators to bind switches and buttons to key presses.Not sure if this is where you were headed, or if it is something that you would use through pi GPIO?On Jan 31, 2019 9:49 PM, Phil Birkelbach notifications@github.com wrote:Hey guys. What do you think about this little feature...

events

What it boils down to is a way to send global signals in the program with strings instead of having to program them into a module (i.e. hooks) or eval() code like the menu module does. I needed a global event dispatching system for the EGT monitor for setting leaning modes and sending commands to normalize and reset, etc. I worked up a few methods and this is where I am so far. The nice thing about using the strings is now we can let the user setup key bindings with configuration like this...

[Keys]

A = Show Prev Screen

S = Show Next Screen

P = Show Screen, PFD

E = Show Screen, EMS

M = Set Airspeed Mode, TAS

...

It would also let us replace...

"self.myparent.change_asd_mode_event (QEvent(QEvent.ActionAdded))"

... in the menu configuration with...

"Set Airspeed Mode, Next"

...or something similar.

What do y'all think? It still needs some work on how it's imported and I still need to figure out how to handle the key bindings but this is the direction that I'm headed. This pretty much replaces the "hooks" module and I'll probably recommend that we delete that unless you guys can think of a reason to keep it.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

—

You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or mute the thread.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

[birkelbach]

I did some more work on this. I added keybindings and juggled the file structure around a little bit. Instead of 'events' I called it 'hmi' for Human Machine Interface. I moved Garrett's menu module into the hmi package, and I'm planning to add a feature where the actions can be triggered on database value changes as well. Then external buttons can fire actions as well. Current code is at... hmi branch. Imagine being able to manipulate the menu of your EFIS with buttons on your stick grip.

[makerplane-jnicol]

Hey Phil, One more thought is to add in the ability for a key to swap display screens from one pyEfis to another. Should I put this in as a new Feature Request?

[birkelbach]

Explain this to me? Why are there more than one pyEfis'?

[neil-d95]

?On February 6, 2019 at 11:04 AM Phil Birkelbach notifications@github.com wrote: Explain this to me? Why are there more than one pyEfis'?—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[makerplane-jnicol]

So if you had two physical displays set up in the cockpit. One could be the PFD and the other the moving map. Hit the 'swap display' button and it swaps the map to the pfd and vice versa. It would probably mean setting up one as the primary display.

[birkelbach]

Oh Okay. I don't think it needs to be two pyEfis's running just one that puts different screens on different displays. Switching the two would be easy enough. I think this is a feature that would come naturally when we get around to deciding how to support multiple displays.

[birkelbach]

Fixed by #62