GitLab

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>