Open maresb opened 4 months ago
I still feel really conflicted about this. I know that this forces the user to be explicit about their attention, this avoids assumptions about a text element being essential, making it much less awkward to print just a QR or picture. But what if the primary use case is the occasional CLI user who 90% of the time just want to print a text label?
I think one of the things dymoprint
really got right is simplicity. If a user wanted to print hello world
they simply need to run
$ dymoprint "hello world"
Now the interaction will go something like
$ labelle "hello world"
Usage: labelle [OPTIONS] COMMAND [ARGS]...
Try 'labelle --help' for help.
╭─ Error ───────────────────────────────────────────────────────────────────────╮
│ No such command 'hello world'. │
╰───────────────────────────────────────────────────────────────────────────────╯
$ labelle --help
Usage: labelle [OPTIONS] COMMAND [ARGS]...
╭─ Options ─────────────────────────────────────────────────────────────────────╮
│ --version Show application │
│ version │
│ --verbose -v Increase logging │
│ verbosity │
│ --sample-pattern INTEGER Prints test pattern of │
│ a desired dot width │
│ [default: None] │
...
╭─ Commands ────────────────────────────────────────────────────────────────────╮
│ list-devices │
╰───────────────────────────────────────────────────────────────────────────────╯
and now the user needs to read through the menu until they figure out that they need --text
before "hello world"
. And if a user only uses labelle
once every few months, they will forget and need to repeat this process each time they want to print a label.
This may not seem dramatic, especially since we have our eyes so close to the code, and we are not the ones who would forget about --text
. But Linux has a lot of CLI afficionados, and they tend to prioritize simple textual interfaces above all else. With this change, we are obligating them to use a more complicated interface. The above interaction will may require a few minutes instead of a few seconds. I suspect that given the choice, a significant fraction of users would prefer to downgrade to dymoprint
.
I'm no UX expert, and I don't know what the right way forward here is. But I do think there is a logic to giving a CLI a default-to-text interface. I'm questioning if this change is prioritizing development convenience over interface simplicity.
I don't really think we have many CLI users, and I think CLI is just a nice to have tool for sofisticated users. I think we should grow out of the concept that we do a nice utility to print simple text labels, and aim for a more complex tool, which allows us to design sofisticated labels, and which gives great GUI, web interface, libraries, etc.
I basically agree with what you say, but the thing is that default-to-text implementation is a burden on me, and prevents me from introducing actions (such as list-devices
and status
). I think we can do enough by printing some helpful message like:
> labelle hello
*** did you mean to type `labelle --text hello` ? ***
... label help section comes next ...
So to summarize, I personally don't want to invest any more time on this, and I do want to have ability to provide actions other than just 'print' in the CLI. As long as there is no other way around this, I would still want to see this PR merged. Thought?
I don't really think we have many CLI users
I personally have the opposite impression based on recent interactions, e.g. #40 and this blog. But of course this is just speculation.
I think we can do enough by printing some helpful message like:
I think that would be a great solution. However, I don't immediately see any straightforward way of implementing this, since it seems like the argument parsing is handled deep within Click's internals.
@tomers, I think I figured it out!!! :tada:
This is a breaking change. It puts text on the same level as the other options like image or barcode. It is breaking because it now requires any text to be preceeded by
--text
.Ref: https://github.com/labelle-org/labelle/pull/12#issuecomment-2079204101 and below.
To be merged only before a major release.