This is an area where work has started in the last couple months. We often get asks about things that fall into the bucket of widget formatting through triggers. These include:
Resize widget in trigger
Change widget width, height in trigger
Enable/disable button in trigger
Make widget invisible in trigger
Move the X and Y position of widgets in triggers
The underlying limitation right now is making it easy (or even possible) for you to select the widget you want to do these formatting changes to:
I have 25 buttons, how do I know which one is which from a dropdown? What if they all have the same text on them?
You may have noticed in r230, that all widgets now show up in the step tree-
Coming very soon you will be able to rename and group these widgets. This visibility to all of the widgets in your app in one step is the first step to being able to identify what widget you want to impact.
So in short - We are just beginning the work to enable this sort of functionality, but the scope of this work is fairly large, so I wouldn’t expect to see this functionality full incorporated in 2022.
Thanks for bumping things you run into, this is how we drive focus on what we work on.
Pete
Hi Pete, Great to see tulip team so active in the community. Every time I have a question I lookup knowledge base and the community. Thats why I keep bumping old posts.
I did notice the step tree, and I love it!
The underlying limitation right now is making it easy (or even possible) for you to select the widget you want to do these formatting changes to:
In terms of the above, from my previous experience (Rockwell CCW, Beckhoff TwinCAT) the Widget name can be edited in the properties pane. (I hardly renamed anything, there was no need for it)
The hide or disable options were also a field in the properties where we can link a variable. See the screen shots below. I believe Codesys has the same approach, not sure about Siemens.
The reason I compare Tulip to PLC HMI is because I think there will be more automation engineers using Tulip than front end developers.
Actually out of interest I would like to know what the demography of Tulip 'developers". (if you are in liberty to discuss).
Thanks for this added context! We are always looking to duplicate the patterns seen in the other tools our customers are familiar with.
The typical app builder persona varies a whole lot, but to generalize-
Most app builders are engineers in a direct support role for manufacturing. Disproportionally new customers come from companies that either are new to production software, or have gone around and around and around with legacy systems, never getting the flexibility they need.
Common software experience: Excel (maybe a little visual basic), the microsoft suite, Email clients, some basic data visualization experience (but probably not sql), some programming of some sort (ladder logic, or something like python).
I came from a Tulip customer and fit this mold pretty much exactly. I constantly found places where I needed simple software solutions, but I didnt have the software background needed to make these tools (and make them stable enough for for 24/7 production), this is where Tulip slotted into my toolbelt.
Sometimes we can sneak smaller features into the release cycle, but getting this done, and getting it done right is something that is a bigger engineering ask.
Widget configuration in triggers is at least a few months of work for a sizable chunk of the engineering team that works on the app editor. These bigger asks have to follow the normal product roadmap process (and cant sneak to the front of the line, like quick wins). right now that roadmap doesn’t have this work starting in 2022, but we don’t have too much clarity past the end of the year.
In the meantime, this can absolutely be done with custom widgets:
If you are interested I can make an example of this sort of custom widget and share it here.
I threw together an example custom widget for this function-
This widget takes two inputs, a boolean for enabled or disabled, and the variable the user input will be written to. This is kinda bare bones and lacks some flexibility with the normal text widget (like font size, background color, etc) but that could quite easily be added to this structure.
This can be imported/edited/improved in your instance by going to account settings → Custom Widgets → Import. (must be on r230/LTS8 or later).
NOTE: I am not a software developer, and this widget hasn’t gone through the same level of code review a Tulip library plugin would, use this at your own risk customWidget-Disable Text Input.json (2.3 KB)
It took longer to make this post than it did this widget.
I was trying out custom widgets last night and ended up doing the same as you did. But I cheated. I used this example from the Tulip library https://tulip.co/library/apps/custom-text-input-widget-unit-test/
Now Im learning more about HTML, CSS and JS. Very exciting !!
I imported the custom widget, the custom widget works well . since we can control the disable/enable of textbox, we also can control the visibility as the same way via a boolean variable.
Thanks for your post!.
I read the article Custom Widgets Overview | Tulip Knowledge Base - Support for Building Operations Apps.
but unfortunately, the youtube website is blocked by China government. I am unable to watch the Example widget build video. I hope tulip team can demo or write an article how to build custom widget. such as disable text input custom widget.
Totally! It was as simple as changing the HTML to that of a single select. I used this webpage as an example:
The tricker part of this is making it act like a normal widget where you can pass it a list of options. To do this I:
Added a Options prop
Added a function that is called every time options changed
3.This function first cleared out the list of options
This function then added each option back.
Feel free to explore the code!
Note: This widget didn’t go through the code review process a normal Tulip Library Plugin would, use it at your own risk customWidget-Disable Single Select.json (3.1 KB)
Reading this post I think it is obvious that we can achieve a lot by using custom widgets, but the original suggestion by simple configuration to hide existing pre-delivered input widgets using simple boolean variables is still very much relevant.
To get around it we e.g. make buttons transparent and make sure the trigger does not fire if transparent. Or we duplicate the step to make specific fields greyed out and place a box on top so they cannot be used to give the end user the feeling of specific fields made irrelevant for the data entry when not required. Managing this without resorting to custom widgets would still make sense to me.
Please vote for this product suggestion if you agree
Totally agreed. This request has languished for some time because the right way to solve this is to enable a whole bunch of widget properties to be driven dynamically:
Focus
Disabled/Enabled
Hidden/Unhidden
Widget-specific properties, like labels
etc.
It’s a balancing act between a quick win and a long-term vision. We don’t want to build a point-solution without considering the longer-term gaps we want to fill. The underlying need for this sort of flexibility is something we are actively tracking, and a lot of thought is going into the right way to approach this problem.
To me this shows there is a strong wish, but some do not use the search before posting, so there are several threads, that could be closed and linked to this one or so…