- 17 Mar, 2009 20 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
That is the same problem as we already had with other object types. The interface really needs to unload when its owner stops it, not when the reference counter drops to zero. This fixes a reference dead loop when an interface yields itself (such as Qt through the view menu) and a crash if an interface releases itself last (unmapping the running caller code).
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Erwan Tulou authored
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
The macosx drawable variable that used to hold the drawable window reference is splitted up in two variables "drawable-agl" (used by macosx safari/mozilla plugin) and "drawable-gl" (used by macosx interface).
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
- 16 Mar, 2009 20 commits
-
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
Patch by Erwan10, <brezhoneg1@yahoo.fr>, simplified by /me
-
Jean-Baptiste Kempf authored
-
Erwan Tulou authored
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
In one case (noted by Erwan Tulou), this also fixes a large leak. There is _absolutely_ no point in holding an object and releasing it immediately. Holding an object only makes sense if: - the object cannot vanish while calling vlc_object_hold(), and - either: - the object could have otherwise vanished before vlc_object_release(), or - there is no way to avoid the (otherwise not needed) vlc_object_hold() because it comes from another component. Conversely, it makes no sense to hold an object, if: - it could vanish already while calling hold (race condition) -> this is *invalid* and might crash, - there is already a valid reference to the object throughout. I don't know in which case that code was, but the popup menu definitely does invalid object access in some cases. For instance: - start playing a single video, - seek to a few seconds before the end, - open the popup menu, go to video / deinterlace, - wait for the video to finish and the playlist to stop, - click on "X" from the deinterlace submenu. Oops.
-
Rémi Denis-Courmont authored
-
Sébastien Escudier authored
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
Renamed: npunix.c to npunix_old.c npwin.cpp to npwin_old.cpp Added new files from mozilla source code npunix.c npwin.cpp
-
Jean-Paul Saman authored
-
Jean-Paul Saman authored
macosx: playlistlock is held when playlistinfo panel is updated, so call PreparseEnqueue with pl_Locked. updatePanelWithItem is called from modules/gui/macosx/intf.m line 1565 with playlist lock held. If this solution is wrong then revert and fix properly.
-
Jean-Paul Saman authored
-
Rémi Duraffort authored
-
Rémi Duraffort authored
-
Rémi Duraffort authored
-
brezhoneg1 authored
dialog provider for skins and 1 as the regular qt4). The problems for skins are real (lead to crashes when using menus). The one for regular qt4 was obviously a typo, but sometimes even removing a typo may have side effects. If so, please find attached a patch that reverts this part of the previous patch. Erwan10 Signed-off-by: Ilkka Ollakka <ileoo@videolan.org>
-
Jean-Baptiste Kempf authored
-