Věční remcalové, ukojte své choutky (GTK file dialog)

18.8.2007 21:51 | Přečteno: 2442× | linux | poslední úprava: 14.9.2007 20:06

Na světě je spousta remcalů. remcají pořád, všude a proti všemu. Budiž jim to přáno, máme tu remcalokracii a remcat se může skoro proti všemu. Jedna remcalí skupinka, GTK haters si neříkají, tu remcá pořád proti GTK.

Maximum výtek se směřuje proti bezvadnému souborovému dialogu, s kterým neumí pracovat, protože není tak úplně pro lamy, i když oni si myslí že ano. GTK haters mají totiž blízko ke GNOME haters, a GNOME haters si myslí, že GNOME ... no to je jedno, to bych moc odbočil.

O co mi vlastně jde. Jde mi o to, že bych od remcalích GTK haterů rád slyšel, jak si představují ideální souborový dialog. Aby zde popsali svou vizi, souborový dialog svých snů. Pokud tento vysněný souborový dialog nebude mimo realitu, pokusím se o vytvoření jeho prototypu v Pythonu. Bylo by troufalé si myslet, že jej pak někdo implementuje v C a že se stane součástí GTK, ale zkusme na chvíli předstírat že ano.

Tak do toho, jak by měl vypadat a jaké by měl mít vlastnosti ideální souborový dialog? Jestli jste jí remcalové schopni, prosím o serióznost.

---

vlastnosti ideálního souborového dialogu

Zde je výpis k 19. 8. 2007 21:15, co jsem si z vašich přání odnesl:

• přejmenování adresáře
• wildcars
• zobrazit víc souborových atributů, možnost podle nich třídit
• historie adresářů
• načítání atributů na pozadí
• případný expander defaultně otevřený
• náhledy obrázků
• cesta v textové podobě
• má být fulscreen
• rozlišování podle přípony i za cenu nekonzistence se zbytkem systému
• indikace: spustitelný, jen pro čtení
• pamatovat si stav třídění
• stručný vícesloupcový režim zobrazení
• tlačítko refresh
• výběr pomocí obdélníku
• adresní řádek s autocomplete
• automatická změna focusu, šipky do seznamu, text fo adr. řádku
• snadno ovladatelný jen pomocí klávesnice
• drag and drop
• základní operace se soubory: kopírování, mazání, přejmenování
• otevření terminálu na aktuální cestě
• otevření správce souborů na aktuální cestě

---

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

       

Komentáře

[phero]

To jsou otazky, idealni je ten v KDE - jaky jiny.

[disorder]

a to je takmer identicka kopia toho z windows...

[miso]

Pokial sa dobre pouziva, je to problem?

[disorder]

mne sa dobre pouziva aj ten z Gtk+, v niektorych ohladoch lepsie a celkovo (cize nie v absolutnom porovnani ale beznom pouzivani) mi tam nic nechyba

[miso]

Mysli, ze pokial sa to nezvrhne na flame, tak zistis co inym ludom na Gtk+ dialogu vadi
(mozno aj ty by si uvital zmenu k lepsiemu, len si si uz zvykol)

[disorder]

moje stretnutia s file dialogom zacinaju a koncia zvycajne enterom (pripade pred tym enterom este prejdem do ineho adresara). nechapem co ini ludia robia, tvaria sa akoby tam travili hodiny...

ja som si na nic nemusel zvykat, mne sa pacil od zaciatku (aj v gtk 1)

[Michal Kubeček]

(pripade pred tym enterom este prejdem do ineho adresara)

A zrovna tohle je u Gtk2 filepickeru uživateli nepříjemně zkomplikováno.

[disorder]

v tom pripade nie som uzivatel?

[Michal Kubeček]

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í?

[disorder]

neviem ci mi to vadi, nikdy som to nepotreboval kvoli takej blbosti spravit...

[Michal Kubeček]

V tom případě se možná bavíme každý o jiném dialogu. Já mám na mysli filepicker, který používají např. aktuální verze Firefoxu, GIMPu nebo VMware. Ten mi bez přepnutí do plnohodnotné podoby adresář změnit neumožňuje.

[disorder]

nepouziva firefox a GIMP vlastny?

asi hovoris naozaj o inom, mne to ide...

[Michal Kubeček]

Mluvím o tomhle. Není to sice úplně aktuální verze (a možná ani firefox), ale ten současný save as dialog ve Firefoxu vypadá skoro stejně, jen jsou jednotlivé prvky trochu zaoblenější. Ve Firefoxu ale naštěstí lze snadno nastavit používání KDE filepickeru, s GIMPem nebo VMware je to bohužel horší.

[disorder]

opakujem, firefox a GIMP maju svoje dialogy.

ano, hovorim o niecom takomto -- no, skusil si kliknut na to rozbalovatko a vybrat svoj oblubeny dir.? alebo stlacit ^L?

[Michal Kubeček]

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.

[disorder]

http://img242.imageshack.us/img242/9694/saveas1py6.png

[Michal Kubeček]

To je (pro mne) naprosto k ničemu, to mi umožní jen výběr z několika málo předem určených adresářů.

[disorder]

a to ^L nejde? mne to iceweasel zozral. takze si mozem vybrat zo svojich oblubenych adresarov alebo kam chcem...

[Michal Kubeček]

Funguje, ale nějak mne to neoslovilo. Sice rád používám textové uživatelské rozhraní, ale ne vždy a ne na všechno. A tohle je zrovna situace, kdy dám přednost klasice (reprezentované třeba KDE filepickerem).

[deda.jabko]

problem je, jak mam vedet, ze mam zmacknout Ctl+L? z toho dialogu nemam sanci poznat, ze tam nejaka takove fce. je...

[disorder]

ktory idiot by sa ucil pouzivat pocitac, ze? vsak to je primitivne!

[deda.jabko]

muzete mne to vysvetlit, kde se o takove funkci mam naucit?

z toho dialogu neni vubec zrejme, ze tam takova fce je.... neni k tomu napoveda... ergonomie sama....

[disorder]

http://www.gnome.org/learn/users-guide/latest/overview-applications.html#filechooser-open

dalsi co spadol uceny z neba, ze? hned si vedel pouzivat vim/emacs, co? (vyber si)

[miso]

spustim vi:

type :help[Enter] or [F1] for on-line help

[disorder]

pokial si myslel vi (ako ozajstne vi, nie vim), tak z toho mozes vyzistit akorat strohy zoznam skratiek

pokial myslis, ten slavny vim:

E433: No tags file E149: Sorry, no help for help.txt

hm...

[miso]

Som si isty, ze vies o com je rec

[disorder]

neviem ako dobre funguje napoveda v gnome (nepouzivam), ale ako priklad si uviedol vim, kde mi to absolutne nejde. mal si skusit radsej emacs...

[Petr Mach]

Že ti chybí soubory s nápovědou k VIMu snad není chybou VIMu, ne? By mě zajímalo, jak jsi o ně mohl přijít. Nedělal sis ručně místo na disku a nesmazal je?

[disorder]

rucne nerobim upravy do systemu, nie som barbar.

uplne obycajny balicek vim-tiny + vim-common co mam od instalacie etch...

[deda.jabko]

super! takze pokud me ten idiotsky dialog vyskoci v mozille nebo eclipse... tak se pujdu podivat na stranky gnome... to uz se rovnou muzu jit zeptat na hlavni nadrazi....

navic toto reseni, apriori predpoklada pripojeni k internetu... coz prekvapive nemusi byt vzdy, kdyz clovek pouziva file-dialog...

[disorder]

tak si nainstalujes gnome-user-guide s tvojej oblubenej diskety

[deda.jabko]

to ale neresi ten problem, ze kdyz pouzivam file dialog.... tak me nedava smysl to hledat pod gnome

[disorder]

tak to hladaj v kde, mne je to fuk

[Michal Karas]

Tak to máte asi opravdu nějakou starou verzi. Mně se ten dialog otevře v takové formě, v jaké jsem ho minule nechal.

[Michal Karas]

Aha, tak níže v diskuzi už to je zmíněňo, takže se omlouvám za zbytečný komentář.

[Michal Kubeček]

Firefox 3.0 Alpha 7 (verze stará asi tak dva týdný). Nepamatuje si to, pokaždé je znovu nerozbalený.

[Michal Karas]

GTK+ 2.10.14 a Firefox 2.0.0.6 (nebo GViM 7.1.77 nebo GIMP 2.2.17) funguje.

[Michal Kubeček]

Kombinace Firefox 3.0 Alpha 7 a Gtk2 2.10.6 ne.

[thingie]

Možná je to nějaký distribuční patch, u mozilly by se člověk ani nedivil.

[Michal Karas]

Zajímavá kombinace. Zbrusu nový Firefox a třičtvrtě roku staré GTK.

[Michal Kubeček]

Gtk je distribuční (OpenSuSE 10.2, release loni koncem roku), Firefoxe si překládám sám, protože v distribuci je 32-bitový build (kvůli flashi, který tam stejně nechci). V 10.3 už by IIRC měl být 64-bitový Firefox, takže toho asi nechám.

[Michal Kubeček]

V tomto případě jsem si ale hlavně chtěl vyzkoušet některé zajímavé novinky z verze 3.0.

[Luk]

Horší dialog, než je tenhle, jsem snad neviděl. To se někdo musel pořádně praštit o futro, že něco takového vymyslel.

Naopak za dobrý považuji dialog v KDE (ano, je Windows-like, ale to přece není problém) nebo dialog v javovském Swingu. Pracuje se s nimi pohodlně a efektivně.

[Michal Kubeček]

Já viděl horší. Ale na jeho omluvu je nutné upozornit, že jsem ho poprvé viděl před nějakými 13 lety a pravděpodobně je ještě o dost starší. A nikdo ho nevydává za poslední výkřik techniky a netvrdí, že takhle se to má dělat.

[Pietro]

To sa podoba na dialog z NextStepu alebo niecoho takeho, nie?

[Michal Kubeček]

Tipoval bych, že je to Athena (ve variantě Xaw3d), ale už je to přeci jen nějaký ten pátek, co jsem se s takovými věcmi běžně potkával. V každém případě to pamatuje doby, kdy byl Motif vrcholným estetickým zážitkem… :-)

[Luk]

Ano, pravda, já ho vlastně viděl také, ale už je to dávno.

[happy barney]

Vám nevadí, že existujú ľudia, ktorý majú iný systém prace ako vy?

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.

[Michal Kubeček]

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á.

[happy barney]

riešenie vášho (a nielen vášho) problému:
zopár libiek (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)

[miso]

V tomto pripade (pokial ti vsetko vyhovuje) si spatne v diskusii Gtk-filedialog-remcalovia

[disorder]

nevyhovuje mi vsetko na 100%, ale mam v nom vsetko co som kedy potreboval...

[otula]

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?
To bylo opravdu velmi špatně zvolené přirovnání. (Pokud něco z těch věcí lze v XP nebo ve Vistě, tak se předem omlouvám, prakticky/úplně vůbec se s těmito systémy nesetkávám.)

[disorder]

identicky ber s rezervou. a snad nechces tvrdit, ze windows je len nepodarena kopia KDE? co tu bolo skor?

[otula]

Netvrdím, že MS to zkopíroval z KDE. Chtěl jsem jen říct, že zdání klame, a to, že na první pohled se tyto dialogy mohou zdát jakoby podobné neznamená, že podobné skutečně jsou.

[disorder]

a co spravime s faktom, ze su si naozaj viac nez podobne, hm?

[...............23]

patentujeme si ho a zažalujeme ich!

[otula]

právě jsem napsal odpověď a malinko níže k dialogu z Visty. Tedy: podoba mezi klasickým filedialogem např. z Win2k je prakticky nulová, funkčnost naprosto rozdílná. Podoba s filedialogem z Visty je zatraceně velká (ale Vista tu nebyla dříve, než KDE, že jo?) A vývojáři KDE určitě nemohou za to, že MS o x let později „vymyslel“ stejný filedialog.

[disorder]

odpovedal som nizsie

[Lu-Tze]

http://www.answers.com/topic/windows-vista-open-dialog-png

Řek bych, že skoro všechno ve win je. Otázka na ty protokoly nemá ve win smysl (tam není důvod, aby tohle řešil desktop environment). Hlavně to políčko search je teda luxusní fíčura

[otula]

Hm, tak tady už bych byl i ochoten tvrdit, že tohle MS z KDE zkopíroval (on to SAMOZŘEJMĚ neudělal, že ano?)

[Lu-Tze]

http://www.youtube.com/watch?v=jiWi-0FQ1RM

Řek bych, že se inspiroval i v GNOME, třeba u save as dialogu hodně...

[disorder]

je to len "vylepsenie" toho strasne nevkusneho povodneho dialogu, v tejto podobe dokonca so stazenou pouzitelnostou...

nie si tak trochu zaslepeny? princip je tam uplne bez zmeny...

[otula]

Vidíš to, jak jsem psal, zdání klame. Tentokrát mne. Ignor napsal, že by řekl, že skoro všechno ve win je, tudíž jsem to bral jako hotovou věc, a při zběžném pohledu na zmíněný screenshot jsem nabyl dojem, že je to jak v KDE. Bližší pohled (třeba to dále zmíněné video) ukáže, že tomu tak ale není. Opravdu jsem Vistu živě ještě neviděl, ani mne to nějak neláká, takže to nemohu posoudit objektivně. A jestli jsem zaslepený? Těžko říct. První jsem znal DOS, potom různá Windows, pak Linux/Gnome (vyzkoušel jsem si letmo i BeOS, QNX) a nakonec jsem skončil u KDE, které jsem předtím nechtěl ani vidět. Přestože se mi Gnome líbí víc, používám KDE, protože mi více vyhovuje. Pokud je tohle zaslepenost, pak jsem zaslepeny.

[Lu-Tze]

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.

[otula]

Hm, dá se tam ručně vypisovat cesta? A náhledy tam také nevidím (Špatně se mi diskutuje o něčem, co neznám. Opravdu by to chtělo sednout si k tomu, a ne koukat na demovideo)

[Lu-Tze]

Cesta, pokud si dobře pamatuju, se dala vždycky napsat do pole "filename". Náhledy jsou ukázány na tom videu...

[otula]

No jo, ale to by ji člověk musel znát celou úplně přesně. Měl jsem na mysli ten komfort, jako v KDE či Gnome.

[Lu-Tze]

To taky není pravda. Dá se v tom pohybovat skoro přesně jako v unixu pomocí cd (akorát nefungují wildcardy). Vyplnění 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.

[otula]

Promiň, rozhodně jsem tě nechtěl osočovat. A když si to po sobě čtu, asi to tak opravdu vyznělo. Takže ještě jednou, promiň.

[disorder]

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...

[otula]

No jo, promiň, nepředpokládal jsem, že narazím na borce, kterému je hned všechno úplně jasné. Takže se ti omlouvám, protože jsem zaslepený blbec, a ty dialogy jsou samozřejmě úplně stejné, jen ten z Visty je dokonca so stazenou pouzitelnostou.

[disorder]

pekny vystup, ale nic take netvrdim.

napriek tomu je zrejme, ze vsetky sucasti povodneho dialogu su nielen pritomne, ale takmer na rovnakych miestach...

[otula]

Nejde o to, že jsou přítomné původní součásti, ale že přibyly nové. (Velmi praktické) záložky, přibyla pro mnohé šikovná tlačítka zpět a vpřed. Také vyhledávání, které je (možná) velmi užitečné, a (dokonce) zatím v KDE není. Chybí mi tam náhled vybraného souboru (možná lze zapnout?). Pokud jde o rozmístění, je přirozené, nemá cenu ho moc měnit.

[disorder]

nic co by som potreboval, ale ja nie som typicky klikac. napriek tomu nemas pravo upierat windowsu pravo na evoluciu...

a "prirodzene" si nechaj pre seba, pocitace nie su cloveku prirodzene...

[otula]

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ří.

[Rezza]

To bude jeste roku a roku trvat nez zkopiruji Widle dialog z KDE :)

[atan]

Ted jsem zase porovnal oba, a u me je KDE jasny vitez.

[Luboš Doležel (Doli)]

Já se tomu dialogu vyhýbám, co to jen jde, ale aspoň funkce přejmenovat adresář (nebo dokonce soubor, ale to už bych asi chtěl moc) by tam být mohla. Už se mi hodně krát stalo, že jsem vytvářel adresář při dělání screenshotu ve VMware, ale napsal jsem chybu, které jsem si nevšimnul, nebo jsem přepnul do jiného okna (hledal jsem verzi distribuce) a neuvědomil jsem si, že to vytváření adresáře potvrdí s nedopsaným jménem.

Pak musím jako idiot otevřít nějaký filemanager/konzoli a ten adresář přejmenovat, protože to ten GTK+ shit neumí.

[Luboš Doležel (Doli)]

K tomu návrhu - ať vypadá třeba jako ten ve Windows, ten v KDE nebo ten v Qt 4. Je to jedno, hlavně ať není tak debilní.

[Lu-Tze]

To zní docela rozumně. Možná by ale bylo lepší úplně funkci vytvoření adresáře vyhodit a místo toho tam dát tlačítko, které otevře aktuální adresář ve výchozím file manageru (v nautilovi ). 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).

[Josef Kufner]

No, ty základní operace, jako je přejmenování, vytvoření adresáře a smazání by tam být mohly. Jsou to věci, které jsou až překvapivě často potřeba. Nehledě na to, že ve Windows jsou open/save dialogy prakticky srovnatelné s průzkumníkem, vlastně to je průzkumník. Takže pokud se k tomuhle chcete dostat, tak už ten otvírací dialog by musel být konqueror nebo nautilus.

Co se týče přejmenovávání přímo v tom pohledu na adresář, jak se tam jen objeví texte entry uprostřed seznamu, tak je to pěkně debilní nápad bez ohledu na to, kde to je a co to dělá. Tím spíš, že to ten adresář nejdřív vytvoří a pak se spustí jeho přejmenování. Ach jo.

[Lu-Tze]

Co já si tak z KDE pamatuju, tak tam jde v otevíracím dialogu např. filtrovat obsah adresáře pomocí wildcardů - roletové menu filter je tam totiž editovatelné. Jak něco podobného udělat v gnome nevím. Teda né že bych to kdy potřeboval, jen mě to teď napadlo.

[Petr Mach]

GTK má editovatelné roletové menu, žadný problém.

[Lu-Tze]

Jak teda tam tu masku zadám? Koukám na to a nic nevidím

[Petr Mach]

Aha to jsme si nerozuměli. Já myslel že se ptáš, zda to jde implementovat, ne jestli je to už implementováno .

[thingie]

Podle mě by na většinu z nich stačilo napsat k tomu rozumnou příručku k použití a (třeba i násilím) donutit remcaly to přečíst.

[Bluebear]

Pokud je grafické rozhraní tak nepochopitelné, že si uživatel bez příručky ani neotevře soubor, tak děláme něco špatně...

[disorder]

ano, mali by sme vsetko pomenit tak aby ludia zvyknuti na windows neboli zmateni... duh

[Bluebear]

Ne; měli bychom to psát správně.

[disorder]

a z akeho dovodu podla teba dialog z qt vyzera tak ako vyzera? mne sa ten z Gtk+ pacil vzdy viac (netvrdim, ze je dokonaly) a nie je to kvoli tomu, ze je iny nez windowsacky

[thingie]

Jo. Ale postřílet blbé uživatele nejde, takže je třeba jít do příručky

[miso]

Snad je viac moznosti ako len tieto dve

[Kyosuke]

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.

[thingie]

Když si uděláš jednoduché srovnání, zjistíš zajímavou věc: co do plochy jsou oba víceméně stejně velké a množství obsažené informace takřka ekvivalentní:

Gnome, KDE.

(jiný první soubor je tam kvůli odlišnému řazení, KDE je co do locales úchylnost)

[...............23]

lenže v tom gtk sa nedá nastaviť zobrazenie súborov vo viacerých stĺpcoch tak aby som hneď videl ktoré súbory v tom adresári mám (pic)

okrem toho tomu gtkáckemu chýba tlačítko refresh, ktoré sa občas zíde

pri viacnásobnom výbere súborov ktoré nie sú vedľa seba musím v gtk na každý jeden klikať, v kdečkovom proste spravím obdĺžnik okolo skupiny súborov...

inak mne ani ten gtk dialog bohvieako nevadí, gnome a gtk veci nepoužívam z úplne iných dôvodov...

[thingie]

Backend by měl změny hlídat, refresh by tedy neměl být třeba.

[...............23]

Tak v tom prípade to buď nefunguje alebo to má moc dlhý timeout. Aspoň klávesová skratka (F5) by na to mohla byť...

[thingie]

No u klávesové zkratky budou všichni remcat, že jak o ní mají vědět 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...

[Petr Mach]

Prosím konkrétnější popis doplňování cesty a vysvětlení pojmu screen estate.

[Käyttäjä 11133]

Neznáš bashcompletion, nebo co? :D

[Petr Mach]

Znám, ale tam se cesta nedoplňuje automaticky, ale až po stisknutí tabu. Tudíž jsem myslel, že se chce něco jiného, spíš na způsob omnicompletion nebo tak. Proto jsem požádal o bližší vysvětlení.

[frEon]

