Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/23/21 5:34 PM, Michael Sweet wrote:
> Robert,
> 
>> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <rl...@al...> wrote:
>>> ...
>>> No, but having fixed limits does make memory usage *predictable*.
>>
>> Well, other than that the underlying driver might not have such predictable memory usage.
> 
> Well, I can't do anything about the drivers themselves, just PAPPL. :)

Sure, but what kind of devices are you looking at where even dynamic arrays that for most drivers
won't exceed maybe a dozen elements and even Gutenprint (which isn't designed to run on such
devices) won't exceed a few hundred will blow out memory?  Drivers that are complex enough to need
very large numbers of settings aren't likely to run in a very tightly memory constrained environment
anyway.

>> So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
>> of options (or one set of options for each group of options, such as Basic Printer Options, Basic
>> Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.
> 
> The usual way is for one attribute = one value (or set of values).  Collections allow you to define more complex values.

Complex values, not complex settings.  That's really not going to be sufficient.

>>> ...
>>> You already have a GTK+ UI, and modern web UI has similar capabilities.
>>
>> I'd just as soon use the existing GTK+ UI rather than have to write a new web application.
> 
> Well, that is ultimately your call.

Is this going to seamlessly provide the extra settings to users?  Or will they have to use the web
app to edit something to save as a named setting, but won't be able to change it on the fly?  This
sounds very painful for users with sophisticated needs.

>> Even a local TCP port (http or https://localhost) has its problems, since it means that something
>> running under a different UID can access it.  A lot of browsers strongly discourage use of http
>> these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
>> what looks to me to be dubious benefit.
> 
> Well, again PAPPL handles all of this for you, and yes I understand that browsers have totally screwed things up WRT IoT device access - that is something I've been fighting for the last 10 years - but the standards call for web UI because that at least is portable.

Ugh.  Tons and tons of JavaScript or the like.