[Sorry for the long post. When I wrote the list I didn’t know it will grow so much]
—
I’ve been playing around with the menu event and I have some suggestions and bugs (some unrelated to the menu event, but interesting specially #4 about frozen widgets)
Bugs:
1)With the sample script (the ‘hello goodbye’ one) occurs a bug that I think could happen in other places too: when clicking a menu (and the alert is shown) if an item in the container with a binding updates at the same time more or less, the alert will have as title the name of the binding script, instead of the menu one. I can repeatedly trigger this using the binding animate(“$ll_second”,1000)
2) In the script editor, while editing the name/path of a script from the dialog, clicking accept or cancel doesn’t hide the keyboard, it is still shown and active on the script code, that is possibly hidden by the side menu (the keyboard should close).
3) If you are on the script editor and you multitask to other apps, a script editor app is shown on the recent list. However clicking it shows the desktop instead of the editor.
4) I found a reliable way to freeze widgets, but first two related bugs:
4a) On general settings there is an ‘auto edit mode’ option that says ‘enter edit mode when adding an item’. I do remember that previously it said ‘when moving’, but now I’m not sure. Anyway that’s exactly what the setting does, not what it says. To be more clear: no matter what you choose, edit mode will be entered always after adding an item (except when adding a widget that opens an activity to configure).
4b) Add a panel, and then a widget. From 4a), if the widget doesn’t open an activity to configure, the panel will be in edit mode with the widget correctly displayed, but when you exit edit mode the widget is instead a ‘zombie widget’ (not sure how to call it). They will appear as if its internal ‘initialize event’ never run. Some I tried were shown as opaque rectangles, other even invisible. Best to try a few and check. To fix it restart the launcher.
4c) If you followed the steps in 4b) (add a panel, add a widget, restart launcher) now the widget works correctly…until you edit that panel. When doing so it will appear as normal while in edit mode, but from now on it won’t never update in normal mode (you can even interact, but it won’t update, and you can see the result of your clicking in edit mode). I’m highly sure the edit mode of a panel is a duplicated of the original panel, and the widget is a copy. There seem to be an issue with this, the widget on the original panel becomes a zombie and the one in the edit panel gets the updating events (or whatever).
Wow, so long. Now they come the suggestions:
5)Add a menu event in general settings. It will be nice to have an extra button in all menus of the launcher for example, or to change them to dark. Note that if you set a custom menu event of an item it will need to run both scripts (first the general one, then the custom). Not sure how difficult this is to implement, so don’t worry if you leave it on the todo list.
6) The menu event is only for scripts, and even choosing another action does nothing. So why not directly open the run a script dialog?
7) Talking about the run script dialog, now that they can be in folders what about the same ‘folder/name chooser with the ‘include sub directories’ checkbox?
Again sorry for the long post 😛
]]>
D5 Creation
< ![CDATA[
No problem for the post length (but I wish that G+ would display it in a wider box when viewed alone, the tiny column looks ridiculous)
And thanks for the feedback.
1) This is directly linked with https://plus.google.com/u/0/100430440392224314007/posts/RKoWi515r2u. In fact this bug has been there since… probably V10. I’ll have to fix this one day, but certainly not for V14 given the amount of stuff I still have to do.
2) Good catch, I don’t know why the keyboard is sometimes shown, sometimes not, and why it is sometimes hidden, sometimes not. It doesn’t work the same on all devices. I am a bit worried about using manual show/hide instructions because it shouldn’t be necessary, but maybe I’ll have to do it anyway.
3) Quite strange, I haven’t had the time too look at this.
4a) Indeed, there are inconsistencies on how edit mode is handled. I noticed that recently, and what I will certainly do is remove (or hide) this old “Auto edit mode” which isn’t very useful now. It was added a long time ago to help in a transitioning behavior, but it’s not really needed today.
4b and 4c) Oh, widgets… Did I already said that I don’t like widgets ?
Now I remember why I implemented a view cache for widgets. I ditched it in V14 a bit too fast. Now I remember that on some Android versions it works to create two views for the same widget, on some other it miserably fails. The cache job was to ensure that not two views were created for the same widget. Because you are right: editing a panel results in creating a new view (the full view hierarchy for the container), this is a hack, the container is displayed in a temporary folder. Well, I’ll resume this widget view cache, but that’s pretty annoying because not all use cases will work correctly.
5) I’ll do, but not in a cumulative way. The reason is that it is easier to call two separate menu configuration tasks from a single script, than undoing things, should you decide that for a given item you don’t want the global menu customization.
6) This is because it allows me to streamline operations in a generic way. The custom view has direct script access, but this is an exception, and it’s a pain. I may improve things by taking the user directly to the run script configuration and keeping the underlying implementation details hidden.
7) I forgot about it, but I noticed it and is on the TODO list.
And again don’t be sorry for the long post as your feedback is of a great help!
]]>