Animation XML documentation?

I’ve been looking over the animation examples XML on github, and I’m able to figure out most of it, but was wanting to know if you have the syntax documented for how the XML is parsed?

Example, under the only option in the examples is equal, but other options, Not equal, equal or greater than, less than, etc, are not shown in the examples. Additionally the variables, the only example is “Dummy variable 1”, but what about different Target ID’s? Can you use the targetId value or does it need to be the name listed inside Realdash? I’m assuming tolerance= is what the value needs to be to fire the trigger, and reset= and cooldown= would be when the trigger can reset and how long the cooldown is.

A bit more documentation would be very helpful with the animation XML.

Additionally I would assume that using the animation XML can also be a way to create all of the trigger and actions that you can from inside the GUI? However one thing that doesn’t make a lot of sense with the way the XML is laid out is that the actions under trigger is pointing to the animations above? Are there other actions that can be laid out in the XML?

Only morph (change size/position) and fade actions can be defined in XML. The morph actions do not appear in RealDash actions list as there is no way to edit them anyways.

For a long time we have been dreaming on having an animation editor in RealDash, making this XML unnecessary as its plainly obvious that is was developed for our internal use only. It is a big task though, hope to find time to develop it at some point.

What about the other variables in the xml?

I updated the example XML files for more information.

<!-- name="name of the trigger" -->
<!-- condition="larger(default)|smaller|equal" -->
<!-- variable="name of the variable, only dummy variables and dummy timers are supported" -->
<!-- tolerance="value to trigger on" for example, if condition="smaller" and tolerance="1", trigger will fire if variable is less than 1  -->
<!-- reset="value to reset (allow trigger to fire again)" this is an inverse of condition, trigger is reset if variable is larger than 1 -->
<!-- cooldown="seconds until this trigger can fire again" -->

Hope this helps a bit.

Something that might be a useful feature to have, is to allow triggers and actions to be created with the XML. While using the GUI works, it’s a bit clunky to use sometimes. Doing it through the XML would allow a way to include multiple gauges and such to be added to a particular action and trigger easier.

Yes, but that is exactly the opposite that we would like to move on this, best solution would be to get rid of this animation XML completely and have an animation editor in RealDash.

To improve, I’d like to hear how the Triggers->Actions GUI could be improved to make it more convenient to use?

One thing that I could see to make it better would be a way to select multiple gauges for 1 action instead of having to create an action with the same name.

Past that, I’m thinking more interface issues. Things like it feels like RealDash is designed to be more touch oriented and not as much keyboard/mouse. Additionally, the application I’m working on is a 1280x390 screen which introduces other problems with the GUI. I’m mainly trying to think about being able to do a dash design as quickly and efficiently as possible. Sometimes the UI (top, bottom and side menu bars) get in the way. While they can be closed and moved, opening and closing them multiple times isn’t efficient.

This is where I think being able to create an xml to import could help to make it more efficient. Either that OR create a desktop centric application that can do the dashboard animations while also being able to import the graphics elements to create the dash file, then import it onto the application. A dash editor that mirrors photoshop in its tools and usability.

That’s where I think having an xml drop in solution might be a good solution as an interim fix if you didn’t want to have a desktop application for dash creation and design. It would give the speed of creating the triggers and actions and even an easy way if following what all gauges are part of what actions and what actions are part of what triggers.

Past that a dedicated desktop application to do dashboard designed, like a photoshop type application, that assets can be imported, placed, modified, to create a full .rd file that can then be put into the app would be the absolute best way of doing it, but I also understand that is a lot more work.

I could see if you did the separate application that you could limit it to manufacture licenses only as the average RealDash user might not have a need for that, but someone doing many designs for different platforms does need a way to quickly make designs.

Try Ctrl+W

I’m not going to develop another photoshop. I’m sure you realize its not possible without millions of dollars and dozens- if not hundreds of developers.

It is true that RealDash has grown out of its original mobile app mold, but I’d hope you would have reasonable suggestions on how to improve it.

There is a Finnish company ‘Rightware’, and ‘QT Automotive’ which offers exactly what you are looking for. Their licensing is way deeper though. It would not make sense for us to develop similar systems and trying to compete with them. Our niche is Dashboards for everyone for cheap.

I’m not necessarily talking about developing a full photoshop application, I’m meaning something that has the utility of photoshop in the aspect that you can click the different gauges and manipulate the different options of the gauge with a right click, or a menu over on the side of the workspace to change the different options. I don’t think it would be well suited for RealDash to do any graphics design work, just an import of the graphics, being able to drag and drop them in locations on the workspace, and be able to set their input targets, colors, etc, then also be able to create the triggers and actions from a desktop type environment vs a mobile environment.

This is where I said that using an import for an XML might be a good stopgap to allow the speed of creating triggers and actions that a desktop can give, without need to create a completely different application. The idea that I’m thinking for this would be to follow the same type of format that you have with the animation XML (actually it could be the same engine), go into RealDash, create the gauge and name it appropriately, put it in the location that it needs to be, then create an XML with the action that you want to have happen, then a trigger section. Now I do understand that not all actions would be able to be done with XML, such as playing sound, or playing a video as there isn’t a gauge item for those, but it would be possible to follow the rest of the XML format for hiding, showing, fading gauges quickly through the XML.

The biggest issue, and I don’t know right off the top of my head how to fix it with the current setup and design except what I mentioned above, is that it is a multiple click process to create triggers and actions in a mobile centric environment that it’s impossible to reference any other settings without exiting what you’re in. For example, I have a group of gauges that I want to hide based on a trigger. It’s about 30 items. For the hide action to work, I have to create an action for every one of them, and either name them the same thing, so I can have 1 action in the trigger, or I have to add all 3 of them to the trigger. When creating 30 actions that are named the same thing, it’s easy to loose which gauge I’ve already added and which one I haven’t. I tried to use containers and use 1 action for that container (which would cut down on the complexity), but there appears to be a bug in either what I’m doing or a bug in Realdash that is making it where they don’t show up properly.

Doing this under an XML file would be much easier than the GUI in this aspect.

Have you considered making a plug-in for figma?

That’s not a bad idea to use some sort of software that would allow plugins to design and export the .rd files if they can do that with plugins.

Over the years we have though of a lot of different importers. At some point we were prototyping with Adobe XD import, but it was too complicated to integrate into RealDash. If I ever find some spare time I can take a look at what kind of plug-in interface Figma supports.