| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Wrapper functions 4 lyfe.
|
|
This should make it easier to add state for individual sockets, which
will be needed in coding better data handling.
(Update: Actually, that wasn't necessary, because I wrote it as a more
general wrapper function which contains its own state. Still, this could
come in useful in the future, and it arguably reduces the code
complexity anyway.)
|
|
|
|
|
|
|
|
|
|
|
|
...for consistency with a socket.js (coming soon to a theater near you!)
|
|
Backend save/restore code (living in serialized-backend.js) has been
well tested and shouldn't need much change going forward. Now we get to
begin working on the actual synchronized-over-socket-server commands!
|
|
|
|
...for consistency with a socket.js (coming soon to a theater near you!)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's called loadPlaylistOrSource now, and can take a grouplike (which it
will process with processSmartPlaylist as usual) instead of a URL to
pass to a crawler.
This is so that all functionality for loading a playlist can be
collected in and accessed through one interface, so that modifications
to the way playlists are loaded will be reflected across everywhere that
loads a playlist.
|
|
|
|
It's called loadPlaylistOrSource now, and can take a grouplike (which it
will process with processSmartPlaylist as usual) instead of a URL to
pass to a crawler.
This is so that all functionality for loading a playlist can be
collected in and accessed through one interface, so that modifications
to the way playlists are loaded will be reflected across everywhere that
loads a playlist.
|
|
This is the start of a project to let two (or more) instances of mtui
link together and host a party where tracks are accessed on each user's
own machine. Backends will be linked so that any actions taken in one
will be reflected in another. This function is a key part of
implementing this, since mtui depends on all instances of a track be
referred to by the same JS object, and the new function allows the
(approximate) identity of a track to be serialized and transferred over
the internet (or any static format) and restored later, on another
device, and/or even in a differently structured music library.
|
|
i forgot to implement menuItems. oops. :P
|
|
i forgot to implement menuItems. oops. :P
|
|
this makes a very nice animation of the duration going up as data is
processed for new tracks :3
|
|
|
|
oops v_v i apparently forgot to commit this!!
|
|
|
|
|
|
this makes it so that the value of timeData at any point will always be
associated with the track which is currently playing. i thought this was
already how timeData worked -- that assumption is what makes a lot of
the math in updateQueueLengthLabel work!
|
|
this should help make the wider length label fit better!
|
|
|
|
This was already the previous behavior, but a misplaced
restoreGrouplikeData was overwriting that effect. With this
commit, the scroll position will still be restored, but the
selected item will be correctly changed to whichever was
opened.
(This arguably means it's no longer necessary to restore the
selected item in save/restoreGrouplikeData at all, but it's
kept there in case a grouplike is ever unloaded through some
means besides opening its child -- actually this is the case
if you reveal an item whos ancestor groups don't fully overlap
with that of the previously open group.)
|
|
|
|
|
|
|
|
this was causing a funky visual bug which made the queue pane look like
its bottom-right corner was pointing downwards (like the top-right
corner of a pane is)!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
