Java na Linuxu

27.6.2008 09:47 | Přečteno: 1769× | Java

Tak už chápu, proč nemá spousta lidí ráda Javu na Linuxu. Já už po dnešku také moc ne.

Od té doby, co používám Mac, tak nedám na Javu dopustit. Apple jí opravdu zaintegroval do systému takovým způsobem, který nemá u ostatních OS konkurenci. V současné době se snažím vylepšit chování dialogu pro výběr souborů. Standardní implementace Javy totiž neřeší to, že při ukládání můžu vybrat existující soubor. Ten pak bez varování přepíšu. Nebudu zde rozebírat samotný problém přepisování a přejdu rovnou k věci, která mě fakt vyrazila dech.

Tou věcí je naprosto šílený a odporný nativní dialog pro výběr souborů na Linuxu. Java standardně podporuje dva typy dialogů: nativni (zajišťuje ho OS) a Swingový (vykresluje ho Java). Jenže to, co na mě vybaflo při zavolání nativního dialogu bych snad nepřál vidět ani svému nepříteli. Proboha co je na tom tak těžkého si zjistit, zda jsem na KDE nebo na GNOME a podle toho zavolat patřičnou funkci (proceduru, apod.). Posuďte sami:

Tahle hrůza má fakt k nativnímu dialogu hooodně daleko. Jasně, desktopů na Linuxu je spousta. Docela bych ještě omluvil, že se tenhle hnus zobrazí někomu na Fluxboxu - i když i tam bych ho docela litoval. Ale zobrazit toto pod KDE, kde je tak pěknej nativní dialog, to je prostě lemplovina největšího kalibru.

Mohl bych samozřejmě brečet dál - viz skvělé vykreslování Swingu. Na Windows se při změně velikosti okna velmi nepěkně překresluje a při přesouvání zanechává stopu. Na Linuxu v programu Esmska prozměnu v okně About občas (spíš často) nezobrazí vnitřek textového pole, kde jsou autoři...

A závěr? Jasně, Java nikdy nemůže být 100% nativní. Jenže problém je v tom, že se pánové od Sunů ani o to nesnaží. Díky bohu, že Apple vyvýjí vlastní Javu sám. Sice jí vydávají později, avšak ta kvalita je úplně někde jinde. Přesto i tam narážím na limity, které vytvoři Sun svým nedostatečným zájmem o jiné OS, než je Windows.

Pro srovnání, tady jsou dialogy vyvolané v Javě pomocí nativní třídy java.awt.FileDialog. Jak jistě poznáte, jedná se o Mac OS X Leopard a Windos XP:

       

Komentáře

[Michal Vyskočil]

Nebude to tím, že na Linuxu/X11 nic jako nativní dialog doopravdy není?

[Algi]

No jo, ale Java přece umí detekovat, na kterém desktopu běží. A proto, když zjistí, že je na KDE/Gnome, tak přece může zavolat nativní dialog. Nebo něčemu nerozumím?

[Michal Vyskočil]

Že by proto?*

