Last week in QtGStreamer – week 7

This week George merged some of the patches I have been working on to the QtGStreamer master repository, including support for Events. (*) He also wrote and committed a bunch of bugfixes and some improvements to the build files.

I started to work on some refactoring for our refCounted object, with an eye on addressing two issues that are common to other GStreamer bindings as well. So far things are promising, but this effort will take a little more time before it is ready to be merged.

And finally, the Kamoso team announced that they have completed the intial port to QtGStreamer. It is still a work in progress, but it is good to be able to collaborate on real world applications instead of just hacking on an “ideal” library API. We have already some adjustments in our long and public TODO list thanks to the input from Alex, and I wish the Kamoso team good luck with the project.

(*) As a comment to that, I still need to adjust my workflow to git: I use to prototype things and commit frequently in the local directory to avoid losing work, but this produces a not-so-good history as things are added and deleted… and do not end up in the final patch, just in the commit history. To avoid this I was rebasing and squashing, but the side effect of this for big changes (like the TagList support I was working on) is that it tends to be a very long and not-so-manageable merge request, which takes more time to process. I promised George I will send smaller, atomic patches from now on :). But generally I think that I am now finally getting into the git mode of thinking: it requires a mental adjustment for people like me that were used to CVS and SVN and were afraid of branching… Once you adjust there is no going back, I am glad KDE is migrating to it.

5 thoughts on “Last week in QtGStreamer – week 7”

  1. Useful tip:

    git checkout master
    git checkout -b myfeaturebranch
    # hack
    git commit -v -m “blah
    # repeat a few times
    git rebase -i master

    squash commits together as needed and all sorts of fun to make for a more usable history

    you can take this to a more insane level by splitting patches etc as well, but I don’t do that anywhere near as often as merging items together and reordering commits.

    (of course, DON’T do this on a public branch! rewriting history is not good)

    1. Thanks, that is more or less what I was doing… but I have this tendency of working on two features at the same time 🙂 You know, when you are stuck on something it is usually good to take a break and examine a different problem, and suddenly the solution appears naturally.
      So due to this at the end (after rebase/squash) I still need a way to separate this into 2 or 3 discrete commits, any tips on how to do that?

  2. git add -p is useful if you suddenly find you’ve been working on multiple things in the same checkout, but generally speaking, it’s better to force yourself to use branches more often if you can 🙂

  3. Two tips for git:

    1) stgit is the best thing ever for managing and polishing up a series of patches.
    2) checkout -p is really useful.

    That is all. 😉

Comments are closed.