during this week I've been fixing some bugs recommended by my mentor, Daniel.
I've fixed the following bugs:
- https://bugs.launchpad.net/mixxx/+bug/1522906 with this bug I had to discover how skin.xml works.
- https://bugs.launchpad.net/mixxx/+bug/1108371 this bug was originally fixed but there was a mistake when fixing it so the bug got reopened and I had to fix it.
Also with Daniel we began to discuss the idea of creating a Manager class to control multiple elements in the Library GUI. The idea is to allow the skin designer to setup for example a Collapsed and an Expanded version of the LibrarySidebar and, with the Manager class, switch between this two elements. This is not only for the LibrarySidebar, the idea is to add it to the following elements:
- LibrarySidebar
- SearchBox
- CoverArt
- Library
After that, Daniel found that RJs has decided to create a Manager class for everything that needs to be managed (more info here: http://mixxx.org/wiki/doku.php/mixxx_init_refactor ) so we decided to adapt our Manager to this design creating the concept of the LibraryManager. The current LibraryManager has the following design:
Currently I am working on fixing this bug: https://bugs.launchpad.net/mixxx/+bug/1474098 and I am having some problems on saving an array to User Settings.
Great progress!
ResponEliminaBTW "Library" (src/library/library.cpp) is already the manager class for the library, so I think you should rename the Library class to LibraryManager.
Does LibraryManager need to be aware of the different versions of the sidebar, search box and main library the skin author produces? What about using a stacked widget here and defining a CO to toggle between the expanded/collapsed versions?
The idea of the skin system is to remove the involvement of C++ code whenever possible -- I think by creating custom widgets you can do this without changing much of the Library manager.
However I may be missing something so please feel free to explain why it's necessary to change the LibraryManager for this project.
Hi RJ,
ResponEliminawe've been talking with Daniel and what we exactly want is a Manager for the Widgets related to the library and not the library itself. The idea has changed a bit since I published this weekly report.
Our current idea is to setup LibraryFeatures (different from the current LibraryFeature class) that interact with our LibraryViewManager (we changed the name to avoid confusion). The LibraryViewManager will contain some WLibraryStack that are classes that inherit the QStackedWidget (as you suggested) and every WLibraryStack will contain the LibraryFeatures for this stack and a couple of buttons allowing the user to add more features or switch the current shown feature (we are currently working in make this viable for the controllers).
So the WLibrarySidebar, WSearchLineEdit, WCoverArt and WLibrary classes should implement the WLibraryFeature interface allowing the LibraryViewManager to setup the necessary signals and slots to allow the classes to interact between themselves.
I will soon add more info in the project wiki
ResponElimina