Portál AbcLinuxu, 6. května 2024 11:27
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:
Tiskni
Sdílej:
$ 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/ docOn 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.
Aby se vyhnuli komplikacím s GnomeVFS pod KDE, tak prece muzou rozlisit, v jakem prostredi jsou a podle toho zobrazit dialog...
27.6.2008 13:05
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
27.6.2008 14:45
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
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.
27.6.2008 11:40
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
27.6.2008 11:32
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
27.6.2008 11:34
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
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…
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ý
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.
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?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í.
Dotáže se uživatele?Ano, stejně jako každý jiný file dialog v systému.
27.6.2008 10:01
27.6.2008 11:30
NSSavePanel *sp = [NSSavePanel savePanel];
[sp setRequiredFileType:@"txt"];
[sp beginSheetForDirectory:NSHomeDirectory() file:nil modalForWindow:parentWindow modalDelegate:self didEndSelector:@selector(savePanelDidEnd:returnCode:contextInfo:) contextInfo:nil];
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
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.
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ý…
27.6.2008 17:14
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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é.
27.6.2008 19:15
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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 zareagovatNení 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í.
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?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.
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ápadprotože aplikace si stejně musí existenci či neexistenci souboru ověřit a musí stejně adekvátním způsobem zareagovatNení 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í.
27.6.2008 20:29
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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 neexistujeA 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.
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)?Pokud programátor není úplné nemehlo, naprogramuje to tak, že se messagebox se zprávou zobrazí přes souborový dialog.Naprosto zbytečná komplikace.
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…
27.6.2008 21:16
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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...
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…
27.6.2008 22:56
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.6.2008 00:14
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.6.2008 00:37
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.6.2008 15:17
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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řilTo je ale blbost! Pokud už existuje, tak návratová hodnota přece řekne, že je vše OK!
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:
trueif the named file does not exist and was successfully created;falseif the named file already exists
28.6.2008 15:30
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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ží).
28.6.2008 15:13
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.6.2008 15:31
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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).
28.6.2008 16:30
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
27.6.2008 20:31
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.
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ápadNebuď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+
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…
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
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ů.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.