Post events in non-main thread

[wolfc01]

Hello Stuarteberg,

we are using your mechanism. Question: is there are reason why at playback time the events are not posted on the main thread? Now a secondary thread is utilized for that.

Thanks in advance for your answer!

Best regards
Carl.

[stuarteberg]

Hi Carl,

we are using your mechanism

Interesting! Is it working well for your app? I'd be very interested to hear what type of app you're planning to use it with (if you're allowed to share any details).

is there are reason why at playback time the events are not posted on the main thread?

A separate thread is used to schedule event posting because I think it simplifies the design. In Qt, all events are processed in the main thread, so if the event posting logic were also in the main thread, I would need to periodically call my event-posting code somehow (possibly extra QTimer instances), which would add extra events to the system. I would have to be very careful to make sure that such those new events were ordered correctly with respect to the other events in the system. I think it would be more complicated, but I admit I never tried it.

On a general note: I never polished this code base (hence all the documentation TODO items in the readme). My app is fairly large and complex. In my app, new widgets are frequently created, destroyed, shown, and hidden. The recording and playback system worked reasonably well, but it wasn't quite deterministic to use on a Continuous Integration server, so I ultimately set this whole idea aside and never came back to it.

As you can see, getting the whole thing to work at all required a lot of little hacks. Before I wrote this, I always wondered why no one had published such a tool before -- it seems like such an obvious idea. Now I see why. Good luck! If you make any improvements, please consider submitting a PR back to this repo.

Best regards,
Stuart

PS -- I have now added a license to this code so that you can use it without any legal concerns. (It's a BSD license, which is compatible with PyQt's GPL_EXCEPTION.txt.)

[wolfc01]

Hello Stuart,

Thanks for your reply. Exactly the determinism issue is hindering to use
your mechanism in an ci environment.

We are now trying to do all in the mainthread.

Can we ask some qestions in the future? I think you have extensive
knowledge regarding this kind of stuff.

What kind of automatic testing tooling are you using for testing gui
related apps?

Best regards
Carl.
Op 27 mei 2016 18:38 schreef "Stuart Berg" [email protected]:

Hi Carl,

we are using your mechanism

Interesting! Is it working well for your app? I'd be very interested to
hear what type of app you're planning to use it with (if you're allowed to
share any details).

is there are reason why at playback time the events are not posted on the
main thread?

A separate thread is used to schedule event posting because I think it
simplifies the design. In Qt, all events are processed in the main thread,
so if the event posting logic were also in the main thread, I would need to
periodically call my event-posting code somehow (possibly extra QTimer
instances), which would add extra events to the system. I would have to be
very careful to make sure that such those new events were ordered correctly
with respect to the other events in the system. I think it would be more
complicated, but I admit I never tried it.

On a general note: I never polished this code base (hence all the
documentation TODO items in the readme). My app is fairly large and
complex. In my app, new widgets are frequently created, destroyed, shown,
and hidden. The recording and playback system worked reasonably well, but
it wasn't quite deterministic to use on a Continuous Integration
server, so I ultimately set this whole idea aside and never came back to it.

As you can see, getting the whole thing to work at all required a lot of
little hacks. Before I wrote this, I always wondered why no one had
published such a tool before -- it seems like such an obvious idea. Now I
see why. Good luck! If you make any improvements, please consider
submitting a PR back to this repo.

Best regards,
Stuart

PS -- I have now added a license to this code so that you can use it
without any legal concerns. (It's a BSD license, which is compatible with
PyQt's GPL_EXCEPTION.txt.)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPRCJ-aPYVQ3nxWagOLqZwtu9kNO4nwks5qFx31gaJpZM4Iog-i
.

[stuarteberg]

Exactly the determinism issue is hindering to use your mechanism in an ci environment.

Sorry to hear that. Are you encountering a lot of "Couldn't locate object" errors?

We are now trying to do all in the mainthread.

I'd be very interested to see what you come up with!

Can we ask some questions in the future?

Of course. I think this thread we have here might be a good place for future discussion, but feel free to email me (bergs -at- janelia.hhmi.org)

What kind of automatic testing tooling are you using for testing gui related apps?

At the moment, our UI testing is not great. We have some hand-written tests that call UI functions explicitly (e.g. myWindow.myButton.click(). I would prefer to get the event capture system working really well, but I don't have the time to spend on it.

[wolfc01]

Hello Stuart,

We have progress:

• essential for determinism is adding a "syncstate" function in player and
  recording part. At recording time we have a new button "savestate" which
  saves the state of all widgets. State is a set of some relevant properties
  of the widgets. When saving the generated script we now have besides the
  post_event function also a sync_state function. The state in this function
  contains serialezed state of the aforementioned properties. Thus between
  the post_event functions there are save_state functions now.
• we made all running on the mainthread on playback time. The postevent
  function from generated script adds the event to a queue. The sync state
  function repeats processEvents until state is there. We have a qtimer (0)
  which post an event from the queue when the object is there and isEnabled
  (). In between an postevent we let qtimer fire 20 times (why this is needed
  is not understood yet).

We are running a long term test now to see if it deterministic.

Later on i will send the files of our solution.

Best regards
Carl
Op 27 mei 2016 22:04 schreef "Stuart Berg" [email protected]:

Exactly the determinism issue is hindering to use your mechanism in an ci
environment.

Sorry to hear that. Are you encountering a lot of "Couldn't locate object"
errors?

We are now trying to do all in the mainthread.

I'd be very interested to see what you come up with!

Can we ask some questions in the future?

Of course. I think this thread we have here might be a good place for
future discussion, but feel free to email me (bergs -at- janelia.hhmi.org)

What kind of automatic testing tooling are you using for testing gui
related apps?

At the moment, our UI testing is not great. We have some hand-written
tests that call UI functions explicitly (e.g. myWindow.myButton.click().
I would prefer to get the event capture system working really well, but I
don't have the time to spend on it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPRCOx1AVZr2DDGjLqUVOg9eUtzeH9Tks5qF05DgaJpZM4Iog-i
.