ta cesta se doplnuje polo automaticky, jakmile zacnes psat, tak to nabizi moznosti, ze kterych si sipkovimy klavesamy muzes vybrat. skupina nabizenych moznosti se samozdrejme zuzuje podle toho co vyhovy pocatecnim znakum toho cos napsal.

to je prave ten luxus, ze kdy potrebuju do nejakyho adresare, treba /home/michal/dokumenty/knizka.pdf tak mi staci napsat /h sipka dolu, m sipka dolu, d sipka dolu, entr vybrat soubor (bud misi, nebo pouzit zase stejne doplnovani, ale ve vyberu souboru, ne cesty)... zadna akce neni zbytecna a zadna z tech akci neni proto ze by programator si myslel ze ikonka navic by mohla chudacky blbecky mast a proto kazdy kdo by chtel neco otevrit v adresari o uroven vis by musel kliknout na neco jenom aby tu moznost dostal (no snad chapete co chci rict)...

[phero]

Tady je trochu škoda, že když vybereš něco z toho výběru (třeba /home), tak se ten výběr neposune do toho adresáře.

[Josef Kufner]

Problém je trošky s tím, že šipka dolu je poněkud daleko a myš ješte dál. Tab je na levý malíček.

[miso]

defaultne otvorit zoznam suborov

rozbalovacia historia

rychlejsie nacitavanie suborov (stat a podobne na pozadi)

ziadne tajne skratky (priklad - zadanie celej cesty)

Inac ocenujem tvoju snahu (sice pochybujem, zeby sa nieco v upstreame zmenilo) - konecne ina reakcia nez preco by sa to nemalo zmenit, ze sa da zvyknut a podobne

[miso]

+ nahlady obrazkov, to sa vzdy zide

[Michal Kubeček]

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.

[disorder]

je to uplne obycajny expander, nevyzera tak len podla ludi co take nieco v zivote nevideli...

[Michal Kubeček]

Zopakuji to ještě jednou: aktivní prvek by neměl (až na maličký trojúhelníček) vypadat nachlup stejně jako obyčejný statický text. Je to velmi matoucí.

[disorder]

zopakujem to este raz: je to uplne obycajny expander

[Michal Kubeček]

Pro člověka, který je velmi dobře zvyklý na záludnosti defaultního stylu Gtk2. Pokud i člověk, který s PC pracuje skoro dvacet let, má problém na první pohled poznat, že ten "obyčejný expander" je něco jiného než statický text (protože vypadá naprosto stejně), co očekáváte od počítačů neznalého uživatele?

[thingie]

No já nevim, jednak je to opravdu úplně běžný widget, který je ledaskde a pak, stačí to zmáčknout jednou, páč si to stav pamatuje. (nemusí platit pro jeblé emulace typu Firefox.)

[Michal Kubeček]

Ještě jsem bohužel nenarazil na aplikaci, která by používala Gtk2 filepicker a pamatovala si stav "rozbaleno". Normální prvek to sice možná (pro znalce Gtk2) je, ale až na ten trojúhelníček to vypadá naprosto stejně jako kterýkoli statický label, takže pro uživatele, který s tím není dobře seznámen, je to zatraceně matoucí. Je to úplně stejná čuňárna, jako když na některých webech nejsou odkazy ani podtržené ani odlišené barvou.

[J. M.]

V novějších verzích GTK+ už si to rozbalení pamatuje, je tam i permanentně zobrazený adresový řádek nahoře.

[Michal Kubeček]

Opakuji: ještě jsem neviděl aplikaci, která by si to pamatovala.

[J. M.]

Asi proto, že používáte staré GTK+.

[J. M.]

Tady je obsah mého ~/.config/gtk-2.0:

<gtkfilechooser>
  <location mode="filename-entry"/>
  <show_hidden value="true"/>
  <expand_folders value="true"/>
</gtkfilechooser>

[J. M.]

Pardon, soubor je gtkfilechooser ve výše zmíněném adresáři.

[Michal Kubeček]

Nepomohlo. Tedy jak jsem právě zjistil, GIMP (nechtělo se mi Firefox restartovat) si sice pamatuje stav "rozbaleno", ale pouze po dobu běhu programu. Jakmile ho ukončím a spustím znovu, je zase zabalený.

[J. M.]

A jakou máte verzi GTK+? Mně se ten konfigurační soubor (~/.config/gtk-2.0/gtkfilechooser) automaticky aktualizuje při každém použití toho dialogu.

[Michal Kubeček]

Jak už jsem psal jinde, je to verze 2.10.6.

[J. M.]

Aha. Z výpisu opravených chyb mezi 2.10.7 a 2.10.8:

153828	Filechooser does not remember state

[thingie]

U mne si to pamatuje každá co jsem zkoušel, dokonce i ten blbej Firefox. Takže chyba bude na jiné části drátu.

Co se týče toho rozbalování, tak tady opravdu zaznívá demence protlačená od Windows do zbytku GUI světa. Tlačítka mají něco dělat, rozbalovátko pak má rozbalit více informací. Používá se to na mnoha místech a je to logické. Je to odlišené, taková šipka se opravdu normálně nikde nepoužívá. Též je prvek při přejetí myší zvýrazněn. Tohle je udělané dobře, nedeformovaný uživatel to pochopí...

[Michal Kubeček]

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.

[thingie]

No dobře. Tak já asi příště nebudu podvádět, do zdrojáků se dívat nebudu a tu jednu větičku v rozkazovacím způsobu (jeden ze tří kousků textu na tom dialogu) budu správně, jako každý jiný neznalý uživatel co se nepodíval co to opravdu je, považovat za okénko experimentální prózy...

[Michal Kubeček]

Opravdu se tak usilovně snažíte nepochopit, o čem mluvím? Abych k rozeznání aktivního prvku musel přečíst, co je na něm napsané, to je ještě horší než chtít, abych to poznal podle miniaturního trojúhelníčku. To bychom rovnou mohli zrušit tlačítka a nahradit je obyčejným textem. Vždyť je tam přece napsáno, co dělají, ne? Pro dobrou použitelnost rozhraní je potřeba, aby určité věci byly vidět ihned, ne až při bližším prozkoumání.

[disorder]

o tom co je expander sa staci presvedcit raz. podpriemerne inteligentny clovek to pochopi z napisu hned.

este nieco? argumentacia dost pochybna...

[Michal Kubeček]

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.

[disorder]

priklad s odkazmi nie je ekvivalentny, odkazy nemaju konzistentny styl vsade na webe a vedla seba grafikon hyperlinku (a tiez sa nemusia rozsvietit, a uz vobec nie na cely riadok)

[thingie]

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ů.

Ihned to je vidět. Ten prvek je označen, má i zkratku, což je u běžného textu blbost. Jen tak pro zajímavost, 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. V opačném případě se obávám, že máte určité problémy s vnitřní konzistencí vašich názorů

[Michal Kubeček]

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ý.

[thingie]

Co třeba takto?

Fakt nevím kde je rozdíl. Krom toho, že proti tomu druhému jste se asi rozhod vybojovat svatou válku.

[Michal Kubeček]

Vůbec ne svatou válku. To je jen taková třešnička na dortu, kdybych na tu věc nemusel pokaždé znovu kliknout, klidně bych se s tím smířil.

[thingie]

