1. 25 Feb, 2014 1 commit
  2. 24 Feb, 2014 1 commit
  3. 27 Jan, 2014 1 commit
  4. 24 Jan, 2014 1 commit
  5. 15 Jan, 2014 1 commit
  6. 21 Dec, 2013 1 commit
  7. 11 Dec, 2013 1 commit
  8. 08 Dec, 2013 1 commit
  9. 28 Nov, 2013 1 commit
  10. 25 Nov, 2013 1 commit
  11. 24 Nov, 2013 1 commit
  12. 18 Nov, 2013 1 commit
  13. 11 Nov, 2013 3 commits
  14. 08 Nov, 2013 2 commits
  15. 03 Nov, 2013 1 commit
  16. 02 Nov, 2013 1 commit
  17. 30 Oct, 2013 1 commit
  18. 24 Oct, 2013 1 commit
  19. 22 Oct, 2013 1 commit
  20. 13 Oct, 2013 1 commit
  21. 11 Oct, 2013 1 commit
  22. 09 Oct, 2013 1 commit
  23. 08 Oct, 2013 1 commit
  24. 06 Oct, 2013 1 commit
    • Shubham Chaudhary's avatar
      Notify the user that JuK is docked on startup. · 61e5fc8d
      Shubham Chaudhary authored
      We show a simple notification if the user starts up JuK and it is set to
      dock in the systray on startup (as otherwise the user may wonder why it
      didn't open up). Although a "Do not show again" checkbox is not possible
      with KNotification, it is possible to remove this additional
      notification by going to "Application and System Notifications" in
      System Settings to manage "Juk music player" application notifications.
      
      We do *not* show a notification if a session is being restored to avoid
      noise, however JuK will show the main window if the user tries to start
      it up again after it's already running, so this should be OK.
      
      Thanks to Shubham Chaudhary for the bugfix (you're been marked as the
      patch author), and Michael for reporting the bug.
      
      This bugfix adds new strings so it cannot be backported. It will show up
      first in KDE SC 4.12.
      
      BUG:316832
      FIXED-IN:4.12
      GUI:
      61e5fc8d
  25. 03 Sep, 2013 4 commits
  26. 25 Aug, 2013 1 commit
  27. 20 Aug, 2013 1 commit
  28. 17 Aug, 2013 2 commits
  29. 24 Jul, 2013 2 commits
  30. 14 Jul, 2013 1 commit
    • Michael Pyne's avatar
      coverinfo: Do not crash if an MP3 file has no ID3 tag. · 0318fb35
      Michael Pyne authored
      This rarely happens since taglib will simply create an ID3 tag if one
      didn't exist before... but taglib can't do this if it can't find the
      file, which now seems to occur for files with a non-UTF8 filename
      encoding.
      
      You see this as a 'Couldn't resolve the mime type of <<foo>> -- this
      shouldn't happen' message on the console. In this situation JuK is able
      to resolve the file to an appropriate TagLib::File subclass, but the
      TagLib object is in an invalid state.
      
      CoverInfo wasn't checking for this (it was assuming any TagLib::File*
      that it was given was valid).
      
      I took a look through the reported JuK crasher bugs and didn't see
      anything relevant.
      
      I'm not sure whether this will end up in the KDE SC 4.11 or 4.11.1.
      0318fb35
  31. 30 Jun, 2013 2 commits