michaelrsweet / pappl

PAPPL - Printer Application Framework
https://www.msweet.org/pappl
Apache License 2.0
309 stars 49 forks source link

Allow adding explaining text to web interface pages #183

Closed tillkamppeter closed 1 year ago

tillkamppeter commented 3 years ago

Now after having posted 4 CUPS-driver-retro-fitting Printer Applications in the Snap Store I see one, really missing feature for improving user-friendliness and ease-of-use of PAPPL-based Printer Applications:

Adding explaining texts to web interface pages.

Here I do not mean hard-coded texts coming from PAPPL, but texts supplied by the developers of the PAPPL-based Printer Applications.

Most important example is the "Add Printer" page: Here could be written which kind of printers the Printer Application generally supports (the HPLIP one for example most HP and Apollo printers, and also tell the user that if their printer appears more than once under the "Devices", which entry is recommended, for HPLIP for example that the HPLIP entries (using the HPLIP backend) allow for simultaneous printing and scanning and also could in some cases lead to higher print quality, whereas the standard backends allow for polling installable accessory configuration and option defaults from PostScript printers. There could also be hints at the "Drivers" list to help the user to choose the best driver entry for his printer (if "Auto" turns out to be unsatisfying for his particular printer).

Also hints on the "Media" and "Printing Defaults" pages telling that the actually available options and choices depend on the installable accessory configuration as set under "Device Settings" could be useful (PostScript, Ghostscript, and HPLIP Printer Applications).

Another possibility would be to add some introducing text on the main page of the web interface.

An example web interface page with explaining text (not from PAPPL) is the "Add PPD file" page of the PostScript Printer Application.

There should be the possibility to add a text for the page (at the top, after the title and before the first interactive widget), for each static widget of the page (on "Add Printer" for "Name", "Device", "Host/IP", and "Driver"), and for each group of dynamic widgets (on "Printing Defaults" for the vendor-specific options).

tillkamppeter commented 3 years ago

Also for printer web interface pages ("Media", "Printing Defaults", ...) text addition should be possible individually per-print-queue, so that for example any hints about installable accessories only appear for printers where the driver actually supports managing installable accessories (for example in the retro-fitting Printer Applications the printers which have an "Installable Options" group in their PPD files).

michaelrsweet commented 3 years ago

Will include this in the localization work for 1.2

michaelrsweet commented 2 years ago

Adding this sort of text/UI is going to be complicated - I want some more time to figure out the best way to integrate this and what to add.

michaelrsweet commented 2 years ago

@tillkamppeter OK, so looking at this I don't see extending things to allow annotation of every form control - that just isn't feasible to support since you can expect random HTML changes that would alter the naming or layout for each feature release.

Adding support for a per-page (based on the resource path) is doable, e.g.:

"/media" = "Some text to show at the top of all media pages.";
"/printername/media" = "Some text to show at the top of the media page for printername.";

Thoughts?

tillkamppeter commented 2 years ago

Yes, introducing a possibility to add text for each page, as you suggest, would already be great, especially with assignment via resource path, as this also allows per-prnter variations, as for example to have different texts depending of whether there are installable accessories or not.

Per-widget would also even be possible, as each widget has a name, to make its value available when submitting the page:

"/printername/media:quality" = "High quality mainly for photos, not much enhancement for text"

This naturally requires that widget names are kept stable between PAPPL releases.

michaelrsweet commented 2 years ago

This naturally requires that widget names are kept stable between PAPPL releases.

... which isn't something I want to commit to since I want to be able to change the feature set and web UI between feature releases.

michaelrsweet commented 2 years ago

Will implement per-page text banners for 1.3.

tillkamppeter commented 2 years ago

OK, let us go this way.

michaelrsweet commented 1 year ago

Changes completed:

[master dc8714c] Add support for per-page text banners/headers (Issue #183)

[master 4e4e039] Add support for default localization for printer pages (Issue #183)