Feature request. Can Omniget look up ytdlp, PDFium etc. from any directory in the system

[PaduaPlay]

Re-requesting with additional feedback on omniget_0.7.7 since #196 was closed with "A field for pointing at a binary in an arbitrary location is still open as a follow-up (today only PDFium accepts a custom file, and even then it copies rather than referencing in place)."

Some feedback on this option in omniget_0.7.7 ..

• The UI for this in omniget_0.7.7 needs some work.. Options are only partially visible.
• Since the UI was truncated for the PDFium option as well (could not see any of the radio button options for PDFium) even that could not be pointed to a local copy. (to test if it copies it to \data in the app directory).
• And, some UI text is in Portuguese even if the app language is different.

The benefit is, of course, when any available local copy of ffmpeg, PDFium and ytdlp can be used from whichever directory they are already in.

Thanks for keeping this open for a follow on release.

[tonhowtf]

@PaduaPlay Thanks — the screenshot did all the work here. Both UI bugs are real, both are fixed in PR #223, and one of them explains why you couldn't test the PDFium option at all.

The Portuguese text. My first three attempts to find it failed: en.json was clean, the browser-extension component uses 24 correct translation keys, and searching pt.json for the exact strings in your screenshot found nothing. What found it was searching the published tag directly:

$ git grep -n "Atualizar / Instalar" HEAD -- src/
HEAD:src/components/settings/SettingsPlugins.svelte:104

