Altap Salamander Support Forums

Narazil jsem na takovou zvlastnost, kterou nechapu

Jsem v adresari, prohlizim fotky, spacem se posunuji dale. Vse ok. Pokud ted zmenim adresar v panelu kde jsou fotky na nejaky jiny, prohlizeni prestane fungovat. Klavesa space je neaktivni a uz nefunguje. Navrat do adresare to neopravi. Musim pak PictView zavrit a jet znovu. Pokud se prepnu Tabem do dryheho panelu, tak to funknost nenarusi.

Otazka teda zni - jak to vlastne funguje interne? Kdy se provadi enumerace souboru a co ji ovlivnuje? Urcite to neni aktivnim panelem (viz presunuti na druhy panel). Nemelo by fungovat prochazeni i kdyz adresar zmenim? cekal bych ze seznam souboru v danem adresari je nejak prednacteny a pak pres nej jedu v cyklu.

Raptor wrote:Narazil jsem na takovou zvlastnost, kterou nechapu

Jsem v adresari, prohlizim fotky, spacem se posunuji dale. Vse ok. Pokud ted zmenim adresar v panelu kde jsou fotky na nejaky jiny, prohlizeni prestane fungovat. Klavesa space je neaktivni a uz nefunguje.

Mel jsem za to, ze se to zde jiz nekolikrat vysvetlovalo, ale opet jsem to nenasel Tak mam jen odkaz do helpu:
Opening Previous or Next File from Panel or Find Window.

Jak je to interne implementovane? Vsecny viewer pluginy pouzivaji iteratory poskytovane Salamanderem, jejichz funkcnost zavisi na tom, jak ma uzivatel momentalne nastavene masky k jednotlivym pluginum.
V okamziku zmeny cesty nebo zavreni Findu je iterator zneplatnen.

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

Chapu. Stejne bych byl radsi kdyby to fungovalo i pri zmene adresare, ale preziju to.

Otazka do pranice: pokud bude v budoucnu implementovan tabbed browsing do AS - bude to delat taky pokud se prepnu na jiny tab? To by bylo asi nezadouci, zvlaste kdyz se pak muzu prepnout zpet.

bud by to chtelo varování že opouštím adresář který je prohlížen což ale bude otravovat nebo třeba při návratu do adresáře umožnit znovuprohlížení
ideální uchovávat asi ten seznam souborů nebo rucne ho obnovit ?

mozna jeste lepsi varianta proste prejit na nejblizsi dalsi akorat jak s tridenim - pokud uz nejsem v adresari pouzit zatim dle abecedy ?
nebo by treba stacilo uchovavat pri volani vieweru typ trideni - to zabere par bitu a pak by si viewer mohl zit klidne dal i bez AS

BTW: volat viewer bez AS by se mi obcas taky docela hodilo

Možnost upozornit na otevřený Viewer je problematická, protože Salamander neví, zda byl viewer již zavřen nebo ne. Případně, zda Viewer zobrazuje stále soubory z původní složky. Jak Internal Viewer tak PictView mají příkaz Open...

Možnost znovu získat seznam souborů při požadavku Vieweru na další soubor je nevhodná, protože by Salamander musel znova vylistovat celou složky a to na pomalých sítích může být problém (třeba taková WiFi).

Možnost pamatovat si seznam souborů po opuštění složky komplikuje potřeba zajistit uvonění tohoto seznamu. V současném návhru není cesta, jak by Viewer oznámil Salamanderu, že již seznam nepotřebuje (Viewer byl zavřen, uživatel otevřel jiný soubor, Viewer nepodporuje přechod na další soubor, ...). Salamander teď volí jednoduchou cestu: seznam uvolní při opuštení skložky v panelu.