JXP Commander - přepis do GTK

7.7.2006 18:12 | unknown_category

Protože si spousta lidí stěžovala na pomalé načítání JXP Commanderu, upouštím od gtkmm a přepisuju ho do gtk. Nadále ale hodlám používat C++. Také budu používat vlákna, takže by výpis souborů a ostatní I/O operace neměly zdržovat načítání ani běh programu. Také veškeré stringy píšu v angličtině a používám na řetězce funkci (nebo je to makro?) gettext, takže by to pak mělo jít překládat i do jiných jazyků, jak je u většiny GNU programů zvykem. Také přemýšlím o použití cmake pro překlad programu, ale na to je zatím čas. Tak to je pro dnešek vše.

       

Komentáře

[VícNežNic]

Nevím, jestli si něco pomůžeš. Zůstal bych u gtkmm, když už C++, ale třeba návrh by to chtělo zlepšit určitě (je-li jaký ).

[brk]

Souhlas. Jak už jsem jednou psal, když jsem hrábl do zdrojáků a místo /dev si dal hned po startu načíst /, kde toho je minimum, tak start byl takřka okamžitý.

[Luboš Doležel (Doli)]

Já bych se na přepis do čistého GTK+ vykašlal, to nemá cenu. Těm, kterým to připadá pomalé, bych doporučil upgrade stroje nebo větší trpělivost (kolikrát za den znovu spouštíte filemanager?).

[VícNežNic]

No, živě si pamatuju, jak jsem kdysi ještě na starém stroji gtkmm kompiloval a málem nezkompiloval, protože to sežralo všechen disk a trvalo několik hodin Vtipné bylo, že dokumentace hrdě oznamovala (možná ještě oznamuje, zase tak dávno to není), že je to jenom thin wrapper

Je pravda, že kompilovat C++ v gcc je vždycky zážitek.

[andree]

Je pravda, že kompilovat C++ v gcc je vždycky zážitek.

O RLY?

[elviin]

??

[JiK]

...kolikrát za den znovu spouštíte filemanager?...

kdyz startuje pomalu, tak ani jednou!

prikladem budiz docela pekny filemanager mucommander, jeden z mala, ktery je pro OS X, aniz bych musel nejak instalovat knihovny a kompilovat trebas mc nebo krusader. Je fajn, ale poooooooomaaaaluuuu to startuje, takze to radsi ani nespoustim...

[Luboš Doležel (Doli)]

Mě systém bootuje víc jak dvě minuty (mnoho služeb) a taky nešílím. Prostě nevypínám.

Tak filemanager taky nevypínejte a je to.

[Daniel Kvasnička ml.]

...kolikrát za den znovu spouštíte filemanager?...

kdyz startuje pomalu, tak ani jednou!

nezlob se, ale to je nehorazna kravina. Lubos naznacoval, ze takovy program se spouzti treba jednou za den a ze tedy pokud s nim produktivita uzivatele vzroste, tak dlouhe spusteni neni na zavadu.

Stejne je to s Eclipse. Startuje hrozne pomalu, ale je to paradni IDE na vsechno mozne. A jednou ho rano pustit, to me nezabije.

[kyknos]

Možná proto raději používám vim :) Také považuji pomalé spouštění za podstatnou vadu. Zejména u programů jako je filemanager. Obzvláště takové by se měly spouštět v "nulovém" čase.

[Michal Karas]

Nezlobte se na mě vy, ale pokud někdo tvrdí, že když program nic neumí a startuje několik sekund, řešením je upgrade HW, tak by si měl dát ledový obklad na čelo.

A například cd dev; gftp jasně ukazuje, že není problém, aby takový program startoval mnohonásobně rychleji.

[kotyz]

taky je mucommander v jave, to leccos vysvetluje ...

[Filip Jirsák]

FUD

[kyknos]

fakta

[Filip Jirsák]

Co to tedy vysvětluje?

[lefti]

