Some questions regarding windows handling - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Skinning (https://forum.kodi.tv/forumdisplay.php?fid=12) +--- Thread: Some questions regarding windows handling (/showthread.php?tid=310511) |
Some questions regarding windows handling - baza_dwa - 2017-03-26 1. <ononluad> for a window - is this called on ActivateWindow() for another window? What if the window activated is a dialog? 2. How to close a custom dialog, returning back to calling window? Are there some default buttons for a custom dialog with default actions? 3. I am calling ActivateWindow() from a custom dialog. Should I somehow cleanup current custom/normal dialog before calling ActivateWindow()? RE: Some questions regarding windows handling - jurialmunkey - 2017-03-26 1. <onunload> is called when the window closes, so it doesn't happen for MyVideoNav when DialogVideoInfo is called because MyVideoNav is still open behind the dialog. However, if you have an <onunload> in DialogVideoInfo it will happen when you go back to MyVideoNav (because the dialog closes). 2. <onclick>Close</onclick> should work fine (or whatever other tag, like onleft or whatever). Otherwise you can use Dialog.Close(ID) See these wiki entries for commands you can use in <onclick> <onleft> etc. commands http://kodi.wiki/view/Action_IDs http://kodi.wiki/view/List_of_built-in_functions 3. You will likely have to close the custom dialog before calling another window etc. e.g. Code: <control type="button"> RE: Some questions regarding windows handling - baza_dwa - 2017-03-26 So, there is always a full stack of open windows which can be navigated back with returns from the current dialog? And if I have different background for different windows, all they are kept in the memory? Is there some guide/best practices regarding memory management in skins? Does closing any of the visited explicitly windows break the chain or just remove one link? What about querying a window which has not been opened yet with Window([window]).Property(key)? Does it instantiate the window in the background, not displaying it, or just constructs the fetched value? RE: Some questions regarding windows handling - smitchell6879 - 2017-03-26 For memory management it is my understanding that using the visible tag for the backgrounds will help with that... The window(id). Property (key) in most cases is only available after you setproperty (key,value,I'd) somewhere in the skin. Not sure I follow with the rest of what your asking RE: Some questions regarding windows handling - baza_dwa - 2017-03-27 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? RE: Some questions regarding windows handling - jurialmunkey - 2017-03-28 (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) 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. RE: Some questions regarding windows handling - baza_dwa - 2017-03-28 Just one more question - how do I close the current non-dialog window, going back? I cannot find any action on the List of Built In Functions... In keymap there are functions like Back or ContextMenu, but they are not on the list. RE: Some questions regarding windows handling - jurialmunkey - 2017-03-29 I linked you a list of the Action IDs that are used in keymaps before (back and contextmenu are in there) http://kodi.wiki/view/Action_IDs I'm not sure exactly what you mean, but you can use keymap actions as <onfoo> commands (e.g. onclick, onleft, onback etc.) Code: <onclick>Back</onclick> Code: <onclick>Close</onclick> Code: <onclick>PreviousMenu</onclick> Code: <onclick>ParentDir</onclick> RE: Some questions regarding windows handling - ronie - 2017-03-29 (2017-03-29, 07:08)jurialmunkey Wrote: yup 'close' is an alias for 'back' 'parentdir' is an alias for 'back' as well. both 'close' and 'parentdir' are deprecated, so it's best to only use 'back'. RE: Some questions regarding windows handling - jurialmunkey - 2017-03-30 (2017-03-29, 18:34)ronie Wrote:(2017-03-29, 07:08)jurialmunkey Wrote: Good to know. Looking at the button translator I'm guessing "parentfolder" does what I assumed "parentdir" did? If so, its not on the wiki in either Action IDs or Built-in Functions. |