1. 31 Jan, 2018 1 commit
    • Michael Pyne's avatar
      Remove the 'emitChanged' hack in Playlist::createItem<> · 894e87d6
      Michael Pyne authored
      Whichever code is creating these items is in the best spot to know
      whether there will be one or many of these items and when the best time
      is to permit the playlist to sync up afterwards.  This permits the
      createItem functions to focus more on just that function.
  2. 29 Sep, 2017 1 commit
  3. 26 Aug, 2017 3 commits
  4. 27 Jul, 2017 1 commit
  5. 26 Jul, 2017 1 commit
  6. 30 Nov, 2013 1 commit
    • Michael Pyne's avatar
      GIT_SILENT: Update source code license headers. · d969a0b4
      Michael Pyne authored
      Thanks to Eric Newberry (from Google Code-In) for running the heavy
      lifting on this.
      I made some other corrections since we're touching all the source
      anyways (e.g. fixing my email addresses), fixing the encoding of Richard
      Lärkäng's name, and I've also chosen to avoid the fancy box-shaped
      comments so that there's no issue with trailing spaces/tabs.
  7. 14 Jun, 2013 1 commit
  8. 26 May, 2013 1 commit
  9. 04 Jul, 2009 1 commit
  10. 11 Nov, 2008 1 commit
  11. 09 Jan, 2008 1 commit
  12. 24 Jun, 2007 1 commit
  13. 19 May, 2007 1 commit
  14. 11 Apr, 2007 1 commit
  15. 26 Feb, 2006 3 commits
  16. 01 Sep, 2005 1 commit
  17. 23 Feb, 2005 1 commit
    • Scott Wheeler's avatar
      Ok, more than five hours late and coolo still hasn't turned me into a pumpkin. · 5fc3e83d
      Scott Wheeler authored
      I've been assured that this will happen in the morning, though after three hours
      of sleep, I think the effect would be natural.
      The moral of the story:  test features in apps you maintain before the day of the
      freeze.  (I knew that the play queue was broken, but not quite how badly -- this
      was mostly Michael's turf, but he's away for another few weeks.)
      Ok, so stuff that happened:
      Fixed the "magical not-showing-back-up" Play Queue (was related to saving the
      play queue, which even when set up properly just caused all sorts of crashes.
      Commented out for now, ideally to be reenabled in 3.4.1) -- #99191
      Fixed up a lot of the quirkiness with the interaction of the Play Queue and the
      rest of the application playlists.  This hopefully fixes #98473 (if not, just
      Double clicking on an item (anywhere) plays it immediately. #97021
      And the catch all, #88888, "this sucks" was mostly implemented.  Some of the things
      I took a different line on, but you got at least 3 of the 6.  The last two I don't
      agree with.  If you feel so compelled, open more specific requests from here on out.
      Basically this structurally changed things so that instead of adding items to the
      play queue when turned on and always using that as the main location for playing
      now the play queue is only used when there's stuff in it.  When it's empty again
      playing resumes in the list that the last item in the play queue came from.  It
      will jump back into the play queue as soon as something is added.
      This is still a little rough, but it doesn't crash all the time like it was before
      (fixed at least three crashes on this one) and is close enough to actually being
      releasable for me to now get a couple hours sleep.
      svn path=/trunk/kdemultimedia/juk/; revision=392533
  18. 11 Nov, 2004 3 commits
  19. 06 Nov, 2004 1 commit
  20. 05 Sep, 2004 1 commit
    • Michael Pyne's avatar
      Fix bug 88847 (Previous track doesn't work anymore in Play Queue mode). This... · 28fb30f1
      Michael Pyne authored
      Fix bug 88847 (Previous track doesn't work anymore in Play Queue mode).  This was actually by design, as items in the upcoming playlist are so ephemeral that keeping track of them would later crash JuK.  However, instead the associate collection list item is stored instead, which I feel is a better alternative.
      BTW to the reporter, JuK doesn't actually use the history playlist for this. ;-)
      svn path=/trunk/kdemultimedia/juk/; revision=344076
  21. 19 Aug, 2004 3 commits
    • Scott Wheeler's avatar
      A number of modifications to the new "upcoming playlist" stuff. · 286f74ae
      Scott Wheeler authored
      *) First, I think that the name "Play Queue" is better.  I'm still not crazy
         about that, but for a user visible string I like it more than "Upcoming Playlist".
      *) Switched the icon to use the "today" icon for now.
      *) I don't see any reason to disallow removing files in the upcoming playlist;
         that seems like an unnecessary special case.
      *) Don't raise the upcoming playlist when it's shown.  That wasn't concistant with
         the other "special" playlists.
      *) Get rid of the "upcoming item" thing in the Playlist RMB menu and just have it
         automatically show / enqueue things into the upcoming playlist; one queueing
         system is enough, thank you.  ;-)
      There are a handful of other things that need to happen here, but I presume that
      those will come from Michael and I over the next little while.
      svn path=/trunk/kdemultimedia/juk/; revision=339083
    • Michael Pyne's avatar
      Like an idiot I forgot to include the license headers for the new files. · cbfddbf6
      Michael Pyne authored
      Sorry. :-(
      svn path=/trunk/kdemultimedia/juk/; revision=338994
    • Michael Pyne's avatar
      OK, here it is. This commit introduces a new feature to JuK, the upcoming · 37f111cd
      Michael Pyne authored
      playlist (which is currently easily the #1 requested feature).  Although
      there's still issues to be solved with it, it seems to work pretty well at this
      point, I've been running this code for a few days now.
      How it works so far:
      * You must enable it by selecting "Show Upcoming Playlist" from the View menu.
      * When the upcoming playlist is enabled, it takes over control of playback
        completely.  You can drag-and-drop tracks onto the playlist to add them to
        the end of the line, or you can use the context menu's Add to end of upcoming
        playlist entry.
      * If loop playback is disabled, then entries will be added to the end of the
        playlist as entries disappear.
      * Hitting Next (or double-clicking an item while a track is playing) will cause
        the currently playing track to disappear.  The History playlist doesn't play
        too well with the upcoming playlist yet, so if you want to keep the songs you
        played, you're better off making a normal playlist.
      * On that note, double-clicking a song will add it to the beginning of the
        queue and immediately start playing it.
      * Random play should work as normal.  If it doesn't, it's a bug.
      * When the list becomes empty, playback stops.
      * There is also a selection in the Settings menu, "Save Upcoming Tracks", which
        will save the current status of the upcoming playlist on exit.
      This is a rather sizeable re-organization/addition of code, so if you
      experience crashes/bugs in the next few days, PLEASE report them, and you can
      probably assume it's my fault. =D
      This feature will probably be tweaked over the next few days as well, but I
      wanted to get it out there for testing.
      I'm closing bug 63260 since this implements the feature.  If you'd like to
      quibble on the specifics, feel free to continue commenting on the bug, I'll add
      myself to the CC: list for it.
      svn path=/trunk/kdemultimedia/juk/; revision=338993