Pluginove rozhrani, nejasnosti

[Petr Solin]

Reaguji na tento prispevek: http://forum.altap.cz/viewtopic.php?p=15213#15213. Konkretne na tuto cast:

AddCustomUnpacker definuje popis/název pluginu, AddPanelArchiver nikoliv - v konfiguraci "Archivers Associations in Panels" se použije Salamanderem generovaný název. CPluginDataInterfaceAbstract je pro potřeby Archive browser pluginu z velké části prázdný - na wiki by mohla být šablona. Skoro všechny CPluginInterfaceAbstract metody obsahují parametr HWND parent. Pro archiver je však třeba používat CSalamanderGeneralAbstract::GetMainWindowHWND (zde si nejsem jist, zda nestačí metodám dialogů předávat NULL - dokumentace mlčí). CSalamanderSafeFileAbstract::SafeFileCreate obsahuje parametry const char *srcFileName a const char *srcFileInfo - fungují však jen dohromady. srcFileInfo má obsahovat datum a velikost souboru, ale není popsán přesný formát řetězce (pro sjednocení mezi pluginy) - hodila by se metoda, která by tento řetězec vytvořila při zadání velikosti a FILETIME struktury. ...

Pluginove rozhrani vzniklo postupne, tedy rozdilne pristupy tu jiste budou. Bohuzel si za ty roky mnohdy nepamatuji, proc konkretne ktery parametr je ci neni v te ci one metode rozhrani. Prosim omezme se na konkretni problemy, pokud potrebujes neco, co ted neni mozne udelat, popis situaci a uvidime co s tim jde delat.

Rozhodne je lepsi odrazit se pri tvorbe pluginu minimalne z DemoPluginu nebo lepe z jineho funkcniho pluginu (napr. UnFAT). V SDK je DemoPlug, UnFAT zatim ne, je to v planu, nejspis na to dojde po prekladech. Zdrojaky UnFATu ti poslu, pripadne i jine zdrojaky, prirozene mame zajem, aby nove pluginy vznikaly.

Co se tyce parentu oken: v dobe zavadeni rozhrani pro archivatory, jsme meli pocit, ze by se okna mela sjednotit, kvuli designu a zjednoduseni kodu pluginu, a ze je rozumne parenty resit za plugin, viz metoda ShowMessageBox a GetMsgBoxParent v CSalamanderGeneralAbstract. Tedy v metodach archivatoru se pouziva bud ShowMessageBox (nema parametr parent) nebo toto:
HWND parent = SalamanderGeneral->GetMsgBoxParent();

Pouziti SafeFileCreate viz UnFAT. Souhlasim, ze by se metoda pro generovani srcFileInfo hodila, tyto navrhy na vylepseni mi posilej nebo nekde stradej, az budu mit dojem, ze mam chvilku na ozdravovani kodu pluginu, budu to realizovat. Tohle konkretne jsem si prihodil na todo.

Wiki na tyhle vecicky bude vazne idealni, urcite neni nasim cilem mit uzasne vypiplane pluginove rozhrani na ukor dalsich veci, ale cas od casu si to jiste nejake ty upravy zaslouzi. Dalsi neprijemnost je, ze jak roste pocet metod rozhrani, tak se toto stava mene prehlednym a snadno muze potencionalni vyvojare polekat (to se jiste deje uz dnes).

[zarevak]

Děkuji za odpovědi!

Posílal jsem pár otázek na mail Honzovi (spolu s informací o pádu FTP pluginu), ale asi už nestihl odpovědět (modře komentáře po ručním zkoušení):

- mají UnpackOneFile a UnpackArchive zajištěny, že pracují se stejným souborem jako ListArchive? V ListArchive testuji, zda se jedná o archiv a v PluginData si pamatuji pozice do archivu pro jednotlivé soubory. V UnpackOneFile a UnpackArchive již jen používám tyto pozice a integritu nekontroluji.... (V archivatory.txt je ukázka z UnFAT pluginu, kdy si UnFAT plugin v ListArchive uloží CFATImage objekt a pak s ním pracuje v UnpackOneFile a UnpackArchive)

- běží archivery ve hlavním vlákně, aby mohly používat SafeFileCreate? Upravíte SafeFileCreate, aby fungoval v budoucnu i po přesunu archiverů na zvláštní vlákno? (Vypadá to, že toto teď funguje ok)

- jaký handle okna mají archivery používat pro ProgressDialogy a CSalamanderSafeFileAbstract? Stačí NULL nebo je třeba SalamanderGeneral->GetMainWindowHWND()? Demoplug je v tomto nejednotný. (Použití SalamanderGeneral->GetMainWindowHWND() v SalamanderSafeFile->SafeFileCreate() nefungovalo správně, protože při dialogu se žádostí o přepsání se po přepnutí do jiné aplikace a zpět dialog někam ztratil)

- CSalamanderForOperationsAbstract::MoveFiles obsahuje parametry remapNameFrom a remapNameTo - o kterých netuším k čemu jsou. Pokud MoveFiles slibuje přesun souborů z místa A do místa B, k čemu je remapování názvů? - Demoplug toto používá: salamander->MoveFiles(tmpExtractDir, targetDir, tmpExtractDir, fileName), což mi připadá divné. (Nakonec jsem MoveFiles opustil, protože přestože v Demopluginu slibuje řešení přepisů, tak soubory přepisuje bez dotazu uživateli; navíc SafeFileCreate řeší vytváření adresářové struktury)

