Re: dogtail-devel [PATCH] Have focus() return bool indicating success
- From: Zack Cerza <zcerza redhat com>
- To: Cole Robinson <crobinso redhat com>
- Cc: dogtail-devel-list gnome org
- Subject: Re: dogtail-devel [PATCH] Have focus() return bool indicating success
- Date: Tue, 02 Oct 2007 12:38:51 -0400
Cole Robinson wrote:
Hi all,
This patch provides functionality I talked about in the previous thread.
Focus returns a boolean value indicating whether or not it managed to
focus on the specified component.
Hi Cole,
I have a better understanding of what you're looking for, now. Right now
we've got two different types of feedback for focus() failures: if
config.fatalErrors is true, we throw exceptions. If it's False, we just
print warnings. I see now that you're really just asking for a way to
programmatically tell if the call fails without having to deal with
exceptions. Seems pretty sane.
I think this is a useful thing to have but upon reevaluation its
probably not the cleanest way to determine if a gui component has been
created yet, since trying to focus on a non-existing widget causes (by
default) a lengthy backoff-retry loop. I wasn't hitting this in my
original crack at this patch as I was only testing with applications and
frames which don't have the backoff.
Since the backoff-and-retry code is needed to find objects that are
created in response to something you've done in a script, I don't think
there will ever be a way to make the case of the object simply never
showing up take less time to figure out, apart from tweaking
config.searchBackoffDuration and config.searchCutoffCount like you've
already done. Now, if you know you're about to execute some call that
shouldn't need any of that, you can always change the config values
right before the call, and change them back right after.
Regardless, this is still useful for test purposes. I have also attached
a small script to test this capability and show a basic usecase. Also in
this patch is a small change to the failure message when we do not
manage to focus on a component, making it more verbose.
The warning format looks better, too. But what if there was no roleName
specified?
Thanks,
Zack
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]