The user may want to use rig-remote while scanning, scanning should be a non blocking task

Marzona commented 8 years ago

Regarding a scanning action the user may want:

to change the signal level to trigger on
to stop the scan
to change the max
to change the interval
to change the delay

while the scan is ongoing. Now the tool is blocked until the scan task completes.

MaineTim commented 8 years ago

Got the fundamental code working for updating a scan option while the scan is running, just have to set up all the bindings for each widget and expand the code in the scan thread to cover all the options, and it will (hopefully) be ready to commit.

MaineTim commented 8 years ago

Pushed a batch of changes, mostly to ui.py, to support interactive scan parameter updates. All the entry widgets, and all the relevant checkbuttons, are now stored in a dict, and as they are updated, they are validated as needed, and previous values are stored. Relevant parameter changes are pushed onto a queue and passed to the scan thread, which has skeleton code to accept them. Next up is to flesh that code out and deal with some leftover details in the config. This update breaks pytest code at the moment, but it's running okay, so I'd rather focus on getting the code finished while it's in my head and then clean up the pytests. Let me know if you see any other stuff that's been broken.

Marzona commented 8 years ago

hello,

it's super fine, providing that you do that in a branch from devel, and you update the issue on github. More or less that was the same approach I was trying to follow (threading and queues). I'm looking forward to see how you managed the dict for the ui.

I'll take care of the bug reported by the user in a few weeks, as I'm out for work in US for a while now, than I'll be on vacation. Anyway I usually follow this logic:

branches:

master is the code that it's out/released (ideally used by customer, the only branch I support for creating issues for bugs discovered by the user) if a User is having a weird behavior I need to get the same codebase (or a tag (that I create only on master) or the master branch.) for reproducing it, creating a test, and then fix the code.

-devel is the collector of all the feature branches for new things, it's there for merging and fixing conflicts. Not expecting that devel works, expecting that what doesn't work has an issue on github. If there is an active work on that issue there should be a feature branch from devel to address the concern. -feature branches are created from devel branch. for every feature I create a branch from devel.. commit and merge in devel. when it's merged and no conflicts are left I delete the branch.

issues:

I try to create one for every new feature and every new bug. when I solve the issue I try to insert the commit that is carrying the resolution and the branch that I committed first.

does it make sense to you?

regards On Sun, Mar 13, 2016 at 4:30 PM, MaineTim notifications@github.com wrote:

Pushed a batch of changes, mostly to ui.py, to support interactive scan parameter updates. All the entry widgets, and all the relevant checkbuttons, are now stored in a dict, and as they are updated, they are validated as needed, and previous values are stored. Relevant parameter changes are pushed onto a queue and passed to the scan thread, which has skeleton code to accept them. Next up is to flesh that code out and deal with some leftover details in the config. This update breaks pytest code at the moment, but it's running okay, so I'd rather focus on getting the code finished while it's in my head and then clean up the pytests. Let me know if you see any other stuff that's been broken.

— Reply to this email directly or view it on GitHub https://github.com/Marzona/rig-remote/issues/6#issuecomment-195989970.

Simone Marzona

Linux registered user number: 509183

PGP key ID: 1024D/36F88CC3

Star Trek (2009):

Burly Cadet #1: Hey farmboy. Maybe you can't count. But there are four of us and one of you. James T. Kirk: So get some more guys and then it'll be an even fight.

MaineTim commented 8 years ago

Oops! I already pushed to code changes directly to devel. Be glad to undo that and put them up on a separate branch off of devel, as you suggest. Let me know.

Marzona commented 8 years ago

if it doesn't cause you too much trouble I would prefer.

the reason is that if I want to code a new feature I'll branch devel and I prefer to have something that "sort of works"

On Sun, Mar 13, 2016 at 5:00 PM, MaineTim notifications@github.com wrote:

Oops! I already pushed to code changes directly to devel. Be glad to undo that and put them up on a separate branch off of devel, as you suggest. Let me know.

— Reply to this email directly or view it on GitHub https://github.com/Marzona/rig-remote/issues/6#issuecomment-195999893.

Simone Marzona

Linux registered user number: 509183

PGP key ID: 1024D/36F88CC3

Star Trek (2009):

Burly Cadet #1: Hey farmboy. Maybe you can't count. But there are four of us and one of you. James T. Kirk: So get some more guys and then it'll be an even fight.

MaineTim commented 8 years ago

Sure. In this case, I'd made enough changes to the structure of the base code that I was worried about things getting out of sync between us, so I thought I'd push it directly. I'll go back and redo it.

MaineTim commented 8 years ago

Done. The code as it stands seems to run fine, but the scan thread doesn't do anything with the updates yet. In implementing that, I may change the way the initial parameters are passed to the thread over to a dict as well, so that the thread update code can reference the parameters more easily. I'll see which way looks better.

MaineTim commented 8 years ago

Hi Simone - I ended up spending some time doing more input validation of the scanning parameters in the new branch (basically forcing all the pertinent entries to have some kind of valid input, one way or the other). If you get a chance, I'd like to hear your thoughts on how the user interaction is handled (too intrusive?) and could be improved. I did end up changing over to passing a copy of the param dict to the thread, as it makes referencing things between the two threads easier.

Marzona commented 8 years ago

Hello,

I'm more than happy to do that, but I'll be able to do it only around April10 as until then I'll be very busy.

thanks and regards

On Wed, Mar 16, 2016 at 12:49 AM, MaineTim notifications@github.com wrote:

Hi Simone - I ended up spending some time doing more input validation of the scanning parameters in the new branch (basically forcing all the pertinent entries to have some kind of valid input, one way or the other). If you get a chance, I'd like to hear your thoughts on how the user interaction is handled (too intrusive?) and could be improved. I did end up changing over to passing a copy of the param dict to the thread, as it makes referencing things between the two threads easier.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/Marzona/rig-remote/issues/6#issuecomment-197089388

Simone Marzona

Linux registered user number: 509183

PGP key ID: 1024D/36F88CC3

Star Trek (2009):

Burly Cadet #1: Hey farmboy. Maybe you can't count. But there are four of us and one of you. James T. Kirk: So get some more guys and then it'll be an even fight.

MaineTim commented 8 years ago

Feature has been added to the devel branch.

Marzona / rig-remote

The user may want to use rig-remote while scanning, scanning should be a non blocking task #6