On Fri, Jun 3, 2016 at 7:43 AM, Joan Marcè i Igual <j.marce.ig...@gmail.com>
wrote:
>
> 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?
>>
> Yes it will be N panes (maybe it's not well explained) but for simplicity
> I only created the examples with 2 pane. There will be only 2 panes for
> each feature (left and right pane) but there can be up to N right pane
> containers.
>
>
>>
>> What if a skin author wanted a "top" and "bottom" frame? Or 3 frames? Or
>> only 1 frame?
>>
>> Although it has the names left pane and right pane it has nothing to do
> with orientation, there will be the skin elements *LibraryLeftPane *and
> *LibraryRightPane* that can be declared anywhere, and the
> *LibraryRightPane* can be declared N times to allow the skin designer to
> have as many right panes as he/she wants.
>
>
I see -- thanks for the explanation. Sorry to nit-pick but could I push for
more salient names for these? I think it's already causing confusion :).
Skin designers will probably also be confused.
We already have <LibrarySideBar> and <Library> XML nodes.
What about <LibrarySidebar> for the button bar, <LibrarySideBarExpanded>
for the expanded sidebar view, and <Library> for the track tables?
Instead of Left and Right? Since from what I understand, LibraryLeftPane is
the expanded sidebar view for the feature?
> 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).
>>
>> Is automatic, when the user has a pane container focused and clicks to
> load a feature in the button bar the feature is loaded in the current
> focused pane container. With this it should be very evident to the user
> which is the current focused pane to avoid confusion. Even so I like the
> dragging idea and if there's enough time I'll add it.
>
> 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?).
>>
> I'll add it as soon as possible
>
>
>> 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?)
>>
>> It is the *LegacySkinParser* the one who creates the two *WLibrarys and
>> *there
> will be two different *WLibrarys* for each *LibraryPaneManager.* One
> will be the right pane and the other for the left. Every
> *LibraryPaneManager* will always have this two widgets but the *WLibrary*
> dedicated
> to the left pane of every *LibraryPaneManager* will be put in one stacked
> widget with the other left widgets of other *LibraryPaneManagers* so,
> when a user focuses one pane it's easy to show the left pane of the focused
> right pane container.
>
I think I'm getting what you mean -- let me restate it to make sure:
Each library feature will have two "loadable views" associated with it --
the expanded sidebar view and the track table view. (e.g. in the case of
Playlists, the tree view of current playlist names and the track table view
for the currently selected playlist).
Request: In future emails can you pick more descriptive words than
right/left? Instead use a word that describes its purpose so we can be sure
we're talking about the same thing.
I think instead of coupling the track table view and the sidebar expanded
view together into a "LibraryPaneManager", the expanded sidebar view should
instead be associated with the selected feature in the library
side-button-bar. I don't see a strong reason for coupling the current
selected track table view with the current selected expanded sidebar view.
It seems it will limit use cases we're discussing where you switch around
to different parts of the library while keeping a previously selected
playlist/crate open to drag/drop tracks. Additionally, since there can be 1
to many "Right" (library track table view) widgets -- it seems we are
already going break the coupling logically.
> And with this the LibraryPane is a very frontend element. However, it
> relies absolutely on the LibraryFeature interface that does all the backend
> tasks.
>
> I will be waiting for your answer,
> Joan
>
>>
Best regards,
RJ
------------------------------------------------------------------------------
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