Fajn, takže to s tím odlišením aktivního prvku nebude tak horké? (vskutku, jaký je rozdíl mezi trojúhelníčkem a čtverečkem pro člověka co to vidí poprvé? vlastně, skoro by nějaké téma mohlo ty prvky kreslit stejně)

Tenhle problém by se dal vyřešit použitím rozumně nové verze, což tu říká už asi pět lidí

[Michal Kubeček]

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".

[Petr Mach]

Tak to tedy ne, na oblíbené položky ať mi nikdo nešahá .

[Michal Kubeček]

Také by to mohlo být volitelné, vy byste tam měl své položky a já svůj strom. Ale autoři si řekli ne. Když položky, tak pro všechny… :-(

[Petr Mach]

Já bych si tipnul, že ten neznalý uživatel to bude mít snazší, než ten zaujatý a zvyklý na něco jiného. Něco se naučit je snadné, změnit zvyk je horší.

[disorder]

> co očekáváte od počítačů neznalého uživatele?

ze sa bude ucit pouzivat pocitac?

[#Tom]

Např. ve FireFoxu při ukládání stránky: Procházet jiné adresáře? Proč ne, někomu to možná pomůže. Ale kéž by to šlo vypnout!

[Michal Kubeček]

Doufám, že výrazem "vypnout" nemyslíte, že byste tu funkci "rozbalení" úplně zrušil…

[#Tom]

Ne, ale nevadilo by mi, pokud by i něco takového šlo nastavit.

[Vinicius]

Tohle chovani neni nic moc. Vznika tak, ze aplikace pozadujici po GTK+ tenhle dialog prida parametr, ze je to dialog pro ukladani a GTK+ pri tomto nastaveni necha expander zabaleny. Skoda, ze se chovani neda nastavit centralne, a kdyby k tomu bylo jeste nejake klikatko...

[#Tom]

Mně chybí možnost zadání plné cesty bez mačkání čehokoli dalšího, nějaké utajené lomítko nebo Control+L mne neuspokojují. Kód je naneštěstí tak dlouhý, že jsem neměl sílu jej měnit.

[thingie]

Můj návrh sice asi nikdo nebude mít rád, ale nejradši bych tam vybírač souborů neměl žádný. Místo něj by stačila chytristika která by věděla co vybrat. A v mém případě by to bylo dost možné, protože to používám hodně předvídatelně.

[kyknos]

Já mám GTK raději než Qt. Ale ten dialog nesnáším.

Především tam chci cestu. Editovatelnou. Ihned při otevření dialogu. A ta cesta musí zůstat celá. Ne, že když stisknu enter, aby se v dialogu objevil adresář, na který cesta ukazuje, se mi kus cesty konvertuje na ta nesmyslná tlačítka reprezentující adresáře a já už nemůžu cestu přepsat. Fuj.

V KDE se to chová skvěle.

Tohle by mi stačilo.

[J. M.]

Je absurdní vyzývat přispěvatele k serióznosti a konstruktivnosti, když celý zápisek je snůška sprostého urážení, apriorního nadávání komukoli, kdo s ním nesouhlasí, nesoudnosti a protiřečení si. Je to něco velmi podobného jako „ty kreténe, jseš vypatlanej, tvoje blbý názory mě vůbec nezajímají. Tak a teď mi řekni svoje názory. Ale seriózně!”

Za prvé: jestliže celý blog post neustále opakuje to, že ti, kteří mají jakékoli konkrétní výtky vůči souborovému diaogu GTK+, jsou věční remcalové, kteří s ním neumějí zacházet, pak je vymalováno a není se o čem bavit. Šlus. Stejně tak jako když hned zkraje autor napíše, že ten dialog je bezvadný (tedy dokonalý, protože nemá jedinou vadu). Tak proč se pak k**** ještě na něco ptá? To absolutně postrádá logiku. Když ho názory lidí nezajímají, pak by to měl říct upřímně a nepředstírat něco jiného. Tenhle blog post je prostě plivnutí do ksichtu slušným lidem a proto, ačkoli bych sem mohl zkopírovat to, co jsem psal už v jiných diskusích na toto téma, tedy zcela objektivní a nepopiratelné vady a chyby tohoto GTK+ dialogu, psát to sem nebudu.

[Kyosuke]

Ty jsi ale rejpal. Buď rád, že se Petr Mach aspoň konečně zaregistroval - už jen to je obrovský pokrok!

[disorder]

autor nepyta kritiku Gtk+ dialogu ale opis idealeho dialogu (tiez sa nezmyselne pyta, pretoze vacsinou sa o takej blbosti bavia len fanboys isteho DE, takze vsetci opisu len ich oblubeny dialog)

[Petr Mach]

Abys remcal proti GTK souborovému dialogu po tobě stejně nikdo nechtěl .

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č.

[J. M.]

Já jsem ten zápisek četl pozorně třikrát. A stojím si za tím, co jsem napsal – je to donebevolající výkvět blbosti a sprostoty. Nejdřív cílovou skupinu celý zápisek urážíš a posměšně opakuješ, že jsou blbí, neschopní a neví, o čem mluví (a že pravdu máš ty a ten dialog je dokonalý, bez jediné vady) a jejich názory jsou tudíž irelevantní (protože jsi je stoprocentně, se vším všudy, bezpodmínečně zavrhnul, dokonce i preventivně, ať jsou nebo budou jakékoli, prostě nikdy na nich nemůže nic být), abys jim nakonec, ještě se zopakovaným urážlivě posměšným oslovením, řekl, ať se tedy vyjádří. Proč by ti měli něco sdělovat, když jsou blbí a nechopní, a jejich názory jsou irelevantní? Za prvé člověka nemotivuje k tomu, aby se s tebou vůbec bavil, když mu neustále celou dobu bezdůvodně nadáváš a zesměšňuješ ho, za druhé lžeš když říkáš, že tě jejich názory zajímají, když celý zápisek křičí pravý opak. Věčný remcal, který neumí používat GTK+ dialog, ti k užitku nebude, z toho nic dobrého nevzejde. A pokud vzejde, musel bys uznat, žes prostě v celém tom blogpostu blábolil. A to by ses taky musel za tento sprostý a hloupý blogpost veřejně omluvit. A to bys na to musel mít slušnost, čest a kuráž.

[Petr Mach]

Člověče, říkal jsem přečíst po té, co si strčíš hlavu do kbelíku se studenou vodou, takhle vidíš rudě a nepřemýšlíš. Domýšlíš si nesmysly, asi mě soudíš podle sebe nebo co. Nic z toho co říkáš jsem nepsal, opravdu ne, fakt si to přečti, až se uklidníš. sám uvidíš . 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íš .

[J. M.]

Já to vidím s čistou hlavou od začátku. Napsal jsi to, co jsi napsal. Je to hloupý, urážlivý, hulvátský, povýšený, arogantní, nesmyslný a protiřečící si zápisek. Jediná možnost jak by tomu mohlo být jinak je, že jsi to celé myslel jako recesi. Ale pokud to celé byla jenom sranda, poznává se to velmi těžko kvůli absenci nějakých záchytných bodů.

[Dunric]

Čert vem intuitivnost ovládání (je to věcí zvyku) a absenci extra featur, ale to neuvěřitelně a neopodstatněně pomalé otevírání adresářů s velkým počtem souborů je otravné a pro mě je to jeho hlavní neduh. Přitom takový QFileDialog tímto netrpí a atributy a typy souborů zjišťuje taky.

Vývoj Gtk+ nesleduju, ale pracuje už někdo na optimalizaci ? Kdy lze očekávat začlenění do nové verze ?

[Zdenek.Z]

Jo, to jsem chtěl taky napsat. Na ovládání bych si zvyknul (i když dialogy z KDE programů mi přijdou lepší, ale chápu, že všem se zavděčit nejde), ale to, jak je to neuvěřitelně pomalé to posouvá pro mě použitelnost Gtk file dialogu v některých aplikacích někam úplně do háje. Třeba ve Firefoxu, kde si občas chci určit aplikaci, kterou otevřu daný typ souboru.

[Michal Vyskočil]

Dialog je třešnička na dortu. 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í.

Nechápu, že na jiných systémech nepoznám systémové komponenty od těch z Qt, nebo Swingu, kdežto na Linuxu je taková pitomost důvodem k dlouhým a naprosto zbytečným flamewars. Mě osobně je úplně jedno, v čem je ta aplikace napsaná a pokud se to celé aspoň snaží tvářit konzistetně, nic víc mě nezajímá .

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ě.

[disorder]

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)

[Michal Vyskočil]

Ten argument jsem zaslechl několikrát nejen od tebe (včetně toho, že je KDE kopie Windows - ovšem jediná podobnost, kterou vidím já je, že má KDE ve výchozím nastavení podobnou spodní lištu s tlačítkem "start", jinak je imho UI Windows chudým příbuzným v porovnání s UI KDE).

Přiznávám že ho nechápu, stejně jako jsem teď nepochopil tvoji větu (zvycajne maju iracionalny odpor nielen voci vsetkemu mimo KDE, ale aj voci comukolvek co sa tyka windows). Protože já to chápu tak, že flamewaristi jsou obvykle milovníci KDE a odpůrci Windows, což jsi asi říct nechtěl ...

[disorder]

myslel som tym flamerov, ktori sa dokazu donekonecna hadat aj o takej blbosti ako jedno male okienko (a to zhodou nahod len KDE fanboys...)

[Michal Vyskočil]

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

[disorder]

tomu osamotenemu postu hovoris "hadat sa"?

no, uz to priznaj, ze jediny kto sa furt zacina hadat o takej blbosti je...

[xm]

Mr. Troll útočí!

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.

[disorder]

ale no, ja mam teraz cas, preto sa zapajam :)

no neviem kde si prisiel na to, ze ja tu vytahujem nejake temy, ja vzdy len odpovedam...

a teraz k veci -- neviem preco utocis na mna a neposkytnes radsej nejaku zmysluplnu odpoved :)

[thingie]

Hloupost. Obětovat vnitřní konzistenci aplikací za zdání podobnosti v rámci systému, to je nesmysl.

[Michal Vyskočil]

Nesmysl, v Linuxu skoro každý trpí syndromem NIH a ještě to vydává za svoji přednost. Než mít konzistenci omezenou na množiny aplikací podle použitých toolkitů, jsem raději pro konzistenci přes celý systém (zvlášť, když jinde to není takový nepřekonatelný problém).

[thingie]

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á. Ř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. Budu v hajzlu. 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.

[Michal Vyskočil]

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.

[thingie]

> Proč třeba není možné, aby Gnome i KDE dialog měly stejné nastavení oblíbených adresářů?

Mam pocit, že sdílet tohle nastavení nějaká snaha byla, ale ta se vzhledem nesouvisí. To je standard z trochu jiného chlívku.

> 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í? Standardy například pro IPC, datové formáty a tak opodstatnění mají, bez nich se aplikace a počítače nedomluví. Standard pro vzhled žádné takové výhody nemá, přesto by jeho dodržování bylo dost drahé.

Krom toho vzhled a chování definují zejména desktopová prostředí, pro které to je ,to co prodávají`. (Tady je vhodné si všimnout, že to víceméně znamená, že takový standard už existuje, jenom není pouze jeden.)

> 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í?

Protože ta použitá knihovna do značné míry určuje chování aplikace a i jen tyto dva konkrétní toolkity se v přístupu v mnoha ohledech značně liší? A protože opodstatnění, výhody a nevýhody mají oba tyto přístupy?

[miso]

> 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

[thingie]

Vůbec ne. Gnome třeba dosud na Windows nefunguje, ale jednou bude. Pak se jistě začne shánět po možnosti jak vnutit svůj vzhled a dialogy pokud možno všem aplikacím. Stejně tak KDE. Protože pokud budete používat na Windows Gnome, pak pro vás ,nativní a ty správné jednotné` dialogy budou ty z Gnome. Definovat jednotný vzhled pro operační systém je dneska tak absurdní přežitek, že to snad dojde i zdejším kritikům :-P

[David Jaša]

Pak se jistě začne shánět po možnosti jak vnutit svůj vzhled a dialogy pokud možno všem aplikacím

Hm, 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č?

[thingie]

Protože by to bylo ještě horší To nikdy neuchodíš

[Petr Mach]

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.

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. Všechno je to utopie. X Window prostě žádnou GUI knihovnu, kterou by mohla používat všechna prostředí nemají. A kdyby měly, nebude tu prostor pro GTK a QT. Leda bys chtěl míchat univerzální GUI s GUI specifickým pro prostředí, pak bys měl krásně nekonzistentní všechny aplikace, protože by používaly dvě různá GUI současně každá aplikace. Nic horšího si už nedovedu představit.

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ěží. Ale jestli KDE přejde na GTK, budu jen rád.

[Michal Vyskočil]

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á).

