V14b3 beta
What’s new?
The most visible change is the support for “plugins”: it consists in allowing the user to click on “Add item” and select either a built-in object, or a plugin loaded from an APK. You can try it with the sample clock APK (download it here : http://www.lightninglauncher.com/scripting/samples/Clock-2.1.apk) and watch the video to see how it works.
In fact the feature is currently pretty basic. At the moment, it is mostly the same as loading a script from a package, except that the APK is shown in the “Add item” dialog. More documentation and sample source code can be found here: http://www.lightninglauncher.com/wordpress/scripting/.
This sample clock plugin also demonstrates new features found in V14b3:
– support for customizing the item popup menu, meaning that you can now remove, or add items to create your own menu content, through script. Pretty much everything can be done, from easily adding a new menu item, to fully replace the whole popup content. There’s one limitation though: this is available for items, not for the container menu. This official hook replaces the smart but fragile implementation based on ViewTreeObserver.
– support for using Lightning preference controls (the ones used in the app’s settings screen). This can be used to easily create preference screens.
Naturally, that version also comes with a few bug fixes, but not that much. Good!
But there’s something bigger to come… stay tuned!
Full ChangeLog: http://www.lightninglauncher.com/wordpress/change-log/
D5 Creation
< ![CDATA[
Something bigger than the ability to display our own settings screens???? Wow
]]>
< ![CDATA[
Yes, way more
]]>
< ![CDATA[
Yay, now I have to find time to integrate that into my apps đ
]]>
< ![CDATA[
Lukas Morawietz I tried to make it in a way it’s not too hard when you already have a script package. The most difficult part remains to package things in an APK. Maybe later I’ll allow “raw” scripts to be displayed in this plugins section.
]]>
< ![CDATA[
Pierre HĂ©bert yeah it should be pretty easy, as for most things I should be able to just change the intent filter, add the part that moves the item in the setup and then I’m good to go.
]]>
< ![CDATA[
Pierre HĂ©bert One question though: What would be the easiest way to have multiple items in one apk? Do I need to create activities for all of them? (I’m currently using a fragment structure, that’s why I would like to avoid that)
]]>
< ![CDATA[
Yes you need multiple activities for the descriptive part (icon and label are extracted from the activity info), but in the Android Manifest.xml you can use several activity-alias and a single real activity. In onCreate you can discriminate which alias is used using the class name of the component name. An alternative to activity-alias is to create subclasses with some “getIdentity()” method.
]]>
< ![CDATA[
Pierre HĂ©bert I noticed in the sample: You are using a few of the old api methods. As this is an example how to do things correctly, I think those should be replaced with their new counterparts.
]]>
< ![CDATA[
This is true, I’ll do it
]]>
< ![CDATA[
Pierre HĂ©bert also, your installScript is broken. Use
var path = ‘/’+MY_PKG.replace(/\./g, ‘/’);
instead. This will replace all dots, not just the first.
]]>
< ![CDATA[
Pierre HĂ©bert and static final String INTENT_EXTRA_SCRIPT_PACKAGE = “p”; should probably be included in the sample, or is there documentation for that elsewhere?
]]>
< ![CDATA[
Thanks, mixing java and javascript is too much for my brain đ
This is documented in the reference sample package (SampleLLXScript.tar.gz) but I could update the clock sample as well
]]>
< ![CDATA[
Cool. Thx
]]>
< ![CDATA[
How to custom the item popup menu? Could anybody explain?
]]>
< ![CDATA[
In the item properties, in the events panel, long tap on the “Menu” setting : it will display the documentation, including a sample.
(expert mode need to be on)
]]>
< ![CDATA[
Running scripts on background seems to be broken in the beta. getItemByName generates null error. Used to work in the v12 build. Running the scripts in desktop fixes the issue, but requires LL to be in the foreground
]]>
< ![CDATA[
“There’s one limitation though: this is available for items, not for the container menu” Why? can this restriction be lifted in the future?
]]>
< ![CDATA[
Wern-Yuen Tanâ it works for me. If you list the content of the container using getAllItems(), can you see your items or is it empty?
Lukas Morawietzâ I was waiting for this question đ This isn’t a technical problem but I wasn’t too sure it would be safe to allow replacing the whole content of this critical menu. I know that almost everything can be done anyway, but… What do people think about this? Pros: can be used to have a coherent look if the item menu is customized, can be used to provide container/app features. Cons: not sure about safety.
]]>
< ![CDATA[
Pierre HĂ©bert yes it does show up. but the original script, which uses SetBoxBackground does not work when running it in background mode from Tasker. I use LL.currentDesktop() as the container, maybe that’s why it doesn’t work from the background. is there a better way?
]]>
< ![CDATA[
Pierre HĂ©bert I’d like to add options for the music widget, but the main element is a panel. That is why I’m asking. Maybe you could block the removal of the settings option? Then people could always turn scripts off if the rest of the menu is screwed.
]]>
< ![CDATA[
whed user doing some mistake, they can do this: disable scripting đ
]]>
< ![CDATA[
Wern-Yuen Tan if you think this could be linked with a special context, could you please send me a template or a sample code so that I can reproduce the bug ?
Lukas Morawietz that’s a good point. It makes sense to see a panel as a single object, hence having its menu customized is a good use case.
Danbar Danbar only if the settings screen can be reached đ
]]>
< ![CDATA[
setting screen is everytime reached, by app drawer – tap to Lighntning launcher, or add shortcut – LL action.
]]>
< ![CDATA[
Pierre HĂ©bert this is the script snippet that i’m getting a null error on getItemByName, when trying to run in the background from Tasker. (the items and variables like map and image exist and are defined by the rest of the script ahead of this line below which is drawing the error:
LL.getCurrentDesktop().getItemByName(‘map’).setBoxBackground(image, “n”, true);
i think it may be that LL.getCurrentDesktop() no longer works in background in V14. it used to work in V12. i saw this other bug report with a similar issue but am not sure if it has been resolved:
https://plus.google.com/104593802059787517143/posts/HAc1xmTCeGB?sfc=true
]]>
< ![CDATA[
Based on your description, I assume LL.getCurrentDesktop() does work, otherwise you would have notice it a lot sooner in the script, where the items are created. In fact, no matter what the returned container is if items are dynamically created in the script (as long as the container is not null). If a call to getItemByName later doesn’t return the item, then there are two possibilities: either the container is not the same, or things have been scrambled in the middle, but I can’t say what with one line. The devil is hidden in details!
]]>
< ![CDATA[
Will send you the script via mail. LL.getCurrentDesktop is actually first used on the error line above
]]>
< ![CDATA[
Pierre HĂ©bert did some more testing, and found a workaround with LL.getItemById which works in Background. LL.getCurrentDesktop().getItemByName(‘xxx’) works only in Desktop on V14, returns null error if run in Background
]]>
< ![CDATA[
Wern-Yuen Tan thanks for the script. I slowly start to understand. I though the ‘map’ item was dynamically created. I’ll have a look at something and I’ll come back to you with a test version.
]]>