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.
playlist_DeleteFromInput() requires recursive search through the whole
playlist to find the correct playlist item. This only makes sense if
the playlist item or playlist item ID are not known.
Passing a playlist item parameter to a locked playlist function cannot
make sense. This replaces the parameter with a boolean to select the
playlist or media lirary - like playlist_AddInput().
The prototype bug was introduced ed0b72e3 before the playlist tree
locking was defined/implemented, and somehow did not get corrected
until now.
Nodes are not supposed to have real input items. The parameter was
always NULL, except when copying another node, in which case it did not
matter whether it was or was not NULL.
Convert/Save dialog has had option to specify 'start time' but
no option for setting 'stop time' in the interface. The backend
'stop-time' option was already present. This patch simply adds
and enables the edit widget for end time in Qt interface.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The only V4L2 controls "without" minima and maxima are the 64-bits
integers. Those are not handled properly by the Qt UI anyway, since
neither the QSpinBox nor the Q(Abstract)Slider support the proper
range of values.
The dynamic type of the object referred to by "event" is not
QMouseEvent if "event->type()" is Event::Leave.
The previous implementation would unconditionally refer to the object
as-if it was a QMouseEvent when it is simply a QEvent; causing
undefined-behavior.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
Given that the media-library is conditionally enabled, the
implementation should not add an entity for such if it is not there.
This commit fixes that issue.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
This commit fixes the below:
- Since we are dealing with the playlist, it should be locked for the
operations inside PLModel::getPLRootType.
- There is a problem associated with comparing the value of the
different node's p_input (input_item_t*).
Given that the input_item_t* can be shared across several nodes, we
could end up in a state where the prior implementation leads to a
false-positive.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
This patch fixes ticket #10051, where it is described that one cannot
create a new directory in the playlist/media-library unless one does it
by right-clicking on an existing item.
In other words; if a request to create a directory is initiated in a
context where the list is empty, it would not work.
The reason is imply because the function prematurely returns if the
passed index does not refer to a specific item, and as such the relevant
check (and premature return) is removed in this commit.
PLModel::createNode already has functionality in place to handle
creating directories as top-level of the relevant playlist, so the
premature return was just blocking this from kicking in.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
Given that one should always be able to sort the playlist, aborting sort
on "indexes.empty()" is inaccurate since we should not mandate that:
- a user either right-clicks on an entity in order to sort, or;
- has at least one index selected.
This commit fixes the above described issue, as well as the arguments
passed to PLModel::sort. More specifically, that the first argument is
the first index (if any), and the second being the root index.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
There is no need to compare the index associated with the right-click,
and the return-value of "rootIndex()" now that VLCModel::getItem is used
instead of PLModel::getItem.
If "item" is NULL, we know that it is not an item within the playlist
(excluding the root).
This commit is also more than justifiable if one looks at the
implementation of PLModel::rootIndex; we should not go through all that
work when a simple NULL-check is sufficient.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
There is no need to lock the playlist if the index is not associated
with the current item, as such this commits first checks whether this
condition holds or not, only to then lock the playlist (when it is
actually necessary.
PL_LOCK / PL_UNLOCK has also been replaced by usage of
vlc_playlist_locker.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
A user should be able to add something to the playlist as long as we
are not invoking the action upon an item that is already there,
as such; checking the return-value of getPLRootType() is enough.
This commit removes the redundant check that follow, and also makes it
clear that we would never fall-through to ACTION_SORT.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
Given that the relevant action saves the current playlist (ie.
ROOTTYPE_CURRENT_PLAYING) to a file, it only make sense to show this
option if the user is actually looking at that playlist.
This commit changes the logic associated so that it appears when that is
the case, not just because we have items in the current view.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
It is not enough to simply check if an item's URI starts with "file://"
as it will lead to false-negatives. As an example, if the associated
item has a MRL starting with "file/es://...", we would consider it not
to be part of the local file-system (and as such, we do not provide the
option to explore the associated directory).
This commit fixes the issue by invoking vlc_uri2path, if we get a a
non-NULL pointer as the returned value, the item in question resides in
under a path that is suitable for exploration.
As a note; using vlc_uri2path is what is being done when ACTION_EXPLORE
is actually initiated - this commit can as such be viewed as creating
symmetry between checking if it is a supported action, and invoking it.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
Enqueing (adding) items to the current playlist should always be
accessible as long as the playlist where the context-menu is brought up
can be changed by the user.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
A user should be presented by the option to clear the playlist, as long
as;
- the playlist is allowed to be changed by the user, and;
- we have at least one entity inside of it.
This commit changes the previous logic so that it follows the reasoning
above.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
The associated logic has been changed so that the option is enabled, if;
- we are allowed to modify the playlist, and;
- the playlist is a tree, and;
- we either are creating a top-level entity, or the entity to which
the newly created node will belong is not read-only.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
Prior to this commit, ACTION_PLAY was supported if:
- the index was not associated with the currently playing
item, or;
- the playlist was paused.
In other words, the option would not be enabled if the playlist was in
a stopped state.
This commit changes the associated logic to the following, meaning
that the action is supported:
- when the user has right-clicked on an entity, and;
- the playlist is either stopped or paused, and;
- the associated index is not currently playing.
Usage of PL_LOCK/PL_UNLOCK has also been replaced by vlc_playlist_lock
to aid code-reasoning and maintenance.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
PLModel::getItem, which was used prior to this commit, will return
either the item associated with an index, or the item referring to the
associated playlist (currently in flight).
Given that we have options that shall only be available if the index is
associated with a given item, simply having a check to see whether
"item" is not null will ease implementation (the alternative is to
compare it to "rootItem", which is redundant).
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
The index passed will be considered invalid if the user right-clicks on
an area that does not belong to an entity.
Given that there are options that certainly are supported when such
right-click is in flight, we should not prematurely return from the
function; instead each case should respect whether we have a non-root
item tied to the on-going request or not.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>
Rémi Denis-Courmont
Rajeesh K V
Filip Roséen
Steve Lhomme
Thomas Guillem
Francois Cartegnie
Anatoliy Anischovich
Hugo Beauzée-Luyssen
Jean-Baptiste Kempf