Z nejakeho zvlastniho duvodu jsou v Jave vetsinou velmi nepovedene aplikace. Treba takovy Jubler - to je proste ukazkova hruza.

[Heron]

Heh, asi to od tebe má být provokace, ale co se ti na něm nelíbí?

Já bych řekl, že nejkvalitnější programy (v GUI), co jsem na linuxu zažil jsou právě v Javě.

[Kyosuke]

No já si nemůžu pomoct, ale Eclipse je novodobá reinkarnace švýcarského armádního Emacsu. Zkrátka všechny dnešní stroje už Emacs bez problémů zvládají a tak ďábel vymyslel Eclipse...

[Filip Jirsák]

Eclipse zrovna má v sobě i spoustu nativního kódu – a nejsem si jist, zda je díky tomu rychlejší… A jinak vývojová prostředí jsou vždycky pěkní bumbrlíčci – ještě Delphi 3 byla svižná, když jsem pak přešel na C++ Builder 5 zjistil jsem, že mám vlastně strašně pomalý počítač… A myslím, že různá Visual Studia na tom budou podobně. No a od té doby vím, že když chci porgramovat a používat IDE, musím mít v počítači dost RAM, prostě to nějak patří k věci. Ale eclipse není jediný Javovský program…

[Luk]

Eclipse je typická ukázka toho, jak psát žravý a pomalý software. A to i přes použití nativního kódu v SWT. Zde musím konstatovat, že na celé čáře vítězí NetBeans Platform (oproti Eclipse Platform), a stejně tak je to i u IDE na těchto platformách postavených (tzn. vítězství NetBeans a Sun Studia, oproti Eclipse a WebSphere Studiu).

[lefti]

Nelibi se mi na nem neuveritelne neergonomicke gui. Asi nejhorsi co jsem kdy pouzival.

[Luk]

To je proto, že si někteří lidé myslí, že Java za ně všechno vyřeší. Ti, kteří si to nemyslí, vytvářejí naopak velice kvalitní aplikace - jako je např. jEdit

[Luboš Doležel (Doli)]

Mě se Jubler líbí. Možná i proto, že se mi nepodařilo najít nic stejně kvalitního nativního

[abr]

Za jak dlouho ti nabehne? Pro me ty 4 sekundy nic neznamenaji. Jak uz tu nekdo rikal- spustim jednou po startu na novy workspace a neresim.

[#Tom]

Já Midnight Commander za celý den spouštím mnohokrát, klidně i stokrát, když na to dojde.

[Kníže Ignor]

Promiň, ale pokud dál budeš naprosto nesmyslně třídit bubblesortem tam, kde je možné použít rychlejší algoritmus, pak ti přepsání do čehokoli nepomůže. Pokud si navíc uvědomíš, že k zobrazení obsahu adresáře je potřeba znát pouze prvních k položek, můžeš obsah adresáře zobrazit v čase O(n + k*log(k)), kde n počet souborů v adresáři a k je počet zobrazených řádků. Zbytek už můžeš třídit "na pozadí" v čase, kdy se uživatel teprve rozkoukává

[petr_p]

Pouze za predpokladu ze v case mensim nez O(k*log(k)) dokazes rozpoznat onech prvnich k v celem budoucim vypisu.

Myslim si, ze na to ale budes muset tech n polozek nejdriv setridit nebo sehnat alespon k-prvkovou podmnozinu polozek, ktere budou zarucene na zacatku setrideneho vypisu :)

[Luk]

Každopádně je n*log(n) vždycky lepší než n*n. Už pro pouhých 1000 položek je to 1000*10 = 10 000 oproti 1 000 000, tedy řádově 100x rychlejší.

[Kníže Ignor]

Myslim si, ze na to ale budes muset tech n polozek nejdriv setridit nebo sehnat alespon k-prvkovou podmnozinu polozek, ktere budou zarucene na zacatku setrideneho vypisu :)

Třídit to celé opravdu nemusím:

1) budu mít haldu velikosti k (nazačátku zaplněnou třeba nekonečny)

2) vezmu prvek, porovnám s maximem na vrcholu, pokud je menší odeberu maximum, vložím prvek, obnovím haldu - to potrvá tedy nejvýše O(log(k))

takže vybrání k nejmenších umím v O(n*log(k)), potom už jenom setřídit těch k-prvků O(k*log(k)), takže dohromady skutečně O((n + k) * log(k))

[petr_p]

Aha, v predchozim prispevku jsi zapomnel uzavorkovat soucet n+k, takze to vypadalo lepe, nez ve skutecnosti.

[walley walleyovic]

asi tak 10x za minutu a mam jich pustenejch tak 20 naraz napriklad, tzn neco chci tak pustim xterm s mc a pak ho necham byt a tohle opakuju do te doby dokud neco chcu

[XMurder]

S gtkmm jsou problémy s instalací v Ubuntu/nebo to neumim:), asi je lepší čistý GTK. Zkus už to jednoduchý verzování třebas jxp-cmdr-0.0.1alpha1-src.tar.gz. Fandim ti

[belisarivs]

No,, ja jsem radsi venoval nekolik minut psani feature requestu pro program Atol.

Autor mi za hodinu odpovedel ze jsou to dobre napady a ze jich vetsinu implementuje.

Jeste jedna trochu OT otazka. Je technicky mozne (no to urcite je, ale jestli to neni velka prasecina vyzadujici prepsani celeho programu) udelat v takovem commanderovi ficuru umoznujici mu se chovat jako mc v teminalu?

Proste nabehne a po stisku Ctrl+O se prepne do konzole a zpet apod.

Myslim, ze to by uvitala spousta lidi. Vcetne me.

[andree]

mozne to asi je, ale ver tomu ze zbuchat nieco take by zabralo tak polovicu casu vyvoja vlastneho programu, ak nie viac.. uz som niekde pod diskusiami o tomto "projekte" pisal, ze zemljanka commander (screenshots)vie pracovat v gtk aj konzoli (afaik).. a tam museli (znovu afaik) prepisat dost vela kodu gtk, aby to slo robit zaroven pre konzolu aj gui - mozno keby sa vyuzil ten kod... ale to prepinanie - to by bola pekna zbesilost, neviem ci to za to stoji

[Michal Vyskočil]

To jsi ho nepochopil, on chtěl, aby se po stisku Ctrl+O schovaly widgety a místo nich se zobrazil emulátor terminálu (respektive ten jednořádkový, aby se roztáhl přes celou obrazovku).

[filbar]

Tak mi teď nová verze končí s chybou:

terminate called after throwing an instance of 'Glib::ConvertError'
Nespesne ukoncen (SIGABRT)

[hanzz]

To mi psalo taky, ale vzhledem k tomu, ze jsem byl v polovine prechodu na gcc 4.1, tak jsem myslel, ze je chyba u me... ale jak vidm tak asi ne :D

[Luk]

Také budu používat vlákna, takže by výpis souborů a ostatní I/O operace neměly zdržovat načítání ani běh programu.

Vzpomeň na Johanku a její varování. S vlákny si může člověk pořádně nabít hubu. Zvlášť pokud se jedná o aplikaci s GUI. Nic proti vláknům, ale je to ošemetné - sice nevím, jak je na tom GTK+ z hlediska vláknové bezpečnosti, ale třeba pro javovský Swing platí docela přísná pravidla. Být tebou, dám si pozor

[Miloslav Ponkrác]

vlákna v grafice jsou vždy o hubu, protože většina grafických toolkitů je napsány neuvěřitelně prasecky, co se podpory vláken týká

závěr: neviděl jsem ještě žádnou grafickou knihovnu, která by slušně podporovala thready bez omezení, pokud nějakou znáte, dejte vědět

[Luk]

