Is it possible to use custom-coded interaction triggers in the designer?

[Jesper Ronnholm]

I work in a team which is tasked with building an application template for a display platform that our clients can use. Our application logic is intended to mainly be founded on a CANopen stack and to use an OD (object dictionary) as mapping to displaying GUI elements in TouchGFX.

Is it possible to create custom interaction triggers for an application template to be used by our client in the TouchGFX Designer? If so, how can it be done?

[Martin KJELDSEN]

​Hi Jesper,

There is currently no way to do create custom, shareable and reuseable triggers. It's a great idea that I've already discussed with the designer team and I will add this feature to the backlog!

Best regards,

Martin

[Jesper Ronnholm]

Hi, thanks.

Our working solution this far has involved abusing the "Hardware button is clicked"-trigger to invoke some logic through inline widget code.

This approach has also exposed some difficulty in trying to prepare widget types with their own underlying mechanics - especially when you need to pass parameters from a data layer.

Being able to pre-define complex widget actions in code before using it in the designer would really improve the utility of platform-specific application templates.

If not already on your agenda, this would also be really useful!

[Martin KJELDSEN]

Thanks for the suggestion! It's definitely something we've discussed before, but may be more relevant now that TouchGFX is an ST product. I will add it to the existing ticket.

[Martin KJELDSEN]

@Jesper Rönnholm​, would it be possible for you to give me an exhaustive example of what you're after all the way from data layer all the way into the designer? Provide use cases, etc. That'd really help us writing a specification.

Thanks!

[Jesper Ronnholm]

Absolutely!

In essence, the two features that I'm thinking of are both about giving the screens and their widgets some pre-existing logic according to type, and the ability to feed arbitrary parameters into that logic.

TouchGFX has great support for taking simple inputs from the screen and passing it to the ScreenView class (both since it is possible to invoke virtual function calls, and executing inline code directly). However, since you need to know about all the widget names, their types, etc. to integrate them with an underlying app, this mostly only helps to interface GUI with existing code for single widgets.

When you're working with displays lacking touch-capabilities, you lose most of the widget-output that normally serve as stimuli. That's when the binding to specific widgets become very apparent, and you're forced to know exactly what's being put into the designer before even writing your code. The reason for this is that most of the widget logic seems to be encapsulated in the TouchGFX binaries, and so is not available for additional logic.

So, in summary, the feature that could be added here is the ability to create new widget types that would be exposed in the designer - where developers can tailor type-specific code attached to every widget of a given type. Then you can create bindings in advance, without having to know about specific widgets.

Also, taking that same idea (exposing new types in the designer) but applying it to interaction triggers as well would give a lot more flexibility in creating input from the underlying app. As stated earlier, the "Hardware button is pressed"-trigger is currently the only useful way of creating an event handler.

By allowing developers to define their own interaction triggers, it would make it easier to provide late binding in the development process, and allow for more flexibility in the designer.

Furthermore, the "handleKeyEvent"-trigger already provide an 8-bit int as parameter. It could be extended to cover other types. Combined with widget-type logic, it would allow much more of the work to be done in the designer.

One example I would imagine of the above could then be the ability to create a widget with predefined functions that take the parameter of an associated interaction trigger. Say, for instance, widget A taking a boolean from interaction B to execute a method C.

EDIT: All the widget logic may not necessarily be enclosed in binaries, but the point being that they are hard to modify or extend.

[Jesper Ronnholm]

Ideally, I also think that in addition to the idea explained above, the described features should naturally integrate with Application Templates, so as to be reusable in different projects with a common hardware platform.