Hi RJ,
thank you for your explanation. I was mistaken with the LibraryViewManager
because
the Library class is already doing most of the functions I was going to
code in the
LibraryViewManager. So, I've changed the wiki to fix the things that were
not right in
the previous design.
> I would like to point out one key design detail of the library. There is a
> "frontend" (GUI components -- WLibrary, WLibrarySidebar, DlgRecording,
> DlgAnalysis, etc.) and a "backend" (non-GUI components -- Library,
> LibraryFeature, BasePlaylistFeature, CrateFeature, etc.).
>
This front-end and back-end separation won't be broken and it was my
mistake that I forgot to write it on the wiki, now is already added and the
changes in the skin level will be minimal (only a few tags will change) to
allow multiple panes.
>
> There are a couple of reasons for this separation:
> * The skin author can create multiple library widgets. All the frontend
> widgets get connected to the library "backend" via the bindWidget methods
> <https://github.com/mixxxdj/mixxx/blob/master/src/library/library.cpp#L178>
> .
> * When we have an Android/iOS port, we will need a completely separate GUI
> implementation but ideally we can reuse all the non-GUI backend code. (I
> realize there are certain parts of GUI logic that got intertwined in the
> LibraryFeatures over the years and for an Android port that would need to
> be disentangled).
>
>
Since it's going to be a left widget and a right widget the
*bindWidget *function
will be separated in a *bindLeftPane *and *bindRightPane* methods to bind
to each container widget.
> From your design doc -- your class hierarchy seems to combine both
> frontend and backend.
>
The drawing is not combining, instead of it shows the relations between the
front-end and back-end.
> The library frontend is split into 4 independent widgets instead of a
> monolithic widget -- WLibrary, WLibrarySidebar, WSearchLineEdit, and
> WCoverArt.
>
This will remain, but with a new set of widgets
> I would prefer that we not go back to one monolithic library widget -- so
> I think one of the main complexities of your design doc will be how to
> implement this functionality while preserving this flexibility.
>
That is the idea
> What will the widget hierarchy look like in your approach?
>
I will have the same approach as it have now but with a WLibrary as left
pane and another WLibrary as right pane for every right pane
> I think your design doc could use a section on how MIDI / HID control will
> control the library once it goes split pane.
>
Added, it is related to this PR (https://github.com/mixxxdj/mixxx/pull/953)
> Things could get very confusing. Will controllers need a "focus" highlight
> to tell us which part of the library e.g. a select knob is affecting?
>
There will be no need, it should be obvious from the GUI which part has the
focus
I will be waiting for your answer,
Joan
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