[Petr Mach]

Pro KDE by to samozřejmě nemělo žádnou výhodu.

Ocenili by to možná někteří uživatelé, že by KDE aplikace měly look&feel GNOME aplikací. Spoustu dalších by to ovšem naštvalo.

Nedovedu si představit ani sjednocení look&feel pomocí specifikace. Už proto, že GNOME i KDE vývojáři mají jiné cíle. Tvůj příklad s apple je nepoužitelný, protože apple přizpůsobilo javu svým cílům, neudělal to sun a nikdo těmto dvěma firmám nepřikazuje/nespecifikuje jak to mají dělat. To imho není reálně možné.

[phero]

Rekl bych, ze je treba autory 3rd party toolkitu naucit, ze neexistuje linux desktop. Ze je to GNOME/GTK a KDE/QT.

[ajikdpoe]

1. nesmie mat tolko nevyuziteho miesta ako povodny gtk dialog

2. musi byt prijatelny do GTK t.j. aby ked si ho pridam aby sa pouzival vsade

3. Zobrazovanie nahladu len ak je to obrazok, inak nech to nezabera miesto

4. Musi byt rychly, nahlad staci zobrazit neskor ale samotny dialog sa musi objavit okamzite

Povodny

Novy

Na mieste *1 pripadne moze byt tlacitko "O Uroven vyssie" a "Vytvorit priecinok"

[thingie]

Zrušení kapkové navigace (či jak tomu říkají) je nerozum, vždyť to zavádí i KDE.

Dát čudlíky do jedné řady je též nerozum, neboť to si tam vkládají aplikace a tohle by to maličko narušilo.

