My Suggestions, in short:
- build good command line apps, and then make separate (gtkdialog) GUIs for them
- Puppy needs a command line package manager (like mine, but better...see latest posts in thread for downloads)
- Puppy needs a fancy, web-based repo/pkg browser (local or online) .. (like salix pkg search, alpine pkg search, or tinycore pkg search)
- Puppy needs a public website for building custom Puppy ISOs
- Puppy needs contrib repos for each official release
Please post YOUR suggestions to this thread about:
1. Improving command line tools in puppy:
- what CLI cmds are missing in Puppy that you like? .. convert? locate?
- what CLI cmds are pain (or scary) to use? .. i hate fdisk..
- what CLI cmds should *Puppy* have? .. pupinstall (like Universal Installer, but no gui), adblocker (like Pup-Advert-Blocker, but no gui), etc
- candidates for "separation of GUI and CLI", such as: Peasywifi, pup-advert-blocker, puppyinstaller, sns, others?
- de-coupling puppy apps from X
- how to improve command line option handling (links to good recipes, ideas, snippets, etc)
- what you want from a CLI package manager
- how to improve error code handling (links to good shell tutorials)
- how to go about making a web-based package manager frontend
- how to best fork and edit the Salix package search site, then where to host
- desired features/workflow/options for Pkg
- suggest command/features you like in other pkg managers that you want in puppy
- etc
2. Suggest command/features you like in other pkg managers that you want in puppy
- what you want from a CLI package manager
- desired features/workflow/options for Pkg
3. Suggestions for a localhost, PHP/PERL web-based frontend for Pkg
- how to go about making a web-based package manager frontend
4. Suggestions for a 'Puppy Linux Package Search' website
- how to best fork and edit the Salix package search site, then where to host
More info:
A command line package manager is not available in Puppy.
PetGet can do only the very, very basics without loading up GtkDialog.
In fact, no apps should need gtkdialog, or even X .. Only their frontends should
NOT building separate UIs and backends is a bad habit of many devs and users (myself included)!
EDIT : AntiX has this: https://github.com/BitJam/cli-shell-utils
A small gtkdialog GUI (like Pup-Advert-Blocker) has the following requirements:Integrated utilities for CLI programs (that can be called from GUIs)
- boot all the way to desktop
- get a WM with menus.. or get a terminal emulator
- find and use a separate GUI to configure net connection, if needed
- find Pup-Advert-Blocker, load it up
- read it, click the right buttons
- ...now finally it runs .. phew!
To prove the point, In the Advert-Blocker thread, technosaurus posted a little bash script to do the same ad-blocking automatically..
His script could be added to startup even before X is trying to load..
EDIT: In fact, it someone DID re-use the command line version and cut out the GUI stuff (for their own): https://github.com/antiX-Linux/advert-block-antix
Another example: Deluge BitTorrent client, in 'ThinClient' mode, separates its daemon (backend),
and offers 3 different UIs to interact with it... You can manage your torrent from command line,
web browser, GTK interface, or just leave the daemon running in the background...
https://askubuntu.com/a/65406
1. Separating a program into CLI and GUI components have has benefits:
* can have a user-friendly, simple, painless setup and install without X
* Puppy users would get lots of unique, user-friendly command line tools
* these puppy-only CLI tools would make no X setup much less painful on old hardware
* users like radky, zigbert and others would have lots of great tools to build GUIs for!
* can use a program without X and its many deps
* can have multiple frontends and GUIs for the program
* can easily create simple-to-use wrappers for more advanced/complex command line tools
* command line tools can work over ssh, in chroots, fake roots, etc
* command line tools are more portable, often requiring no binary deps
* command line tools are scriptable, GUIs are (usually) not
Having lots of good command line tools also means you can provide other users with better documentation,
with well commented, reproducible, copy-and-paste code examples for common tasks..
2. Having a CLI package manager would have these benefits:
* can add/remove pkgs from a remote system (using ssh, or a chroot)
* easier to build/compile pkgs on a remote system
* can update the PPM features without breaking the GUI(s)
* puppy could more easily be used with Vagrant, Docker, etc
* could even have a fully featured pkg manager in the initrd, for some reason..
* programmable in other scripts: other scripts can call the package manager, even in the background to easily setup stuff.
So, for example, I made a command line package manager called Pkg-1.9.0alpha-noarch which has 3 different interfaces:
- the command line interface, with context-sensitive TAB completion of options, pkgs name, repos, etc
- a ncurses/dialog based frontend called Pkgdialog (similar to the Pkgtool and Sbopkg interfaces)
- a GTK interface (using gtkdialog) similar to PetGet
3. Puppy needs a *collection* of various package manager frontends:
* a dialog frontend for easy menu-based package management without X
* a gtkdialog frontend for an easy, gtk based GUI in X
* a command line PHP or CGI (PERL) interface (using query strings, a wrapper for the real command-line pkg manager)
* an HTML4/CSS2/JS web frontend for the PHP/CGI backend
* the package manager web frontend(s) could be accessible over localhost
4. Puppy could have a public website for building (remastering) custom Puppy ISOs
* needs the site hosted at ibiblio, with all the official release ISOs
* needs a PHP powered web server
* web server needs some scripts available to unpack ISO, unpack SFS, chroot into SFS, update pkg selection, [replace kernel and boot manager], rebuild SFS, rebuild ISO
* a command line pkg manager (installer/remover) of some kind would be needed for this to work
5. Puppy users need an easier way to share PETs and packages they make or compile.
* contributing .petbuilds scripts is the besy way to go
* creating a contrib repo is also a good idea
* currently other users would have to hack various files in /etc and ~/.packages to add another users contrib repo
* Puppy users need an easier way of creating their own contrib repos
* Puppy users need an easier way of sharing, adding and removing other users contrib repos to their system