1. 10 Nov, 2013 3 commits
  2. 22 Oct, 2013 1 commit
    • jwatzman's avatar
      Revert "macosx: fixed compilation warning and potential, runtime exception" · 8fdbf0f2
      jwatzman authored
      This reverts commit 55e3f943
      
       and fixes it the right way. I'm honestly not sure what's going on in that commit -- it silences the compiler warning not by actually fixing the problem (which is that the method isn't declared in the interface) but just by not making the method call visible to the compiler! It also completely breaks the feature, by moving things onto the main thread that can't be there, causing a deadlock, as specifically noted in the comment right above this code.
      
      In any event, it's easy enough to revert and add to the interface properly, silencing the compiler warning and unbreaking this extension feature.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
      8fdbf0f2
  3. 23 Jun, 2013 1 commit
  4. 21 Apr, 2013 1 commit
  5. 12 Apr, 2013 1 commit
  6. 18 Mar, 2013 2 commits
  7. 02 Mar, 2013 1 commit
  8. 15 Feb, 2013 1 commit
  9. 10 Feb, 2013 1 commit
  10. 21 Jan, 2013 1 commit
  11. 12 Jan, 2013 1 commit
    • David Fuhrmann's avatar
      macosx: fix and improve window level handling · a02360f2
      David Fuhrmann authored
          - fix behavior of video-on-top by adapting to vout windows handling changes
          - set all windows to status level if one vout window has this level:
          This avoids that video effects panel, audio efffects panel etc. pp. are opened behind
          a vout window. Now they can be used as usual.
      
          Please note, that due to the type of these panels they do not remain visible
          when VLC gets inactive.
      a02360f2
  12. 08 Jan, 2013 1 commit
    • jwatzman's avatar
      macosx: call input_changed in extensions · a8ff5278
      jwatzman authored
      This is obnoxiously complicated. If anyone cares about playing_changed or
      meta_changed, something similar will probably have to be done.
      
      This is a pretty bizarre two-step system to inform the extension manager
      that the input has changed, but it's necessary to avoid a series of
      possible deadlocks and other issues. Here are other possible approaches
      that don't work:
      
      - Just call into the extension manager in -PlaylistItemChanged on the
      main thread. This can pretty easily cause a deadlock if we call
      -PlaylistItemChanged twice in quick succession. The first call will poke
      the condvar the extension is waiting on, causing the extension thread to
      wake up and run extension code; many parts of it -- including the dialog
      code -- must be run on the main thread. The extension thread goes back to
      sleep while blocking on the main thread to become available, while
      holding the extension lock. Meanwhile the main thread goes into the
      second call of -PlaylistItemChanged, attempts to lock the extension, and
      that's a deadlock.
      
      - Restructure the dialog manager to never block on the main thread while
      holding the extension lock. This should work, but as it turns out doesn't
      because the main thread will attempt to lock the same lock twice. What
      happens is that -performSelectorOnMainThread works by injecting an event
      into the main event loop of the main thread. For some unknown reason, as
      part of its processing, when creating an NSAttributedString with HTML, it
      runs the main event loop, which means we can end up executing one
      -performSelectoOnMainThread as part of another. Since the dialog manager
      uses attributed strings with HTML (since dialogs are HTML), we deadlock
      here too. This seems strictly like a flaw in NSAttributedString and/or
      in -performSelectorOnMainThread and is documented elsewhere:
        http://mrrsoftware.com/blog/tag/nsattributedstring/
        https://www.bluestatic.org/blog/2010/05/31/nsattributedstring-spins-a-nested-run-loop/
      
      
      
      - Change around this bit of code to not force it to run on the main
      thread. This would probably work, but, as a newcomer to VLC, I don't
      quite know the implications of doing this, particularly since a lot of
      code here seems to serailize on the main thread as a way of thread
      safety; it would likely require some somewhat intricate restructuring
      and adding of locks.
      
      - Let the extension manager deal with listening for events the same way
      that we do here. That would work, but would require duplicating a
      nontrivial amount of code from here to deal with tracking the current
      input.
      
      - So, instead, we just serialized all calls to -PlaylistItemChanged (so
      we make sure to process them in order, with no one trampling
      p_input_changed), do most of the work on the main thread as before, and
      then actually inform the extension manager out here where we don't block
      the main thread. It seems likely that there are other pre-existing
      deadlock possibilities here -- the main thread can't lock an extension!
      -- but it at least tends to work in my testing.
      Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
      a8ff5278
  13. 25 Nov, 2012 1 commit
  14. 10 Nov, 2012 1 commit
  15. 27 Oct, 2012 1 commit
  16. 20 Oct, 2012 1 commit
    • David Fuhrmann's avatar
      macosx: implement vout actions handling for multiple vout windows · b7165d60
      David Fuhrmann authored
      Now, everything from the video menu and the basic stuff like fullscreen
      should work. If it does'nt (e.g. fullscreen and resize with video-splitter module enabled)
      please blame the core first. ;-)
      
      TODO: There might be some getVout()-calls left which should be investigated.
      
      close #6814
      b7165d60
  17. 08 Oct, 2012 1 commit
    • David Fuhrmann's avatar
      macosx: adapt and fix fullscreen handling after latest changes · dd86d6d4
      David Fuhrmann authored
      Now, every video window is responsible for the fullscreen handling for its own.
      Furthermore, fullscreen now acts entirely in response to vout events, and not over the
      playlist fullscreen variable callback anymore.
      Native fullscreen mode should also work correctly, but of course only
      for embedded video in mainwindow.
      dd86d6d4
  18. 02 Oct, 2012 2 commits
  19. 30 Sep, 2012 1 commit
  20. 21 Sep, 2012 1 commit
    • David Fuhrmann's avatar
      macosx: create new classes for all controls bar related code · a0140fe5
      David Fuhrmann authored
      Now, we have two classes (instantiated from the xib file for each window)
      with controls bar stuff:
      - VLCControlsBarCommon holds all code common for main and detached window
      - VLCMainWindowControlsBar adds code specific for the main window bar
      
      With that, we can avoid all these redundant code for o_detached_*, furthermore
      this decouples all detached window control bar stuff from MainWindow.m.
      
      The objects can be accessed through the controlsBar method.
      a0140fe5
  21. 04 Sep, 2012 1 commit
  22. 03 Sep, 2012 1 commit
  23. 24 Aug, 2012 2 commits
  24. 22 Aug, 2012 1 commit
  25. 19 Aug, 2012 1 commit
  26. 11 Jul, 2012 1 commit
  27. 03 Jul, 2012 1 commit
    • David Fuhrmann's avatar
      macosx: change handling of arrow keys slightly · 0ccbaa82
      David Fuhrmann authored
      When the key is assigned to an main menu item: In this case the event
      is never passed to the controls, so we want to handle it here for these
      exeptional cases.
      
      For all other cases: The event is ignored here and handled by the controls
      (playlist, or video view, which also sends it to vlc core).
      0ccbaa82
  28. 18 Jun, 2012 1 commit
  29. 11 Jun, 2012 1 commit
  30. 18 Apr, 2012 1 commit
  31. 05 Mar, 2012 1 commit
  32. 03 Mar, 2012 1 commit
  33. 05 Feb, 2012 1 commit
  34. 29 Jan, 2012 1 commit
  35. 27 Jan, 2012 1 commit