patch attached to remove use of the obsolete logger interface in the
core interface code.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
(cherry picked from commit f0e01208a3)
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Following the changes introduced by 7ecd927, the affected lines would
result in a warning due to signed vs unsigned integer comparision.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
This removes the insertion offset parameter to playlist_Add(),
playlist_AddExt() and playlist_AddInput().
intf_InsertItem() was the only occurrence where the offset was zero,
a side effect of how the command line is parsed backward. This is now
done explicitly with playlist_NodeAddInput().
A non-zero positive offset made no sense, since:
- the number of children of a node can change asynchronously while the
playlist lock,
- the back-end asserted or triggered undefined behaviour if the offset
was out of range.
DBus was the only occurrence of this bug (see also #17451 comment:4),
and has been fixed in an earlier change.
In all remaining call sites, the offset was PLAYLIST_END. This removes
the parameter which would otherwise constitute a useless constant.
They are set but never used. In practice, the (following) position
parameter determines whether the item is inserted or appended. A
positive position means insertion; PLAYLIST_END means appendment.
- vlc_dialog_wait_question will replace dialog_Question
- vlc_dialog_wait_question with i_type == VLC_DIALOG_QUESTION_CRITICAL and
without action1/action2 will replace dialog_FatalWait
- vlc_dialog_wait_login will replace dialog_Login
- vlc_dialog_display_progress will replace dialog_Progress
- dialog_Fatal is replaced by vlc_dialog_display_error
- vlc_dialog_display_error will replace dialog_Fatal
- vlc_ext_dialog_update will repalace dialog_ExtensionUpdate
- vlc_dialog_wait_question and vlc_dialog_wait_login are interruptible via
vlc_interrupt.
- Nothing prevents to have more than one dialog type displayed at a time.
http://msdn.microsoft.com/en-us/library/b0084kay(v=vs.80).aspx only
mentions the _ prefixed variable.
gcc will always define the _ prefixed variable, like Visual Studio.
The prefixless one is defined in some language standards, e.g. gnu99
but not c99.