Provide the way to tell desktop’s onLoad SOURCE

Provide the way to tell desktop’s onLoad SOURCE

I’ve just found(learned) a desktop’s onLoad event is called even on

opening menu.

If we enter that menu, we see a series of desktop’s thumbnailed images.

In that menu, all desktop’s onLoad events are called if they aren’t already loaded. It does make sense to call onLoad event at that moment.

I think most of onLoad event-handler-script  of desktop do some initialization about desktop items like folder/panel etc.

But if onLoad is called even that menu scene, we dont’ have to initialize, moreover, we CAN’T initailze, because desktop’s sub items(folder,etc) is not instantiaed yet. That means NULL error-prone.

So I’d like to have a way to tell onLoad event’s SOURCE.

For now, all cases give C_LOADED value.

If a desktop is loaded for Config-desktop menu, then LL can give its source as other value. Then we can deal that case differently.

]]>
(Next Post) »

9 Commentsto Provide the way to tell desktop’s onLoad SOURCE

  1. Anonymous says:

    < ![CDATA[

    I’ve used LL.getCurrentDesktop() over LL.getDesktopByName(‘hadr_coded_name’) in a script.


    But in relation with above fact, the latter method can be more robust, especially in onLoad script.



    One situation:


    In desktop#1, you open menu ‘settings-lightning-config desktop’.


    Then desktop#2,#3,,’s onLoad events are called.


    In desktop#2’s onLoad script, if you use LL.getCurrentDesktop(),


    then that resulting desktop is not #2, but #1.



    I thought/presumed that getCurrentDesktop gives always that desktop whose script is attached. But NO. Of cousrse LL gave us currenly-opened desktop, desktop#1. But I guess nobody want that result.

    ]]>

  2. Anonymous says:

    < ![CDATA[

    LL.getCurrentDesktop() returns the current desktop, not the desktop where the script is run. This may not seem obvious, but your supposition that ‘when a desktop is loaded is because it is the current one’ is , as you discovered, wrong.



    It does happens also if you create an item or change properties or even gets the items of a non-loaded desktop, it gets loaded (this happens for all containers). I personally have scripts that forces the loading of all containers, for example my binding dictionary.



    What I try to say is that getCurrentDesktop returns the current desktop and should be used only when you really want the current desktop.


    On the other hand LL.getEvent().getContainer() will return the container the script is run from (only if the source is a container-related one!) so this is the one you should use on your situations.

    ]]>

  3. Anonymous says:

    < ![CDATA[

    TrianguloY Related to onLoad event of desktop, what I need to do is to differenciate current loading’s situation. One is for normal desktop loading, and its the usual case. The other is one, Ive found today, which is called on LL’s config menu, and I think most scripter couldn’t image onLoad’s calling. For the latter case, we don’t have to do any action in onLoad script. So I suggested its uinique event SOURCE value.



    Anyway, owing to your advice, I could tackle my problem using like SOURCE thing.



    // onLoad script of desktop


    function main() {


      if (LL.getCurrentDesktop() != LL.getEvent().getContainer()) {


        return; // don’t do anything.


      }


      // real things to do.


    }


    main();


    //



    Thank you so much.

    ]]>

  4. Anonymous says:

    < ![CDATA[

    +KyongJoon Lee does your solution work?



    if not, you could hardcode the name of your desktop and check that:



    if (LL.getCurrentDesktop().getName() != “foo”) {return;}

    ]]>

  5. Anonymous says:

    < ![CDATA[

    Jappie Toutenhoofd After some more trials, I concluded that a new event SOURCE might be needed.



    Yes, in “Configure Desktop” menu, or “Backup template” menu(where also desktops thumbnails shown) etc, both your way and mine work well for that purpose. HOWEVER…



    I came across another case. When we move from desktop#1 to #2 by swipng/shorcut etc, the desktop #2’s onLoad script has below values.


    LL.getCurrentDesktop() == #1 not #2. (Its contrast to our expectation)


    LL.getEvent().getContainer() == #2.

    ]]>

  6. Anonymous says:

    < ![CDATA[

    That’s because the onload event is a loading event, and so it occurs before the current desktop changes.



    As I said before, the LL.getCurrentDesktop() is designed to return the current desktop, not the desktop the script is run from.



    Edit: didn’t tested but on the opposite the resumed event should be LL.getCurrentDesktop() == #2 (although there were some problems with this and folders and not sure if it works this way)

    ]]>

  7. Anonymous says:

    < ![CDATA[

    TrianguloY Yes, your’re right. The getCurrentDesktop() and onLoad do their work well. My mentions about them are a result of solving ways.



    =================



    Why does Event provide getSource() method? Because, although the same event happened, we might need to react differently with its source.



    Why does Desktop provide onLoad event? Because in the time of desktop loading, we might need to prepare some initializing things. And the initialization is generally done only once.



    Your explanation about onLoad’s calling moment is absolutely right.


    However regardless of it, we all presume when onLoad is called, AFTER ALL my desktop will be loaded and working. And it presumption is valid in most of use cases, where we’re switching between desktops by swiping/shortcut, etc and we don’t care who loaded my desktop, we care my deskop will be loaded after all.



    But in only ONE unexpected scene, onLoad doesn’t mean that onLoaded desktop will be working.


    That scene happens in Setting-Lighting-Configure desktop/Backup template, etc.


    In those case, all desktop are loaded just for getting dynamic thumbnail, not for real/full/normal working. I guess it isn’t full loading.



    More critical case happens after installing new template which uses onLoad for its initialzation.


    If we install (or restore) a template, next scene is choosing one desktop to go.


    So in that scene, new template’s onLoad is called, and tries to initialize something. But that init can be successful or not. If that is based on just calculation-thing, no problem. But if based on desktop’s sub items-things, it can be failed, which was my case.



    To put it simple, current LL’s onLoad context can be grouped two.



    One is to be loaded by other LL’s normal objects, in which they can know/communicate each other.


    The other is to be loaded by LL menu system for LL itself purpose, in which they are seperated,


    which means, as you know, all desktops normal working is halted except some like paused/resumed things.



    So I request a way for us to tell onLoad’s event SOURCE thing.



    Anyway, I’ve tried other ways for one-time initialzation.(I threw away onLoad for init) Yes, currently I’m using onResume event of redundant item. So I really want getSource()’s thing.



    //onLoad


    if (LL.getEvent().getSource() == MENU_LL) { return; // no init. }


    Instead of one-line thing, my hack is to go too cumbersome way.

    ]]>

  8. Anonymous says:

    < ![CDATA[

    Absolutely agree. Let’s ask Pierre Hébert opinion .

    ]]>

  9. Anonymous says:

    < ![CDATA[

    I found a hack for that.



    if (!LL.getEvent().getContainer().getView()) {


      // In LL setting menu, onLoaded desktop has no View.


      return;


    }

    ]]>

Leave a Reply

Your email address will not be published. Required fields are marked *