Posted: Mon 11 Sep 2017, 12:28 Post subject:
A local /usr/share/docs/packages.htmSubject description: A page listing all the packages in your Puppies repo, with links to download

Suggestion: An even easier way to download packages from online

SUMMARY:

A shell script to generate a static HTML page, maybe during a woof build
which lists a table of packages for each supported repo, with each pkg
name being clickable link, straight to pkg (.deb etc) download.

(This is a much simpler alternative to hosting a cool package search site
online somewhere, and a nice page to link to from the default homepage)

DETAILS:

One of Puppies main goals is ease of use.
Puppy often goes the extra mile to make things, easier, simpler, faster.

- finding the Debian/Ubuntu/Slack/other packages site themselves,
- then finding the right DISTRO_BINARY_COMPAT version (stretch, trusty, wheezy, xenial, tahr, etc),
- then finding the package,
- then finding the right architecture,
- then choosing a mirror,
- and finally getting their download...

We could have a link in /usr/share/docs/index.htm to a page which
was generated in woof at build time, and contains a simple listing
of all pkgs from that puppies repo files.

For example, /usr/share/docs/packages.htm

Which could list ALL packages available in the repos, each repo in a
separate HTML table, with name, deps, size, description, and a clickable
link to download the package (woof knows the mirrors that worked at
build time, at least!).

Any deps listed could simply be anchor links (like #pkgname),
which takes the user straight to the package on that same page! How easy..

As in my other post about the default Puppy homepage, we know that
at build time, woof knows (more or less) enough about the Puppy being
built to generate links to specific, relevant web pages..

.... This (mostly generation of a big long HTML table in woof
somewhere at build time) may be a great way to easily download
pkgs from all over the place , and save Puppy users having to trawl
around the interwebz..

---- Improvements ----

However, lots of long table are boring, and hard to scroll around, so some
'accordion' CSS/JS could be used to make each repo table expand/contract
when its Heading is clicked ..

Same for package entries themselves - click a package row, it could
expand/contract to show/hide more details..

(So, something like the pkgs.org interface, but a local single HTML file,
listing all locally installed repos, and generated by a script)

The script that generated this packages.htm page could be re-ran to keep
it up to date (if its generated from the local config and repo files anyway)..

The above will cut the fields we need, then convert ^ (start of line), the | and also
$ (end of line) to HTLM <td> stuff .. It is much faster as it does the file all in one
go (not line by line).. but won't give you links/urls ..

EDIT:

FWIW, I cleaned up the file a little, keeping the HTML as concise as
possible, got the file down to ~1.8mb, then made an sfs of the .htm
file to see (very roughly) how small it would compress:

1. Add a search filter
- add a <script> tag just before the closing </body> tag of each page
- use JS to put a search box as the top of each repo page
- inside the <script> tag:
- use JS to get search term from search input field
- hide (add css display:none) to all non-matching <tr> elems
- clear search field to unhide all elems

2. Don't list deps in the main tables
- list deps as data-deps="" in the <tr>s instead
- click a package, get a popup modal with all pkg details
- modal lists deps as links, to easily download package and its deps all in one place
- popup modal can be achieved with a totally centered <div>, plus CSS to hide/show it
- click the DOWNLOAD button in the modal popup to download the pkg

3. Auto generate links to more packages
- as in this thread, generate links to Slackware/Ubu/Deb package sites
- show links to extra packages under the repos list, in same style

With 'progressive enhancement', features 1 and 2 would only appear if the
users browser supported JS, otherwise they would get just the static
HTML pages as they are now.

...Alternatively, the sh script could be altered to generate a PERL .cgi file,
and the page loaded up on http://localhost, and then more dynamic
behaviours and backend cleverness could be added that way (query strings, calling cmds on the system, etc)._________________Akita Linux, VLC-GTK, Pup Search, Pup File Search

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum