Integrating Flameshot into SingleFile?

[Yekutiel]

I suppose this feature request is probably out of scope and too technically daunting, nevertheless I figured I'd ask: have you considered integrating Flameshot into SingleFile?

SingleFile's annotation features are nice, but a little too limited for my needs. Ideally I would like to use Flameshot when using SingleFile to annotate a webpage.

[gildas-lormeau]

I add similar ideas but the problem is that it is impossible, as far as I know, to constrain the width of the page and make sure it works in all cases. Because of that, I cannot guarantee that what you draw will be correctly placed.

[Yekutiel]

Thanks for letting me know. I appreciate that.

[gildas-lormeau]

I keep it in the back of my mind. One day, I may find a solution :)

[Yekutiel]

I'm not an engineer, but here are a couple of my thoughts...

First, if one of the problems is that a screenshot might "float around uncontrollably" would it be possible to anchor a screenshot relative to other elements on the page? That is to say, if you know where elements A, B, and C are located on a page, and if a screenshot were element D, then would it be possible to anchor element D relative to elements A, B, and C? I have no idea if it would be feasible to store such "metadata."

Second, would it be easier to consistently orient a screenshot if SinglePage were to create an ODT or RTF file instead of creating an HTML?

I'm not trying to brag, but I've worked with many engineers. I have often been able to provide them with creative solutions to what they consider to be vexing logical problems. In other words, if you can explain the logic that is preventing you from implementing this feature, I might be able to construct a somewhat convoluted, yet effective approach to solving the problem.

Engineers almost invariably become stymied by an irresistible temptation to myopically focus on efficiency. An example of this is premature optimization. I despise premature optimization. Engineers are like moths drawn to a flame when it comes to premature optimization.

By contrast—at least initially—I tend to eschew efficiency in favor of effectiveness. Yeah, sure, 9, or 10, or 11 steps might seem absurd.... and slow.... and, well, ummm utterly ridiculous to you, but as a user I would rather wait 50 seconds to have a feature I want, than to not have that feature at all.

Engineers typically roll their eyes and tell me I'm being absurd. Look. Ok? Apple Inc created an entire brand around making user friendly software and hardware. Sure, Apple products are overpriced; I don't use them. But I admire their focus on making user friendly software and hardware.

I will be blunt: I am almost certain there's a way to add the feature I want.

[gildas-lormeau]

To give you an idea of the problem, imagine that you draw something on an element, e.g. an image, on your PC and then this page is displayed on mobile. Many pages adapt the content to the screen. Thus, the element may be smaller or absent. You would have to be able to adapt to this kind of problem. This is a simple example. You can also imagine that the drawing (e.g. a circle) is anchored to 2 elements, e.g. an image and a piece of text displayed on the right on a PC. But on mobile, the text would be displayed below the image.

As a result, I feel that the only way to implement this feature would be to restrict the width (and/or height) of the page so that this problem does not arise. The disadvantage, of course, is that the page would no longer be able to fit the width of the screen. The only way to achieve this is to use an <iframe> element. This is not a beautiful solution but it would work, from a technical point of view.

Today producing something other than HTML is out of scope. It would also require a lot of work.

[Yekutiel]

Many pages adapt the content to the screen. Thus, the element may be smaller or absent. You would have to be able to adapt to this kind of problem.

That final assertion is false. It. Is. Utterly. Totally. And. Completely. False.

You have imprisoned your mind with limitations that don’t exist by implicitly conjuring up what you have deemed… An Essential Requirement. I found the following quotation on The Internets…

The humorist Mark Twain is often credited with a variation of this: “It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.”

Please keep in the front of your mind the adage that, "The perfect is the enemy of the good." You aren't working at Amazon or Google on The Next Big Thing. You are a little FOSS dev who is maintaining a very useful software application. That matters. A lot.

Therefore, it would be reasonable to indicate something like, "Due to technical limitations, screenshots you add as annotations with SinglePage will normally only reliably be displayed on approximately the same size computer monitor which you created them. In other words, normally you won’t be able to reliably display screenshots you have added as annotations with SinglePage on—for example—both your 32 inch computer monitor [sorry, I live in the USA; therefore, I’m using the English measuring system] , and on your Android or iPhone. It’s a case of either A and B, but not both A and B."

Perhaps in cases when SinglePage is unable to reliably display a screenshot which the user had added as an annotation, an error message would be displayed in place of the screenshot indicating something like, “The screenshot you added is not being displayed because it was created on a 32 inch computer monitor. To view the screenshot, you must view this page on a 24 inch computer monitor or larger.” If you want to get really fancy, you might enable the user to click on the error message to see the screenshot as—for example—a PNG or JPEG, so that the user would be able to see and therefore be reminded of the screenshot they had created which is not being displayed as he or she had originally intended.

Your mistake in this case is analogous to premature optimization. In other words, you are saying, “If I can’t do everything, then I will do nothing!” That’s bad. Don’t do that. In other words, often—as in this case—it is better to add a useful feature which has significant limitations, rather than to not add any feature whatsoever.

Normally, a hungry man would prefer a sandwich, but he will normally be willing to eat a slice of plain bread. In other words, feed your users something; don’t let them starve while you dream of preparing a feast for them.

Don’t feel bad. Every engineer I have ever worked with has tended to make this same type of mistake. I’m not an engineer; therefore, it’s easy for me to accept “bad” and “messy” engineering solutions. I almost invariably drive engineers I work with crazy with my “bad” and “messy” engineering solutions.

Engineers almost invariably want “good” and “clean” solutions. Many engineers, for example, dream of building a Utopia on Mars. I would prefer to remain on this little blue planet I was born on, and deal with the “bad” and “messy” problems. Dreaming is great. I dream frequently. But, ultimately, we all need to make compromises. Don’t try to create a Utopia; it’s unachievable. Instead, focus on reasonably improving things. That’s a long-winded way of saying: use good judgment.

If you want to be a great engineer, you must focus on the needs of your users; instead of your visceral yearning to build Perfect Software with Perfect Features.

[gildas-lormeau]

I'm sorry, but we don't share the same mentality, at least in the SingleFile context. I am not only an engineer, I am also a product owner and I refuse to implement a feature if it is bound to be broken. The main reason is the complaints that will accompany it. It's no fun at all to deal with them. My main goal is to provide a product that works as stated and to fix any bugs. The number of bugs should be as small as possible. I also think that's what the majority of users want.

[Yekutiel]

I have read your assertions.

[gildas-lormeau]

Thank you and I have responded to your comments.

[Yekutiel]

Thanks for taking the time to respond to my comments.