Differences

This shows you the differences between two versions of the page.

--- googlesummerofcode [2010/11/23 21:14] – glaubitz
+++ googlesummerofcode [2011/01/19 14:04] – glaubitz
@@ Line 68: / Line 68: @@
   * Port Sony MZ-RH1 Python upload script to libnetmd - Required expertise: **Advanced** (both C and Python knowledge)
-  Task: Port the python code in netmd/upload.py (see: [[netmdpython]]) to C, or better add the functionality of upload.py to the C library libnetmd (see: [[http://sourceforge.net/projects/libnetmd/]]). This involves both knowledge in Python and C. Porting the Python code of upload.py will add support for the populuar upload functionality of the Sony MZ-RH1 Walkman to libnetmd allowing users to backup all their old MiniDiscs with an easy to use GUI on all supported platforms. Since the future plan is to have two C libraries (libhimd for HiMD support and libnetmd for NetMD support) which are used by GUI applications or plugins for media players like rhythmbox, Songbird or amarok, porting the Python code of upload.py to the C library would fit perfectly into the roadmap of this projects software. **Benefit**: Users will be able to backup their old MiniDisc recordings with a free software on nearly all operating systems and not just Windows/32-Bit.
+  Task: Port the python code in netmd/upload.py (see: [[netmdpython]]) to C, or better add the functionality of upload.py to the C library libnetmd (see: [[http://sourceforge.net/projects/libnetmd/]]). This involves both knowledge in Python and C. Porting the Python code of upload.py will add support for the populuar upload functionality of the Sony MZ-RH1 Walkman to libnetmd allowing users to backup all their old MiniDiscs with an easy to use GUI on all supported platforms. Since the future plan is to have two C libraries (libhimd for HiMD support and libnetmd for NetMD support) which are used by GUI applications or plugins for media players like rhythmbox, Songbird or amarok, porting the Python code of upload.py to the C library would fit perfectly into the roadmap of this projects software. An existing, early implementation of this library can be found here: [[http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/mdlib.tar.gz]] **Benefit**: Users will be able to backup their old MiniDisc recordings with a free software on nearly all operating systems and not just Windows/32-Bit.
 === QHiMDTransfer ===
@@ Line 84: / Line 84: @@
     Task: Make the source code ready to be built and run on [[http://www.haiku-os.org|Haiku]]. Since we have not tested the software on Haiku yet, we cannot really say how much time and efforts it will take to get the software running. However, since there are already ports of all libraries by [[qhimdtransfer]] and [[libhimd]] (especially Qt) to Haiku, it should be feasible to get things running. This task also involves writing build instructions for Haiku (see: [[compilingonhaiku]]) which explain in detail what packages will have to be installed on a freshly installed version of Haiku to be able to clone the git repository and build the code from source. **Benefits**: Users of the Haiku operating system will be able to connect and use their HiMD devices with their operating system of choice.
+  * Versioning of QHiMDTransfer - Required expertise: **Basic**
+    Task: Leverage the version control capabilities of our //git// repository to automatically determine the version number of [[qhimdtransfer]] during build. For this, the //qmake// project file has to be extended to read the current version from //git describe// command, see: [[http://www.qtcentre.org/wiki/index.php?title=Version_numbering_using_QMake]]. For the case that the application is build from a tarball source, i.e. outside git, a fallback file called //RELEASE// should be in the root of the source tree to give the release version number. This makes especially sense since tarballs will always be produced for release versions while the development source stays within //git//. The version number determined should both be displayed in the about dialog of the application as well as used for the //automatic updates//. **Benefits**: A proper versioning is mandatory for every larger software project so QHiMDTransfer should have one as well. Also, it is required for the planned //automatic updates// on Windows and MacOS X.
+  * Integrate Automatic Updates - Required expertise: **Advanced**
+    Task: Extend [[qhimdtransfer]] with the functionality of automatic updates on Windows and/or MacOS X. This functionality is solely part of [[qhimdtransfer]] and allows for automatic updates of the installed software. Preferably, the updater works in a similar manner like the one in [[http://www.videolan.org/|VLC media player]]. Both the Mac and the Windows version offer a menu item "Check for Updates" which queries an URL specified in the source code or configuration settings for an updated version on the servers and automatically downloads them. Qt provides the required functionality to make http queries with the classes [[http://doc.qt.nokia.com/4.7/qnetworkaccessmanager.html|QNetworkAccessManager]] and [[http://doc.qt.nokia.com/4.7/qnetworkreply.html|QNetworkReply]]. Other implementations are welcome as well, even though Qt is always preferred as this is the framework the whole application is based on. A very easy and alternative implementation on MacOS X would be using and integrating [[http://sparkle.andymatuschak.org/|Sparkle]] with Qt, see: [[http://el-tramo.be/blog/mixing-cocoa-and-qt]]. In fact, there is also a Windows version of Sparkle available, called [[http://winsparkle.org/|WinSparkle]]. **Benefits**: Users will be able to automatically update the installed version of [[qhimdtransfer]] on their Windows and MacOS computers. (//Linux and other Unix-based operating systems don't need this functionality as they usually install all software over a package manager anyway.//)