(2017-03-27, 19:10)baza_dwa Wrote: I mean what about a situation when you call Window(weather).Property(some_prop) without opening weather window beforehand. Is the property populated/instantiated magically in the background?
Kodi handles memory management. No need to do anything like that in the skin. Yes you can access other window properties from outside the window (you just can't access skin strings or window properties inside itemlayout/focusedlayout, but that's a whole other story).
I'm not sure with Weather. I remember that previously you had to go into the window first, but I don't think that happens anymore and the properties are just filled as soon as the weather is fetched regardless of where you are (not 100% on this, but pretty sure). You can always access Home window properties where ever you are.
Whenever you use ActivateWindow, kodi will remember the previous window it came from. When going back it will follow that breadcrumb trail. All the "return" in an ActivateWindow does is tell kodi that you want to go back to the previous window when you reach that library node rather than going back through the whole library to the base window.
For instance,
Code:
ActivateWindow(Videos,videodb://movies/genres/,return)
Will take you to movie genres, where you can click on categories like Action and then press back to return to genres. However, because of the return parameter, when you press back from the genres page, it will go back to the previous window rather than down one level to videodb://movies -- If you didn't specify return, you would go back to the parent videodb://movies folder and then to its parent videodb:// folder before returning to the previous window.
If you want to take the current window OUT of the breadcrumb trail then use ReplaceWindow instead. This tells kodi that instead of adding the next window to the trail, replace the current one in the trail with the new one.
You can't explicitly close a window in the breadcrumb trail because only one window is open at a time. However, you can have a stack of dialog windows and explicitly close one with Dialog.Close -- I think in that case, going back just returns to the next one in the stack.