Tohle mne taky zaráží, přestože jsem programátor a autor několika pluginů.
Nebylo by možné ty iterátory zachovat dokud existují otevřené Viewery?
Salamander pro zobrazení Vieweru volá:
CPluginInterfaceForViewer::ViewFile(..., int enumFilesSourceUID, int enumFilesCurrentIndex);
Teoreticky by bylo možné nahradit parametr
enumFilesSourceUID předáním nově vytvořeného
CSalamanaderEnumFilesManager *enumManager.
Pokud by plugin umožňoval přejítí na předcházející a následující soubor, pak by plugin ve
ViewFile() zavolal
CSalamanaderEnumFilesManager::Lock(), čímž by se inkrementoval interní počet referencí a dokud by plugin při zavření okna nezavolal
CSalamanaderEnumFilesManager::Release(), tak by existovala kopie enum seznamu pro tento plugin. (Enum seznamy by se sdílely, takže 5 pluginů se stejným seznamem by sdílely jedno paměťové místo).
Bezpečnější a pro C++ programátora jasnější implementace by byla, kdyby CSalamanaderEnumFilesManager::Lock() vrátil nový CSalamanaderEnumFiles objekt a ten by plugin používal pro přístup k seznamu a při zavření okna pluginu uvolnil.
Výhody:
- zachování seznamu souborů po opuštění pluginu
-
CSalamanderGeneral by se odlehčil a zprogramového hlediska by se zapouzdřil seznam souborů do nového objektu
Komplikace:
- Soubor v seznamu může být smazán. V současnosti, pokud prohlížíme soubory v panelu, tak je seznam automaticky aktualizován. Při prohlížení seznamu výsledků hledání již seznam aktualizovaný není a plugin nahlásí chybu. Pro seznamy stále zobrazené v panelu, je možné seznam stále s tímto novým postupem aktualizovat. Při opuštění složky v panelu, ztratíme možnost aktualizovat položky seznamu, ale stále umožníme uživatelům seznam procházet.
- Plugin může zapomenout zavolat
Release() a uvolnit tak paměť seznamu. Vzhledem k tomu, že plugin musí explicitně požádat o držení seznamu, tak autor pluginu ví, že někde alokoval prostředky, které je třeba uvolnit. Pokud Salamander nějakým způsobem bude držet informace, který plugin seznam zamknul, může je při odnačtení pluginu uvolnit. Případně na situaci upozornit, aby otravoval Plugin Developera
Nevýhody:
- Paměťová náročnost (vzhledem k současným pamětěm nepovažuji za problém. Navíc kopie vzniká až při opuštění složky v panelu nebo zavření/změně Find okna, takže situace je po většinu času stejná jako teď)
- Nekompatibilita Plugin Interface (vzhledem k časté změně interface a malému počtu ne-Altapích pluginů nepovažuji za velkou nevýhodu)
- Implementace zabere několik dnů až týdnů práce
