Gui separation #57
Gui separation #57
Conversation
|
Thanks for the PR, can you please rebase your work and apply your
commits on top of the develop branch?
|
Previously playCtrl had part of gui handling, and functionality due to untoggle the play button when playback stops. Make play_once and play_many be just one function Before when many playbacks were needed, play_many was executed in its own thread and created a thread for play_once. But now just a "play_once" thread is created and it calls a playback how many times are needed
atbswp/control.py
Outdated
| self._stop_locks[0] = True | ||
|
|
||
|
|
||
| class PlayInterface: |
There was a problem hiding this comment.
This name might be confusing for a newcomer in the code base, since in OOP an interface is something with a well-defined meaning and more importantly that cannot be instantiated.
atbswp/gui.py
Outdated
|
|
||
| # play_button_ctrl | ||
| self.pbc = control.PlayCtrl() | ||
| self.pbc = control.PlayInterface() |
You can also just swap the names, I think it still makes sense. |
|
Just found a bug in infinite playback with these changes. Steps to
Expected behaviour: The capture stops instantly or at least stops after Observed behaviour: The capture keeps running forced to kill the |
That's weird. Here it's working fine: |
|
That's weird. Here it's working fine:
Try to record only the mouse and stop the playback with the
keyboard (if you didn't change the default shortcut it's F10 iirc).
|
|
In the meantime I implemented the event-based solution we discussed here |
Due to the refactoring of PlayCtrl, the playback hotkey was not working because its event was still being handled according to the previous way.
I'll check that. |
|
A rebase on top of develop would be great, I modified a bit the PlayCtrl, so you might have to solve merge issues. |
RMPR
force-pushed
the
develop
branch
2 times, most recently
from
ca8f39d to
49a7f0a
Compare
2 participants
So, class naming first? What about PlayGui?