Odpovídáte na názor ke článku Čeština? Jdi mi k šípku!.
[67] [69] Samozřejmě pokud jsou kvůli UTF-8 třeba úpravy funkcionality aplikace (hledání, zalamování), neřešil bych už jako problém to, že je nutné se poprat i se jmény souborů. Navíc cp a mv sice fungovat budou, ale už u ls správně konstatujete, že nastane problém. Gzip a tar sice budou zdánlivě fungovat, ale pokud archiv ze svého počítače jedoucího v UTF-8 rozbalíte u mě (a já pojedu 8859-2), názvy souborů se okamžitě zmrší. A i na jednom počítači se vám začnou na jednom FS míchat názvy souborů v různých CP, psané Unicode/ne-Unicode aplikacemi.
Tvrdíte sice, že pojetí zpětné kompatibility ve Windows je příliš úzké, ale ve skutečnosti ty aplikace dělají přesně to, co uměly na starém systému. Souhlas, že to má omezení ohledně dopředné kompatibility. Ale je to strategické do budoucna (ne jako v případě těch překladů do a z UTF-8 před a po každém volání), a nemrší to znakové sady.
Autoři Qt by vám nepoděkovali. Vedlo by to k tomu, že byste musel konverze dělat ručně. Získat list souborů v adresáři v jedné formě, převést do stringů, ty nacpat do GUI, až uživatel na něco klikne tak postavit ze stringu zase jméno souboru v UTF-8... Ušetřil byste převod pouze ve chvíli, kdy dostanete z libc název souboru v UTF-8, pak na něj už nijak nesaháte (ani ho nezobrazujete), a jen byste ho hned použil. Takových situací asi nebude moc. Všechny ostatní situace by dopadaly úděsně, a byly by na chyby (kódování) daleko náchylnější.
Nepíšu v Qt, ale konstanty pro oddělovače adresářů, metoda pro path contatenation (@"můj adresář",@"můj soubor.ext") apod. minimálně v .NET Frameworku jsou. Samozřejmě pracují se stringy (podobně jako Qt, nebo libc), v případě .NETu jsou to UTF-16 stringy. Trochu problém je v tom, že na to autoři SW kašlou, takže Mono (nebo nějaká jeho nadstavba, už nevím) například automaticky překládá \ na / apod.
Unicodová normalizace se řeší jinde. Vy GUI prvku vždy házíte string. Co s ním dělá GUI prvek, a jak ho případně cestou normalizuje, to je jeho věc. Pravda, v případě Linuxu propadne skrz Qt, kde se převede na UTF-8, na X11 libs, a pak se pošle přes síťovou vrstvu (nebo shared memory) X11 serveru. Děsně neefektivní, a pomalé. Ale já to nevymýšlel.
Daleko horší alternativa ale je, abyste měl pa-string pro jména souborů, jiný pa-string pro normalizovaný Unicode, a mezi nimi jste převáděl ručně.
[67] Ve Windows je nějaký font matching podle stylu apod., tabulky volitelně (vzhledem k množství fontů se nepoužívají).
Typograf, ale i jakýkoliv jiný grafik, bude samozřejmě chtít GUI. Takže mu nezbude, než Inkscape nebo Scribus. NO a náhrada fontu v jakémkoliv DTP či grafickém programu je velmi špatně.
Profesionální ajťák pracující pro korporát (narozen 1974). V soukromí však rád prosazuji svobodný software. Snažím se mít přehled o technologiích a trendech. Zastávám názor, že pokud chci něco kritizovat, musím s tím mít nějakou zkušenost. Jsem hrdý manžel, otec dvou dcer a opečovávatel kočky plemene Britská modrá krátkosrstá. Mám rád hudbu, knihy a kulturu obecně. V některých věcech však jdu proti proudu – používám Linux (konkrétně ZorinOS), svobodný software (LibreOffice, GIMP, Inkscape či Joomlu!) a jezdím v hybridním japonském autě.
Přečteno 55 080×
Přečteno 44 480×
Přečteno 39 306×
Přečteno 27 489×
Přečteno 27 389×