[Jardík]

Mě by tam vadil ten combobox dole, protože když tam bude delší text, tak se ten dialog nechutně roztáhne. Chce to takový, kde lze normálně označovat text, který by se posunoval, byť by třeba nemusel být editovatelný.

[cynik]

Podle me je psani nejakeho noveho dialogu na otevirani souboru zbytecna prace. Ten soucasny, se myslim, vazne povedl. Rychle se v tom hleda, prechazi mezi adresarema, atd. atd. Jedina vec co me vadi, je double-click na otevreni souboru. Kdyby se tohle podarilo odstranit...

[Michal Karas]

Mně zatím připadá, že většina těch věcí, co je ve shrnutí z 23:15, by se dala v pohodě přidat i do toho idiotského a koncepčně špatného dialogu, jaký máme teď.

[Jardík]

Spatlej něco, jako je v KDE a klidně bych to snad do C přepsal. Vlevo by měly být nějaké ty záložky, jako v KDE či GNOME, ale ať to respektuje nastavení adresářů podle freedesktop.

[Martin Böhm]

Když opáčko, tak opáčko.

[zenek]

No, já sice o GTk dialogu neremcám, protože je mi víceméně ukradený a když mě občas přepadne, tak se s ním nějak poperu... Ale musím říct, že jsem asi idiot, protože jsem ho nepochopil dost rychle na to, abych ho označil za intuitivní.

[disorder]

"intuitivni"... ze s tym konecne neprestanete...

[miso]

Az to bude intuitivne, vsetci stichnu

[disorder]

no, ty zrejme mas pouzitie toho debilneho dialogu v predlzenej mieche, co?

[satanatas]

souborový dialog mích snů? tomu se nevyrovná ani ten z kde, a ten je nejlepší

[Jan Martinek]

Velmi si vážím tvé snahy, ale mám obavy, že remcání je vlastnost povahová...
Nicméně kdybych za každou cenu potřeboval na tom file dialogu něco změnit, tak tohle:
- Nastavit, aby se pouštěl full-screen (protože jinak musím zmáčknout klávesu navíc, což je hrůza, že?). Tím se řeší "plýtvání" místem.
- Přidat další sloupce s vlastnostmi souboru, podle kterých lze třídit (především velikost, koncovka).
- Typ souboru zjišťovat pouze podle koncovky a atributů. Tady se prostě tluče unixový svět a desktop. Opravdu nepotřebuju, aby se každý soubor otvíral jen proto, aby se přečetlo pár bajtů a podle toho nastavila ikonka. Rozlišení podle koncovky mi bohatě stačí a když navíc na první pohled uvidím, jestli je to "executable" nebo "read only", budu úplně happy.
- Ať lze nastavit, podle čeho má třídit defaultně a kde má být kurzor. S oblibou používám v shellu "ls -ltr" a hned vidím, se kterými soubory jsem pracoval naposled. Ale to by se asi hodilo jen mě a ostatní by to mátlo ...
- Nějak rozumně vyřešit označování více souborů.
- No a když by tohle všechno fungovalo, tak by se takové widgety daly dva vedle sebe, napsalo pár skriptů a vznikl by dvoupanelový file manager

[mirec]

Idealny suborovy dialog v gtk vyzera takto.

[miso]

Ach to vyuzitie priestoru
Ikonkam nalavo by bohate stacila polovica priestoru, co maju.
Takisto ten checkbox na prvom obrazku zaplna vela priestoru (ale nenapada ma ako to riesit)

[mirec]

Je to KDE dialog -> veľkosť ikoniek je nastaviteľná (pravé tlačítko na panel s ikonkami / malé ikony)

[Jardík]

škoda jen, že to neumí utf8 a autor to nechce opravit :(

[MJ]

Vlastně všechno, co mi na GTK-čkovém souborovém dialogu vadí, jsou maličkosti, ale bohužel dosti zásadní:

(1) vše musí být pohodlně ovladatelné z klávesnice, včetně třeba skoku o adresář výš. (2) většinu místa má zabírat to nejdůležitější, totiž seznam souborů. (3) preview je hezká featurka, ale co kdyby třeba umělo ukázat začátek textového souboru? :) (4) datum modifikace zobrazované jako "Today" je úplně nanic.

[Jan Martinek]

1) Alt+šipky nahoru a dolů. Odnedávna to funguje i v Qt filedialogu. Zvykl jsem si na to tak moc, že to mačkám i v shellu
2) Nastavit si klávesovou zkratku pro (vertikální) maximalizaci.
Pokud to jen trochu jde, tak počítač ovládám zásadně bez myši. Takže jestli se objeví nějaká nová verze file dialogu, hlásím se jako tester klávesových zkratek

[...............23]

Toto si jaksi prehliadol, hlavne teda ten prvý odstavec. Inak vyser sa na to, neviem čo tým chceš dokázať...

[Michal Fecko]

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

[Jan Martinek]

Co to měříš? Souvisí to nějak s tímhle?

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

[Michal Fecko]

Co to měříš? Souvisí to nějak s tímhle?

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

Na zaciatku je pridane toto...

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

... tak som to spustil a pastol som vysledky...

[Jan Martinek]

Aha, to je přímo v tom blogu! Jsem slepej
Teď bohužel nic nevyzkouším, protože mám všechno v keši. Ale mohu potvrdit z dřívějších testů, že volání stat() je takřka vždy rychlé jako prase ve srovnání s otevíráním a čtením (byť jen pár bajtů). Proto bych byl rád, aby si file dialog vystačil pouze se stat(). A když už by se opravdu měly soubory otevírat, tak se přimlouvám za O_NOATIME.

[Ses]

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

[David Jaša]

$ 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)

[Michal]

Takze co je pro me nejdulezitejsi: chci mit adrersni radek s autocompletion. pokud do neho zadam cestu adresare tak se po entru otevre v hlavni casti dialogu. Pripadne se hlavni cast dialogu muze aktualizovat automaticky behem psani.

[tomm]

Notebookovy disk na 5400.

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

[frEon]

notebookovy disk

# 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

[Jan Martinek]

Vidím, že se drasticky přibývá požadavků na "ideální souborový dialog". Jen prosím o zrušení toho "načítání atributů na pozadí". Co se tím myslí? Provádět stat() na pozadí je hrozný nesmysl. To by se pak postupně doplňovala velikost, rozlišení na adresář/soubor a podobně? Kdo s tím přišel a z jakého důvodu?

[Petr Mach]

Řekl bych že ti, co mají pomalý disk a nechce se jim čekat na to, až se to načte všechno a neuvědomují si, že postupná aktualizace bude celkově trvat delší dobu i když něco uvidí hned.

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.

Druhá možnost je vytvořit datový model a ten neplnit najednou až mám všechna data. Nejde ho ale ani aktualizovat postupně po jednom, to by bylo velmi pomalé. Ale šlo by třeba uvažovat, že se bude plnit po stovce souborů. To jest, načtou se data prvních 100 souborů, zmrazí se view, naplní se model, odmrazí se view, načtou se data dalších 200 souborů, zmarzí se view, doplní se model, odmrazí se view, načtou se data dalších 400 souborů a tak dále až dokonce. Tohle doplňování by pak mohlo být prováděno na pozadí, takže by s dialogem šlo pracovat.

