-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mon, 04 Apr 2016 16:35:55 -0100 "Joan Marcè i Igual"
<j.marce.ig...@gmail.com> wrote:
>Hi RAWRR,
>
>Thank you for your suggestions.
>
>When you talk about the Browse PC view you refer to porting the
>the
>advantage of using folders elsewhere in the library. Do you mean
>by this
>adding also the folders feature to the current library and
>allowing the
>user to
>set the tracks on "virtual" folders only existing in Mixxx? Do you
>think
>it can be a bit confusing for the final user having also the
>Clementine look
>like sort (v.0.1.2)?
>

Yes I agree confusion is possible, or even likely if the UI is not
arranged just right. I think you might be uncertain if I mean
adding a direct view of local filesystem to your v0.1.2 section.
No, that isn't my suggestion. It seems like you may have a kind of
virtual folders already suggested and local view and virtual view
are not both necessary in the same section.

So there are two fundamental UI perspectives here. one is the idea
of sorting, the other is the idea of containing, and they are not
the same workflow.

In the case of sorting we presumably have a potentially enormous
list, and the current "sort by column" allows the user to "clump"
groups of tracks according to categories.

In the case of containing, more or less that means folders; they
can be called crates or playlists or virtual folders, it doesn't
change the fact that they function in the Mixxx UI as a kind of
directory. So these directories can be virtual (crates or
playlists, or autogenerated according to categories, whatever) or
they can be a direct view of existing structure in a user's local
filesystem, but they are ways to isolate tracks in a container and
thereby abbreviate the list a DJ must scroll through to grab what
they need.

I'm a little confused at v0.1.2 by the wording and accompanying
image: "the view has two modelers one for the menu (Library,
Autodj, iTunes...) and other for the songs" - I can't see in the
diagram where "menu" is. But what I do see seems to suggest you
already have an implementation of virtual folders envisioned (re:
above "autogenerated according to categories").

As long as we have a tree of folders/crates/directories - visual
containers, in other words - I think that works, so long as each of
these containers have all the columns and options the current main
Library view has, meaning easter egg, Preview, Year, BPM, etc..

Currently Browse View is the only View that allows in Mixxx any
visualization of tracks by "container", and this Browse View lacks
some of main Library's features. This is the problem that inspired
the two bugs cited.

>
>I like your "lasso (rubber band) select in library" and it can be
>very
>useful also,
>the scrollbars "midi-scriptable" will be very useful but I think
>that it's
>beyond this project.
>

So rubberband select is a yes? If so, great! I understand re:
scrollbars.

>
>I've been playing a bit with skins and I think that splitting the
>library
>view into a set of
>widgets can give the skin designer a lot of freedom. Currently the
>skin
>supports tags
>for *LibrarySidebar*, *SearchBox*, *CoverArt*, and the *Library*
>itself, in
>my opinion the
>State / Progress / Controls widget can also be separated (in a
>*LibraryControls* tag
>for example). To allow the skin designer to play with this we can
>separate
>the
>*LibrarySidebar* tag in different tags: *LibrarySidebarButtons*
>and
>*LibrarySidebarMenu*,
>the first one will contain the main buttons (Library, Notes,
>AutoDJ) and
>the second one
>will contain the sub-menus for every item (Library Tree (legacy),
>Crates,
>Playlists
>for the Library item).
>

I mainly want to see the thought of others on these items.

>
>I like your colored line idea maybe we can allow the skin designer
>to set a
>border color
>when creating widget groups.
>

Sounds good. Basically I mean either a colored border that
surrounds both a tab and its children, or a colored line that leads
from a tab to its children.

>
>What do you think about times? Will be enough time to do the
>rubber band
>select?
>

I do feel that at a minimum your new code should support this
feature's future place, because I'm not sure how well the current
Library code does. But I'd hate to sabotage your schedule with my
old feature request. I guess this is another item I hope others
will vote on.