Jestli můžeš, pošli mi UnFAT plugin - myslím, že by mi mohl pomoci odpověděd na spousty drobností

[Petr Solin]

Uz jsem to odpovedel mailem, tak znovu:

V jednom panelu je jedna cesta, k ni patri jedny PluginData, kdyz se cesta v panelu zmeni, vola se znovu ListArchive, ziskaji se nova PluginData. Kdyz se zmeni soubor na disku, a nejde o disk se sledovanim zmen, je Refresh na userovi, jinak se udela automaticky (vola se znovu ListArchive). Takze uplne slepe bys s tim pracovat asi nemel, na druhou stranu, asi je dost malo pravdepodobne, ze ti nekdo zmodifikuje archiv "pod rukama". Nevim, to uz si posud sam. Dalsi varianta je, ze si do PluginData das otevreny handle na soubor archivu (povolis jen sdileni pro cteni), pak ti ho nemuze nikdo zmenit.

Zatim ano. Vice threadu bude mit nejspis jiny rozhrani, az to vznikne, zkusime stavajici pluginy prevest, melo by to byt snadne, ale to se uvidi az to bude.

GetMsgBoxParent. GetMainWindowHWND byla chyba, sel aktivovat progress dialog, opravil jsem to i v dalsich pluginech, copy&paste problem.

Jde o dotazy na prepis: ptame se usera, jestli chce prepisovat soubor v cili souborem z archivu misto souborem z tmp adresare (MoveFiles se pouziva jen pokud se vybaluje napr. externim softem a dotazy na prepis chces mit svoje - tedy do tmp adresare vybalis co potrebujes, pak to presunes).

Co se tyce nefunkcni MoveFiles: posli plugin, mrknu na to v debuggeru, tuhle metodu uz zadny plugin nepouziva, takze se do ni mohla zanest chyba.

[zarevak]

Co se tyce nefunkcni MoveFiles: posli plugin, mrknu na to v debuggeru, tuhle metodu uz zadny plugin nepouziva, takze se do ni mohla zanest chyba.

Oprava: MoveFiles funguje správně přesně jako uživatelské Move F6 - tedy i s dotazy uživateli a chybovými dialogy

Poznámka pro sebe: než nahlásíš chybu, zkontroluj, zda soubory, které chceš přesouvat, jsou na zdrojové cestě a cíl sis nepřepsal sám

[zarevak]

Pár další otázek:
- Jak funguje skipPath parametr metody SafeFileCreate? Při testování svého pluginu jsem ji zatím nikdy neviděl naplněnou. V UnFAT pluginu to vypadá, že slouží k nějakému přeskočení zbytku adresáře a pak se zahodí (což spoléhá na seřazení seznamu souborů...) Podle SDK může být skipPath parametr ignorován - pravděpodobně je pak řešeno pomocí silentMask a skipped?

- Je nutné při extrakci prvního souboru vždy volat testování allocateWholeFile (pomocí nastavení nejvyššího bitu)? Tento test způsobuje fragmentaci souborů, které se allocateWholeFile snaží zabránit

- Je bezpečné posílat do CSalamanderRegistryAbstract::GetValue již nastavené výchozí hodnoty? Přežijí tyto hodnoty volání metody i při jejím neúspěchu? (Jednoduché testování naznačuje, že přežijí) - zjednodušil by se tak kód LoadConfiguration:

Code: Select all

void WINAPI CPluginInterface::LoadConfiguration( HWND parent, HKEY regKey, CSalamanderRegistryAbstract *registry )
{
	Config_Value = 123; //nastaveni vychozi hodnoty

	if (regKey != NULL)   // load z registry
	{
		registry->GetValue(regKey, CONFIG_VALUEKEY, REG_DWORD, &Config_Value, sizeof(DWORD));
	}
}

[Petr Solin]

Koukal jsem po tom skipPath a je to zrejme usite na miru UnFAT pluginu, v jinem pluginu se to zatim nevyuziva (nastaveno na NULL). Vraci se v tom uzivatelem skipnuta cesta. V UnFATu se to pouzije pro rychly preskok vsech polozek patricich na tuto skipnutou cestu. Parametry silentMask a skipped neovlivnuje, jestli je skipPath NULL a nebo se pouziva.

Testování allocateWholeFile jsme zavedli diky bug reportum, to neni jen nase paranoia. Bohuzel existuji konfigurace, kde misto nafouknuti souboru a jeho nasledneho prepisu od zacatku dochazi k nafouknuti souboru a naslednemu nesmyslnemu zapisu na konec souboru (nefunguje seek na zacatek souboru, vznikne dvojnasobne velky soubor). Tedy test doporucuji, nicmene je to na tobe. Mam tenhle problem hodne vysoko na todo, opravim to fragmentovani po tomto testu (i kdyz ho tu bohuzel nejsem schopen reprodukovat).

Nas kod buffer nemeni, ovsem stejne ti neodpovim, protoze buffer vstupuje jako parametr do RegQueryValueEx a tam netusim co se s nim deje, zeptej se u MS. Koukam do kodu, ze my na to nezmeneni celkem hresime, takze asi se muzes klidne pridat, ale zaruceny to neni.