danpla

> There is no decent phone left with a 3.5mm jack, which is a really sad state of things... Unless you know one? Feel free to suggest.

Sony Xperia phones traditionally have a 3.5 jack and a normal screen (without holes and other nonsense for the camera).

With proper image pre-processing, Tesseract can recognize even tiny text (5-7 px high).

dpScreenOCR

Try dpScreenOCR:

https://danpla.github.io/dpscreenocr/

dpScreenOCR is a free, open-source, and cross-platform optical character recognition tool with support for more than 100 languages.

dpScreenOCR works is like this: you select an area on the screen using a keyboard shortcut, and then text from that area is extracted and, depending on your choice, can be copied to the clipboard, saved to the history, or sent to another application (e.g. dictionary/translator). In most cases, you don't even have to interact with the GUI, and the program can reside in the system tray.

The biggest changes since the program (v1.1.0) was mentioned in HN[1] in 2022 include:

* Added a language manager that allows you to install and remove languages without leaving the application. Previously, you had to manually download the language files and place them in special directories.

* Added a stand-alone GNU/Linux bundle (in a TAR.XZ archive), which should work even on legacy systems released in around mid-2014 or later (tested on Ubuntu 14.04).

* Fixed recognition with vertical variants of Chinese, Japanese, and Korean.

* Added proper selection rectangle scaling according to the screen DPI. The width of the rectangle can now also be configured (as requested by @Lakuma in [1] :).

* Thanks to contributors, the website has been translated into several languages. Some languages are still to be added, so help with translation would be greatly appreciated: https://hosted.weblate.org/engage/dpscreenocr/

The full list of changes since v1.1.0 can be found here: https://raw.githubusercontent.com/danpla/dpscreenocr/v1.4.1/...

The source code (zlib license) is available on GitHub: https://github.com/danpla/dpscreenocr

[1]: https://news.ycombinator.com/item?id=32123437

> What they would lose is that they wouldn't exist in the first place or wouldn't be as full-featured.

These are some pretty bold statements.

* "They wouldn't exist in the first place" implies that ImGui was the primary reason and foundation for creating these programs. As if using the traditional retained mode GUI is so unbearable that without ImGui the authors would have abandoned the idea of creating these tools in the first place.

* "Or wouldn't be as full-featured" implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.

> I'm surprised this is so hard to comprehend?

Well, I'm surprised that some people keep presenting the immediate mode GUI as the silver-bullet alternative to the traditional GUI. Don't get me wrong: I understand that IMGUI is a great tool if you need to quickly add a throway GUI to a game, but otherwise there is a price to pay, both by the developer and the end user.

> 'Immediate mode UI' is only an API design philosophy, it says nothing about what happens under the hood.

Well, if you have a traditional immediate mode API like:

    if (button("Start"))
        start();

Then it's not just about the API philosophy: at the very least, it ties the event handling to the drawing.

I didn't use RemedyBG or Tracy, but I did try ImHex (https://github.com/WerWolv/ImHex) and it loaded 12% of the CPU because everything is being repainted 60 times per second. Heck, it even has an option to limit the FPS, which solves the CPU load a bit, but at the same time results in sluggish input because the event handling is tied to the drawing frequency.

So yes, the experience was not good, and I don't see what these tools would lose by using a proper GUI. I don't want every utility to drain my laptop battery like a decent video game.

ImGui is great if you already have a loop where everything is unconditionally redrawn every frame, but otherwise it's a really odd choice for an end-user application.

Unfortunately, if you're using the standard library, you get this just by switching to the C++20 mode. For example, the committee decided to put tons of std::ranges-related stuff right in <algorithm>.

https://www.reddit.com/r/cpp/comments/o94gvz/what_happened_w...

> I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable

The author talks about the code bloat, beacause of "an API that encourages custom formatter specification to live in a template". But at the end he mentions the standard solution to this problem:

> A preferable interface (I use, but also others AFAIK) is to check the type in a template (no choice there), and dispatch the formatting routine to somewhere that lives in a single translation unit.

So what prevents you from doing this with <format>? As I understand, the implementations of parse() and format() of std::formatter don't depend on the template parameters and can delegate to non-template functions residing in one CPP file. You can also provide additional wformat_parse_context/wformat_context overloads if you need wchar_t support.

> Anything object oriented is slower than anything procedural.

Well, that's not always true; it's better to use a profiler.

In many cases, it's trivial for the compiler to inline objects (e.g., used as predicates for <algorithm> routines), resulting in better performance compared to the equivalent procedural code.

> running constructors and destructors is expensive

If the object is not polymorphic (and sometimes even if it is), the compiler can inline both the constructor and destructor, resulting in exactly the same assembly output as the procedural code.

> Expected errors - like "user not found" - should use a value instead of exception. In Python, you can use sentinel objects, or tuples, or None.. lots of options really.

That's why exceptions are called exceptions, not errors. If a routine called openFile() can't open a file, that's a pretty exceptional situation, and it's up to the caller to decide whether the exact reason is an error in their case.

The exception object is already a value that can have not only a message text, but also any data members, so why reinvent the wheel with sentinel objects, tuples, etc.?

> The examples in post, where you catch exception and re-raise Exception back are terrible - what's the point of them? There is no extra clarity, just verbosity. I would defect them in any code review.

Typically, you re-raise an exception after adding some content to it. This may be less important in Python, which gives you a great stack trace, but in a language like C++, the lack of context information makes the exception basically useless.

> I have the idea that most people use browser-based email clients anyway?

Indeed, but it's not an option if you have more than one email account on the same service.

As I know, SPARK can do this (in particular, thanks to the strong type system).

https://learn.adacore.com/courses/intro-to-spark/chapters/01...

Location: Vancouver, BC, Canada

Remote: Ok, but not a strict requirement

Willing to relocate: Yes

Technologies: C, C++, Python 3; GCC, MinGW/MSYS2, CMake; POSIX, WinAPI, Qt, GObject/GTK+, SDL; Git, Mercurial

Résumé/CV: https://drive.google.com/file/d/12hRwpXv1ALDeuaq1cmC28Az1qYG...

Email: [email protected]

GitHub: https://github.com/danpla

Areas of experience include cross-platform development, porting, multimedia, GUI, object-oriented design, optimization, refactoring.

Oh, thank you. I tried the ZIP on VirusTotal, and it looks like the false positives are triggered for Qt platform plugins, namely qwindowsvistastyle.dll qwindows.dll:

https://www.virustotal.com/gui/file/2adff5ef8aaf1c7674422cdd...

I'll try to figure out what to do about that.

I just updated the Windows installer to fix long startup time and high drive load. Sorry for the inconvenience.

You're welcome! For now, it's impossible to configure the capture box, but I can add an option to change its thickness in the next version.

You're welcome!