TrueJournals

I’ve been working on it for a while, but since I’ve made the code public, it’s time for an official announcement: libptp++ is ready!

When working on my project for senior design, part of the challenge was being able to communicate with a Canon camera, and be able to send commands to CHDK.  There’s an excellent python library that does the job, but running on the Raspberry Pi, it was really slow.  After doing some more benchmarking and testing, I determined that Python was just going to be slow on the Raspberry Pi, and it was time to move on to a different language.

I decided to pick C++ for a few reasons:

1. It’s just about as fast as you can get.  I’m sure there are people who will say that it’s not quite as fast as C, but it’s going to be pretty close.  Having a compiled language is much faster than any interpreted language.
2. It’s object-oriented.  I felt that pyptp2 had a great API, and was already accustomed to using it.  With an object-oriented language, I could simply implement this existing API.  I also feel that objects provide great assistance to the programmer.
3. I wanted to.  I’ve been wanting to get into C++ and see what the syntax is like and what it’s capable of, but haven’t had a good chance to.  This provided me this opportunity.

So, I started work on building a PTP library in C++.  I’ll note here that there IS a PTP library in C.  However, I had a lot of trouble figuring out how to use this library (it’s heavily tied in to the ptpcam program it comes with), and all CHDK extensions I could find were poorly documented, and, again, tied heavily to some other program.

Having said all that, I’m very proud with where libptp++ is.  It’s as functionally complete as I need it for my senior design project, but I’m still working on expanding it.  The CHDKCamera class it provides is mostly complete, but the PTPCamera (for camera’s that don’t or can’t run CHDK) is unimplemented.  Going forward, I’ll need to look into what functionality that class will need to provide.

I’ll also note that I did my best to document everything using Doxygen strings.  One of my complaints about libptp2 is that it’s poorly documented, so I don’t want to run into the same trap.  Run libptp++ through Doxygen and you’ll get some wonderful documentation.  There’s even an example included in there!

I’m releasing this code under the LGPLv3.  Basically, this means (to my understanding) that you can use it however you want, as long as you release the source code.  Additionally, the LGPL allows this library to be included in commercial products.  Again, though, the source code must be provided.

I hope someone else can get some use out of this library!  It’s certainly not perfect, but its current state is a good start.  I encourage anyone that finds a bug to file an issue on GitHub, or fork the project, fix the bug and send in a pull request!

https://github.com/TrueJournals/libptp–

Printing form responses in Google Drive is an awful experience.

That’s a strong statement, but it’s the truth.  Forms in Google Drive are used for so much more than simply numerical responses, with some being used for surveys, sign ups, and other data that just doesn’t fit properly in a spreadsheet.  Yet, that’s the only format Google presents this data in.  While spreadsheets are fantastic for numerical data analysis, they do little for analysis of open-ended survey responses.

And this statement even makes the assumption that you’re attempting to read the data off a computer screen.  Want to print out the data to keep a hard copy (or just to reduce eye strain from your computer’s back light)?  Forget it!  You can attempt to print the responses in landscape, but you’ll end up with an unorganized mess of papers which doesn’t really solve the original problem.

So, how can we get the data from the Form into a format that’s pleasant to read, and easy to print?  We use a script!

The Google Apps scripting engine is amazing.  I’ve previously used it to create rudimentary conditional formatting in Google Docs.  Now, I wanted to play around with it more and generate single page(-ish) reports of individual responses to a Google Drive Form.  I say “-ish”, because the script doesn’t guarantee a single page.  The end length is simply based on the response length and number of questions.

So, how do you use this script?  Just find it in the script gallery!  Searching for “Report Generator” should find the script and allow you to install it easily!  Once installed, a new menu — “Report Generation” will pop up on your spreadsheet.  Simply select the row you want to generate a report for, and choose “Generate Single Report” (or generate all at once!).  In a few moments, you’ll have a new folder in your document list, and a doc and/or PDF of the report.

The script has a few configurable options, which are for the most part self-explanatory.  I’m working on getting some documentation up at the script’s help page, but that may take me some time.  I also plan on adding more features to the script: the ability to change the folder name, change the resulting document names, change the formatting of the output, etc.  I’ve never published a script to the gallery before, but I’m hoping I’ll just be able to update the script when I have new features ready.

So, if you’re looking for a good solution to printing out responses to Google Drive Forms, check out “Report Generator” in the script gallery!

At my work, we use Web Help Desk to track support tickets.  It’s a very nice, very slick piece of software, and from my understanding, version 10.2 implements an API going forward.  Unfortunately, we use version 10.1.10.1, which doesn’t have the same API.

The problem I ran into was this: often, there are other tasks to be completed, so I’m not just staring at the WHD ticket queue the entire time I’m at work.  However, if a client logs a ticket, I have no way of being notified without going to the web help desk page and checking manually.  This results in one of two things happening: either I check the ticket queue every few minutes, breaking my workflow on other projects, or a ticket doesn’t get responded to for a while.

I wanted a way to be notified of new or updated tickets that pop up without having to continually go back to the WHD tab of my browser to actually check for new or updated tickets.  Unfortunately, without an API, I thought this was going to be difficult.  Until I found this: a WHD Notifier for Chrome.

However, this still didn’t quite achieve what I was looking for.  While this did provide me with a notification of the number of new or updated tickets within the browser, it didn’t notify me when this number changed. So, I still had to watch my web browser, and even then, continually check this small, inconspicuous number in the top-right corner of my screen.  Since Chrome extensions are simply Javascript, HTML and CSS, I decided to try my hand at modifying it to better suit my needs.

Here’s the list of things I needed:

1. Pop-up notifications of a change in the number of new/updated tickets (like in Gmail).
2. The ability to not save username and password.  The computers share a single profile between multiple users, so I don’t want individual passwords saved past the browser session.
3. (Optional, if I could figure it out) Grabbing login info from the WHD web login, so you don’t have to go into the extension options every browser session.

After some coding, a lot of trial and error, and a lot of research, I was able to meet all three goals. If you’d find it useful, you can download WHD Notifier version 1.5.  Simply configure it with your WHD URL, choose what to display/be notified of, and you’re good to go.  If you login to web help desk, the notifier will grab that login information and start updating.

If you’re interested in seeing the source code for this extension, you can find a zip of the source here.  I’ll see if I can throw it up on GitHub later today or this weekend.  There’s some interesting things being done here — submitting the login form in WHD sends a call to forms.submit() instead of going through the normal submit procedure — this means that I couldn’t simply add an onsubmit handler to capture the login information.

Instead, I inject another piece of JavaScript into the page which overrides the submit() method for all forms.  This calls chrome.extension.sendMessage to message the background page with the username and password, then proceeds to call the submit() method I had overridden.  You can find the form handling things in autoLogin.js and autoLogin2.js.  I had to inject autoLogin2.js on the page because chrome content scripts aren’t allowed to override prototype methods.

If we ever update our WHD installation, I’ll try to update this extension again to use the new API — I should be able to add some more features with that, too.  For now, this should work for all versions of WHD 10.0.8 or later.

Update: Code is now on GitHub