Portál AbcLinuxu, 6. května 2025 14:52
Zde si můžete stáhnout zdrojové kódy JXP Commanderu. Tato předělávka do gtk zatím NEUMÍ NIC. Jedná se zatím pouze o GUI doplněné o nějaké ty dialogy (kopírovat do, přesunout do, přejmenovat, o aplikaci). Teď potřebuji nějaký ten VFS (ještě nevím, jestli použít již naprogramovaný, nebo ho naprogramovat), pak teprve začnu s funkcemi jako výpis adresáře, protože dělat to jen tak na lokálním filesystému a pak to celé přepisovat, se mi nechce.
P.S. pro Davida: Spokojen?
Tiskni
Sdílej:
9.7.2006 21:15
David Watzke | skóre: 74
| blog: Blog...
| Praha
9.7.2006 22:02
Jardík | skóre: 40
| blog: jarda_bloguje
9.7.2006 21:44
Filda
| nejmenší velkoměsto
9.7.2006 21:54
Jardík | skóre: 40
| blog: jarda_bloguje
9.7.2006 21:57
Jardík | skóre: 40
| blog: jarda_bloguje
Chyba Parametr relationId je prázdný!
Tak znovu a lépe: GNOME Human Interface Guidelines 2.0
10.7.2006 08:47
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
9.7.2006 22:35
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
A proč neudělat prostě VFS, které bude multiplatformní, a které prostě bude umět FUSE využít, když tam bude, ale nebude na něm přímo závislé? Tím spíš, že napsat dobrý VFS je v podstatě velmi jednoduché.V podstatě se to nevylučuje, ale proč psát dvakrát jednu věc? VFS už máme v jádře, funguje pro všechny programy a funguje dobře.
Filesystém a GTK jsou naprosto jiné věci, takže porovnávat hranice GTK a filesystému je poněkud divné.Mluvil jsem o přenositelnosti. Z toho pohledu je kyblik co to dělá.
Navíc si člověk ve vlastním VFS může pohlídat věci, na které bych u FUSE nevěřil. Třeba se může dát jako podmínka, že VFS bude plně thread safe, což se pro Commander může velmi hodit.FUSE běží naprosto odděleně od programu, který k tomu přistupuje. Pro program se filesystém mountnutý pomocí FUSE tváří stejně jako každý jiný. O žádné thread safe nejde, protože obsluha filesystému běží ve vlastním procesu. Jde jen o to, aby ve filemanageru byla trošku sofistikovanější obdoba čudlíku "mount", nic víc. A že by bylo fajn, kdyby ten čudlík pouštěl externí nástroj, který by byl použitelný i samostatně.
Snažit se na Linuxu se standardním bezpečnostním modelem jakkoli omezovat proces s EUID 0 je pošetilost.Proč myslíte, že příkaz
passwd neptá roota na heslo ani v případě, že mění své vlastní? Proč myslíte, že se procesům s EUID 0 nehlídají přístupová práva? Je to (a) proto, že to psali blbci, nebo (b) proto, že si autoři uvědomovali, že by takové "zabezpečení" nepřineslo absolutně nic?
10.7.2006 00:15
Josef Kufner | skóre: 70
Uživatel přece vůbec nemusí tušit, že se používá nějaké FUSE atd., to není jako když si to explicitně namountuje sám...Proč by to neměl tušit? Vždyť na obsluhu bude mít krásné okýnko, stejně jako má teď na připojování se k FTP. Pokud to bude přehledně uděláno, tak s tím nebude sebemenší problém. Spíš naopak, bude mít jedno okýnko na připojování všeho.
10.7.2006 11:31
Josef Kufner | skóre: 70
10.7.2006 12:52
Josef Kufner | skóre: 70
A to, ze to uz neni potreba se pozna podle toho, ze posledni program opusti/uzavre ten adresar (tj. padne posledni reference).Jenže takováhle definice toho, co je potřeba, bude uživatele jenom mást. Jinak potřeba není to, s čím už uživatel nechce pracovat. Dobře, odpověděl jsi mi alespoň na jednu otázku - že uživatel to nebude muset explicitně odpojovat sám. V případě toho pádu jxp-cmd si to teda už pořeší systém sám - je na to FUSE připravené nebo se proto musí něco udělat? Já bych tedy styl práce, že uložení souboru znamená commit změn na třeba ftp serveru, nepřijal. Sice vim je v tomhle skoro dokonalej, ale stejně se zlozvyku občas napsat :w v průběhu práce nezbavím. BTW jak to bude s obnovením rozdělané práce třeba v tom vimu - nebude to znamenat, že se musí mountovat vždy na stejné místo (do stejného adresáře)? To by bylo celkem nepříjemné, ne?
10.7.2006 14:45
Josef Kufner | skóre: 70
Něco-jako-VFS může být jistě i přímým důsledkem návrhu programu.
Příliš by mě netěšilo, kdybych možnosti té knihovny mohl využívat teprve až po změně programů v nichž jí chci používat. To by mi dalo poměrně málo. A ještě míň v situaci, kdy už spousta programů má něco vlastního co by se tlouklo.
Já mám pocit, že právě takhle knihovny vznikají. A že se dají používat až po změně programů. Nějak mám pocit, že je to přirozené. A já zatím mluvím o commanderovi a VFS, která se dá snadno zobecnit. Nějak jsem se za osmnáct let praxe naučil, že dobrá analýza a dekompozice programů je věc, která ve svém důsledku ušetří čas a peníze, zvláště pokud se program pak má udržovat.
No jo, přirozené. Ale teď prakticky. Pokud je tak jednoduché udělat multiplatformní VFS, že je to dokonce jednodušší než to nedělat (což už je samo o sobě velmi zajímavé ), proč jich tedy není milión, ze kterého by si šlo jeden pěkný vybrat? A proč ty stávající taky vždycky nefungují tak ideálně? (třeba o GnomeVFS by se dalo povídat…) Nějak mám pochyby.
Jistě, že VFS máme už na úrovni OS. Tak proč toho nevyužít a je nutno mít další na úrovni aplikace? Dovolím si takovou skutečnou ukázku ze skutečně používaného programu.
player->priv->current_file = g_strdup_printf ("file://%s", escaped);
To je z Muine, hudebního přehravače; a k čemu to je? escaped je cesta k souboru v Linuxu, jenže GStreamer (který bude číst current_file a získávat z něj zdroj k přehrávání) používá GnomeVFS. Muine jinak nic takového nepoužívá. Přijde to tady někomu hezké, elegantní nebo k něčemu dobré? Mi ani moc ne.
Ale myslel jsem to tak, že pro průměrného programátora v Javě je snad zvykem navrhovat programy jinak než pro průměrného Delphistu.
Zrovna porovnávání dvou řetězců přes == mi v Javě dokonce i funguje 
A ani to není nelogické
Porovnávání řetězců == v Javě funguje, ale obsah řetězců to neporovnává.
To mi trochu připomíná dialog z filmu Marečku, podejte mi pero:
Tak co, běhá to?Běhá, ale neseje.
No, to je ale u secího stroje dost podstatnej problém, nemyslíte?
:-)
A taky bychom měli jít spát. Minimálně v jednotném čísle ano.
To já taky. A kdybych nemusel dobastlovat padesátou výjimku z výjimky (nikoli ve smyslu exception) do windowsové aplikace, kterou jsem kdysi coby hřích nezralého mládí vyplodil, už jsem mohl jít spát dávno. A taky bych nemusel ráno vstávat v nelidskou hodinu… :-(
No, mně tohle téma fakt tak extra nebere
Jinak, == v důsledku svým způsobem obsahy řetězců porovnává, když se na to podíváme určitým způsobem. Pro některá použití je to snad dostačující. Ale to je jedno, já tu (teď) fakt Javu nechci hájit (ani hanit). Určitě by mohlo být někdy fajn mít porovnání, kde mi třeba "Dog" == "Pes" bude souhlasit a to se v Javě neudělá. (tady by mělo patřit ale, ale myslím, že je to ale tak zjevné, že tam ani být nemusí )
Třeba Java je absolutně jediný jazyk, který jsem kdy poznal, kde porovnávací operátor neumí porovnávat řetězce (s výjimkou C, kde řetězce vlastně neexistují). To považuji za blbost jako hrom, která mi vadí rozhodně víc, než spousta jiných věcí.Tohle tvrzení dokazuje to, že jste také některé důležité věci okolo Javy nepochopil. Java také nemá řetězce, ve stejném smyslu, jako je nemá C. "Řetězce" v Javě jsou objekty typu
java.lang.String. Operátor == pak tedy zcela logicky porovnává referenci, nikoli hodnotu – stejně jako to dělá v C. Jinými slovy, porovnání řetězců v Javě se chová úplně stejně jako v C. Jediný rozdíl je v tom, že Java za jistých okolností (přesně specifikovaných) dokáže rozpoznat, že se jedná o dva stejné řetězce a použije pro ně stejný objekt. Pak na ně shodou okolností funguje i ==. Ale používat == v Javě na porovnání řetězců je prasárna a programátor, který to použije, by měl 100× opsat na porovnání řetězců se používá metoda equals().
10.7.2006 14:45
Josef Kufner | skóre: 70
== pro objekty už je definován. A byla by pěkná hloupost mít takový operátor, který se pro všechny objekty chová nějak, dokonce i pro jeden objekt neString a jeden String se chová stejně, lae pro dva objekty třídy String se najednou bude chovat jinak.
To že má Java blbě přetížený operátor + ještě neznamená, že se má ta nelogičnost rozšiřovat dál a dál.
==? Nelze, protože operátorem == se porovnávají reference. Lze porovnávat řetězce v Javě operátorem ==? Nelze, protože operátorem == se porovnávají reference. Ale C to má dobře a Java blbě.
No a k logice vašeho názoru: řetězec v Javě je objekt. Pproveďte si ve vaší obhajobě s/řetězec/objekt/ a zamyslete se nad tím, zda to dává logiku.
Možná vás mate, že Java má přetížený operátor + pro "spojování" řetězců. Ale operátor + jinak pro řetězce nemá žádný význam, takže tomuhle využití nic nebrání. Ale operátor == už je pro objekty definován, jak by se najednou mohl pro nějaký objekt chovat jinak?
Co byste dělal s následujícím kódem? Jednalo by se o porovnání "řetězců" nebo objektů (referencí)?
String a = "a"; Object b = "b"; System.out.println(a == b);C# umožňuje porovnávat hodnoty řetězců proto, protože používá přetížené operátory (na rozdíl od Javy). Takže programátor je povinnen před použitím operátoru
== si zjistit, co tento operátor dělá. Java oproti tomu přetěžování operátorů nepoužívá, operátory používá jen pro primitivní typy a navíc jako syntaktický cukr přidává možnost použít operátor == pro porovnání referencí objektů (protože tam ten operátor s ničím nekoliduje) a operátor + pro "spojování" řetězců (opět operátor s ničím nekoliduje). Osobně bych dal přednost tomu, kdyby operátor + byl definován jen pro primitivní typy (aspoň by programátor opravdu věděl, co se s řetězcem děje, a nepovažoval by String za primitivní typ nebo za modifikovatelný řetězec), a vůbec by mi nevadilo, kdby se pro porovnání referencí objektů používal třeba operátor === nebo nějaká metoda.
Pokud se vám líbí spousta různých operátorů, používejte třeba Perl, ale většina programátorů se shodne na tom, že čistá syntaxe bez různých vychytávek je plus Javy. Dokonce i autoboxing primitivních typů byl přijat hodně rozporuplně a je to dost kontroverzní věc, protože je to sice dobrá vychytávka, ale zdrojový kód to poněkud zatemňuje.
Lze porovnávat řetězce v C operátorem ==? Nelze, protože operátorem == se porovnávají reference.
Dovolím si oponovat. V céčku operátor == porovnává své argumenty. Jsou-li to čísla, porovnává čísla. Jsou-li to pointery, porovnává pointery. Reference porovnávat dost dobře nemůže - protože jazyk C reference nemá. Stejně tak nemá datový typ "řetězec", proto těžko očekávat, že operátor == bude porovnávat něco, co v jazyce není. Na druhou stranu, jak znám filosofii céčka, jsem přesvědčen, že kdyby jazyk C datový typ "řetězec" obsahoval, operátor == by je porovnával (tj. porovnával by obsah), stejně jako je porovnává ve standardní C++ knihovně.
== porovnává jeho obsah. Ale ani Java ani C datový typ "řetězec" nemá, oba jazyky se v tomto chovají stejně, takže říkat, že Java to má blbě a měla by to mít jako C je poněkud mimo.
== porovnává reference.
java.lang.Object.equals()?
== u všech typů mi připadá názornější.
final equalsReference(Object), která by ale ve skutečnosti nebyla pravou metodou, ale místo ní by kompilátor dosazoval nějaký interní kód VM. Pak by byla druhá metoda, třeba operator==(Object), která by ještě asi navíc měla být přetížena pro primitivní typy (nebo by kompilátor rovnou za Object.instance == primitivní_typ dosazoval false?), kterou by bylo možné volat i jako operátor ==. Takže bychom rázem měli dvě "podivné" metody. Zatímco teď je to, co má programátor implementovat, metoda třídy, a to, co má na starosti runtime prostředí, je implementováno jako operátor. Mně to tedy přijde jednodušší.
Každopádně o tom můžeme diskutovat, jak chceme, autoři Javy vybrali == pro porovnání identity, tak se s tím buď smíříme, nebo můžeme psát v něčem jiném.
Ale jestli někdo bude číst tohle vlákno, možná získá dojem, že otázka chování operátoru ==, zejména ve spojení s "řetězci", je pro rychlost programu klíčová
Lze porovnávat řetězce v C operátorem ==? Nelze, protože ...
řetězce v C nejsou a nebyly . Řetězec v C je jen pole znaků, které je dle konvence ukončené nulou. Navíc se C netváří jako vyšší programovací jazyk, ale je to takový vyšší assembler (nic proti C).
U Javy je ovšem následující problém. Jazyk samotný používá prostředky, které ovšem nejsou v daném jazyce implementovatelné - přetížený operátor +. Stejně jako u Pascalu, v němž nešlo napsat writeln je toto desingová chyba.
Co byste dělal s následujícím kódem? Jednalo by se o porovnání "řetězců" nebo objektů (referencí)?No v tomto případě by se jednalo o porovnání referencí, protože obecné porovnání typů String a Object si neumím představitString a = "a"; Object b = "b"; System.out.println(a == b);
. To jednoduše závisí na definci metody == objektu String . Co je divného, že se pro různé typy chová různě? Kolikrát člověk porovnává u řetězců rovnost referencí a kolikrát rovnost obsahu?
Dokonce i autoboxing primitivních typů byl přijat hodně rozporuplně a je to dost kontroverzní věc, protože je to sice dobrá vychytávka, ale zdrojový kód to poněkud zatemňuje.Proto tohle vůbec nemělo vzniknout. Jsou (a starší) jazyky, které efektivitu reprezentace základních typů řeší na úrovni virtuálního stroje, takže se o to programátor vůbec nemusí starat
. Z mého úhlu pohledu se jedná o další desingovou chybu Javy.
Teď trochu rána pod pás . Musím používat dynamicky vytvořený řetězec, protože Squeak konstatní řetězce převádí na symboly a obě porovnání by potom pochopitelně vyšla true.
str1 := Date today asString. str2 := Date today asString. Transcript show: str1 = str2; cr. "true - rovnost obsahu Transcript show: str1 == str2; cr. "false - identita objektů
+ se nepřu, psal jsem už několikrát, že bych byl radši, kdyby v Javě nebyl.
+ pro řetězce se mi taky nelíbí, bez konstruktoru Stringu jako literálu bych se také obešel. Ani jedno z toho nehájím. Ale ani jedno z toho neznamená, že řetězec v Javě je něco jiného než objekt.
java.lang.String, což je potomek třídy java.lang.Object. A protože operátor == má pro objekty funkci porovnání referencí, a Java nemá přetěžování operátorů, nemůže najednou nějaký potomek třídy java.lang.Object změnit chování tohoto operátoru.
equals() a potřebuje místo ní operator==() neznám.
Mimochodem, Pascal, Objective-C, JavaScript nebo PHP nejsou OOP?
+ pro "skládání řětezců", ale to už nikdo nezruší…
OK, místo Pascal si dosaďte Object Pascal nebo Delphi, on Pascal jako takový je již dávno mrtev. JavaScript s Javou nemá kromě názvu nic společného, rozhodně to neměl být interpretr Javy. Ta "Java" v názvu je jenom čirý marketing, vzniknout o pár let později, jemnoval by se asi XPScript Ostatně správný název jazyka je ECMAScript, JavaScript je Netscapovská implementace.
No a obecný Turingův stroj umí taky jen číst, zapsat a skočit. Takže něco na tom bude
ObjectPascal že má přetěžování operátorů? Už je to tedy docela dlouho, co jsem v Delphi programoval, ale na nic takového si nepamatuji. Ani v referenční příručce k ObjectPascalu k Delphi 3 jsem to teď nenašel… gpc také kompiluje ObjectPascal, snad všechny kompilátory, které dnes umí Pascal umí ve skutečnosti nějaký ObjectPascal, proto jsem psal, že čistý Pascal je mrtev.
O tom JavaScriptu by nebyl nějaký odkaz? Všude (např. i wikipedia) je to uváděno tak, že JavaScript vznikl jako LiveScript v NN a s Javou nemá "nic" společného.
Ani v referenční příručce k ObjectPascalu k Delphi 3 jsem to teď nenašel…
Ono také Delphi 3 už pár let není zrovna state-of-the-art. C++ Builder 5 jsem si pořízoval před více než pěti lety a tou dobou už byla na spadnutí šestka Delphi…
PS: vzhled této diskuze je názorná ukázka toho, když se o něčem říká, že to jde do ztracena. To jsem netušil, že to může mít i takovýhle "fyzický" význam
„Myslím, že by se vždy mělo velmi vážit pro a proti, než se přidá do syntaxe jazyka konstrukce, která umožní jenom jinak zapsat to, co už jde vyjádřit jinými prostředky jazyka (a z hlediska výsledného programu je obojí stejně efektivní).“Teď jste sám potvrdil, že Java je prostě zbytečná (viz poznámka o jednoduchosti a konzistenci výše). Za celých skoro patnáct let existence nepřinesla nic nového, jen to zabalila do balíčku pro masy korporátních kodérů. To je chabý výsledek. Protože totéž se klidně mohlo provést se Smalltalkem, Selfem nebo jiným podobným jazykem, a kromě shrink-wrappingu technologií by to přineslo i něco málo (nebo hodně) navíc.
. To obcas boli ...
No v tomto případě by se jednalo o porovnání referencí, protože obecné porovnání typů String a Object si neumím představitNa druhou stranu, oba ty objekty Stringy jsou a šlo by je tedy porovnat podle obsahu. Chcete porovnávat obsahy, jenže už teď porovnávate reference.
==, Java to umět nemůže, nebude-li ten jazyk příslušně přiohnut, aby přeci jen nějaké to přetěžování zvládl.
Jako ostatní jazyky, i Java má dvě operace porovnání pro objekty, jednu pro porovnání adresy (reference) a jednu pro porovnání obsahu. To, že pro porovnání adresy používá operátor == mi připadá docela vtipné, alespoň člověka vždycky praští do očí, jestli chce opravdu dělat to, co dělá. Kdyby ještě šlo u kompilátoru zapnout varování na každé použití operátoru s objektem, byl bych spokojen. Aspoň by si někteří "programátoři" ráčili všimnout, že řetězec je v Javě objekt a hodnota se porovnává metodou equals().
Pro člověka i počítač čitelnější je zápis operací jako funkcí resp. prefixových operátorů, infixové operátory nám připadají přirozené jenom díky jejich neustálému používání v běžné matematice. Infixové operátory ale mají tu nepěknou vlastnost, že jsou tam problémy s prioritou operátorů, asociativitou a očekáváme od nich komutativnost. Pokud bych si měl vybrat mezi jazykem s přetíženými operátory a jazykem bez operátorů, vyhrál by to ten bez operátorů. Protože operátory nejsou nic jiného, než jenom zkrácený zápis volání metody nebo funkce. A doby, kdy bylo potřeba psát kód co nejkratší, aby se s tím nikdo nemusel děrovat, máme za sebou, dnes už se ví, že nejdražší je čas programátora, a tedy kód musí být především čitelný a nevadí, že je trochu delší.
A doby, kdy bylo potřeba psát kód co nejkratší, aby se s tím nikdo nemusel děrovat, máme za sebou, dnes už se ví, že nejdražší je čas programátora, a tedy kód musí být především čitelný a nevadí, že je trochu delší.Ano
if (string.equals(string2)) je čitelnější než if string1 == string2:. Jazyk je čitelný pouze, pokud neobsahuje složitá pravidla, výjimky a výjimky z výjimek - což bohužel Java obsahuje. Bohužel říkám proto, že v ní musím programovat. Člověk by neměl poznat lepší jazyky, pokud potom musí pracovat v Javě 
.
Já myslím, že vaše obhajoba Javy plyne primárně z toho, že neznáte o moc jiných jazyků.
== i další operátory jsou pro mne výstraha, že je to něco neobjektového, tak abych si dával dobře pozor na to, co dělám. Navíc si dovedu představit nekomutativní equals, což kdyby někdo naimplementoval jako operátor ==, tak s ním vživotě nepromluvím
Programoval jsem už v lecčems a Java mi zatím přijde jako nejlepší. Protože nevymýšlím, kterou konstrukci jazyka bych měl v daném případě nejlíp použít, ale soustředím se hlavně na samotný problém, který mám s tím nástrojem (Javou) vyřešit.
Ale je pravda, že je potřeba přijí Javě na chuť. Někdo píše v Javě jako v okleštěném C++, úpí pak on, Java i já, když to po něm musím číst/opravovat
„Pro člověka i počítač čitelnější je zápis operací jako funkcí resp. prefixových operátorů, infixové operátory nám připadají přirozené jenom díky jejich neustálému používání v běžné matematice. Infixové operátory ale mají tu nepěknou vlastnost, že jsou tam problémy s prioritou operátorů, asociativitou a očekáváme od nich komutativnost. Pokud bych si měl vybrat mezi jazykem s přetíženými operátory a jazykem bez operátorů, vyhrál by to ten bez operátorů.“Děkuji za pomoc při propagaci Lispu a Forthu...
. Stejné to je třeba u HashMap, kdy není možné operátor [] použít s jiným typem parametru než je int a proto se to musí obcházet metodou get(). Nebo možná by mohlo fungovat mapa[key.hash()].
Navíc jsou v Javě jsou operátory brány jinak, než běžné metody, tudíž není možné toto chování nijak změnit. To je IMHO Pascalovina - jazyk samotný používá prostředky, které nejsou v daném jazyce implementovatelné.
== používá i pro objekty a + pro Stringy obhajovat nebudu, jak už jsem napsal, u + bych to uvítal, == pro porovnání referencí používám tak málo, že by mi metoda místo něj vůbec nevadila.
Že by bylo možné operátor [] použít pro mapy je pro mne novinka, to je nějaká Java 7?
Když jste tak vysazenej na ty operátory, fakt doporučuju Perl, tam si operátorů užijete…
Java je objektový jazyk, tam je nejpřirozenější nemít operátory vůbec. Kvůli rychlosti (uvědomte si, k čemu byla Java původně zamýšlena), do ní byly přidány primitivní typy a k nim operátory.Samozřejmě, že ve skutečném OOP jazyce operátory nejsou. Na druhou stranu takové OOP jazyky umožňují mít jako selektor zprávy třeba
+. Ostatně právě u Squeaku řeší efektivitu základních typů virtuální stroj. <rejp>Ale my se tu přece bavíme o Javě</rejp>
Že by bylo možné operátor [] použít pro mapy je pro mne novinka, to je nějaká Java 7?
Neviděl bych na tom nic zvláštního. Operátor [] má pro hashové pole stejný sémantický význam, jako u klasického pole. Bohužel mi překladač Javy (tuším, že 1.4) trval na argumentu typu int - tohle je zvyk z Pythonu, nebo JavaScriptu. Nevidím nic zvláštního na tom, že jazyk podporuje konstrukce pole[6], pole["klíč"], nebo dokonce pole[objekt].
Nevidím nic zvláštního na tom, že jazyk podporuje konstrukce pole[6], pole["klíč"], nebo dokonce pole[objekt].
Respektive mi přijde zvláštní, že to v Javě nejde.
[] pouze k indexaci pole, pro mapu ho nemůžete použít, ani s typem int.
Opět, v Javě to nejde proto, protože Java nemá přetížitelné operátory. Někomu možná chybí, mně by naopak přebývaly, protože metoda s dobrým názvem mi přijde srozumitelnější…
10.7.2006 00:30
Josef Kufner | skóre: 70
Vás by netěšilo mít program, který byste slinkoval s jednou knihovnou stylu VFS a získal byste možnost pracovat s libovolným zdrojem, včetně FTP, HTTP, CVS, SVN a další, aniž byste se o to nějak musel starat? Obrovská spousta programů by to využila.Ale to už máme. Je to libc a filesystém jako takový. Jen si vem ext2, vfat, nfs, … A odnedávna už je možné díky FUSE připojit téměř cokoliv. (a mám pocit, že už jsem to tu psal) Asi namítneš, že to není multiplatformní, ale co místo portování knihovny naportovat FUSE?
FUSE je omezeno svým interfacem, který je v případě FUSE velmi dobrý, ale možnostem interface FAR pluginů to opravdu nedosahuje.
Mě osobně připadá jednodušší navrhnout prostě VFS interface a udělat to multiplatformně, než portovat FUSE, které je od začátku vymýšleno jako kernel + user modul, tedy jako něco co čeká asistenci jádra.
Na FUSE se mi navíc nelíbí, že když kouknu na stránky FUSE projektu, počítají tam s glibc knihovnou. Tedy ne se standardní C knihovnou, ale s glibc.
10.7.2006 00:22
Josef Kufner | skóre: 70
Aha, v tom případě nemá smysl nic, protože i na Linuxu je commanderů až to není hezké. Naopak, nemá smysl dělat nemultiplatformní commander.Ale v Linuxu není žádnej dostatečně hezkej
Jinak by tahle diskuse vůbec nevznikla...
Multiplatformní věci nemusí umět jen průnik funkčnosti všech systémů, to je blbost. Pokud bude VFS navržená dobře jako interface, může umět naprosto všechno co by uměl nativní program ve Windows a nativní program v Linuxu, či na jiných systémech. Dokonce to nemusí ani zbytek commanderu vědět, že VFS vyrovnává rozdíly mezi filesystémy a mezi operačními systémy.Bohužel, obvykle věci, které chtějí umět všechno, neumějí pořádně nic…
10.7.2006 01:12
Josef Kufner | skóre: 70
10.7.2006 01:36
Josef Kufner | skóre: 70
10.7.2006 02:57
Josef Kufner | skóre: 70
9.7.2006 22:30
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
10.7.2006 01:03
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
10.7.2006 01:13
David Watzke | skóre: 74
| blog: Blog...
| Praha
Například Qt knihovna je brzda většího komerčního rozšíření Linuxu.A to víš, že Karel drogy nebere? A má vlastní muzeum. Myslíš, že s tímhle přístupem budeš mít někdy vlastní muzeum?
9.7.2006 22:45
Jardík | skóre: 40
| blog: jarda_bloguje
9.7.2006 22:40
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Nebo kdyby alespon byla moznost to nejak prepnout potom... precejen kdyz clovek pouziva Gnome tak to neni od veci to mit integrovane.
*** glibc detected *** corrupted double-linked list: 0x0817c148 *** Aborted...a to jsem jenom kliknul myší do panelu, kdo ví, co se stane, až tam budou nějaké soubory
Trošku mě mrzí, že to nepoužívá Glade, ale to je jedno. Každopádně, proč autor nepoužil pro about dialog komponentu, která je přímo pro tento účel dostupná v GTK+, to bych rád věděl
10.7.2006 12:22
Jardík | skóre: 40
| blog: jarda_bloguje
Ale kouknu na to.
10.7.2006 12:26
Jardík | skóre: 40
| blog: jarda_bloguje
libgtk1.2-dev 1.2.10-18 libgtk2.0-dev 2.8.18-1 libc6-dev 2.3.6-15Debian Testing.
. Inu Cesi...
10.7.2006 19:53
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
13.7.2006 13:10
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.