This issue tracker is closed. Please visit UPPAAL issue tracker at Github instead.

Bug 379

Summary: textual editing of templates?
Product: UPPAAL Reporter: Judi Romijn <jromijn>
Component: GUIAssignee: Gerd Behrmann <behrmann>
Status: ASSIGNED ---    
Severity: enhancement    
Priority: P2    
Version: 4.0.3   
Hardware: PC   
OS: Linux   
Architecture:

Description Judi Romijn 2006-12-15 14:05:14 CET 
I must say, the graphical user interface is very nice. It could have some more features, but I'll post a separate enhancement request for that.

But in some cases, I just want to paste the same text into 10 or more transitions as synchronisation label, or invariants into many locations, etc. I would very much like to be able to do some textual editing of my templates as well. Since the .ta format is not supported anymore, this would boil down to exiting the .xml files. Now that is a bit too low level for me...

So could we have some textual editing facility for the templates? Like, say, a separate window that lists all transitions (resp locations) with their attributes in the same style as a single transition editing window, and you just navigate through it with mouse or TAB button. That would be really neat!
Comment 1 Gerd Behrmann 2006-12-15 14:15:28 CET 
First a little correction: The TA format is still supported, although the proper file ending is called .xta (extended TA, because it supports templates). So you can achieve what you want by saving in the xta format (simply use the .xta ending when specifying the file name), editing the file and loading it back into Uppaal. Graphical information will be stored in an UGI file, so even your layout will be preserved.


That being said, we have previously considered to have alternative views of the automaton. Some tools provide a matrix organization of the automaton, which - at least for relative small automata (less than say 20-25 locations) - would be practical. We have also considered providing the extended TA version in an extra tab alongside the graphical representation.

Both approaches would be fine, however I cannot promise if and when any is going to be implemented.