Re: [Libmtp-discuss] Album and Playlist suggestions

[Ali S. <ca...@gm...>]

Hi, please see the attached patch files, I took a guess and assumed that I
can just cat multple (relevant) patches together. I hope this works out, its
my first time submitting a patch :)
These patches address the lack of a parent_id field in albums and play
lists.

I would just like to clarify one point:
When a new album is created on the device, LIBMTP shows two different
versions of the same information. One version is the album abstraction, this
contains the metadata, and track information. The second version displays
the album file. This file has the raw file name, with the .alb extension,
and its size.
It is shown because the only ObjectFormat that is skipped when creating the
file listing is the PTP_OFC_Association type. Thus, libmtp reports a new
file. However, if a GUI wishes to show both, files, and albums, the creation
of a album, should show up as a file as well. However, when an album is
created, the only information the caller (GUI) has is the album information.
There is no way to get the implicit object information that is created,
without calling  LIBMTP_Get_Filelisting_With_Callback and searching for the
object that has the same id. This is a bit tedious and wasteful. It seems it
would be best, allbeit a bit messy, if Create_New_Album returned a pointer
to the LIBMTP_file_t* that holds other information, such as the object file
name, and its size. Or, alternatively, albums should not appear in the
filelisting at all. But that sort of  breaks the linux philosophy that
everything is a file :)
Please let me know what you think,
Ali

On Tue, Feb 26, 2008 at 4:56 AM, Linus Walleij <lin...@gm...>
wrote:

> 2008/2/26, Ali Shah <ca...@gm...>:
>
> > I would like to suggest some policies regarding the way we handle the
> > derived file types, Album and Playlist.
> > I propose that LIBMTP_Album_t and LIBMTP_Playlist_t both should have a
> field
> > for their parent directory rather than  supply a parent directory at the
> > time of creation.
>
> Why not both...? You have this new field and you supply it at creation
> time also (as we do today).

> The reason being an LIBMTP_Album_t is displayed as a file on my device
> (and
> > i expect most other devices). This means that when we create new albums,
> a
> > new file must be created to represent this via LIBMTP_new_file() as
> libmtp
> > does not implicitly create an encapsulated file for every new derived
> type
> > we create on the device (eg track, album or playlist).
>
> I don't quite follow this. We create objects for albums and playlists
> alike,
> they are no different from tracks or files or folders. They should turn up
> in
> file listings with "mtp-files" with apropriate suffixes afterwards.
>
> That is I *DO* think we create an "encapsulated file" (whatever that is,
> this
> is not PTP/MTP terminology).
>
> > This way when a new album is created on the device with this field set
> to 0,
>
> You mean the parent_id field?
>
> > it can be updated to the corresponding default destination's ID.
>
> No it can't. After some tiresome testing we concluded that you cannot
> update parent_id on objects on any devices on the market. You have to
> specify parent ID when you create any object, no matter if it's a file,
> track, playlist etc. It cannot be changed afterwards.
>
> > This helps
> > us GUI makers keep different views of the underlying file/album/playlist
> > abstraction in sync with the device, since we can tell who the parent
> folder
> > is for the given album and look it up in a hash table etc.
>
> Yeah it's still good to have the parent_id I guess so we could add that
> (interested in writing a patch?)
>
> But you will never be able to move tracks or filelists etc around in
> folders on the device in any simple way. The devices are not designed
> to handle this.
>
> > Sometimes I wonder if the policy should be that when a new derived file
> type
> > is created on the device, libmtp should create a file as well.
>
> It does. It creates an object, e.g. a playlist "foo" is created as an
> object
> with filename set to "foo.zpl".
>
> > The reason is
> > simple: if one were to disconnect the device, and reconnect it, one
> would
> > see two duplicate object IDs. One of which is a file and the other would
> be
> > the derived file type we created, perhaps this could be returned via a
> > double pointer from the LIBMTP_Create_* functions.
>
> Uh... you should only create albums, playlists and albums with the
> LIBMTP_Create_Album() etc functions, not by abusing the file API.
>
> Perhaps I don't quite understand this... please correct me. :-/
>
> Linus
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Libmtp-discuss mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmtp-discuss
>