I have a set of UI tests that are testing the state of a checkbox. There is no in-built checkbox element in swift, therefore I am using two images (checked and unchecked). When I am running the tests with the simulator open, everything works fine. When I am running the tests in the command line (needed for continuous integration) all the tests fail at the parts where images(assets) are included. Therefore the assets are not visible to UI tests (even though I gave them visibility in the image settings)
This is how I am testing the images:
tablesQuery.cells.containing(.staticText, identifier: item).images["checked"].tap()
Should I call the images in a different way? Is there any other option to make images visible besides checking the option to make images visible to the UI tests?
UI tests are opening the application itself and testing the presence of elements on it. Therefore, file paths are not visible to them (just like objects). A good trick is to set an accesibility identifier of the image every time the image changes state. Set the identifier with the same name as the image that is present and it should work.
accessibilityIdentifier = "checked"
Related
I've created a plugin and it works fine when I open the project but as soon as I press ctrl + s to save the scene for the first time since opening, the buttons on the plugin (Close_btn in this case) stop working
tool
extends EditorPlugin
var Key_Btn=null;
var UI=load("res://addons/Plugin_Name/UI.tscn").instance();
func show_UI():
get_editor_interface().add_child(UI)
func close_UI():
if(get_editor_interface().has_node(UI.name)):
get_editor_interface().remove_child(UI);
func _enter_tree():
Key_Btn=Button.new();
Key_Btn.text=" Key ";
Key_Btn.flat=true;
add_control_to_container(CONTAINER_CANVAS_EDITOR_MENU,Key_Btn)
Key_Btn.connect("pressed",self,"show_UI")
func _exit_tree():
close_UI();
remove_control_from_container(CONTAINER_CANVAS_EDITOR_MENU,Key_Btn)
This is what the plugin button looks like:
The UI that pops up when you press the button:
How do I solve this?
I tried your code. I did modify the UI as I describe below. However, with your code, at no point the UI or the button to open it stopped working.
This is what I tried (closing and opening the project between tests):
Saving, then opening the UI. Then closing the UI and opening it again.
Opening the UI, then closing it, then saving, then opening it again.
Opening the UI, saving with the UI open, closing it, then opening it again.
I tested on Godot 3.3, 3.4,, 3.4.3 and 3.5 beta 1.
Since you have a Button called Transparent Background. I had it set to Full Rect, and set the alpha of its self_modulate to make it transparent. Consequently it won't let me interact with anything in the editor…
To be able to close the UI, I had to add a script to Control Main that looks like this:
tool
extends Control
func close():
if is_inside_tree():
get_parent().remove_child(self)
Don't forget to make a tool script.
And I connected the press signal from the Transparent Background and Close_btn to the close method I added.
An alternative would have been to emit a signal from the UI and on the EditorPlugin have it connected to close_UI… I didn't do that because I didn't want to change your code. And since it all worked with that code, I can say that issue for you is not that code.
Also be aware that you load an instance the UI scene on the initialization of your EditorPlugin. In consequence…
Some modifications to that scene won't be reflected on the EditorPlugin until you disable and enable it again, or load the project again.
And I say "some modifications", because you will see reflected the modifications to the resources it had when loaded. For example, I can modify the script I attached, or re-import texture, and so on. However, if I replace the resource with a new one, I will see the old resource on the already loaded UI.
With that in mind, I tried modifying the script I attached to introduce an error and saved… And the UI still appears. Except, since the script I attached was not working, I could not close the UI, so I had to close Godot altogether.
In fact, the only way I have been able to make the button stop working after saving was by introducing an error in the EditorPlugin code and saving. I can only assume this is what happened to you.
I'm developing an ExtendScript CEP Panel for After Effects that makes changes to the individual frames of a layer's source video file through an external Python script. After changes are made to the source file, After Effects often does not correctly display the updates made and instead appears to be relying on the Memory and Disk Cache for pre-render previewing purposes. As more edits are made over the course of a few minutes, the preview eventually refreshes to display the changes, however this is not ideal for our editing purposes.
To resolve this issue programatically, I have tried two approaches:
The menu bar in the After Effects application itself features an option to "Purge > All Memory & Disk Cache..." which deletes all cached media and refreshes the preview instantly. While I did find a way to execute this menu option programatically using an ExtendScript function app.executeCommand(10200), the approach prompts the user to confirm the purge in a dialogue box and seems too computationally expensive to execute on each frame of a processed video.
Another approach I tried was programatically reloading the media using layer.source.mainSource.reload(), however this did not seem to resolve the issue either.
Is it possible to reliably refresh the main pre-render preview in After Effects programatically with ExtendScript to reflect changes in source media?
I'm working in a custom AOSP build for which I made an overlay that changes the device default theme. I've put those overlays in:
device/overlay/framework/base/core/res/res
Now I'd like to make a different overlay for the same build in such a way that changing a property will change the overlay that is applied.
So for example I set
setprop persist.brand brand1
And i see overlay1, then:
setprop persist.brand brand2
and see overlay2.
I've been digging into RRO and was able to change some overlays with custom apks but I have no clue how to tie that to a system property.
EDIT:
I found that I can achieve similar results by compiling rro apks using
include $(BUILD_RRO_PACKAGE)
in the Android.mk.
What I noticed is that in the build_rro_package.mk there is a comment that says
## Set LOCAL_RRO_THEME to the theme name if the package should apply only to
## a particular theme as set by ro.boot.vendor.overlay.theme system property.
What I understand is that I can group many rro packages into the same LOCAL_RRO_THEME name and then activate or deactivate them together using the ro.boot.vendor.overlay.theme property. If this is correct then it's exactly what I was looking for
The problem I face now is that when I set LOCAL_RRO_THEME with a different name than the LOCAL_PACKAGE_NAME the overlay won't show when I list them with:
cmd overlay list
This doesn't make much sense, but maybe I'm doing something wrong?
which AOSP version are you working on? There's a runtime overlay feature in AOSP 9(though Google has not publish the document yet, but it's there). On the earlier version, this can't be done because overlay system is done on compile time. If you really want to change resources on the runtime, you need to modify the framework, especially PackageManagerService
Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?
About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.
I am currently detecting elements by their accessibility labels when writing automation testing?
This causes a lot of problems.
Is this the correct way of detecting elements?
If not is there a better way to
detect elements without using the
accessibility label?
UI Automation uses the accessibility label (if it’s set) to derive a name property for each element. Aside from the obvious benefits, using such names can greatly simplify development and maintenance of your test scripts.
The name property is one of four properties of these elements that can be very useful in your test scripts.
name: derived from the accessibility
label
value: the current value of the
control, for example, the text in a
text field
elements: any child
elements contained within the current
element, for example, the cells in a
table view
parent: the element that
contains the current element
Instruments User Guide
Don't understand what you mean by "This causes a lot of problems.". Accessing elements by their accessibility properties in Automation Instrument is quite easy.
var button = UIATarget.localTarget().frontMostApp().mainWindow().buttons()["Cancel"];
Of course you can access elements also by their order on the screen. For example:
var button = UIATarget.localTarget().frontMostApp().mainWindow().buttons()[3];
will refer to 4th button (they are numbered from 0) label on your screen. But in case you will decide to rearrange elements on your screen in next version of the app this method can broke your tests, therefore accessing them by accessibility label is more safe.
In addition accessibility elements makes your app more accessible for people (with disabilities) who will rely on VoiceOver for using app interface- so using accessibility properties in making interface tests force you to build better accessibility for your app.