Fast edit feature - Enhancement

[Yinameah]

As I already proposed, I think a "fast edit" feature should be added in LiSP.
I did some work in this direction with #79, which is usable but far from being satisfying. Both because it does'nt reach the usability I aspire to, and because the implementation is creepy.

I open this issue to disscuss the what and the how. It may be seen more as a roadmap/guideline as I know this involve a lot of work.

In my opinion, the feature should go as following :

1. Replace current dialog based editor who will always be slower to work with, and having two different way of editing properties leads to unwanted complexity both in the code and in the usability in end user perspective.
2. Implemented independently of the layout, so it works the same way with List and Cart Layout.
3. As you type update.
4. When multiple cues are selected, only common properties are displayed, of course. But if the property has the same value in the different cues, the common value should be displayed. If the different cues have different value for the same property, then the value should be greyed. And in this last case, it should still be possible to enter a new value (by double-clicking or something) which would overwrite all other values.
5. The last used tab setting should remain selected as you change cues selection to allow fast overview of a specific property across multiple cues. Ideally, it should even "remember" the last selected tab, because if you are looking for, let's say "midi settings" across multiple midi cues, you don't want to reselect the right tab everytime you go trought a non midi cue.

I know this involve big work, more than probably complete rewrite of the "Settings Pages" Widgets. But in my opinion, it's really worth it.

About the implementation, I'm not experienced enough in coding to have the solution in mind. I will continue experimenting as soon as I have free time again.
For the time beeing, using Qt's QWidgetMapper (http://doc.qt.io/qt-5/qdatawidgetmapper.html#details) seem a good lead. It involve of course a custom Qt model to store the properties, or at least some kind of wrapper around current way of dealing with that.
But I have to confess that I'm far from having a good enough understanding of the Qt's Model/View Framework.

Any idea/feedback are more than welcome.

[FrancescoCeruti]

👍 a few thought on those "steps":

1. agree on this
2. obviously
3. this is probably the main reason for this, still I strongly believe that we need to keep the undo/redo feature (more on this later)
4. more or less what is already happening, but improved
5. mmmh, okay, something like | user select a tab -> we save this selection -> user select another cue -> if the last tab is available we show that otherwise the first available, but we don't change the one we've saved unless the user select another tab -> ....

Back on the 3, I think we have mainly to options for undo/redo:

1. we create a snapshot of the settings when the editor is opened (or switch) to a new cue, and when the editor is closed (or switch to another cue) we push an undo/redo action on the stack (the same LiSP is using at the moment) with a new version of the settings, this allow the user to quickly undo all the changes, after closing <- this method looks a bit rough, to me, plus if you have "fast-edit" it might turn out to be mostly useless
2. allow to have two modality, one that use live-updates, and another where the changes are applied manually and where it's possible to revert the changes.
3. We save all the properties edit <- this can conflict with QT keeping it's how edit-stack per widget

About the implementation, I think that following the QT model/view here is a pain in the , mainly because QT M/V framework is build on indexed data, in my opinion the way to approach this is to create some wrappers that use the widgets "change signals" to update the properties, we may be also able to have two-way binding (if the property change the widget is updated and vice versa)

[Yinameah]

Thanks for your thoughts.

About 3) :
I didn't think about undo/redo, which is of course capital.
But I think it's better to find a way to put every change in the undo stack. I've the feeling that two modality is a bit confusing at use time. It's not because you want to update properties in a fast way that you don't need the undo function anymore. It may even well be the opposite.
What would prevent to push the change in the undo stack on every "change signals" of the widget ? Too much data ?

About 4) :
Absolutly. The part where the improvement is significant is to display common values. You can select multiples cues and easily make sure that they all have the same (and right) value.

About 5) :
Exactly what I had in mind !

About Qt's M/V, indeed, working with it is a pain.
The difficulty is that not every Widget react the same way. It's quite easy for a TextEdit or a SpinBox, but you have a list (like keyboard mapping for exemple), it's a bit different. Maybe we should find some sort of standardization that allow to easily add new properties pages / deal with common situations..
I thought about that because I have also in mind to improve the CueListView with the ability to change the displayed proporties directly in the list. For exemple, changing "AutoNext/AutoFollow/None" directly by clicking on the arrow makes "debugging" of a sequence vastly easier. It's a different issue, but I had in mind that using the same Qt Model for FastEdit and ListView could be easier. Now I guess nothing prevent us to use the same wrappers for the two purposes.

[FrancescoCeruti]

What would prevent to push the change in the undo stack on every "change signals" of the widget ? Too much data ?

Not really, but qt already have a build-in undo/redo for most input-widgets, I don't think it suit our needs, and it might instead conflict, see qt-bug

The difficulty is that not every Widget react the same way. It's quite easy for a TextEdit or a SpinBox, but you have a list (like keyboard mapping for exemple), it's a bit different. Maybe we should find some sort of standardization that allow to easily add new properties pages / deal with common situations..

Yes, this is why I talk about wrappers, we should define a common interface and that use it to also create custom class to adapt qt widgets to this interface (boring but should be easy)

ListView made me think ... if we want to have an underling qt model, we can be able to have a custom model that maps cue-properties to model-indexes without really caring for the effective index (column) of a property, the model will then get the data from the cue objects

[FrancescoCeruti]

Just throwing some ideas, they probably need some more thought, especially the qt-model one