$ cd icedtea6-1.2/openjdk/jdk/src
$ du -ah linux/ | tail -n 1
1,4M    linux/
$ du -ah solaris/ | tail -n 1
15M     solaris/
du -ah windows/ | tail -n 1
6,2M    windows/
$ ls windows/ solaris/
solaris/:
back  bin  classes  demo  doc  hpi  instrument
javavm  lib native  npt  sample  transport
windows/:
back  bin  classes  demo  hpi  instrument
javavm  lib native  npt  resource  transport
$ ls -1 windows/native/sun/windows/*FileDialog*
windows/native/sun/windows/awt_FileDialog.cpp
windows/native/sun/windows/awt_FileDialog.h
$ ls linux/
doc

On totiž Linuxový desktop nebyl nikdy pro Sun zajímavý.

* ve zdrojácích openjdk se nevyznám, takže je možné, že ukazuji něco jiného.

[pnemec]

To znamena mit alespon 3 dialogy. Zpravovat 3x tolik kodu... No ale ted je java openSource, takze uvidime jak se misto Sunu na Javu vykaslou pro zmenu distribuce :)

[Algi]

No, 3x vice kodu mozna. Ale na druhou stranu - podle me by to nebylo zas tak moc ne? Krom toho, file dialogy pouziva kazda aplikace, takze vykuchat to nekde ze zdrojaku by nemusel byt az zas takovy problem.

[petr_p]

A co KIO nebo GnomeVFS? Jak chcete tohle řešit? Těžko si JVM otevře soubor, který ve VFS vlastně ani neexistuje, těžko si JVM namapuje do paměti takový soubor atd.

Netvrdím, že to není řešitelné, ostatně tyto desktopové VFS to řeší, ale kdo by se s tím chtěl zabývat v každé aplikaci zvlášť. Zvlášť v JVM, která má vlastní VFS. Je to asi tak obtěžující, jako používat GnomeVFS zdroje v KDE aplikacích.

[Algi]

Aha, takže důvod není ani tak šlendriánství v GUI, jako problémy s file systémem. No, abych byl upřímný, tohle mě nenapadlo. Já do Javy zase tak moc nevidím. Na druhou stranu, proč to ale jde ve Windows/Mac OS X? A dále, opravdu by byl takový problém naimplementovat alespoň GTK filedialog? Vždyť svým způsobem toto na Win/Macu také udělali - naimplementovali jeden filedialog s jeho VFS. Nebo jsem vedle jak ta jedle? Aby se vyhnuli komplikacím s GnomeVFS pod KDE, tak prece muzou rozlisit, v jakem prostredi jsou a podle toho zobrazit dialog...

[Limoto]

Pokud by měli implementovat jenom jeden dialog, měl by to být spíš Qt, protože pokud to dobře chápu, tak Qt bude brzo umět běžet pod GTK.

[Algi]

A bude vypadat naprosto stejně jako ten pod GTK? V případě že ano, tak by to opravdu byla dobrá volba. Nechcete někdo poslat patch?

[mirec]

To vie už teraz.

[Daniel Kvasnička ml.]

Tohle by IMHO melo byt soucasti standardizace v ramci LSB nebo neceho podobneho. Tedy at uz bezi ten program pod KDE nebo pod Gnome, oba by meli byt schopni pres implementaci nejakeho verejne dostupneho rozhrani te Jave pristup k takovych vychytavkam poskytnout.

KIO ani GnomeVFS v soucasne dobe neumozunuji zadny non-GUI pristup pres API ci alespon pouhou commandlajnu?

[Michal Vyskočil]

No v X11 by spíš prošla specifikace třeba freedesktop.org, kterou by ostatní nějak dodržovali - takže by nemusel být všude stejný dialog, ale stejně se chovající a vypadající.

KIO ani GnomeVFS v soucasne dobe neumozunuji zadny non-GUI pristup pres API ci alespon pouhou commandlajnu?

GIO/GVFS by to mělo umět (dokonce se pracuje na mostu KIO-GIO), ale je to zatím poměrně čerstvá záležitost.

[kotyz]

Ale jsou, jen jich je znacny mnozstvy -> gtk1, gtk2, kde3, kde4, qt3, qt4, motif, tk, ... Kazdej toolkit ma svuj a i nektery prostredi maji vlastni. Taky mam KDE a ruzny programy po me hazeji ruzny dialogy, ty kdeckovy jen kdeckovy aplikace, ostatni bud gtk nebo vlastni dialogy (ty z tkabberu to je fakt neco, dokonce maji jinou barvu nez je nastavena v samotnym programu).

[phero]

tak swing KDE nepodporuje _vubec_ a gnome _velice spatne_ a do budoucna to nevypada ne velky zmeny

[Dušan Hokův]

tenhle co ukazujes je nativni, ale z doby gnome 1.x jestli to pomatujes

[Algi]

Nepamatuju. V té době jsem ještě znalo pouze Windows. Krom toho jsem myslel, že pochází ze Solarisu. Takže si nemám na co stěžovat, je nativní

[kotyz]

Ta hruza je nativni GTK1 dialog. Stejnej je treba u XMMS nebo gmplayeru. Je to takova 'cesta do praveku'

[kotyz]

Pripadne by to jeste moh bejt Motif (to je snad jeste starsi a myslim ze to je k videni u xpdf a xnview).

[Filip Jirsák]

Standardní implementace Javy totiž neřeší to, že při ukládání můžu vybrat existující soubor. Ten pak bez varování přepíšu.

Co by na tom měla řešit Java? To je věc programátora, aby ošetřil, co se má stát, když uživatel vybere existující soubor.

Jinak k tomu dialogu – když někdo ve swingové aplikaci nepoužívá nativní swingový dialog, dobře mu tak Pro swingovou aplikaci je nativní swingový dialog, ne žádný jiný. Je to jako kdybyste chtěl, aby KDE aplikace používala „nativní“ GTK+ dialog jenom proto, že svůj systém považujete za postavený na GTK. Ano, někdo takové věci chce, ale není mi jasné, v čem je souborový dialog tak extra, a proč někdo nepožaduje „nativní“ (ve „svém“ toolkitu) menu, tlačítka, okna…

[Algi]

No, Java to evidentně neřeší, ale mám dojem, že například takový AppKit tohle dělá automaticky.

Nativní swingový dialog? To je vtip, ne? Vždyť se podívejte, jak vypadá. Ani na jedné z platforem není nativní. Chová se jinak, vypadá jinak. Mým cílem je, aby aplikace co nejvíce zapadala do systému. Na ideologii Swingu v tomto případě kašlu, protože ten mě v tomto směru zklamal.

Nativní dialog není extra v ničem. Naopak, mohl byste argumentovat tím,že postrádá spoustu funkcí z JFileChooseru. Jenže vypadá a chová se jako doma - teda až na ten Linuxový . Jak jste si mohl všimnout, tak nativní dialog na Macu ukazuje všechny disky, vzdálené počítače, apod. Nativní dialog na Windows ukazuje to, na co jsou uživatelé z Windows zvyklí. A co ukazuje swingový JFileChooser? Představu Sunu o filedialogu. Na to ale není nikdo zvědavý

[freshmouse]

Mým cílem je, aby aplikace co nejvíce zapadala do systému.

V tom případě na to jdeš špatně. Piš tak, aby byla aplikační logika nezávislá na toolkitu a pro každou platformu si napiš vrstvu, která obsluhuje potřebný toolkit aktuální platformy.

[phero]

a nebo pouzi QT misto swingu (-:

[Filip Jirsák]

No, Java to evidentně neřeší, ale mám dojem, že například takový AppKit tohle dělá automaticky.

No, to musí být nádhera. A že jsem tak smělý, co dělá automaticky? Dotáže se uživatele, přepíše soubor, nedovolí přepsat soubor, vytvoří záložní kopii souboru, smaže soubor, vyhodí výjimku, zastřelí obsluhu…?

Nativní swingový dialog? To je vtip, ne? Vždyť se podívejte, jak vypadá. Ani na jedné z platforem není nativní.

Platforma pro swingovou aplikaci je swing. Do swingové aplikace zapadne jedině souborový dialog se swingovým L&F, nativní dialog operačního systému nebo desktopového prostředí bude v takové aplikaci cizí.

[Algi]

Dotáže se uživatele?

Ano, stejně jako každý jiný file dialog v systému.

NSSavePanel *sp = [NSSavePanel savePanel];
[sp setRequiredFileType:@"txt"];
[sp beginSheetForDirectory:NSHomeDirectory() file:nil modalForWindow:parentWindow modalDelegate:self didEndSelector:@selector(savePanelDidEnd:returnCode:contextInfo:) contextInfo:nil];

Tento kousek kódu vám zajistí, že omylem nepřepíšete soubor a že bude mít příponu txt. Proč bych proboha měl psát kód, který bude hlídat, zda soubor neexistuje a potom ručně vytvářet nějaký chybový dialog?

Platforma pro swingovou aplikaci je swing. Do swingové aplikace zapadne jedině souborový dialog se swingovým L&F

Špatně si rozumíme. Já tvořím aplikaci, která používá knihovnu Swing a systémový look and feel. Proto vypadá (až na jednu výjimku) NAPROSTO shodně jako nativní aplikace. Systémové integraci na Esmsce jsem věnoval spoustu času, takže vím o čem mluvím. Dialog, který poskytuje JFileChooser je na Macu cizí. Nezapadá tam a nereaguje na běžné klávesové zkratky. Je totiž navržený Sunem a Apple jej chtě-nechtě musel převzat. Zato FileDialog je plně v kompetenci Applu - má systémový vzhled, reaguje na systémové zkratky a rozvržení komponent naprosto přesně odpovídá zvyklostem daného OS. Podívejte se prosím na screenshot a srovnejte si to s tím "výtvorem" od Sunu. Pakliže tvrdíte, že by uživatel měl být spokojený s JFileChooserem, tak vás musím ubezpečit, že ne. Alespoň ne na Macu, kde každá aplikace přísně dodržuje HIG. Howg

[Filip Jirsák]

A zajistí to jak? Co když ten soubor vznikne mezi tím, co uživatel zadá jméno souboru v dialogu, a okamžikem, kdy se jej pokusí aplikace vytvořit? Co když aplikace soubory nepřepisuje, ale přejmenuje je na záložní soubor a vytvoří nový soubor (jako třeba při rotaci logů)?

[Michal Vyskočil]

ale není mi jasné, v čem je souborový dialog tak extra, a proč někdo nepožaduje „nativní“ (ve „svém“ toolkitu) menu, tlačítka, okna…

Ne typicky některé dialogy nabízejí hromadu funkčnosti, jako záložky, náhledy a spol, zatímco ručně dělané obvykle ne. Rozhodně stejný Look and Feel aplikací prostě přispívá k dobrému dojmu z desktopu.

[Filip Jirsák]

Ne typicky některé dialogy nabízejí hromadu funkčnosti, jako záložky, náhledy a spol, zatímco ručně dělané obvykle ne.

Což ale záleží na konkrétní implementaci – a zrovna souborový dialog GTK 1 tedy nad swingovských dialogem zrovna nevyniká. A swing není jen tak ledajaký toolkit, aby u něj člověk předpokládal špatný souborový dialog. A pokud je špatný, má se udělat lepší, ne si jej půjčovat z jiného toolkitu. Napadlo by snad někoho tvrdit, že GTK má divně udělaná menu, a mělo by je raději dělat pomocí Qt?

Rozhodně stejný Look and Feel aplikací prostě přispívá k dobrému dojmu z desktopu.

Pokud bude aplikace mít swingovský L&F, rozhodně do ní nezapadne souborový dialog nějakého cizího toolkitu. A že by takový dialog zachránil dojem z celého desktopu, když zbytek aplikace bude jiný…

[Luboš Doležel (Doli)]

Co by na tom měla řešit Java? To je věc programátora, aby ošetřil, co se má stát, když uživatel vybere existující soubor.

To by měla řešit třída představující ten dialog... je to tak jinde obvyklé.

[Filip Jirsák]

Jak už jsem se ptal výše – co má řešit? Uživatel vybere v souborovém dialogu existující soubor a má se dít co? Druhá otázka je proč to má řešit, protože aplikace si stejně musí existenci či neexistenci souboru ověřit a musí stejně adekvátním způsobem zareagovat, takže jakákoli aktivita souborového dialogu v tomto směru mi přijde jako nežádoucí.

[Algi]

Jmenujte mi případ, kdy je nežádoucí, aby se aplikace nezeptala, zda chce uživatel přepsat soubor v ukládácím dialogu. Promiňte, ale asi mi něco uniká

[Filip Jirsák]

Třeba v případě, kdy chce uživateli rovnou nabídnout nové jméno souboru. Tak jako to dělají třeba download managery.

[Algi]

Špatný příklad. Pokud nabídne nové jméno, tak přece nenabídne jméno stávajícího souboru a ten vzápětí nepřepíše! Stále nejsem přesvědčen, zkuste to jinak

[Filip Jirsák]

Takže pokud si uživatel chce nechat navrhnout nové jméno souboru, má nejdřív souborovému dialogu potvrdit, že chce soubor přepsat a pak mu konečně bude moci aplikace nabídnout nové jméno? To je trochu uhozené, ne?

[Luboš Doležel (Doli)]

Uživatel vybere v souborovém dialogu existující soubor a má se dít co?

Má se zeptat uživatele. Je to lepší, než kdyby dialog zmizel, ukázal se warning, uživatel to odmítl a file dialog se zase objevil.

protože aplikace si stejně musí existenci či neexistenci souboru ověřit a musí stejně adekvátním způsobem zareagovat

Není mi jasné, proč by si aplikace měla existenci či neexistenci nějak ověřovat. Té už je to jedno, ta prostě začne zapisovat, ať tam soubor je, nebo není.

[Filip Jirsák]

Uživatel vybere v souborovém dialogu existující soubor a má se dít co?

Má se zeptat uživatele. Je to lepší, než kdyby dialog zmizel, ukázal se warning, uživatel to odmítl a file dialog se zase objevil.

Pokud programátor není úplné nemehlo, naprogramuje to tak, že se messagebox se zprávou zobrazí přes souborový dialog. A třeba navrhne uživateli nový název souboru. Nebo mu navrhne starý soubor přejmenovat. Jak má autor toolkitu vědět, co z toho bude zrovna programátor chtít?

protože aplikace si stejně musí existenci či neexistenci souboru ověřit a musí stejně adekvátním způsobem zareagovat

Není mi jasné, proč by si aplikace měla existenci či neexistenci nějak ověřovat. Té už je to jedno, ta prostě začne zapisovat, ať tam soubor je, nebo není.

Takže uživatel zadá název souboru, dialog zjistí, že neexistuje, mezi tím soubor vznikne a pak do něj aplikace začne zapisovat, protože má zprávu od dialogu, že soubor neexistuje. To je taky dobrej nápad

[Luboš Doležel (Doli)]

Pokud programátor není úplné nemehlo, naprogramuje to tak, že se messagebox se zprávou zobrazí přes souborový dialog.

Naprosto zbytečná komplikace.

mezi tím soubor vznikne a pak do něj aplikace začne zapisovat, protože má zprávu od dialogu, že soubor neexistuje

A proč by měl ten soubor vznikat? Tohle není serverová aplikace nebo kdovíco, tohle slouží třeba jako dialog pro uložení dokumentu. Není důvod, proč by měl během té sekundy ten soubor magicky vzniknout.

[Filip Jirsák]

Pokud programátor není úplné nemehlo, naprogramuje to tak, že se messagebox se zprávou zobrazí přes souborový dialog.

Naprosto zbytečná komplikace.

Co je na tom komplikovaného? A proč má aplikace nutit uživatele zadat nový název, když třeba dokáže sama navrhnout vhodnou alternativu? Proč má nejprve uživatele otravovat jedním dialogem, že zadaný soubor existuje, a pak dalším, když potřebuje vytvořit odvozené názvy (jako třeba ukládání stránky z prohlížeče do .html + adresář s rekvizitami, nebo balení do vícemédiového zipu)?

Není důvod, proč by měl během té sekundy ten soubor magicky vzniknout.

Taky není důvod, proč by měl někdo do HTML formuláře pro SQL dotaz psát uvozovky, proč by se mělo jedno vlákno zastavit a druhé rozběhnout zrovna v tomhle okamžiku, proč by někdo poslal tak velký blok dat – jo jo, takových „není důvod, proč“ už jsem slyšel…

[Luboš Doležel (Doli)]

Co je na tom komplikovaného? A proč má aplikace nutit uživatele zadat nový název, když třeba dokáže sama navrhnout vhodnou alternativu?

To má aplikace tipovat, jak to pojmenovat? No když už takové harakiri, tak si prostě může tu danou funkci filedialogu vynout a je to.

Taky není důvod, proč by měl někdo do HTML formuláře pro SQL dotaz psát uvozovky, proč by se mělo jedno vlákno zastavit a druhé rozběhnout zrovna v tomhle okamžiku, proč by někdo poslal tak velký blok dat – jo jo, takových „není důvod, proč“ už jsem slyšel…

V životě jsem neviděl program, který by používal file dialog, ale vykašlal se na jeho funkci ověřování existence souboru a celou operaci, která má normálně tak 3 řádky, komplikoval kvůli tomu, že během 1 milisekundy by se v tom samém adresáři (třeba Dokumenty) mohl čistě znenadání objevit soubor se stejným názvem...

[Filip Jirsák]

V životě jsem neviděl program, který by používal file dialog, ale vykašlal se na jeho funkci ověřování existence souboru a celou operaci, která má normálně tak 3 řádky, komplikoval kvůli tomu, že během 1 milisekundy by se v tom samém adresáři (třeba Dokumenty) mohl čistě znenadání objevit soubor se stejným názvem...

Podle toho ty programy vypadají Jinak ta operace s testem, zda se podařilo soubor nově vytvořit, zabere asi tak jeden řádek navíc, takže to je opravdu komplikace…

[Luboš Doležel (Doli)]

Jenže pak musíš kontrolovat i důvod selhání a ne všechny "API" ti řeknou, jestli to selhalo kvůli právům nebo třeba právě kvůli existenci toho souboru. Plus pak musíš sám nakódit buď zobrazení varování a znovuzobrazení filedialogu, nebo to zintegrovat do něj, což bude ještě tuna dalšího zbytečného bloatu.

[Ladicek]

Obecně řešení chyb je příšerné množství kódu "pro nic". A tímhle příšerným množstvím kódu se liší dobrý software od průměrného.

[Luboš Doležel (Doli)]

Ukaž mi desktopové programy, které si do sebe takový zbytečný bloat připustily.

[Ladicek]

Sice to nemá nic společného s ukládacím dialogem (natožpak s Linuxem), ale korektní zpracování chybových situací je například jedním z největších rozdílů mezi Total Commanderem a Altap Salamanderem.

A neříkal bych tomu bloat, ale spíš slušnost. Pravdaže se to dneska asi moc nenosí.

[Luboš Doležel (Doli)]

Tady nejde o žádné zpracování chybových situací, jsi mimo.

[Filip Jirsák]

Pokud program bez ptaní přepíše nějaký soubor, není to chyba? V Javě je vytvoření nového souboru atomická operace, která skončí úspěchem jedině v případě, kdy soubor neexistoval a podařilo se jej nově vytvořit. Takže pokud programátor neotestuje návratovou hodnotu a bude spoléhat, že se soubor vytvořit podařilo, může se stát, že jenom přepíše existující soubor, ale také se může stát, že se vůbec žádný soubor nevytvořil (protože je třeba na disku jen pro čtení). To už má celkem dobře nakročeno k tomu, aby data ani neuložil – samozřejmě bez toho, že by uživateli něco oznámil.

[Luboš Doležel (Doli)]

Pokud program bez ptaní přepíše nějaký soubor, není to chyba?

Kdybych měl v programech na každém Xtém řádku kontrolovat, jestli se třeba nezměnila velikost souboru, tak má FatRat velikost a rychlost skoro jako OpenOffice.org. Pokud se tam ten soubor objeví mezi stisknutím OK v dialogu a otevřením souboru, tak je to jen blbost uživatelů. Tohle by se mohlo stát jen kdyby šlo o síťový disk a dva lidé dostal nápad uložit soubor se stejným názvem ve stejnou milisekundu.

Takže pokud programátor neotestuje návratovou hodnotu a bude spoléhat, že se soubor vytvořit podařilo, může se stát, že jenom přepíše existující soubor, ale také se může stát, že se vůbec žádný soubor nevytvořil

To je ale blbost! Pokud už existuje, tak návratová hodnota přece řekne, že je vše OK!

[Filip Jirsák]

Pokud se tam ten soubor objeví mezi stisknutím OK v dialogu a otevřením souboru, tak je to jen blbost uživatelů. Tohle by se mohlo stát jen kdyby šlo o síťový disk a dva lidé dostal nápad uložit soubor se stejným názvem ve stejnou milisekundu.

Na lokálním počítači se to může stát třeba tak, že počítač je z nějakého důvodu vytížen, GUI reaguje pomalu a uživatel sám zvolí dvakrát akci uložit a nepozná, ve kterém dialogu zrovna je.

Kdybych měl v programech na každém Xtém řádku kontrolovat, jestli se třeba nezměnila velikost souboru, tak má FatRat velikost a rychlost skoro jako OpenOffice.org.

Stačí na jednom řádku otestovaná návratovou hodnotu funkce vytvářející soubor. Ignorovat, že se nepodařilo vytvořit soubor, není podle mne dobrý nápad. Když tu chybu ignorovat nebudu, musím stejně uživateli zobrazit hlášku, a v případě existujícího souboru mu nabídnout soubor přepsat. Aby se ten dotaz nezobrazil 2× pokaždé trochu jinak, musel bych stejně příslušnou funkci v souborovém dialogu vypnout. Takže by v API mohla být příslušná metoda, ale u ní by musel být komentář: „tuto metodu v žádném případě nepoužívejte“.

To je ale blbost! Pokud už existuje, tak návratová hodnota přece řekne, že je vše OK!

JavaDoc říká něco jiného:

true if the named file does not exist and was successfully created; false if the named file already exists

[Luboš Doležel (Doli)]

Názorně:

QFile file;
QString fname;

fname = QFileDialog::getSaveFileName(); // [1]
file.setFileName(fname);
if(!file.open(QIODevice::WriteOnly)) // [2]
{
   // ošetřit selhání: filesystem readonly, práva, etc...
}

Ty mi tvrdíš, že se mezi [1] a [2] zčistajasna ten soubor fname objeví na disku od někoho jiného. To se na desktopu stane asi těžko a na síti by to asi bylo bordelem na síťových discích (a uživatelé si pak problém zaslouží).

[Ladicek]

pak musíš kontrolovat i důvod selhání atd.

Tak nevím, je to chyba, není to chyba…

[Luboš Doležel (Doli)]

Jsi mimo, normálně k žádnému selhání totiž nedojde.

[Ladicek]

K selhání může dojít ze spousty důvodů, které už tu byly řečeny. I v takovém zdánlivě jednoduchém případě, jako je ukládání souboru.

Techniku obsluhy nestandardních situací k tomu nedojde samozřejmě taky znám a aplikuju

[Luboš Doležel (Doli)]

Jsi vážně mimo, chyby handlovat samozřejmě ano, ale v normálním případě handluješ jen problém, že se nedá zapisovat.

[Ladicek]

Přestaň už psát, že jsem mimo, to všichni víme

Nedá se zapisovat není příčina, ale důsledek. Jak jsem říkal: průměrný software ohlásí nelze zapisovat, dobrý software řekne nelze zapisovat, na disku není místo, nebo nelze zapisovat, nemáš práva, atd. (Podprůměrný software pak spadne a ten špatný se bude tvářit, že se nic neděje, a přitom nezapíše ani bajt )

Granularita řešení chyb je samozřejmě designové rozhodnutí a není nic špatného na tom být průměrný (zvlášť když z hlediska normálního průběhu věcí jsem výborný); někteří ale opravdu jdou až tak daleko, že se snaží chovat se rozumně i ve chvíli, kdy dojde paměť (zase ten Altap).

[Luboš Doležel (Doli)]

Jenže pokud neřešíš existenci souboru při otevírání, tak nemusíš dělat speciální case pro tuto situaci a stačí ti jen vybafnout popis chyby.

[Luboš Doležel (Doli)]

Nebo spíš milisekundy. Vždy už je úplně jedno, jestli to ověření dělá dialog nebo program. I tak ten soubor může mezi ověřením a otevřením vzniknout... teoreticky.

[Filip Jirsák]

I tak ten soubor může mezi ověřením a otevřením vzniknout... teoreticky.

Pokud knihovna (jako např JRE) zaručuje, že vytvoření souboru bude atomické, pak opravdu jen teoreticky.

[Algi]

Pokud programátor není úplné nemehlo, naprogramuje to tak, že se messagebox se zprávou zobrazí přes souborový dialog. A třeba navrhne uživateli nový název souboru. Nebo mu navrhne starý soubor přejmenovat. Jak má autor toolkitu vědět, co z toho bude zrovna programátor chtít?

Uvažoval jste někdy nad tím, že chování file dialogů by mělo být konzistentní? Uživatel je upozorněn standardním způsobem, že soubor již existuje. Pokud bude soubor chtít přesto přepsat, přepíše si jej. Pokud ho bude chtít přejmenovat, přejmenuje si jej. Nechápu, proč by mu progam měl navrhovat nějaké jiné jméno. Copak vidíte uživatelovi do hlavy, jakou má představu o pojmenovávání souborů? Takováto "umělá inteligence" je jedním z důvodů, proč nepoužívám rád Windows. Snaží se totiž myslet za mě...

Takže uživatel zadá název souboru, dialog zjistí, že neexistuje, mezi tím soubor vznikne a pak do něj aplikace začne zapisovat, protože má zprávu od dialogu, že soubor neexistuje. To je taky dobrej nápad

Nebuďte paranoidní. Krom toho, v momentě, kdy má uživatel zobrazený dialog, tak ten automaticky zobrazuje veškeré změny. Pokud tedy ve složce mezitím vznikne soubor, dialog ho okamžitě zobrazí. Nevím jak na ostatních systémech, ale na Macu rozhodně. Výhoda HFS+

[Filip Jirsák]

Uvažoval jste někdy nad tím, že chování file dialogů by mělo být konzistentní? Uživatel je upozorněn standardním způsobem, že soubor již existuje. Pokud bude soubor chtít přesto přepsat, přepíše si jej. Pokud ho bude chtít přejmenovat, přejmenuje si jej. Nechápu, proč by mu progam měl navrhovat nějaké jiné jméno. Copak vidíte uživatelovi do hlavy, jakou má představu o pojmenovávání souborů?

Vyzkoušejte si někdy pár webových prohlížečů a download manažerů. Jak se chová spousta z nich? Vezmou jméno stahovaného souboru, zjistí, zda takový soubor již neexistuje, a pokud ano, vytvoří odvozený název – třeba přidají číslo. To je ale podle vás nekonzistentní chování. Vždyť si uživatel to číslo může klidně dopsat sám, prohlédne si adresář, zjistí jaké je nejvyšší číslo a přidá jedničku. Proč by to za něj měl dělat počítač, že, aspoň si uživatel procvičí matiku…

Nebuďte paranoidní. Krom toho, v momentě, kdy má uživatel zobrazený dialog, tak ten automaticky zobrazuje veškeré změny. Pokud tedy ve složce mezitím vznikne soubor, dialog ho okamžitě zobrazí. Nevím jak na ostatních systémech, ale na Macu rozhodně. Výhoda HFS+

Jak se dialog dozví o změně, když ta složka je třeba na vzdáleném serveru připojená přes FTP? A zobrazení změny v dialogu je celkem na nic, když už uživatel ten dialog zavřel a soubor vznikne až pak…

[Algi]

Vyzkoušejte si někdy pár webových prohlížečů a download manažerů. Jak se chová spousta z nich? Vezmou jméno stahovaného souboru, zjistí, zda takový soubor již neexistuje, a pokud ano, vytvoří odvozený název – třeba přidají číslo. To je ale podle vás nekonzistentní chování. Vždyť si uživatel to číslo může klidně dopsat sám, prohlédne si adresář, zjistí jaké je nejvyšší číslo a přidá jedničku. Proč by to za něj měl dělat počítač, že, aspoň si uživatel procvičí matiku…

Ale ne. Špatně mě chápete. Safari při ukládání má dva módy: první (pro BFU) je ten, že mu prostě řeknete, ať soubor uloží. On se na nic neptá a rovnou jej začne stahovat do složky ~/Downloads. Pokud tam takový soubor existuje, přidá za jeho název pomlčku a číslo o jedna vyšší. Pokud chcete explicitně určit kam a jak se soubor uloží, zobrazí se vám dialog. Pokud kliknete na soubor, který existuje, pak se vás zeptá, jestli ho chcete přepsat a zkontroluje jeho příponu. Webový prohlížeč, stahovač torrentů, Adobe Lightroom, Pages, .... Všechny tyto programy jsou rozdílné, ale ctí jednu zásadu: nevymýšlí nesmysly. Chovají se inteligentně a mají unifikované chování.

Jak se dialog dozví o změně, když ta složka je třeba na vzdáleném serveru připojená přes FTP? A zobrazení změny v dialogu je celkem na nic, když už uživatel ten dialog zavřel a soubor vznikne až pak…

V případě ukládání na FTP se dialog pochopitelně o změně nemusí dozvědět. Nevím, nezkoušel jsem. Vymýšlíte ale už opravdu paranoidní případy, nemůžu si pomoct. Krom toho, nejsem si vědom, že by zrovna toto Java nebo Cocoa framework nějak extra obsluhovaly. O Javě bych velmi pochyboval, v tomto směru je vcelku primitivní (až místy stupidní), Cocoa netuším. Zas tak dobře zatím tento framework neznám a nerad bych šířil nesmyly. Přece jenom, je tu pár Macařů, kteří by se mi pak mohli smát

[Filip Jirsák]

Vymýšlíte ale už opravdu paranoidní případy, nemůžu si pomoct.

Aplikace, která předpokládá, že všechno bude ideální, špatně dopadne.

Krom toho, nejsem si vědom, že by zrovna toto Java nebo Cocoa framework nějak extra obsluhovaly.

Co by na tom měly obsluhovat? Mám připojený nějaký vzdálený systém třeba přes FUSE (třeba sshfs), vzdálený systém neumožňuje oznamovat změny, tím pádem se o změnách nedozví ani FUSE, tedy ani systém, takže se o tom nedozví ani žádný uživatelský program.

Pořád uvádím jenom pár příkladů, co se může stát. Každopádně aplikace, která si vytvoří nový soubor, zapíše do něj a zavře jej, a během těchhle operací si vůbec nekontroluje návratové hodnoty a to, jestli operace proběhla, skončí v lepším případě nějakou výjimkou, v horším případě případě vypíše „soubor uložen“, ale soubor nebude nikde. Pokud by souborový dialog chtěl usnadnit programátorovi práci s nejčastějším případem, může volitelně při zadání jména existujícího souboru položit uživateli dotaz, zda se má soubor přepsat – pak ten souborový dialog ale musí zajistit i vytvoření souboru a aplikaci předat deskriptor vytvořeného a otevřeného souboru. Jinak přímo vede programátora k tomu, aby ignoroval ošetření nestandardních stavů.

[petr_p]

Nebuďte paranoidní. Krom toho, v momentě, kdy má uživatel zobrazený dialog, tak ten automaticky zobrazuje veškeré změny. Pokud tedy ve složce mezitím vznikne soubor, dialog ho okamžitě zobrazí. Nevím jak na ostatních systémech, ale na Macu rozhodně. Výhoda HFS+

To není žádná paranoia. Tohle je zcela běžný příklad bezpečností chyby, kterou se straší všichni, co zapisují do /tmp. Jediné řešení je stylu fd=open(filename, O_WRONLY|O_CREAT|O_EXCL, mode); s následnou kontrolou, jak to dopadlo (fd!=-1).

Pokud chce toolkit řešit existující soubor, tak takto se smyčkou přes errno==EEXIST a aplikaci musí (vedle názvu souboru) vrátit otevřený deskriptor a aplikace musí s tímto souborem manipulovat jen přes tento deskriptor.

[freshmouse]

Musím tedy říct, že Java jako taková by měla používat takový dialog, jako nabízí aktuálně používaný toolkit. Jestli chce programátor něco jiného, je to jeho věc.