Refactoring and improving gui

[szeli1]

I'm planning to refactor gui and I would like know what to support.

Problems:

• Repeating code in gui classes (drag and drop, context menu, Journalling).
• Code inside Qt protected functions (hard to move to different lib in the future).
• Journalling system can be unreliable.
• Code isn't written ideally, same functionality can't always be called from 2 places.
• Selecting multiple widgets is often unsupported or implemented separately.
• Journalling isn't separated from functionality, so sometimes unnecessary journalling checkpoints are made (for example zooming in the song editor changes the zoom slider's value that makes checkpoints)

Refactor goals:

• Handle repeating code with 1 class.
• Handle QT code with mostly 1 class acting as a layer between QT and gui. (this can give structure for different gui implementations).
• Handle journalling automatically in most cases.
• Give a structure to GUI that will guide ideal future code implementation.
• Implement unified widget selection

Feature goals:

• Improve data management between widgets (like StringPairDrag).
• Implement shortcuts.

Solution:

• Moving user interactions through an "action" class:
  • Actions will have names, functionality and acceptable data types.
  • Actions can be shown in context menus
  • Actions can be triggered by shortcuts or by any way.
• A class that unifies common widget code, handles Journalling, handles Actions:
  • It will support running an action on all selected widgets (if they support that action)
  • actions will run separately for each widget, but there will be a preprocessor that is called only once, this will allow muting/unmuting or moving plugins up or down.

Support targets:

• All AutomatableModels (knobs, zoom slider, mute buttons)
• All clips (refactor clip selection and adding support for all context menu functionality)
• Effects and mixer channel widgets in the future (copying, pasting, support for all context menu items with selection)
• Editors in the future (dragging sound, instruments to song editor, maybe refactoring editor buttons to use actions)
• Graph widget in the future (support for pasting in samples)
• Audio sorces in the future (support for pasting in audio or dragging samples from a graph to custom waves inside instruments (sound exporting support requiered))

Questions:
- How sould data get from one place to an other? (I believe String pair drag can be used for this)
- Should the "last selected widget" be marked in a different color and act differently? (for example multiple knobs are selected and an automation clip is selected last, should it link the knobs to itself?)
- Use QT QActions? Why, why not?
- What else to support? Can it be done with a preprocessing function and a function for each widget?

Issues: casting?

Base pr: #7488

[AW1534]

how about dragging files from file explorer or browser directly into LMMS?

[szeli1]

I'm unsure how that works with QT. While this idea focuses on dragging inside LMMS, dragging from outside isn't being targeted as a feature. Maybe the selected widgets could get access to the files dropped in lmms in the future.

[ifndefJOSH]

@szeli1 Qt handles drag and drop from external applications quite seamlessly:

• https://doc.qt.io/qt-6/qtwidgets-draganddrop-dropsite-example.html (example)
• https://wiki.qt.io/Drag_and_Drop_of_files (wiki documentation)
• https://doc.qt.io/qt-6/dnd.html (main docs)

You just have to override the same dropEvent() handler you'd have to use anyway to get drag and drop from within the application.