Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Exposing custom options in the web interface #2807
Comments
|
CUPS.org User: till.kamppeter This was already reported as STR #1729 (http://www.cups.org/str.php?L1729). |
|
CUPS.org User: larsuebernickel I've just applied the patch against the latest subversion code (revision 7493), and it works without problem. |
|
CUPS.org User: mike This is a dupe of STR #1729; moving the patch over there, however your patch will still require a bit of work since we can't depend on Javascript for the user interface (that breaks text-only browsers which we do support). Thanks for the patch! |
|
"cups-1.3.7-expose-coptions.patch": diff -aur cups-1.3.7/cgi-bin/admin.c cups-1.3.7-mine/cgi-bin/admin.c +/*
/*
title = cgiText(is_class ? _("Set Class Options") : _("Set Printer Options")); @@ -2910,7 +2960,7 @@
- */
- continue;
@@ -2936,6 +2979,70 @@
@@ -3185,10 +3298,15 @@
Only in cups-1.3.7-mine/cgi-bin: tags
+TH.sublabel {
HR {
|
michaelrsweet commentedApr 18, 2008
Version: -feature
CUPS.org User: larsuebernickel
Hi,
attached is a patch which adds support for setting custom options to the web interface. The patch is against 1.3.7, because svn wouldn't compile for me last night.
It basically adds a 'Custom' choice to all PickOne options (i.e. it doesn't hide it anymore). Whenever that choice is selected by the user, the parameters for that custom option are displayed and can be set. I used some javascript in the templates for that - I hope that's okay.
Open problems: For now, all parameter types are set via a simple text input and are not validated in any way. Also, Multi-parameter options have their parameters shown in alphabetic order, which is kind of weird for PageSize for example (first Height, then Width).
Please tell me what you think of it and if I'm headed in the right direction (This is my first time with the CUPS codebase ;) )
P.S: Slightly off topic: CUPS seems to ignore the *CustomFoo and *ParamCustomFoo keywords if they are between *OpenUI and *CloseUI. Is this intentional? I think it'd make more sense inside *OpenUI and *ClosUI ... The GTK+ printing dialog recognizes them in any case, and that's also the way I implemented it in foomatic-rip. The docs are not really clear about this either ...