Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More metadata for queried manga #4

Open
ghost opened this issue Apr 6, 2021 · 6 comments
Open

More metadata for queried manga #4

ghost opened this issue Apr 6, 2021 · 6 comments

Comments

@ghost
Copy link

ghost commented Apr 6, 2021

Hi there,

I was wondering if you had planned to implement the ability to add more metadata to a manga in the listChapters function. For example, adding the author, cover art, description, etc.

Something like this:

return JSON.stringify({
  title: 'One Punch Man',
  description: 'Formatted\nText',
  author: 'ONE',
  cover_url: 'https://example-url.com/',
  chapters: [
    {
      id: '866961',
      title: 'Ch. 131 - Heroes Never Lose'
    },
    {
      id: '952595',
      title: 'Ch. 132 - Something Huge'
    },
    // ...
  ]
});

I'm not sure if it's possible, since it would probably require changes to the main program, but I was just curious if this was on your roadmap.

Thank you!

@hkalexling
Copy link
Member

Hi!

I do wish to revamp the plugin system, but I don't have a concrete plan at this moment (see getmango/Mango#24 (comment)).

Some of the more advanced features are only available in the built-in MangaDex downloader (not the MD plugin). These features include manga searching (tho you can hack this like what you did with the Manganelo plugin), chapters filtering, and the auto-updater. I would love to move these features to plugins as well, so we can just maintain an official MD plugin and retire the built-in downloader. What you suggested also makes sense, and I will try to include it in the v2 of the plugin.

I will create a draft/RFC for the new plugin system when I have the time, so you or the general users can criticize and give feedback. Since you are now experienced with developing the plugins, if you want to and have the time, feel free to take the lead with the draft and I will just chip in. Anyways, please feel free to suggest other improvements that you want to see!

@ghost
Copy link
Author

ghost commented Apr 8, 2021

Thank you for your response. It's great to hear that it'll come sometime in the future.!

When I'm free, I'll have a look at what I can do. I'm not at all familiar with Crystal, so I might not be too useful but I'll try and see how much I can accomplish.

@hkalexling
Copy link
Member

hkalexling commented Apr 8, 2021

@TheBritishAccent Oh, don't worry about the main app and Crystal. I was thinking that we can first design the new JS API similar to what we have in the Wiki. So to list down the steps:

  1. Design the new JS API/interface and document everything (this is only about the JS part, and we just need to design and document the interface in Markdown)
  2. Brainstorm and improve the design, and open an issue for other users to comment
  3. I will then implement the interface in the main app with Crystal

So I was thinking perhaps you could help with step 1 (if you want to, of course!). Don't worry if you can't - I will be happy to do it myself :)

@GlassedSilver
Copy link

GlassedSilver commented Aug 22, 2021

The cover should be a local file and not depend on hotlinking to an online source that may go down at any time, disallow hotlinking, change the URL scheme or anything else getting thrown between the Mango server and theirs. At least in my opinion.

Maybe even store covers per volume and then a general one, one that may move along with the latest volume or the earliest, based on user preference.

Just an idea though.

cough

Well... I just checked out the existing file and realized that's how the internal path is referenced. Nevermind! Sorry for that.

@hkalexling
Copy link
Member

@GlassedSilver I think it's still a valid point. Currently Mango uses the first page of each cbz file as the cover, which can be overridden by custom covers uploaded by the user. The nice thing about getting the cover from a remote URL is that for ongoing manga the cover will get updated frequently, so the user can always expect the latest cover. So the order of precedence can be custom upload > remote URL > first page. That is, when the remote URL is not responding or returning an error code, fall back to use the first page.

@GlassedSilver
Copy link

@GlassedSilver I think it's still a valid point. Currently Mango uses the first page of each cbz file as the cover, which can be overridden by custom covers uploaded by the user. The nice thing about getting the cover from a remote URL is that for ongoing manga the cover will get updated frequently, so the user can always expect the latest cover. So the order of precedence can be custom upload > remote URL > first page. That is, when the remote URL is not responding or returning an error code, fall back to use the first page.

The remote should not be hotlinked, but downloaded imho.

Also, those updated covers usually are for specific volumes.
Personally I store my covers in the manga folder as cover.ext or in the volume subdirectories as cover.ext.

I think it could be nice to automatically check for that and reference that file in the json. Any uploads would then be overrides.

That's also how Mangadex stores and picks covers: per volume (at least from my observations so far).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants