Rewrite of the website

[coyoteclan]

I have looked through it fixed the issues I found. You might want to check FAQ and Wiki page @ivan-hc

[coyoteclan]

Some things that need to be done:

• Add APPIMAGE URLs from old markdown files to the sources field in the new json files
• Add json parsing support in AM, AppGallery (and vappman too?)
• Add pla-install URI handling in AM-GUI and AppGallery

The CONTRIBUTING.md is on it's way. Did I miss something?

[ivan-hc]

@andy5995 can you review this?

We also talked about this on Discord.

[coyoteclan]

added source urls from both UNOFFICIAL APPIMAGE: and APPIMAGE: lines in some apps

[andy5995]

@ivan-hc I will try.

In my opinion, if a lot of changes are needed for a website rewrite, then it normally should be done in smaller chunks so changes can be efficiently reviewed by the maintainer. If this were my project, I'd suggest a contributor submit the first required stage in a pull request. After that is reviewed and merged, then a "stage 2" commit and PR.

Why are over 3000 files getting changed in this single pull request? The site is normally generated using tools and scripts from the AM repo. If the existing site generator can't write the proposed changes, then my first thought would be a single converter script is needed in the AM repo that will implement the proposed changes to all the appimage entries.

I can't think of any more feedback right now, but if I do, I'll post here. And maybe I'll be able to review more once my questions are answered.

[ivan-hc]

@andy5995 I completely agree. Changes like this need to be analyzed in gradual phases. @coyoteclan here are too many changes to analyze.

[coyoteclan]

Why are over 3000 files getting changed in this single pull request? The site is normally generated using tools and scripts from the AM repo. If the existing site generator can't write the proposed changes, then my first thought would be a single converter script is needed in the AM repo that will implement the proposed changes to all the appimage entries.

This is a catalogue, it's expected. The generator script and workflow is updated. It does generate the new website. But I had to test it so I enabled the workflow and ran it. You can see individual commits.
Of course I had to convert the existing apps manually first to retain their data. But new apps and stats are generated like they were previously.

[andy5995]

Why are over 3000 files getting changed in this single pull request? The site is normally generated using tools and scripts from the AM repo. If the existing site generator can't write the proposed changes, then my first thought would be a single converter script is needed in the AM repo that will implement the proposed changes to all the appimage entries.

This is a catalogue, it's expected. The generator script and workflow is updated. It does generate the new website. But I had to test it so I enabled the workflow and ran it. You can see individual commits. Of course I had to convert the existing apps manually first to retain their data. But new apps and stats are generated like they were previously.

But there are thousands of changed files and thousands of changed lines in this commit. In cases like this, you need to eliminate all the changes that aren't required, submit changes for the script additions and changes so the maintainer (@ivan-hc ) can examine them without the extra noise. I understand you wanted to test, and that's great, but I believe @ivan-hc would need you to remove your test output/artifacts from the PR.

[coyoteclan]

Why are over 3000 files getting changed in this single pull request? The site is normally generated using tools and scripts from the AM repo. If the existing site generator can't write the proposed changes, then my first thought would be a single converter script is needed in the AM repo that will implement the proposed changes to all the appimage entries.

This is a catalogue, it's expected. The generator script and workflow is updated. It does generate the new website. But I had to test it so I enabled the workflow and ran it. You can see individual commits. Of course I had to convert the existing apps manually first to retain their data. But new apps and stats are generated like they were previously.

But there are thousands of changed files and thousands of changed lines in this commit. In cases like this, you need to eliminate all the changes that aren't required, submit changes for the script additions and changes so the maintainer (@ivan-hc ) can examine them without the extra noise. I understand you wanted to test, and that's great, but I believe @ivan-hc would need you to remove your test output/artifacts from the PR.

okay cool. I need further testing. I will copy the generated output in apps/ and re-add the old files temporarily when i am done. after the PR is merged, we can re-add the new app files back.

[coyoteclan]

@andy5995 i proposed a simple syntax for defining app info on pkgforge discord:

# some app
description of your app.
only use bold, italic, underline, lists markdown here
do not add links or images here
use SOURCES field if you package someone else's app

# SCREENSHOTS: https://someapp.io/1.png https://someapp.io/2.png
# SITES: https://someapp.io
# SOURCES: https://github.com/name/someapp-appimage
# BUTTONS: Label_of_Button::https://discord.gg Donation_Link::https://someapp.io/donate

the app.html file uses json

this info would then be converted to json by a script during pages deployment and served on the website
so this essentially gives us a nice API on website and AM can still get the raw info files from github repo because @ivan-hc prefers not to use jq and complicate the am -a option

this new syntax will simplify the AM about logic too because the format was pretty inconsistent previously

i am currently working on this

[coyoteclan]

@andy5995 @ivan-hc done.

this app info (AM can use this)
gets converted to this json
and shows as this page

check it out, check other parts of the website if you have the time, if there are changes to be made, i will do it. Then i will remove the 3369 apps generated and replace them with old md files for PR review

[andy5995]

I don't see this as being desirable. It would be an extra maintenance burden for this project to have links to the Discord, donation buttons for other projects. How would that information get updated when the links change or become dead over time? @ivan-hc agree?

buttons	
0	"Label_of_Button::https://discord.gg"
1	"Donation_Link::https://someapp.io/donate"

That's from https://coyoteclan.github.io/Portable-Linux-Apps.github.io/apps/testapp.json

[coyoteclan]

I don't see this as being desirable. It would be an extra maintenance burden for this project to have links to the Discord, donation buttons for other projects. How would that information get updated when the links change or become dead over time? @ivan-hc agree?

buttons	
0	"Label_of_Button::https://discord.gg"
1	"Donation_Link::https://someapp.io/donate"

That's from https://coyoteclan.github.io/Portable-Linux-Apps.github.io/apps/testapp.json

That's for an example. The original contributing.md said you can add extra buttons. So I included a way to define extra buttons. The matter of links becoming dead is same as it was before.
We could use a workflow to check for dead links, an action for that already exists.

[ivan-hc]

To write a markdown is simpler than compiling a json, and more customizable for common users.

[coyoteclan]

To write a markdown is simpler than compiling a json, and more customizable for common users.

i think you didn't read my message properly. Users write this:

# some app
description of your app.
only use **bold**, *italic*, ++underline++, lists markdown here
- do not add links or images here
- use SOURCES field if you package someone else's app

# SCREENSHOTS: https://coyoteclan.github.io/Portable-Linux-Apps.github.io/contribute_ss.png https://coyoteclan.github.io/Portable-Linux-Apps.github.io/contribute_ss.png
# SITES: https://someapp.io
# SOURCES: https://github.com/name/someapp-appimage
# BUTTONS: Label_of_Button::https://discord.gg Donation_Link::https://someapp.io/donate

it gets converted to json for site deployment automatically by the workflow but this info file remains intact in the repo. no json files are committed. the json files are only used on website. users write and edit the above mentioned markdown-ish format.

so like i said before, we are getting both benefits now:

• contributors only edit a simple info file
• we get a nice json api on the website

i updated the faq entry on how to improve app pages