On Thu, Jun 2, 2016 at 9:14 AM, Joan Marcè i Igual <j.marce.ig...@gmail.com>
wrote:
> 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.
>
>
Thanks for the updates!
> 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.
>
>
Good to hear :)
>
>> 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.
>
I'd like to push back on this a little bit just to see whether it can be
made more general.
Why hard-code any orientations into this? And why 2 panes instead of N?
What if a skin author wanted a "top" and "bottom" frame? Or 3 frames? Or
only 1 frame?
Maybe instead of coding specific orientations, we just keep a list of
available panes and then the logic for considering which pane to load a
library feature's view into can consider the least recently used pane (or
whatever the scheme is for loading views to panes)?
BTW, maybe I missed it -- but how will the user choose which pane to load a
sidebar item into? Is it automatic or a specific choice by the user (i.e.
dragging an item from the sidebar into a pane).
>
>
>> 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
>
>
Could you add some actual skin XML examples for various configurations?
i.e. maybe an example of how to skin each of your example mock ups and then
an example of how to do a completely different mockup (i.e. with the
sidebar on the top?).
In the updated diagram, it looks like LibraryPaneManager creates two
WLibrarys -- but in the skin logic, there is no way to constrain the skin
author on how many WLibrary widgets to create -- so I'm just curious how
that would look in skin.xml such that you can still style/position each
widget individually, etc. Does LibraryPaneManager get access to WLibrary
through a bindWidget process similar to how the Library class does today?
(Is LibraryPaneManager in the "frontend" or the "backend" under this
design?)
You can look at http://www.mixxx.org/wiki/doku.php/creating_skins for an
example of how to show skin XML with inline comments -- that way we can see
how the skin.xml authoring process will be affected by the change and as a
side benefit when the changes are ready we can copy/paste them from your
design doc into the creating skins page!
> 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
> )
>
Ah, I missed Daniel's comment on that PR -- looks good.
>
>
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
>
Possibly though in a dark club at 1am it might be nice to support a
highlight :). This is already quite a large project though so file that
under "super stretch goals".
> 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