Přitom bych ikony speciálních souborů (adresář, socket, roura) doplnil hned, ikony ostatních souborů podle typu bych vyhledal, načetl a doplnil zpětně teprve až po úplném načtení modelu. Opět na pozadí.

[Jan Martinek]

Názvy (tj. os.listdir) a metadata (tj. stat()) udělat naráz, naplnit model a pak teprve zobrazit. Doufám, že existuje dost důkazů, že to bude rychlé dost. A teprve potom se můžou dít různé další blbinky, pokud si je uživatel přeje - náhledy obrázků, ikonky, přehrávání videí, nastavení inotify atd. Toť můj názor.

[Luk]

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:

1. Načíst položky adresáře.
2. Načíst (stat()) atributy těch souborů, které jsou uvnitř viewportu (jsou viditelné).
3. Zobrazit seznam souborů.
4. Začít načítat atributy na pozadí.
5. Pokud někdo pohne s viewportem, synchronně donačíst atributy položek, které ještě nejsou k dispozici, a teprve potom je zobrazit.

[thingie]

No, pokud mi zavolání stat na všechny soubory v /usr/bin trvá sekundu, tak je to trochu zbytečná komplikace.

[Luk]

Jenže ne vždycky je to tak rychlé. Například jde-li o vzdálený filesystém s nepříliš rychlou přenosovou trasou, může to být podstatně pomalejší. Ale stačí i jen přístup přes FUSE, např. na NTFS (a nechci slyšet: "Fuj, Windows!" ).

[thingie]

Nicméně tím navrhovaným přístupem se taky všechno nezamaskuje.

[Luk]

Proč by se mělo něco maskovat? Stačí, že se s tím bude rychleji a pohodlněji pracovat. Má to samozřejmě své mouchy (třeba když někdo bude chtít "Directories first", bude to na některých filesystémech problém), ale pořád je to lepší, než když se to bude třeba i několik (desítek) vteřin načítat, než vůbec půjde něco dělat.

[Luk]

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:

1. Načíst položky adresáře.
2. Načíst (stat()) atributy těch souborů, které jsou uvnitř viewportu (jsou viditelné).
3. Zobrazit seznam souborů.
4. Začít načítat atributy na pozadí.
5. Pokud někdo pohne s viewportem, synchronně donačíst atributy položek, které ještě nejsou k dispozici, a teprve potom je zobrazit.

[Jan Martinek]

A dost. Vyjasněme si, co jsou to ty atributy. Já pod tímto pojmem chápu všechny informace, které jsou k dispozici po zavolání stat(). A v takovém případě nevidím nejmenší důvod pro nějaké volání statu() na pozadí. Mám asi tři roky starý počítač a zavolání stat na 10000 souborů trvá 2.3 sekund (po zakešování dvě sekundy). Co ještě chcete optimalizovat? Mrazení GUI by sežralo daleko víc než udělat to celé naráz.

[Jan Martinek]

Opravuji. Předchozí výsledky platí pro _příkaz_ stat (chtěl jsem si ušetřit práci). Po přepsání do pythonu a po zakešování trvá stat() (bez interpretace toho co vrátil) na 10000 souborů pouze 0.22 sekund i s podtaktovaným procesorem.

[Luk]

Viz výše.

[Josef Kufner]

Rozumné by také bylo, aby se nějak smysluplně choval fokus. Třeba, že šipky půjdou do seznamu souborů a zbytek do text entry pod ním. Taky bych rád měl zpět to filtrování tabem jako bylo v původním dialogu v Gtk 1.2 a až do 2.4 (přibližně). Tj, že se neobjevuje nejaký popup blivajz z textentry, ale upravuje se seznam souborů v oknu. Tedy, že napíšu ab, zmáčknu tab a v oknu zbyde jen ab*.

Také by nemělo být při testování dialogu dovoleno používat myš. Vůbec. Kompletní navigace po dialogu by měla být dostačující pomocí šipek a entru. Jde to a není to nijak složité. Také to vyžaduje, aby byl na počátku seznamu adresář "..".

Když bude takle skrouhnutý hejbání fokusem, bude to svádět k používání myši na ostatní widgety, ale totéž zvládnou klávesové zkratky (podtržená písmenka s altem).

Základní operace se soubory, jako je drag and drop do jiných oken s konquerorem nebo nautilem a čudlík na vytváření adresáře, kopírování, přejmenování a mázání by neměly chybět. Také je fajn mít možnost otevřít v aktuálním adresáři terminál nebo správce souboru (podle uživatelského nastavení -- prostě udělat cd a spustit definovaný příkaz).

Přejmenování souborů a vytváření adresářů si otevře dialog na dotaz na nové jméno. Žádné zvrhlosti, které se potvrzují ztrátou fokusu.

[phero]

Když už focus ... taky by nebylo od věci, kdyby se choval toolkit stejně jako WM při nastavení "focus policy", napřiklad "Focus follows mouse". Ale to nema s filedialogem nic společnýho, ale je to věc celýho toolkit.

[Josef Kufner]

Mno, fokus vramci okna je v mnoha pripadech neprakticka blbost. Pokud je to dialog na vybrani nejake veci jako treba tady diskutovane dialogy na vybirani souboru nebo je to treba chatovaci okno jabber klienta, tak nejaky fokus nema smysl. Proste pismenka a sipky do stran patri do text entry a sipky nahoru/dolu vybiraji v seznamu souboru. V pripade chatovaciho okna je vstup viceradkovy, tak se daji vsechny sipky kurzoru v textovem vstupu a pgup/pgdown posunuje historii zprav. Je to daleko praktictejsi nez nejake hopsani fokusem. Pritom ovladani mysi to nijak neovlivni.

Fokus ma smysl, kdyz je vstupnich poli vice a pripletou se tam jeste nejaky zaskrtavatka a cudliky -- napr. konfiguracni dialog.

[Marián Kyral]

Dva 7200rpm disky v Raid 1

[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

[Milan Jurik]

1) Nepridavat radek pro editovani cesty by default - naprosta vetsina uzivatelu ho nevyuzije a jen jim bude zabirat misto navic. Kdo chce, muze si ho opravdu nastavit (tlacitkem, klavesovou zkratkou, editaci gconfu etc.), GTK si pamatuje nastaveni dialogu (a KDEckari prece touzi po maximalni konfigurovatelnosti).

2) Zadne nacitani cehokoliv na pozadi a doupravovani vypisu po prvotnim zobrazeni - je matouci a skryva informace po dobu, nez neni kompletni -> vede k problemum u neznalych lidi

Prosel jsem uz tolik ruznych operacnich systemu a prostredi (vcetne KDE), ze si je ani nepamatuji. A kdyz tak sleduji kritiky toho filedialogu, tak to spise vypada na emocionalni boj proti GTK jako takovemu, se spoustou argumentu jako - on si to nepamatuje (pamatuje, jen tam byla chyba), ono se to musi zapinat (ano, musi, protoze to vetsina uzivatelu nepotrebuje), ono je to jine nez KDE (ano, je a je to dobre ). Proste je to jine prostredi a presto spouste lidi vyhovuje.

Filedialog je urcen pro vyber souboru, ne pro manipulaci s nimi.