> 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.
> 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.
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
>
------------------------------------------------------------------------------
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
