Change --text from argument to option

[maresb]

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.

[maresb]

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.

[tomers]

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?

[maresb]

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.

[maresb]

@tomers, I think I figured it out!!! :tada: