Dotaz: Binární prohlížeč v KDE (Krusader)

[lertimir]

Jedna z věci, které jsem si oblíbil na Total commanderu ve widlích, je jeho viewer na soubory. Je super rychlý, protože nenačítá celý soubor, ale jen těch pár bloků, které jsou nezbytně nutné pro zobrazení a zobrazí byty jako grafické symboly (vybrané) znakové sady. Bez nějakých překladů.

Hledám něco podobného v KDE. Krusader mám hodně rád jako správce na soubory, ale implicitní prohlížeč v Krusaderu je k tomuhle nepoužitelný.

1. Otevírá celý soubor. Tím pádem u velkého souboru je to pomalé.
2. Otevírá soubor v editačním režimu. To je pro binární soubor nesmysl. a jen to zdržuje.
3. Používá nesmyslné zástupné znaky pro byty, které nejsou standardně tisknutelné.

Rád bych našel viever, který zobrazí, co načte, formou byte na byte s tím, že mohu zvolit znakovou sadu, která bude reprezentovat přečtené byty.

Odpovědi

[Migi]

Asi nejblíž k TC má DoubleCommander. Akorát je troěku retardovaný. Neumí ssh/sftp.

[l4m4]

Pokud akorát kopíruješ soubory, tak snad dává ssh/sftp ve filemanageru smysl... Ale normálně je mnohem praktičtější sshfs, se kterým můžeš s těmi soubory na vzdáleném systému pracovat v čemkoli. Celkově mám pocit, že filemenagery tajně touží stát se druhým emacsem a implementovat v sobě znovu všechny ostatní programy....

[lertimir]

To má smysl pouze, když jsem ke vzdálenému systému připojen v lokální síti. Tedy na rychlém spojení. Naprosto si třeba neumím představit, když bych nějaký větší text měl editovat v OO a byl na 15Mbitové (což má v lokálním provedení cca 1Mbit upload) a OpenOffice mi každou chvíli dělal automatické uložení. Aplikace typicky vůbec nic neví o rychlost přístupu a jejich tvůrci často očekávají rychlost blízkou lokálním diskům.

Pro vzdálené systémy se mi vždy vyplatila práce: zkopírovat lokálně -> upravit a zpracovat -> synchronizovaně nakopírovat zpět. A je úplně jedno, jestli to udělám s připojeným sshfs, nebo přes filemanager nebo přes specifického sftp klienta jako třeba filezilla. Osobně právě na toto preferuji ty externí sftp klienty, protože jednak budou mít databázičku všech míst s nimiž takto si data vyměňuji a mi také jasně rozliší, co je lokální a vzdálené a pravděpodobnost chyby je mnohem menší.

[lertimir]

Já jsem z Krusaderem velmi spokojen, co se týká jeho schopností práce se soubory. Porvnávání a synchronizace adresářů, hromadné operace se soubory, v současnosti i práce s frontami. výborné. Jen ten prohlížeč. v podstatě se spustí stejná aplikace, která ale umí i editovat a pokusí se vše načíst do paměti. Ale podívám se na něj.

[Max]

Tady nejde o file manager, ale o prohlížeč, který používá a v krusaderu lze definovat, co má při jaké akci použít. Takže jde jen spíš o to, aby si tazatel našel nějaký vhodný prohlížeč, který si potom v krusaderu nastaví -> Nastavení -> Konfigurovat krusader -> Obecné -> Viewer/Editor
Zdar Max

[Max]

Možná bych zkusil zaasociovat gVim, nebo něco podobného, to by mohlo být rychlé.
Zdar Max

[lertimir]

gvim je, ale gnomí nadstavba, která si bude taha spoustu gnomích knihoven. Nebo ne.

[Max]

Šílenost kolem QT only, nebo kolem GTK only prostředí je absolutně nesmyslná.
Zdar Max

[pavlix]

+1

Ono by bylo naopak ideální, kdyby ty světy konvergovaly k sobě. Tzn. aby rozdíl mezi Qt a GTK byl z pohledu uživatele co nejmenší a projevoval se spíš z pohledu programátora.

Viz freedesktop.org.

[lertimir]

Ano souhlasím, že knihovny by měly konvergovat k sobě. A nejsem nijak moc KDE only, pouze když je řešení v KDE tak zvolím ono. Pokud není, tak mi gnome nevadí například rozumný ekvivalent za inkscape v KDE není. To oktave mi vyhovuje. Ještě zkusím i ten wxHexEditor.

[pavlix]

Dělám to stejně akorát v opačném směru, tedy z pohledu Gnome 3.

[rADOn]

Hexeditor je přímo součástí KDE, umí všechno co potřebuješ a ještě asi milion věcí navíc. Jediná vada kterou má je, že v rámci čtyřkové přejmenovávací mánie se původní jasný název "khexedit" změnil na "okteta" takže o něm spousta lidí neví .

[lertimir]

Díky. Vypadá to, že je to přesně to, co jsem hledal.

[stativ]

Mrkni na wxHexEditor, ten je hodně rychlý. Okteta, kterou tady kdosi zmiňoval je proti němu na velkých souborech neuvěřitelně líná.