Právě proto jsem uvedl ten Swing jako příklad. Ten totiž obecně není thread-safe a skoro všechno (kromě několika málo metod) se smí volat pouze z event-dispatching threadu (tzn. z toho vlákna, které obsluhuje frontu událostí).

[Miloslav Ponkrác]

Pokud něco není jako thread safe navrženo, většinou už se z toho nic takového udělat nedá. Obecně ale platí, že vysokoúrovňové věci bývají málokdy thread safe, proto bych se ten swing moc netahal.

Mnoho grafických knihoven nejenom že není thread safe, ale dokonce mohou efektivně zablokovat thready vůbec. Takové Qt, wxWidgets, nebo Delphi mají chyby v knihovnách, které prakticky znemožňují v mnoha případech vůbec thread safe program vytvořit, a i když grafické věci obsluhuje jen jeden thread.

[petr_p]

Pridavam Tk.

Nakonec jsem musel GUI hodit do jednoho vlakna, do druheho jsem dal dispatcher, a skutecna prace se dela ve vlaknech dalsich, ktera dispatcheru posilaji zadosti a ten pres zdilene promenne komunikuje s GUI vlaknem.

Sice existuji moudre rady, jak pouzivat udalostne rizene ovladani (kde udalost muze byt "na soketu cekaji data na precteni"), ale na skutecnou asynchronni aplikaci je to nepouzitelne.

[Kníže Ignor]

Cože? Jak je vůbec možné, že používám internetový prohlížeč. Jak je možné, že stahuju něco bittorentem (třeba Azureus - java + gtk)? Kterej kouzelník mi umožnil, že program něco počítá a já vidím průběžný výsledky?

