added sample for tkinter live-view&capture and retrieving supported framesizes/intervals

jnohlgard / python-v4l2capture

Python extension to capture video with video4linux2 (fork of https://launchpad.net/python-v4l2-capture)

133 stars 83 forks source link

added sample for tkinter live-view&capture and retrieving supported framesizes/intervals #11

Closed emdete closed 9 years ago

emdete commented 9 years ago

this branch mainly contains two features:

capture program with tk gui (mainly developed to be used with a cheap slide scanner where you want to change resolution while live-view and capture)
add getters for frame sizes and intervals

if needed i can reduce the commits and separate the two features into two branches/pull requests.

regards, michael

jnohlgard commented 9 years ago

You need to get rid of the indentation changes, it is very difficult to review when every line of the file has been changed.

emdete commented 9 years ago

Hi,

you are right, i changed the code formatting alot as i saw it was not consitent (and as a python developer i agree that whitespace matters). so i edit history to have this commits:

run indent on c code
add getter for frame size & interval
add new feature to sample code
collect v4l library switch to one location

the whole reformatting is now a single step done by indent -br -brf -brs -nce -nut -ppi 2 v4l2capture.c and my changes now are quite clear. i also renamed the README as it is markdown and with that extension is properly displayed in github. i removed files that are not needed anymore. i hope that is fine with you.

regards, michael

jnohlgard commented 9 years ago

You need to make a separate pull request for the indentation changes, if you look at the "Files Changed" tab of this PR, you will see that it is quite difficult to review this when everything has changed. Don't mix scripted automatic indentation and whitespace changes to the whole tree with functional changes.

Either:

Create a separate branch, do all the whitespace changes you like, open a new PR, then rebase this change on top of that indentation change branch.

Or:

Make all the functional changes to the current master, without touching the indentation of unrelated functions. Then make another branch based on that PR, run indent and make a new PR with the indentation changes.