Feedback on OdfEdit v2.3

[eturpault]

Comment of @oleg68 in this post GrandOrgue/grandorgue#1162 (comment)
@eturpault , thank you for the new version 2.3. Now I'm able to make the Erfurt organ playable. I added Front and Rear channels to their stops and it works. Great!

Then I tried to add more Windchests Distant and Rear and to move all ranks from existing windchests ranks there. It is not so easy as I wanted. Some notes:

1. At first, desellecting in the Parents window is not so intuitive. I found it after lots of other attempts to do it.
2. The main issue: after changing a windchest of one rank, the old windchest is shut. For moving other ranks I have to remember, what windchest I moved the last rank from and to clik on it for opening. Leaving the old parent open would be high desirable.
3. For moving lots of chld oblects between parents, it would be nice to have a capability to select several ranks in the same time and drag-and-drop them to a new parent with mouse. Is it possible to implement?
4. The Delete button for parents deletes the whole parent instead of detaching this object from the parent. This behavior is not obvious and is quite dangerous. I think it would be better to disable the Delete button for parents at all.

Another useful features to have:

1. Capability of chouse the encoding among ISO-8859-1 and UTF8 for save, including capability to changing for existing ODF.
2. Renumbering the stops and other objects in the manual. Because the three digits of a global stop number usually are the first digit is the manual and two other digits are the number in the manual, the global stop numbers should be changed also. The mouse drag-and-drop interface would be intuitive.
3. Saving the settings across restatts, including the directory where the last ODF was open.
4. And, of cause, the capability of extension the compass would be very interesting (ex. from 56 keys to 61). Don't forget to add Pipe999Tuning and Pipe999Gain in this case.
5. Supporting sample-based tremulants. It is not so difficult in GrandOrgue. I'd add the IsTremulant key for the rank level, but @larspalo would object to this.

[eturpault]

@oleg68, thanks for the interresting feedbacks and suggestions.
Here are my comments :

1. At first, desellecting in the Parents window is not so intuitive. I found it after lots of other attempts to do it.
   ==> once it is understood I think that it is the most natural way to deselect a parent in the parents list, I don't see how to do better. I will change the message in the pop-up window to say "Select/unselect parent(s) of ...", the same for the children list.
2. The main issue: after changing a windchest of one rank, the old windchest is shut. For moving other ranks I have to remember, what windchest I moved the last rank from and to clik on it for opening. Leaving the old parent open would be high desirable.
   ==> ok I will improve this, memorizing which nodes of the objects tree are opened before to update the tree
3. For moving lots of child objects between parents, it would be nice to have a capability to select several ranks in the same time and drag-and-drop them to a new parent with mouse. Is it possible to implement?
   ==> good challenge, I will see if it can be implemented with the GUI framework that I use (tkinter)
4. The Delete button for parents deletes the whole parent instead of detaching this object from the parent. This behavior is not obvious and is quite dangerous. I think it would be better to disable the Delete button for parents at all.
   ==> to detach an object from its parents or children the Parent or Children button must be used. But you are right it is dangerous to delete an object which has children, they become orphan. I will add a message popup if the user wants to delete an object which has one child or more, to inform him that it is not possible while the object has child(ren)

About suggested additional features :

1. Capability of choose the encoding among ISO-8859-1 and UTF8 for save, including capability to changing for existing ODF.
   ==> ok I will add an option in the menu to permit this choice
2. Renumbering the stops and other objects in the manual. Because the three digits of a global stop number usually are the first digit is the manual and two other digits are the number in the manual, the global stop numbers should be changed also. The mouse drag-and-drop interface would be intuitive.
   ==> good idea, I add this to my "to do" list, it will require some work to implement
3. Saving the settings across restarts, including the directory where the last ODF was open.
   ==> I wanted to add this one day, your request confirms that it is required, I will do it
4. And, of cause, the capability of extension the compass would be very interesting (ex. from 56 keys to 61). Don't forget to add Pipe999Tuning and Pipe999Gain in this case.
   ==> I intend to use the attribute Pipe999PitchTuning to retune pipes of a rank for adding upper pipes in the same rank (and the other defined attributes of each pipe like attacks/releases). Which value should be set to Pipe999Gain according to you in case of compass extension ?
5. Supporting sample-based tremulants. It is not so difficult in GrandOrgue. I'd add the IsTremulant key for the rank level, but @larspalo would object to this.
   ==> in HW sample sets that I know, the sample-based tremmed ranks are activated by conditional switches, I have to implement such switches, it will be usefull for other features as well (like conditional couplers).

[oleg68]

5. in HW sample sets that I know, the sample-based tremmed ranks are activated by conditional switches, I have to implement such switches, it will be usefull for other features as well (like conditional couplers).

There are Pipe999IsTremulant keys for marking pipes of tremmed and non-tremmed ranks. If @larspalo agree, I'll implement IsTremulant at the rank level, so you don't need to set Pipe999IsTremulant for each pipe.

Of cause, you should make the same switches for enabling tremulants, because you cann't enable ranks, you can only enable stops with switches.

[eturpault]

@oleg68 : I implemented the objects drag&drop feature that you suggested. One object can be dragged from the objects lists or tree. The object on which it is dropped (in the objects lists or tree) becomes the new parent of the dragged object. Only the following objects types can be moved in this way to another parent : Coupler, Enclosure, PanelElement, PanelImage, Rank, Stop, Tremulant. I can change this list if you want, it is a personal choice according to my feeling about this feature.
If the Control key is pressed on drop, a copy of the dragged object is created as child of the object on which the drop has been done.
Here is OdfEdit v2.5 beta with the feature implemented, could you please test it and give me your feedback ? Thanks.
#25 (comment)

[eturpault]

About the use case : "moving lots of child objects between parent1 and parent2", the easiest way to do it with OdfEdit v2.3 is to select the parent2 in the objects list or tree, to click on the button "Children" and select in the objects list all the objects to attach to the parent2 as child. Then if those objects can have several parents, to select the parent1, click on the button "Children" and unselect the objects which doesn't have to be anymore child of the parent1. In case of objects which can have only one parent (like Rank or PanelElement which can have only one parent respectively WindchestGroup or Panel) there is not need to do an unlink, the link operation has overwritten the previous link.

[oleg68]

Thank you for the hint, but selecting objects from a flat global list is less comode than from a tree.

In my case I have a single windchest Manual 1 and I want to split it's ranks between Manual 1 Front, Manual 1 Distant and Manual 1 Rear. Using your hint I have to remember the rank names that belong to this original windchest for selecting them in the Children window.