This is a major update of the client. The UI has been completely revamped and moved to the browser. Clicking on the history menu item or the configuration menu item now opens the default browser window. It adds quite a lot of options on searching/sorting/filtering of the call records. Here are few screenshots of it.
The recordings page shows all the records found on the local machine in the main area. Upto 10 records can be listed at a time and pages are shown for navigation. Clicking on the play button launches an inbuilt flash player which plays back the file. Clicking on the show details link reveals all the metadata of the call records (eg. date recorded, size, duration etc.). The rename and edit tags link can be used to edit the details. The upload link queues the files for upload (only if your client is associated). The delete link removes the record from your machine.
The sidebar shows the options for batch file operations, searching, sorting and filtering. Now multiple records can be selected at a time and either deleted or queued for upload. The records can also be sorted in ascending/descending order of time, size and duration. The default is newest. The search dialog can be used to locate a record by name or tags. The filter can be used to narrow down the listing by a specific criteria (the possible ones are duration, size, uploaded, date and recorded by).
The cool thing is that search, filter and sorting and be applied one after the other, in any order. So you can locate a call record by name ‘echo’ recorded on a ‘Sunday’ and ordered by ‘increasing duration’. 🙂
The configuration page is an exact replica of the the configuration dialog. It has five tabs, for general options, update settings, recording params, association and advanced. Each of these tabs show a subset of the settings in that particular group.
This is our first step in integrating the desktop client with our web application. Going forward it will be a seamless experience. All the services offered by our web application (sharing, transcribing etc.) will now be delivered through this particular interface.
Apart from the UI change, several bug fixes also went into this release. One of the major bug fix was the issue of connection getting lost between the client and Skype because of which the calls would not get recorded automatically. Now we have added a keep alive mechanism to keep the connection going.
Another major bug fix was the long startup time it used to take if you had a large number of call records stored. That used to happen because of the flat xml file database we used earlier. Now we have moved to sqlite database. So once all your files are migrated, the next startup will be very fast.
Please update now. And please send us your feedback on the UI changes.
Update: Here’s a detailed post on the technology behind the browser based UI. Have a look if you have questions regarding it.
Just completely removed Call Graph. Providing a Javascript interface via your website is a security disaster for me as it effectively allows you (or an intruder stealing the JS) access to the contents of my hard disk. Sorry this is private information. Will be warning other Skype users if this doesn’t change.
The js only provides a presentation layer on top of the data you have on your hard disk. If you do not want the interface, you can always open your call recordings folder and access your data from there.
On the point of stealing, we do not send any data from the local computer anywhere. Not even our servers. Your private information stays private.
We’ll be putting up a more detailed post on this change and go into the reasonings, pro/cons. Please look it up once its done.
[…] The end effect is that you seem to be browsing a page on our web server but somehow magically your local data turns up in the browser! Sounds scary right. How did my data end up being on your server? Did we steal it? […]
http://crims.callgraph.in/blog/2008/09/the-hybrid-desktopweb-application/
Please have a look and comment.
But by providing a JS interface to the CallGraph app you’re essentially letting JS access data on my computer. It doesn’t have to be your webpage it could be a rogue page running a modified version of your own JS and then passing data back to the rogue page’s server via AJAX.
And by the sounds of things you’re making your web-server able to serve the whole of MY computer to a third party website since you don’t know which directory I’m storing the .mp3 files. Normally JS is sandboxed and has no disk access except to cookies so XSS has access to cookies. Yes, Google uses XSS but to access data on ITS own computers, not on my computer. Opening up the whole of my computer to your or rogue servers via JS/Callgraph is not something that is acceptable to me.
We dont open up the whole computer from our embedded web server. It actually does not serve anything other than the requests that can come from our JS. You can try it out for yourself to check.
As we pointed out here, only our JS knows where to connect to the CG web server. Others will have to intercept the URL to know the port number.
The default directory where your records are stored is My Document\My Call Graphs. You can also change it to whatever you like from the config page. We are also planning to introduce a menu item which will open the folder instead of the web page. It will be added in the next release.
Hi, I have Windows vista Ultimate with SP1, i’d just installed Call Graph and i receive the following error message “Initialization Failed”.
Please advise.
Please uninstall the Call Graph, download a fresh copy from our website and try installing that. If it does not work drop me a mail directly at rajiv at callgraph dot in.
[…] update fixes an issue with our last update 1.1.0.0 where the migration to Sqlite DB used to fail in cases where the call record name had Unicode […]