As it was recently announced that overlays or non-supported GUI elements will be blocked from future versions of the URCap SDK (NOTICE: Supported and non-supported GUI elements in URCaps - #4) I’d like to propose a couple of featues that would be needed to port our already existing URCap’s to the new version and to continue working on new URCap’s, that are already in development. I’ve also provided links to other forum threads if they already proposed a similiar feature to highlight its need (I also marked those threads with a “Like”).
The available space of the Installation and Program Node window are rather limited, especially for complex systems with a lot of GUI elements. The following three feature requests address this problem and are highly needed for our URCap’s:
-
Toolbar/Tabs: Possibility to structure different GUI elements, so that different views are available to the user. The overall usability is improved and errors prevented by separating content that does not belong together and combine content that is needed to fulfill a task.
See below the AritMinds Essentials URCap, which uses four different tabs, which all implement a different functionality (manual: https://www.artiminds.com/wp-content/uploads/2017/04/ArtiMinds-Essentials-Manual-1.0.pdf).
Image: Two different tabs to display dynamic content to the user for different tasks.
This feature corresponds to this feature from the forum: [IMPLEMENTED] Tabbed panes like javax.swing.JTabbedPane -
Scrollbars: The amount of GUI elements to display is limited by the resolution of the teach-pendant of the UR robot and the fixed size of the Installation and Program Node window.
Image: Adding new settings to this Installation window is not possible without rearranging everything or making everything smaller (text becomes more difficult to read). The possibility to adding a scrollbar to the Installation and Program Node window can solve this problem.
So adding new GUI elements can be quite challenging, especially if usability should not be impaired.
-
Fullscreen overlays/panels: The two previously mentioned features already address the problem with the limited screen space. In addition I’d like to propose an additional feature request – fullscreen overlays. Fullscreen overlays would allow to display even more content and are useful if information or GUI elements need to be displayed, that do not belong to the Installation tab or Program Node contentwise. Panels or overlays, which can be displayed and hid again, can address this problem. The possibility to set the size of the overlay would be appreciated to address the needs of different URCaps.
Examples for the overlays would be the ArtiMinds Essentials URCap or URCap’s from Robotiq: https://www.artiminds.com/?page_id=2463
A similar feature request can be found here (see animated GIF of “hch”, how such a URCap window might look like): Runtime Interaction GUI elements - #3 by hch -
File dialogs/Access to file system: A file dialog to open or save a file on the UR robot. The ArtiMinds Essentials URcap uses a file dialog to store a recorded path as .urp program on the file system in the /programs folder. The Java API already supports file dialogs, that can be used to implement the above functionality. But the access to the file system (or just certain folders) should still be possible with newer versions of the URCap SDK.
-
Progress bars: The user should be able to see the made progress e.g. loading times. In the case of the ArtiMinds Essentials URCap, the URCap uses a popup window with a progress bar to display the loading time until a recoreded path has been send to the UR robot. Progress bars would also be useful to display the progress the user has made during a task, that consists of multiple steps.
-
Popup dialogs: Possibility to display popup dialogs to inform the user about important messages or errors without the need to run UR script code.
-
Changing the color of text and the background: Colors are always helpful to highlight content, displaying similarities, differences and errors. They also make the user interface more pleasant to the user and help to notice errors immediately.
-
Borders around GUI elements: Borders around a group of GUI elements allow to make it obvious to the user which control elements belong together to fulfill a task and which don’t. They’re especially usefull for complex user interfaces.
This feature was already requested in the URCaps forum: [IMPLEMENTED] Titled border like javax.swing.border.TitledBorder - #2 by jbm -
Playback of videos: New (HTML) element that allows to play videos on the teach-pendant of the robot, e.g. for promotional content or tutorials.
-
Possibility to set the condition if an user-input was valid or not: Currently the URCap SDK allows to set minimum and maximum values for number input fields. If the the user enters an invalid number, an error message is displayed. It would be useful if an error message and its condition could also be defined for input fields with textual content. The ArtiMinds Essentials URCap uses a text input field to enter the IP address of a force-torque sensor. The syntax of the entered IP address is checked, but a separate label is needed to show the user if the entered address is invalid. Maybe the URCap SDK can provice a method, the user can overwrite to define its own boolean condition?
This feature has been already requested in the URCaps forum (sort of): Validating user inputs - #4 by jubeira -
New helper methods for drop-down menus: A SelectDropDownList has methods to add (addItem()) and select an item (selectItem(), selectItemAtIndex()) and to remove all items (removeAllItems()). But there exist no methods to remove a single item or to get the item at a certain index. So changing the content of a drop-down menu during runtime is rather limited with the current version of the URCaps SDK. Without a get-method it’s not possible to iterate over the certain items of a drop-down list. Currently helper methods need to be implemented to have such functionality, e.g. a single item can be removed by removing all items and then adding all the items again except the item that should be removed. A get method can be implemented by calling the two existing methods selectItemAtIndex() and getSelectedItem().
The above functions are needed to adapt the content of a drop-down list dynamically during runtime. So it corresponds a bit to this feature request from the forum: [IMPLEMENTED] JList and JScrollPane - #2 by jbm
If someone else is interested in one of the above features, please feel free to leave a comment.