Portál AbcLinuxu, 30. dubna 2025 23:14
(pripade pred tym enterom este prejdem do ineho adresara)
A zrovna tohle je u Gtk2 filepickeru uživateli nepříjemně zkomplikováno.
Jistě, zkusil… Ale zkusím vám připomenout, o čem se bavíme:
Já: Vám nevadí, že chcete-li změnit adresář, musíte pokaždé nejdřív dialog přepnout z podoby "pro blbé" do normální?
Vy: neviem ci mi to vadi, nikdy som to nepotreboval kvoli takej blbosti spravit...
...
Vy: no, skusil si kliknut na to rozbalovatko…?
O tom přece celou dobu mluvím: že abych mohl přejít do jiného adresáře, musím nejdřív dialog přepnout do plnohodnotné podoby.
type :help[Enter] or [F1] for on-line help
19.8.2007 00:19
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
19.8.2007 00:38
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Osobne napr používam len pár adresárov, na zvyšných 10% použití tá časová náročnosť je vykompenzovaná predchádzajúcou úsporou.
Vám nevadí, že existujú ľudia, ktorý majú iný systém prace ako vy?
Vůbec ne. Zato mi dost vadí, že se mi ten dialog špatně používá.
riešenie vášho (a nielen vášho) problému:
lib-file-open-dialog.so, lib-file-open-dialog-aaa.so, lib-file-open-dialog-bbb.so)konfiguracia:
echo "aaa" > "${HOME}"/.preferred-file-open-dialog.rc
export PREFERRED_FILE_OPEN_DIALOG="aaa"
echo "${HOME}/lib/lib-file-open-dialog-uplne-ina.so" > "${HOME}"/.preferred-file-open-dialog.rc
(vo voľnom čase, cca 1hod mesačne, sa občas venujem aj tomuto nápadu)
19.8.2007 10:00
otula | skóre: 45
| blog: otakar
| Adamov
a to je takmer identicka kopia toho z windows...Proboha, v čem je identický s Win file dialogem??? Lze ve windowsím snad bez klikání napsat cestu (s tím, že mi dialog okamžitě nabízí dostupné možnosti)? Zobrazují se ve windowsím náhledy? Ukáže mi dialog ve Windows náhled souboru, který chci přepsat? Mohu si tam definovat záložky? Mohu s ním přistupovat k souborům přes jakýkoliv protokol?
19.8.2007 12:57
otula | skóre: 45
| blog: otakar
| Adamov
19.8.2007 13:02
otula | skóre: 45
| blog: otakar
| Adamov
19.8.2007 12:59
otula | skóre: 45
| blog: otakar
| Adamov
neudělal, že ano?)
19.8.2007 13:19
otula | skóre: 45
| blog: otakar
| Adamov
Bližší pohled (třeba to dále zmíněné video) ukáže, že tomu tak ale není.A co z toho, co jsi zmínil tam teda není? Akorát tím nabízením dostupných možností při psaní cesty si nejsem jistý a proto jsem taky napsal "skoro". Jinak trvám na tom, že tam všechno je akorát to nemusí být přesně tak jako to znáš z KDE, ale je to tam.
19.8.2007 13:29
otula | skóre: 45
| blog: otakar
| Adamov
19.8.2007 13:39
otula | skóre: 45
| blog: otakar
| Adamov
cesta v poli filename a stisknutí enteru (nebo tlačítka Open) má stejný efekt jako bys v linuxu v shellu napsal cd cesta (a v cestě nepoužil wildcardy), pokud cesta je cestou k adresáři, pokud je cestou k souboru, pak se tento hned otevře.
A hlavně není důležité, cos myslel, ale cos napsal, takže prosím neříkej, že lžu.
19.8.2007 13:59
otula | skóre: 45
| blog: otakar
| Adamov
Vidíš to, jak jsem psal, zdání klame. Tentokrát mne.tu si svoju zaslepenost priznal. mne bolo uz z obrazku jasne, ze sa jedna o rovnaky dialog...
19.8.2007 13:46
otula | skóre: 45
| blog: otakar
| Adamov
19.8.2007 14:09
otula | skóre: 45
| blog: otakar
| Adamov
19.8.2007 14:31
otula | skóre: 45
| blog: otakar
| Adamov
také nerad klikám, a proto mám rád možnost psaní do adresového řádku, nebo jedno jediné kliknutí na záložku často používaného adresáře, místo proklikávání se k němu - takže právě záložky jsou to, co mne klikání ušetří.
19.8.2007 10:53
Rezza | skóre: 25
| blog: rezza
| Brno
18.8.2007 23:16
atan | skóre: 21
| Liberec
18.8.2007 22:03
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
18.8.2007 22:04
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
). Protože dalším logickým požadavkem by jinak bylo dát možnost ten adresář smazat, když už jde vytvořit a přejmenovat.
No a když by se tam dal otevřít ten nautilus, tak by taky nebylo špatné, kdyby šlo do toho otevíracího dialogu šlo drag'n'dropovat z toho nautilu soubor(y).
19.8.2007 16:44
Josef Kufner | skóre: 70
18.8.2007 22:29
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
18.8.2007 22:37
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Trošku mi vadí, že není možné změnit režim zobrazení souborů - aspoň jsem na to nepřišel. Chvílemi se mi stává, že zapomenu, čím začíná název souboru, který chci otevřít, ale zato vím, jak je přibližně veliký - pak je to v KDE nebo v Midnight Commanderu jen otázka seřazení podle velikosti, což je hned. Zato GTK dialog zobrazuje jen název a datum změny. 
(Dokonce ani čas nezobrazuje, i když i to by se občas hodilo.) Nebo si to můžu chtít seřadit podle něčeho jiného, to už je asi celkem jedno, podle čeho - ten dialog mi to prostě nedovolí.
Taky je moc pěkné, že KDEčkový dialog doplňuje automaticky cestu ve vstupním poli. Gtk zjevně taky, ale po prvním Enteru (potvrdí volbu v komboboxu) musím dát druhý, aby se změnil seznam souborů, a to mi přijde hodně nepřirozené. A navíc mi přijde, že GTK dialog oproti KDEčkovému dost neefektivně využívá screen estate. Já vím, pro gnoumaře je to fíčura, ne bug, ale zrovna mně to moc nesedne.
Každopádně by to prostě nemělo být třeba a oprava by měla být opravit to sledování, ne přidávat tam refresh...
19.8.2007 12:05
frEon | skóre: 40
| Praha
19.8.2007 16:50
Josef Kufner | skóre: 70
(priklad - zadanie celej cesty)Za tu dobu, co pracuji s PC, jsem narazil pouze na dva filepickery, které mi opravdu vadily: jeden se už dnes téměř nevyskytuje, používá ho např. xdvi, a druhý je ten Gtk2. Takže moje odpověď by zněla: kterýkoli kromě dvou zmíněných.
Ale chcete-li něco konkrétního, tady to je: naprosto bezpodmínečně musí jít zvolit adresář, aniž bych kvůli tomu musel klikat na nějaké rozbalovací tlačítko. Přes to prostě vlak nejede. Absurditu uvažování autorů Gtk2 filepickeru jen dokresluje skutečnost, že u nich to rozbalovací tlačítko navíc vůbec nevypadá jako tlačítko, ba ani jako něco určeného ke kliknutí - vypadá jako obyčejný statický label.
<gtkfilechooser> <location mode="filename-entry"/> <show_hidden value="true"/> <expand_folders value="true"/> </gtkfilechooser>
Ne, aktivní prvek by měl být zřetelně odlišen od statického textu. A ne, drobný trojúhelníček není zřetelné odlišení. Na tom trvám. Vám to možná nevadí, ale já mluvím o tom, co mně vadí. Byl jsem vyzván, abych napsal, jak bych si představoval dobrý filepicker, tak to píšu.
Též je prvek při přejetí myší zvýrazněn.
Ano, tím se také hájí spousta těch, kdo nezvýrazňují odkazy na svých webech - že se to zvýrazní při najetí myší. Ne, takhle to není dobře, uživatel by neměl být nucen šmejdil po webu myší, aby zjistil, co je odkaz. Stejně tak by uživatel neměl být nucen šmejdit myší po dialogu, aby zjistil, které prvky jsou aktivní.
Tohle je udělané dobře, nedeformovaný uživatel to pochopí...
Obviňovat mne ze zdeformovanosti Windows, to je… jak to říct slušně… úsměvné… Naopak, skoro bych řekl, že z vás mluví zdeformovanost návykem na Gtk2 ovládací prvky, takže se na ně nedokážete podívat pohledem někoho, pro koho nejsou denním chlebem. Stejně jako když si webdesigner nehodný toho označení nedokáže představit, že někdo hned nepochopí, že co je tučně, je odkaz.
Asi holt nejsem podprůměrně inteligentní… :-)
Já to samozřejmě z toho nápisu nakonec pochopím. Ale taková věc by měla být rozeznatelná mnohem snáze, bez nutnosti něco číst - viz příklad s odkazy na webech.
No pokud si chci mačkat na čudlíky podle toho že jsou to čudlíky a ne co je na nich napsáno, tak mě to asi bude vadit, no. Nicméně myslím, že to je spíš typický use-case pro opici, což zase není úplně cílová skupina většiny toolkitů.
Já se snažím bavit o snadnosti používání uživatelského rozhraní. Takže mi jde o to, aby se s dialogem dalo pracovat rychle a efektivně. Když chci vyvolat funkci, v první řadě hledám tlačítka a z nich vyberu to správné. Pokud bych musel prohlížet veškerý text v dialogu a z něj vybírat správný nápis, bude to pomalejší a méně pohodlné. Práce s takovým dialogem bude pro mne méně efektivní a v důsledku méně pohodlná.
ten děsivý miniaturní trojúhelníček je stejně velký (a v mém tématu třeba mnohem výraznější) než checkbox. Proti tomu předpokládám bojujete taky.
Pokud je opravdu v nějakém stylu checkbox ještě méně zřetelný než tento prvek, pak ano, takový styl bych označil za (pro mne) špatně navržený.
On je trochu rozdíl mezi checkboxem, kterých je v konfiguračním dialogu nezřídka i dvouciferný počet, a prvkem, který zásadním způsobem mění celý dialog a který je v tomto případě nepostradatelný, aby (pro mne) byl dialog vůbec použitelný.
2.10.6 je tak strašně stará verze? Podle oficiálního webu není stará ještě ani rok… V každém případě sláva, že to autory Gtk konečně napadlo. Ale neodpustím si poznámku, že to taky mohlo být dřív, když vezmu v úvahu, že mi ten filepicker pije krev už od pre-release verzí Firefoxu 1.5.
Tak teď ještě kdyby tak šlo zrušit ten tlačítkoidní zápis cesty a do levého panelu bylo možné dát celý adresářový strom místo "oblíbených ponožek".
.
Kód je naneštěstí tak dlouhý, že jsem neměl sílu jej měnit.
18.8.2007 22:56
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
.
Zkus si strčit hlavu do kyblíku se studenou vodou, pak si to znovu přečíst a věřím, že přijdeš na to, že jsi nepochopil o čem zápisek je, na co se ptám a pak ti snad bude jasné i proč.
. A názory na ideální souborový dialog anti GTK remcalů mě zajímají, rád bych ho vytvořil .
Mimochodem, jsem zvědav, jestli budeš mít slušnost, čest a kuráž se omluvit za všechna tato křivá obvinění, až se uklidníš .
Vývoj Gtk+ nesleduju, ale pracuje už někdo na optimalizaci ? Kdy lze očekávat začlenění do nové verze ?
18.8.2007 23:50
Zdenek.Z | skóre: 14
.
Ale pokud chceš dobrý file dialog pro Gtk, mrkni se na KDE dialog . Zatím jsem oproti němu slyšel dvě námitky - že je to kopie toho z Windows (což mi nepřijde jako popis chyby, ale osobních antipatií vůči Windows) a že má moc funkcí (které jsou imho před běžným uživatelem skryty a stejně jsou to jenom volání funkcí z kdelibs). Je pravda, že systém co adresář to tlačítko se na některé akce hodí, ale pokud si mám vybrat mezi tlačítky a adresním řádkem, nemají tlačítka šanci.
Pokud se mi na Gtk dialogu něco nelíbí, tak fakt, že je tak "intuitivní", až je potřeba k němu psát manuál. To mi nepřijde jako příliš dobrý návrh takto primitivního widgetu (zvlášť, když KDE dialog toto nevyžaduje a těch funkcí tam má daleko víc!), ať si usability testeři tvrdí co chtějí.
BTW: Příklad Coca Coly ukazuje, že je velice ošemetné tvrdit, něco na základě zkoušek v laboratoři. To, co dopadne výborně v testu nakonec ještě nemusí být to, co se dobře používá v reálném světě.
Zatím jsem oproti němu slyšel dvě námitky - že je to kopie toho z Windows (což mi nepřijde jako popis chyby, ale osobních antipatií vůči Windows)kto to vydava za namietku? snad tym nemyslis mna? ja to hovorim len kvoli tomu aby som schladil flamerov (zvycajne maju iracionalny odpor nielen voci vsetkemu mimo KDE, ale aj voci comukolvek co sa tyka windows)
myslel som tym flamerov, ktori sa dokazu donekonecna hadat aj o takej blbosti ako jedno male okienko (a to zhodou nahod len KDE fanboys...)Obvykle je lepší se vyhýbat používání obecných kvantifikátorů, protože se skoro vždy najde příklad, kdy dané tvrzení neplatí
BTW: mě to jako blbost nepřijde. Opravdu nerozumím tomu, co je tak složitého na filedialogu, že by k němu měl být manuál, abych ho mohl používat
Co tě tu tak pozoruji (i v různých jiných diskuzích), tak právě ty jsi ten největší vyvolávač hádek a přilévač oleje do ohně. Nevidíš si do vlastní huby.
No jenže ty trpíš mylným dojmem, že to co pomáhá windows k té slavné konzistenci je fakt, že je na to knihovna. To možná, ale hlavní je, že je jasně dané jak ten dialog vypadá a jak se chová.Ovšem pokud bys četl pořádně, tak já napsal ...
Raději bych, pokud by freedesktop.org vydalo look&feel specifikaci standardního widget setu (nejraději včetně ekvivalentů komponent z comctrl32.dll z Windows) a autory jednotlivých widget setů uhánět tak dlouho, než ji naimplementují.Pokud tam vidíš něco o tom, že by se měla používat jediná knihovna na všechno, tak to jsem nikdy nepsal. Ono to ani není technicky možné ...
Řekni mi co udělám až budu potřebovat nějaký ovládací prvek který sice bude podobný nějakému z toho tvého supervýběru, ale přesto nebudu moci žádný z nich použít.No, tak si jej napíšeš, ale to bude až poslední možnost po tom, co ti nebude vyhovovat žádný ze standardních prvků (a přesvědčíš uživatele, že je tvoje řešení skutečně lepší). Dnešní situace je ta, že každý tvůrce nového toolkitu si vymýšlí úplně všechno sám. Proč třeba není možné, aby Gnome i KDE dialog měly stejné nastavení oblíbených adresářů? To ale přece neznamená, že pokud nebude nějaký prvek obsažen v nějakém standardu, že se nesmí v žádném toolkitu implementovat a používat. Naopak, pokud bude užitečný, klidně ať se zpětně do standardu dostane.
A proto raději použiju svoje dialogy, které sice možná nebudou stejné jako u jiné aplikace, ale aspoň budou všechny stejné v rámci té mojí. Což je pro mne důležitější požadavek.Alias NIH syndrom, co?
Potom můžu používat multiplatformní aplikace jako OpenOffice (vlastní dialogy), Operu (Qt dialogy), Sqldeveloper (vlastní dialogy), Netbeans (Swing dialogy), Eclipse (Gtk dialogy), které na jiných systémech jako OS X, nebo Windows žádné nepřekonatelné problémy s dodržováním nějakého standardu* nemají. V čem potom je v tomto konkrétním případě neexistence standardu pro look&feel na opensource desktopech výhodou? Proč je první reakcí na nějaký Gtk/Qt program - a kde je opačná varianta s odůvodněním, že chci mít všechno konzistentní? Proč je na Linuxu taková pitomost, jako použitá grafická knihovna tak zásadní věcí?
Já osobně považuji specifikaci standardních názvů pro ikony za první krok a existenci projektů jako Tango vítám. Stejně by bylo možné pokračovat dál a udělat standardní vzhled (osobně by mi se mi líbilo něco ve stylu Clearlooks) a dále vydefinovat standardní množinu widgetů a jejich chování (to snad nebude takový problém) a nakonec i standardní dialogy pro interakci s uživatelem.
* chápu, že na Windows nebo OS X je standard to, co řekne Microsoft, nebo Apple a ve světě OSS nic takového není možné. Ale organizace freedesktop by imho něco podobného dokázala navrhnout a prosadit.
> V čem potom je v tomto konkrétním případě neexistence standardu pro look&feel na opensource desktopech výhodou? Že ho není nutné dodržovat, když není?... a v tom lepsom pripade teraz lutujes, ze si to napisal
Pak se jistě začne shánět po možnosti jak vnutit svůj vzhled a dialogy pokud možno všem aplikacímHm, a proč čekat a nenadefinovat nějaký rozumný standard, který by umožnil aplikacím převzít vzhled a dialogy prostředí bez ohledu na toolkit? Že lze vyřešit vzhled lze ukazuje třeba Tango Patcher (který zařídí, že se všechny slušné windowsí aplikace tváří jako Gtk/Clearlooks) a podobně by určitě šly vyřešit i ty dialogy (včetně např. prostoru pro náhled nebo vlastních voleb aplikace), ale tohle se ti v nějaké jiné diskusi taky nelíbilo. Proč?
No, já vidím problém v tom, že kdyby si freedesktop.org vzalo za vzor GNOME a specifikaci vytvořilo na jeho základě, tak ty budeš mezi prvními, kdo budou chtít, aby se na to kašlalo a KDE mělo své vlastní dialogy.Překvapuje mě, že mě tak znáš
. Ale skutečně, pokud by freedesktop jenom vzalo jedno prostředí a toolkit a chtělo do něj napasovat zbytek, asi by tam nebylo něco v pořádku.
MAC OS a Windows si nemůžeš brát za příklad, protože v nich to funguje jinak. Společné dialogy můžeš mít jen tehdy, když budeš mít společnou knihovnu. To znamená, že bys musel rezignovat na GTK a QT a vytvořit univerzální GUI knihovnu pro linux, nebo přimět GNOME na používání QT nebo přimět KDE na používání GTK.Nemusel. To, co by existovalo by byla jenom specifikace - tento widget dělá tohle a vypadá (ve výchozím stavu) takto. Tento dialog zase dělá tohle a nastavení čte odtud. Takový Apple to u Javy udělal. Aplikace napsaná ve Swingu a spuštěná v OSX pomocí jejich verze JVM bude vypadat a chovat se prakticky stejně, jako nativní aplikace (Sune, vidíš to?). Ano, mnoho Java aplikací možná nebude splňovat Applí guidelines, ale faktem je, že Swing aplikace v OS X není prakticky rozeznatelná od nativní. Ano, souhlasím, že by to byl technický problém, ale pro desktop jako takový by to bylo jenom plus.
Jedna věc je sjednotit ikony a jejich názvy, což je představitelné, druhá věc je sjednotit GUI toolkity, což je představitlené jen stěží.Ještě jednou, já nemluvím o sjednocení toolkitů, ale o definici standardu pro look&feel*. Kdysi tohle v Unixech představoval Motif, proto třeba Tk, Qt, nebo staré Gtk1 vypadalo prakticky jako on. Otázka sjednocení toolkitů je technicky neproveditelná, protože mimo Gtk a Qt, o existuje ještě Swing, Fox Toolkit, Tk, WDE, speciální toolikty pro OpenOffice a kdo ví, co všechno. A každý autor si prostě všechno udělá podle svého, protože ani není pevný bod, podle kterého by se mohl orientovat. * který by to měl složité, protože už existuje hromada knihoven
Ale jestli KDE přejde na GTK, budu jen rád.Nedovedu si představit, jaké výhody by to pro KDE mělo. Qt není jenom widget set, Qt zahrnuje i podporu vláken, síťování, multimédií, zpracování Xml a a tak dále a to všechno s podporou na třech dalších platformách ... Napiš seznam knihoven, které by tohle vše dokázaly pro C++ nahradit (něco umí boost, ale srovnej stáří Qt/KDE a boost, a ten se v novém KDE stejně používá).
19.8.2007 01:02
Jardík | skóre: 40
| blog: jarda_bloguje
19.8.2007 01:06
Jardík | skóre: 40
| blog: jarda_bloguje
19.8.2007 02:27
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
19.8.2007 10:39
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2007 17:14
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
19.8.2007 12:23
Jardík | skóre: 40
| blog: jarda_bloguje
19.8.2007 13:08
Michal Fecko | skóre: 31
| blog: Poznámkový blog
michal@ubuntu-desktop64:~$ python bench.py
bez psyco
/dev/
files: 696
time load: 0.0006 s
time stat: 0.0156 s
time over: 0.0414 s
/usr/bin/
files: 1186
time load: 0.0009 s
time stat: 0.8691 s
time over: 0.0487 s
/bin/
files: 104
time load: 0.0001 s
time stat: 0.0363 s
time over: 0.0041 s
/usr/share/doc/
files: 1082
time load: 0.0245 s
time stat: 0.0108 s
time over: 0.0436 s
/usr/lib/
files: 957
time load: 0.0008 s
time stat: 0.0186 s
time over: 0.0520 s
/usr/share/
files: 273
time load: 0.0002 s
time stat: 0.0024 s
time over: 0.0109 s
chorchoj:13:18:49 ~$ time file /usr/bin/* > /dev/null real 0m28.042s user 0m0.843s sys 0m0.952s chorchoj:13:19:22 ~$ time file /usr/bin/* > /dev/null real 0m1.093s user 0m0.642s sys 0m0.406s
19.8.2007 13:27
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Co to měříš? Souvisí to nějak s tímhle?Na zaciatku je pridane toto...chorchoj:13:18:49 ~$ time file /usr/bin/* > /dev/null real 0m28.042s user 0m0.843s sys 0m0.952s chorchoj:13:19:22 ~$ time file /usr/bin/* > /dev/null real 0m1.093s user 0m0.642s sys 0m0.406s
benchmark
Prosím o spuštění tohoto benchmarku a postnutí výsledků sem zpět.
Uvedený kód zkopírujte do souboru bench.py a spusťte jej příkazem
"python bench.py". Pozor, benchmark lze spustit jen jednou, při
druhém spuštění se data čtou z keše a nedávají reálné výsledky.
Mně se totiž zdá, že stat() nepředstavuje výkonnostní problém,
u mně proběhne do 0.2 sekundy na adresáři v kterém je přes 1500 souborů.
try:
import psyco; psyco.full()
except:
print "bez psyco"
from os import stat, listdir
from time import time, localtime, strftime
paths = ['/dev/', '/usr/bin/', '/bin/', '/usr/share/doc/', '/usr/lib/', '/usr/share/']
def humanSize(size):
size = float(size)
if size < 1024:
return "%.0fB" % size
elif size < 1024**2:
return "%.2fKB" % (size/1024)
elif size < 1024**3:
return "%.2fMB" % (size/1024**2)
else:
return "%.2fGB" % (size/1024**3)
def main(path):
modetype = {1:'IFO', 2:'CHR', 4:'DIR', 6:'BLK', 8:'REG', 10:'LNK', 12:'SCK'}
t1 = time()
files = listdir(path)
t2 = time()
badfiles = []
for fname in files:
fpath = path + fname
try:
fstat = stat(fpath)
except:
badfiles.append(fname)
continue
t3 = time()
badfiles = []
for fname in files:
fpath = path + fname
try:
fstat = stat(fpath)
except:
badfiles.append(fname)
continue
ftype = modetype[(fstat[0]&0170000)>>12]
fuid = fstat[4]
fgid = fstat[5]
fsize = "%10s" % humanSize(fstat[6])
ftime = strftime('%d.%m.%Y %H:%I:%S', localtime(fstat[8]))
t4 = time()
print path
print 'files:', len(files)
print 'time load: %.4f s' % (t2 - t1)
print 'time stat: %.4f s' % (t3 - t2)
print 'time over: %.4f s' % (t4 - t3)
print
for path in paths:
try:
main(path)
except:
raise
pass
bez psyco /dev/ files: 689 time load: 0.0004 s time stat: 0.0051 s time over: 0.0210 s /usr/bin/ files: 2175 time load: 0.0019 s time stat: 1.0518 s time over: 0.0706 s /bin/ files: 104 time load: 0.0002 s time stat: 0.0012 s time over: 0.0032 s /usr/share/doc/ files: 1621 time load: 0.1121 s time stat: 1.2191 s time over: 0.0519 s /usr/lib/ files: 2181 time load: 0.0020 s time stat: 0.5000 s time over: 0.0744 s /usr/share/ files: 338 time load: 0.0004 s time stat: 0.1525 s time over: 0.0108 s
$ python ./bench.py bez psyco /dev/ files: 722 time load: 0.0010 s time stat: 0.0420 s time over: 0.0363 s /usr/bin/ files: 2229 time load: 0.0013 s time stat: 2.2380 s time over: 0.1248 s /bin/ files: 104 time load: 0.0001 s time stat: 0.0697 s time over: 0.0025 s /usr/share/doc/ files: 1687 time load: 0.1962 s time stat: 7.1421 s time over: 0.1015 s /usr/lib/ files: 1872 time load: 0.0012 s time stat: 0.8873 s time over: 0.0469 s /usr/share/ files: 358 time load: 0.0170 s time stat: 1.2246 s time over: 0.0245 s(5400rpm 2,5" disk)
bez psyco /dev/ files: 405 time load: 0.0003 s time stat: 0.0029 s time over: 0.0155 s /usr/bin/ files: 2295 time load: 0.0038 s time stat: 0.3126 s time over: 0.0754 s /bin/ files: 111 time load: 0.0001 s time stat: 0.0142 s time over: 0.0022 s /usr/share/doc/ files: 9 time load: 0.0000 s time stat: 0.0000 s time over: 0.0002 s /usr/lib/ files: 835 time load: 0.0008 s time stat: 0.1786 s time over: 0.0357 s /usr/share/ files: 171 time load: 0.0003 s time stat: 0.2032 s time over: 0.0072 s
19.8.2007 14:28
frEon | skóre: 40
| Praha
# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HTS541616J9SA00 , FwRev=SB4OC7BP, SerialNo= SB2404SJKMVJYE
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=7516kB, MaxMultSect=16, MultSect=?0?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7
$ python bench.py
bez psyco
/dev/
files: 228
time load: 0.0002 s
time stat: 0.0096 s
time over: 0.0079 s
/usr/bin/
files: 1050
time load: 0.0006 s
time stat: 1.0028 s
time over: 0.0367 s
/bin/
files: 102
time load: 0.0001 s
time stat: 0.0864 s
time over: 0.0033 s
/usr/share/doc/
files: 841
time load: 0.0490 s
time stat: 4.6452 s
time over: 0.0282 s
/usr/lib/
files: 1330
time load: 0.1215 s
time stat: 0.6908 s
time over: 0.0461 s
/usr/share/
files: 144
time load: 0.0001 s
time stat: 0.5427 s
time over: 0.0046 s
19.8.2007 22:22
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Teď je otázka, jak to postupné načítání udělat. Jedna možnost je načíst nejprve názvy, ty zobrazit a pak k nim dočíst metadata. To je myslím blbost, protože v první chvíli by člověk nevěděl ani jestli se jedná o o adresář nebo soubor.Typ souboru jde (např. u EXT3, ale myslím že už ne u ReiserFS) zjistit přímo z adresářové položky. Ale o to nejde. Načítání atributů na pozadí úplná blbost rozhodně není. Já bych to celé viděl takhle:
stat()) atributy těch souborů, které jsou uvnitř viewportu (jsou viditelné).
19.8.2007 23:02
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
).
20.8.2007 09:15
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
19.8.2007 22:23
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Teď je otázka, jak to postupné načítání udělat. Jedna možnost je načíst nejprve názvy, ty zobrazit a pak k nim dočíst metadata. To je myslím blbost, protože v první chvíli by člověk nevěděl ani jestli se jedná o o adresář nebo soubor.Typ souboru jde (např. u EXT3, ale myslím že už ne u ReiserFS) zjistit přímo z adresářové položky. Ale o to nejde. Načítání atributů na pozadí úplná blbost rozhodně není. Já bych to celé viděl takhle:
stat()) atributy těch souborů, které jsou uvnitř viewportu (jsou viditelné).
19.8.2007 17:57
Josef Kufner | skóre: 70
19.8.2007 20:35
Josef Kufner | skóre: 70
19.8.2007 22:09
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
[22:07:01 marian@nest bin]$ sudo hdparm -i /dev/sda
/dev/sda:
Model=WDC WD2500KS-00MJB0 , FwRev=02.01C03, SerialNo= WD-WCANK1585164
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
[22:07:05 marian@nest bin]$ sudo hdparm -i /dev/sdb
/dev/sdb:
Model=WDC WD2500KS-00MJB0 , FwRev=02.01C03, SerialNo= WD-WCANK2089114
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
[22:02:04 marian@nest bin]$ python ~/bench.py
bez psyco
/dev/
files: 739
time load: 0.0011 s
time stat: 0.0431 s
time over: 0.0256 s
/usr/bin/
files: 2641
time load: 0.0042 s
time stat: 0.6462 s
time over: 0.1089 s
/bin/
files: 126
time load: 0.0003 s
time stat: 0.0501 s
time over: 0.0048 s
/usr/share/doc/
files: 762
time load: 0.0412 s
time stat: 1.2482 s
time over: 0.0293 s
/usr/lib/
files: 2745
time load: 0.0045 s
time stat: 0.2781 s
time over: 0.1417 s
/usr/share/
files: 223
time load: 0.0004 s
time stat: 0.3052 s
time over: 0.0083 s
). Proste je to jine prostredi a presto spouste lidi vyhovuje.
Filedialog je urcen pro vyber souboru, ne pro manipulaci s nimi.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.