[#Tom]

Proč by to nešlo? Pokud jedno vlákno obsluhuje rozhraní a ostatní vlákna dělají ten zbytek, tak se nic nepokazí.

[Kníže Ignor]

Vzpomeň na Johanku a její varování. S vlákny si může člověk pořádně nabít hubu. Zvlášť pokud se jedná o aplikaci s GUI. Nic proti vláknům, ale je to ošemetné - sice nevím, jak je na tom GTK+ z hlediska vláknové bezpečnosti, ale třeba pro javovský Swing platí docela přísná pravidla. Být tebou, dám si pozor

Pak ovšem toto nechápu.

Z Lukova komentáře se mi zdá, že i když někdo práci s vlákny rozumí, dopadne to většinou špatně. Pokud tomu tak není, je ten komentář naprosto zbytečný a zavádějící...

[Luk]

Bylo to myšleno tak, že i když někdo práci s vlákny rozumí, musí si dávat pořádný pozor, aby někde neudělal chybu. Multithreadové aplikace se totiž strašně špatně ladí a nějaká záludná chyba, způsobená neošetřeným přístupem ke sdílenému prostředku, se projeví třeba jednou za měsíc - a třeba ještě pokaždé jinak.

[Kníže Ignor]

Dobře, ale tohle člověk, který s vlákny pracuje, ví. Po teoretické stránce to vím i já, dokonce jsem se kdysi šťoural v tom, jaké jsou v UNIXu synchronizační mechanismy a jak fungují. Ale nikdy jsem nic neprogramoval, to je pravda. Nicméně vícevláknové aplikace existují a podle mých pozorování řada z nich funguje dobře, proto se mi nelíbí, když je někdo od vícevláknového přístupu odrazován - dejte mu šanci ať si hubu nabije sám nebo ať vás třeba překvapí.

Prostě mám z toho komentáře dojem, že říká něco jako "na to seš moc blbej, do toho se ani nepouštěj".

[#Tom]

Programovat nějaké paralelní procesy se dá i bez vláken, ale potom to vypadá... všelijak...

Jednou jsem napsal jako úkol jednoduchej kecací program obsluhující více klientů a dokonce jsem se při jeho psaní obešel bez vláken... Nicméně onen zdrojový kód je vyloženě na poblití. (Psal jsem to totiž velmi rychle, snad jen asi čtyři dny, pak jsem se k tomu už nikdy nevracel.) Spolu s ostatními úkoly do programování v C je ke stažení na mých stránkách.

[ajikdpoe]

Jo, to poznam, ma to taky magicky nazov, ze "Synchronous I/O Multiplexing" a onoho casu som sa s tym velmi vazne zaoberal ale je to fakt strasna piplacka spravit to tak aby to nepadalo pri chybovej sieti.

[#Tom]

To určitě jo, když jsem to psal, tak jsem myslel, že se asi zblázním. Horší je, že jsem se ani nedostal k tomu, abych to pořádně vyzkoušel.

[Luk]

Programovat nějaké paralelní procesy se dá i bez vláken, ale potom to vypadá... všelijak...

On to zase až takový problém není. Pokud se používá framework s aspoň trochu rozumným mechanismem pro obsluhu událostí (např. Qt), tak si pak stačí jen hlídat, aby se běh nikde nezdržoval příliš dlouho. Každopádně je to mnohem jednodušší než se peklit se špatně fungujícím vláknovým kódem.

[#Tom]

Pokud použiji knihovnu kvalitní, tak to asi vypadá docela dobře. Pokud si to vše dělám sám, tak to vypadá tak, jako u toho domácího úkolu.

[Luk]

Nicméně vícevláknové aplikace existují a podle mých pozorování řada z nich funguje dobře

O tom není sporu. Velice ovšem záleží na tom, jaký charakter mají tyto aplikace. Pokud se sdílí jen málo prostředků a nepoužívají se žádné záludnější konstrukce, opravdu nebývají problémy.

Nemohu ovšem nevzpomenout známý HTTP server Apache, který ve vláknové verzi (worker) funguje velice problematicky. Hlavním problémem jsou moduly, které většinou nejsou připraveny na multithreading - jenže Apache bez modulů (ve kterých je dnes víc než 90 % funkcionality) jaksi není to pravé ořechové.

A něco podobného může nastat i zde (kromě problémů s GUI). Jakmile chceme do budoucna připustit používání pluginů, je potřeba myslet i na toto.

[Filip Jirsák]

U toho Apache je to ale nejspíš způsobeno "mládím" threadového kódu a tím, že se tomu moduly zatím nestihli přizpůsobit (přestože už je to několik let). Původně mylsím Apache uměl jenom forkovat, protože ne na všech cílových platformách byla (použitelná) implementace threadů.

[Luk]

"Původní" (forkující) řešení Apache je v tuto chvíli jediné, které lze použít pro produkční prostředí. Ono už i to vláknové (resp. hybridní) je v tuto chvíli poněkud zavržené, protože se pracuje na MPM event (již dostupné jako experimentální), které řeší problém spojený s nečinným čekání procesů/vláken při Keep-Alive relacích. Bude ovšem ještě méně přenositelné a obávám se, že i bugovitější.

tím, že se tomu moduly zatím nestihli přizpůsobit

Mám silný pocit, že třeba PHP se ani moc přizpůsobit nesnaží. Přitom je to zrovna jeden z nejdůležitějších modulů.

[Libor Klepac]

no napr. v debianu zavisi modul php natvrdo na tom prefork mpm, prave kvuli tomu, ze nikdo nezaruci, co by se mohlo dit na tom workeru

[Miloslav Ponkrác]

Programovat vícevláknové aplikace je skutečně náročné. Především je potřeba takovou aplikaci dobře navrhnout. Případná chyba se často nedá ani dobře odladit, a dost často taky ani není lehce zjistitelná. Chybně navržený vícevláknový program prostě chodí, ale třeba jednou za měsíc se zasekne, nebo jednou za čas prostě vyhodí chybně vypočtený údaj vzniklý synchronizační chybou. Vše je prakticky nederministické, neodladitelné a často člověk neví, jestli je to chyba v programu, nebo jinde.

Jako příklad mohu uvést chyby návrhu v Qt knihovně, které teoreticky znemožňují použít tuto knihovnu ve vícevláknových programech, a přesto to nikomu nevadí. Protože pravděpodobnost chyby je tak malá, že když někomu jednou za rok zkolabuje vícevláknový program, tak to ani Qt knihovně nepřičítá. Jen zdůrazňuji, že ta chyba v Qt knihovně je takového rázu, že můžete synchronizační mechanismy používat jaké chcete a už to nezachráníte.

Kdysi jsem dělával vícero vícevláknových programů a rovnou prohlásím, že to není žádná sranda, tedy pokud se nebavíme o nějakých jednoduchých demonstračních příkladech. A pokud máte naprogramovat něco, co se sdílí mezi spoustou vláken a zároveň to má být maximálně rychlé, pak ...

[Kyosuke]

Ano, přesně to říká. A není sám:

Why Threads Are A Bad Idea (for most purposes)

(Ale možná to nic neznamená, stejně jako nic nemusí znamenat třeba fakt, že v Javě je takřka nemožné bezpečně vícevláknově inicializovat singleton, aby z toho nebyl synchronizační zámek přes celou metodu... )

[Kyosuke]

Mám pocit, že se to samozřejmě týká v první řadě nativních threadů. V jazycích typu Python a Ruby část problémů mizí, poněvadž kód v userspacu, který ta vlákna přepíná, se dá udělat docela deterministický a na míru. Předpokládám přitom, že chování „threadoidního“ kódu v interpretujících virtuálních strojích se dá nějak rozumně srovnat do latě.

[Luk]

Předpokládám přitom, že chování „threadoidního“ kódu v interpretujících virtuálních strojích se dá nějak rozumně srovnat do latě.

Zase připomenu moji oblíbenou Javu Tam by se měl vláknový kód psát vždycky tak, aby vyhověl jakékoli implementaci vláken, tedy green threads i native threads (pro různé OS!). Takže zde platí, že o nějakém srovnávání do latě nemůže být ani řeč. Prostě je potřeba počítat se vším.

[Miloslav Ponkrác]

To je ovšem s prominutím naprostá blbost. Teď nemluvím o Javě, ale obecně.

Vezměte si to tak, že napsat obecně použitelný vláknový kód není legrace a pokud to není nutné, je zbytečně se pohybovat v nejobecnější rovině. Ono stejně veškerá synchronizace není nic jiného, než v podstatě snaha učinit kód "méně vláknově obecný a trochu asynchronní".

[Luk]

Teď jsem to naprosto nepochopil. Co je blbost? Že by se při psaní vláknového kódu nemělo spoléhat na to, jak jsou vlákna přesně implementována?

[Miloslav Ponkrác]

Záleží co chcete dělat. Nejsou jenom preemptivní thready a ne vždy je nutné postupovat naprosto obecně. Jinak kdyby se postupovalo naprosto obecně, pak by veškeré Java knihovny byly thread safe bez omezení.

[Luk]

S tím nesouhlasím. Korektní přístup je ten, že se specifikuje (a řádně napíše v dokumentaci) "pro vlákna platí právě toto", "tento objekt není thread-safe" nebo "pokud potřebujete synchronizovat přístup, pak použijte toto".

Tím nijak netrpí obecnost, aniž by se někomu něco vnucovalo. Kdyby bylo všechno thread-safe, zákonitě by trpěla výkonnost. To v tomto případě není nutné.

[Kyosuke]

Korektní možná. Jenže 1) musí se to udělat (a v Javě je to, pokud vím, ekvivalent záplatovaných kalhot), 2) specifikace pak značně nakyne a programuje se podle ní opravdu „jednoduše“. Myslel bych, že jedna ze základních metod redukce chyb je redukce složitosti.

[Miloslav Ponkrác]

Problém není to, že by thread-safe muselo nutně přinést ztrátu výkonnosti, ale problém je něco jako nemožnost existence univerzálního řešení. Například celá základní knihovna Céčka je ve slušných kompilátorech thread safe a nijak zvlášť to výkonnost nepoznamenává. Takže zákonitě trpět výkonnost nemusí, ač samozřejmě je dost případů, kdy trpí.

Jenže univerzální thread safe řešení neexistuje. Řešení threadů v případě A může být naprosto katastrofální pro případ B. Dám jenom blbý příklad, všichni jsou zvyklí, že funkce pro alokaci paměti, ať už v C/C++, Javě, nebo jinde jsou automaticky thread safe. Jenže právě tohle může vést k naprostému plýtvání pamětí, a nebo k častým blokacím, protože tyto funkce dost zamykají a blokují. Dokonce se prodávaly speciální komerční knihovny pro alokaci paměti, které fungovaly s daleko větší propustností pro programy, které silně využívaly thready.

Bohužel právě na příkladech Javy se moc přemýšlet nedá, Java prostě zvolí jedno řešení a dál se nepřemýšlí. Vybrat si člověk moc nemůže a leckteré synchronizační prvky se v Javě musí emulovat, pokud to vůbec jde.

Osobně bych pro standardní knihovny programovacích jazyků (tedy i Javy) volil cestu, co může být thread safe bez problémů s výkonností, ať je. Tuhle cestu nstupuje C/C++, ale třeba Java ne.

[Kyosuke]

Taky si dovolím připomenout docela velké úsilí, které SAP věnuje vývoji Java VM kontejnerů, které by přiblížily Javu unixovému modelu spolupracujících procesů se sdílenou pamětí. Vše ve znamení architektury „shared (almost ) nothing“ a zvýšení robustnosti.

[Miloslav Ponkrác]

No skvělý, to je ideální technika pro to, aby to bylo robustní co nejméně Ale budiž u SAPu jde hodně o jméno a o marketink.

[Kyosuke]

Já nevím, mně jejich reasoning připadal celkem logický. Jsou-li v softwaru chyby (a ve rozsáhlém budou zcela zákonitě), pak implicitní sdílení stavu je nebezpečnější než explicitní, ne?

[Miloslav Ponkrác]

Máte pravdu. Jen mě přijde, že prostě vyrábějí ORB systém, nebo něco co pod tímhle slovem znám. Jinak nejsem odborník na SAP, takže možná plácám, takže mě klidně opravte.

[ajikdpoe]

Myslim ze prechod na cokolvek ine z gtkmm bol dobry krok. K tomu pomalemu startu, podla mna pomaly start = neefektivny kod. A nemyslim si ze by po uplnom nabehnuti bol ten kod nejakym zazrakom zrazu efektivny, ak je neefektivny pri starte tak aj pri beznom pouzivani. Btw, nedavno som skusal asi 10 dvojpanelovych file manazerov pre X11, skusim to niekde vyhrabat...

p.s. k tej pomalosti, mam Pentium 133 MHz / 64 MB RAM takze viem o com hovorim...

[Luboš Doležel (Doli)]

Pomalý start nemusí být neefektivní kód. Pomalý start znamená, že se načítá mnoho knihoven (C++ wrapper ke GTK+).

Je vidět, že GTKčkařům se člověk jen tak nezavděčí...

[r_b_l]

V tomhle případě to ale platí. Když se ve zdrojácích změní cesta z /dev třeba na /home (kde mám pouze 3 podadresáře) je start dílem okamžiku.

[lankvil]

Zkusil sem si s tim tvym kodem jeste trochu hrat. Nemyslim si ze by pomalost byla zpusobena gtkmm. Kdyz sem vyradil funkci pro trideni ListStore tak JXP Commander najednou startoval jako blesk. To bude tim ze se data tridi uz pri pridavani do seznamu, takze se prochazi zbytecne casto. Setridit predtim quicksortem nebo zapnout trideni az po nacteni adresare do ListStore by mohlo pomoct...