>
>What others think?
>
>I've added all of this to this bug thread (
>https://bugs.launchpad.net/mixxx/+bug/986704)
>
>On Mon, 4 Apr 2016 at 09:45 <re-cy...@hushmail.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I keep track of my own bugs and those I subscribe to best, so
>here
>> are a few relevant ones juxtaposed with observations and
>> suggestions:
>>
>> - - Library view v0.1.2 -
>>
>> This more or less offers a solution to "request filter system in
>> browser on i.e. genre tag"
>> (https://bugs.launchpad.net/mixxx/+bug/671630). Great! Your
>designs
>> seem more or less satisfactory.
>>
>> - - Browse PC view v.0.3 -
>>
>> My concerns are:
>>
>> "option to subdivide Library tracks into virtual folders"
>> (https://bugs.launchpad.net/mixxx/+bug/1228789)
>>
>> and "Add Preview column in Browse, and External Libraries views"
>> (https://bugs.launchpad.net/mixxx/+bug/1160525)
>>
>> The arguments are provided at the bugs, but a synopsis is that I
>> strongly feel that large collections are well served by being
>> sorted into folders. My preference is to create folders by
>artist,
>> but others might prefer genre or something else. Browse view
>> currently allows a Mixxx user to browse their files by whatever
>> structure they have crafted in their local filesystem.
>>
>> I'm all for relegating the Browse view to an impromptu discovery
>> tool, but only if its current advantage of using folders is
>ported
>> elsewhere in the Library.
>>
>> Two more items:
>>
>> I'd like to ask what you think of "lasso (rubber band) select in
>> library" (https://bugs.launchpad.net/mixxx/+bug/1093598). For
>> adding swaths of tracks to either AutoDJ, Analyze, Playlists, or
>> Crates, rubberband select can't be beat, and is far and away
>> superior to ctrl+clicking groups of tracks.
>>
>> The other is "all scrollbars midi-scriptable"
>> (https://bugs.launchpad.net/mixxx/+bug/1463677). Many
>controllers
>> have a browse rotary dial with push toggle, for browsing
>libraries.
>> It only works currently in Mixxx if the user selects a track
>> explicitly, at which point the browse knob can do some
>scrolling.
>> It takes way too many steps to get to that function and making
>the
>> scrollbars scriptable would clean this up considerably.
>>
>> Lastly, I've looked over the entire proposal with an eye toward
>> eventual touch features, and really the only thing I can find
>that
>> might cause problems are Library view v0.2.0 (v0.1.1), wherein
>> right-clicking is discussed, an awkward requirement in touch
>> interfaces, but this is a larger issue throughout the project
>and
>> in this case there are alternative routes to the same result so
>it
>> should be ok. Other than this nitpick, I'm a little worried
>about
>> treeview at all for touch devices as treeviews typically favor
>> small (read: not finger size) controls for collapsing and
>expanding
>> the tree. This again is a problem which already exists (if it
>can
>> be agreed it is a problem at all) and not something Joan's
>proposal
>> introduces. Still, it ears mentioning that facility which relies
>on
>> treeview probably won't work elegantly for eventual touch
>workflow.
>>
>> The only aesthetic complaint I have is that subdividing the
>Library
>> into too many sections starts to look like some kind of fractal,
>> with smaller and smaller nested fields; it can devolve into a
>soup
>> of confusing rectangles. There needs to be a way that the
>hierarchy
>> of parents is unmistakable, in other words, what object on the
>left
>> is responsible for any given rectangle on the right. Perhaps a
>> color trace (a colored line) or shared highlight color, flowing
>> from a tab to its boxes?
>>
>> All in all, it looks like a solid apprehension of our needs,
>with
>> only a few loose ends. Thanks for the effort and vision, Joan!
>>
>> RAWRR
>>
>>
>> On Sun, 03 Apr 2016 06:59:12 -0100 "Daniel Schürmann"
>> <dasch...@mixxx.org> wrote:
>> >Hi skin artists,
>> >
>> >IMHO Joan's proposals, will work good together with various
>future
>> >Mixxx
>> >features.
>> >But how about the beauty?
>> >
>> >Are there special demands, he has to consider to work smoothly
>> >with all
>> >sorts of skins and design aspects?
>> >
>> >Which part might become an independent widget?
>> >
>> >If Mixxx will have a touch or a radio skin, will it still work?
>> >
>> >Does anyone have a cool idea to make the library look modern?
>> >
>> >Thank you for comments.
>> >
>> >Kind regards, Daniel
>> >Am 02.04.2016 6:35 nachm. schrieb "Joan Marcè i Igual" <
>> >j.marce.ig...@gmail.com>:
>> >
>> >> Hello,
>> >> I am Joan and I am currently at my third year of engineering
>in
>> >Computer
>> >> Science and Mechanical Engineering at UPC, Barcelona.
>> >> I applied for GSoC under Mixxx for a Library Layout Redesign.
>> >> The idea is to change the current Qt TreeView (at the left of
>> >the library)
>> >> to buttons at the left allowing more space in the view,
>change
>> >the playlist
>> >> view, change the current library view and (if there's enough
>> >time) add a
>> >> Browse PC view where the user can select songs directly from
>a
>> >PC folder.
>> >> The project will split developed in different releases with a
>> >new release
>> >> every two weeks.
>> >> You can see all the info in the proposal document (
>> >>
>>
>>https://docs.google.com/document/d/1HaZ5s7PKmE73LacEGbxRJy9LIKi0ZF
>b
>> >Z-emdSQ1m68o/edit?usp=sharing).
>> >> Also I include the mock-up of the proposed redesign.
>> >>
>> >> I will be waiting your feedback.
>> >>
>> >> Regards,
>> >> Joan Marce
>> >>
>> >>
>> >> --------------------------------------------------------------
>---
>> >-------------
>> >> Transform Data into Opportunity.
>> >> Accelerate data analysis in your applications with
>> >> Intel Data Analytics Acceleration Library.
>> >> Click to learn more.
>> >>
>http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>> >> _______________________________________________
>> >> 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
>> >>
>> -----BEGIN PGP SIGNATURE-----
>> Charset: UTF8
>> Note: This signature can be verified at
>https://www.hushtools.com/verify
>> Version: Hush 3.0
>>
>>
>wpwEAQMCAAYFAlcCG4EACgkQzo/Gj4mkNMytPwP/dwbpvJl6/xBOxB1husgfbviGW3I
>D
>>
>4Ie2HSwQkqtSCi+cgAs46Da6OxKKrGF7lj9Nfs7Wq9X4jyldfj3bVc/zgW4H4HEtJcz
>C
>>
>2rflnObDnSiGRI83kjBiwMH59fbGOYZ2mDbA+4CLfbvnmiJGwydVUXmVQHRThSvx/cW
>G
>> Dt8Vg/c=
>> =zYTu
>> -----END PGP SIGNATURE-----
>>
>>
-----BEGIN PGP SIGNATURE-----
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0

wpwEAQMCAAYFAlcC7fMACgkQzo/Gj4mkNMxDMAP+KWnScGQQlTGL0xk6GcI3N3QJ9wMu
Y4JWw1hnDjrZSRmf4HWRmjuDgtPw4vZB7cRLL4mgAxtC+N1qMwuzNjybmnJ5u33g3MsJ
bSRo+5TeDjRXUEyyvX5R/7nSX5/polBZyjdsYbdx5/aAVCDsHLk1XxL7cMoT4yCywLY0
jKVJDjk=
=carB
-----END PGP SIGNATURE-----


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

Reply via email to