That section is rendered by a different component than I assumed, and it was never translated — six strings hardcoded in Portuguese, plus the three install hints (chrome://extensions → Modo do desenvolvedor → …) arriving already-translated from the Rust backend. The backend has no way of knowing your UI language, so it now returns a key and the frontend translates it. 10 new keys, written into all 10 locales.

Worth noting this is not limited to 0.7.7 — it is still in main today. Good catch.

The truncated options — this is the one that blocked you. The dependency table had:

.deps-table-wrap { overflow: hidden; }

That was there to round the table's corners, but the ... menu is absolutely positioned and drops below its row. On the last row of the table — which is exactly the PDFium row — the menu fell outside the container and got clipped. So the "point at a local file" option was rendered, but off-screen. You weren't missing it; it was unreachable. Fixed by dropping the clip and restoring the rounding on the header cells instead.

The actual feature request stays open. Pointing yt-dlp, ffmpeg and PDFium at an existing copy in any directory, referencing it in place rather than copying, is still not implemented — today supportsCustomFile is PDFium only, and even that copies the file. #223 does not change that. It only removes the two things standing in front of it, so keeping this issue open for the feature itself.

One honest caveat: I have not opened the app to look at either fix — the reasoning and the checks are solid, but nobody has seen the repaired menu on screen yet. It goes into the pre-release validation list along with the Windows portable-mode item from #209.

[PaduaPlay]

Thank you for the quick responses. Will look for a pre-release build..

[PaduaPlay]

Setting, plugins UI is good in OmniGet v0.8.0. .👍

Looks like a PDFium update site is not live. Sometimes returns 'too many requests'. May be better to consider other update sources for PDFium?

[tonhowtf]

@PaduaPlay Implementado — PR #232. Você pediu isto duas vezes, na #196 e aqui, e desta vez é a coisa toda, não o follow-up.

As três ferramentas agora aceitam um caminho seu: yt-dlp, FFmpeg e PDFium. E, o principal, o arquivo é referenciado no lugar, não copiado.

Você tinha perguntado explicitamente se copiava. Copiava — e essa era a parte errada. Copiar resolve metade do problema e cria a outra metade: a cópia envelhece sozinha. Você atualiza o yt-dlp pelo gerenciador de pacotes e o OmniGet continua na versão velha sem avisar, e o sintoma aparece semanas depois como "aquele site parou de funcionar". Agora um apt upgrade vale imediatamente.

Onde fica: Config → Plugins → tabela de dependências → ... → escolher arquivo. O menu mostra o caminho em uso e tem "Voltar a usar o gerenciado" no mesmo lugar — escolher errado não pode prender ninguém.

Três detalhes que decidi assim de propósito:

• A validação acontece na hora de escolher, com o seletor ainda aberto: caminho que não existe ou pasta em vez de arquivo são recusados na hora. Falhar no meio de um download seria muito pior.
• Se o binário sumir depois, o app volta ao gerenciado em silêncio e registra no log. Se você apagou a pasta, o certo é o download funcionar — não quebrar porque você mexeu em algo fora do app.
• A origem aparece como "custom" na tabela, em vez de dizer "managed" para um arquivo que não é gerenciado.

Sobre os dois bugs de UI que você reportou junto, ambos já estão na 0.8.0, publicada hoje: a seção em português corrigida em 10 idiomas, e o menu cortado — que era, aliás, o motivo de você não conseguir nem testar a opção do PDFium. O botão existia, mas caía fora da área visível justamente na última linha da tabela.

Uma ressalva honesta: não cliquei nisso. Não apontei um yt-dlp de verdade e baixei com ele. O que está testado é a decisão — validação, precedência, o fallback quando o arquivo some. Se você testar quando sair na 0.8.1 e algo não bater, reabra.

Obrigado por insistir. As duas issues suas desta semana viraram três correções e uma feature.

[PaduaPlay]

Thanks again for a quick new release.

OmniGet v0.8.1 allows pointing to locally available ytdlp, FFMPEG and PDFium.

• PDFium status shows missing and does not update to installed, even after pointing to a local file. (ytdlp and FFMPEG show installed status)

• After linking a PDFium.dll the app became draggy - stuttered when the mouse pointer is moved. This is, however, not repeatably reproduceable.
• Perhaps, unrelated to the plugin feature update, Omniget v0.8.1 does not remember window size and position upon exit and reopens at a default location and size. Previously Omniget remembered window size and position upon exit.

[tonhowtf]

@PaduaPlay Thanks for the follow-up — all three are worth digging into, and I did. Here's where each one stands.

1. PDFium showing "missing" after pointing to a local file — confirmed, real bug.

In 0.8.1 the "use my own binary" feature stopped copying the file and started referencing it in place (so your binary never goes stale). yt-dlp and FFmpeg got the full treatment: their status check looks at the custom path first, which is why they correctly flip to "installed". PDFium's check was never updated — it still only looks inside the app's managed folder, so the status stays "missing" no matter what you point it at. It's not a refresh problem; the UI re-fetches correctly, the backend just answers wrong.

While tracing this I found it's actually worse than a label: at the moment the custom PDFium path isn't consumed by the reader at all — the study plugin still loads the library from its own data folder. So your linked .dll is recorded and displayed, but not used. Both halves get fixed together in the next patch: the status will reflect the custom path, and the reader will actually load it.

2. Window size/position not remembered.

I have to be straight with you here: OmniGet has never persisted window geometry — no version had that code, including the ones that seemed to remember. What made it look like memory: closing the window doesn't quit the app, it hides it to the tray, so reopening shows the same living window at the same size. Any full exit (quit from the tray, an update, a reboot) has always reset the window to the default 1100×720, in 0.8.0 and before — I diffed the window setup between the releases to be sure nothing changed in 0.8.1.

That said, you're right that it should remember. Real window-state persistence goes on the list for the next release.

3. Stutter after linking PDFium.dll.

I couldn't reproduce this, and I audited the code for anything that could plausibly cause it: linking a binary writes one small JSON file once — there's no watcher, no polling, no background work tied to it. And given bug 1, the linked .dll wasn't even being loaded, which makes it hard to blame the file itself. I'm not ruling it out, but right now I have no mechanism pointing at us. If it happens again, two things would help a lot: does it survive an app restart, and does removing the custom path (the ... menu on the PDFium row) make it stop? With that I can tell whether it's ours or a coincidence (GPU driver / WebView2 doing something at the same time).

On the PDFium download source returning "too many requests" — noted, that's real (the mirror rate-limits); pointing at alternatives is on the list too.

[PaduaPlay]

Stutter after linking PDFium.dll.
"does it survive an app restart, and does removing the custom path (the ... menu on the PDFium row) make it stop?"

As mentioned this was not repeatably reproduceable. The first time it stuttered, in 0.8.1, it was very noticeable and it did resurface, just once, after an app restart. But that seems to have been a one time thing. Can't reproduce that stutter.

If I remember right, removing the custom path (the ... menu on the PDFium row) did make it stop.

There is no stutter at all with omniget_0.8.4_x64-portable. (missed 0.8.2 and 0.8.3)
Even with testing a clean install, redoing the PDFium reference from scratch etc.
So, it probably makes sense to just hold off on this until the PDFium link local file feature gets implemented fully and then check if it happens again..