Clipboard > "QR code is too large to be displayed"

image

…so how can I access it? I don’t see an option to invoke the image in the default image viewer.

You just need to expand the panel or in your case - the window - a bit

2 Likes

I didn’t realize that that was possible! Thanks.

Hmm, perhaps it should tell you to resize the popup when this happens.

2 Likes

And we probably shouldn’t offer the super inefficient and lossy 1D barcodes there at all. In fact I’m wondering whether there is a use case for allowing to change the format to anything else than QR here at all, aside from “because we can”.

1 Like

How do you even do that? All I see is a show QR code option, that I never noticed (and unsure why you would need this)?

Yes, I suspect that was the motivation. :slight_smile: If we limit it to only one type, we can eliminate this error and also the somewhat odd format chooser UI.

What’s the problem with barcodes, @vkrause and @ngraham? I can’t see why the ability to view them would be disadvantageous, since it means that those who want to use barcodes rather than QR codes need not convert them.

I suppose that if there were well-known, decent software that did this, it wouldn’t be problematic (since it would simplify the codebase) but I don’t know of any.

Let me ask the reverse question: how is the ability to choose a barcode/qr code type useful? What does this feature let you do that you wouldn’t be able to do if it could only display one type?

@ngraham, nothing, to my knowledge – a QR code should be possible to convert to a barcode, after all. But that’s like saying we shouldn’t support JPEG in #Gwenview, because TIFF is better.

I’d love to be perfectionist, but usually it’s not very convenient.

It’s actually quite different, because Gwenview is a viewer app so having broad support for file formats is a good thing, and JPEG and TIFF are completely different file formats with different design goals and use cases. For example JPEG is not suitable for long-term archival due to its lossiness, while TIFF is not suitable for quickly and casually sharing photographic images due its large file size.

In this case we’re talking about an output UI where there is no meaningful differences between the many kinds of bar/qr codes it can output. In such a case, offering a choice is pointless because it’s a false choice: any choice you make changes nothing, affects nothing, makes no difference whatsoever. So offering that choice simply increases code complexity and creates opportunities for bugs–such as the one you found that prompted this thread.

2 Likes

Alright, you’ve won me over. I don’t frequently use barcodes anyway, and I’m not gonna be the new maintainer for the project.


I only provided the comparison between JPEG and TIFF because lossy < lossless (in ideal scenarios). We could both write a thesis about the actual winner in certain scenarios, like decompression time and metadata support.

Right, and even worse for the 1D formats, those can only practically hold 10-20 bytes, and only support a restricted character set. So for a lot of content you end up with something that either doesn’t show up at all or loses relevant information.

1 Like