Significant LibreScribe Progress Made

As you may have noticed, I took a break from working on LibreScribe for a while, and the project looked as though it was abandoned. Well, it isn’t, and I’ve got tons of good news! Since the last time I wrote an update about LibreScribe, in late May, I made several incredibly significant changes. Some of these may not seem that exciting, but they are absolutely crucial in order to further develop the program. Some of these new features (such as retrieving and changing the name of the device) didn’t exist in libSmartpen at all, so implementing them required me to capture packets sent over USB and do a bit of reverse engineering. At first, I used the trial version of USBTrace, but I quickly realized that it wasn’t the tool for the job when I got notifications that I used more than my 256K data limit just by opening LiveScribe Desktop. To make it even less appealing, it costs $195 USD for a single license! That’s ridiculous! So of course, I did a bit of searching, and I found busdog, which does the same job (although using unsigned filter drivers that require modifying windows settings and rebooting several times) for free! Although getting it setup was significantly more frustrating than getting USBTrace working, it was well worth not paying $195, and it does everything I need it to, albeit without as nice of an interface. Anyways, here’s a list of significant changes I made:

  • LibreScribe no longer crashes when retrieving the list of applications installed on the device. This was incredibly frustrating when I was trying to develop it. It also filters out the LiveScribe Connect and System files, so that they are not listed if they are present on the device.
  • Instead of displaying a hard-coded list of notebooks, LibreScribe now retrieves the names of all of the notebooks actually in use on the device.
  • When a device is not present on the system, or LibreScribe can’t find it, the page tree now shows a “No Smartpen Detected” item, along with an brand new icon that indicates that no device is connected instead of the regular pen icon.
  • I added context menu event handlers to the page tree, so now when you right click or press the menu button, LibreScribe can display a menu of options relevant to the item you clicked. More work on this still needs to be done, but if you click the root element (the smartpen itself, or the placeholder when one isn’t connected), you will now see a new menu allowing you to rename the device, refresh the connection, or display information about the device.
  • When the device is unplugged or plugged in, the page tree and the applications/audio lists will now automatically refresh themselves.
  • LibreScribe now retrieves the name of the smartpen from the device, rather than defaulting to “My LiveScribe Smartpen”. It can also set the name of the pen, but this feature is still a little bit buggy (it won’t brick your device, so it’s safe to test). Interesting discovery: In the LiveScribe desktop software, you can set the name of the pen to anything up to 50 characters. This does not mean that the device doesn’t allow more than that, it’s just a ‘soft’ limit in the LiveScribe desktop software. There probably is an actual limit, but I was able to set the device name to almost a paragraph of text, including every symbol you can type on a standard US keyboard, and retrieving it from the pen worked perfectly. The pen stored the entire thing, and returned it when I checked the name, although it did not display the entire string when I turned the device on, just the first part of it. The string of text I tested was “~`!@#$%^&*()-_+={}[]:;”‘<>?/,.\ Testing the maximum name length for a LiveScribe Smartpen… I wonder if I could fit a paragraph in here…? You have got to be kidding me… I typed this much and it STILL works? That’s incredible. There’s virtually no limit to how long the smartpen’s name is. I can’t believe I can set and receive values this long! I’m speechless…“. Needless to say, you can store almost anything in the name of the Smartpen. I wonder how the LiveScribe desktop software would react if it tried to retrieve this string.
  • I added a dialog box to rename the device, as well as another dialog box to confirm the new name.
  • LiveScribe no longer crashes when removing or connecting a smartpen while the program is running.
  • I merged in the inline functions written by Luis Pedro Coelho on his fork of LibreScribe, which are a better implementation of device type checking than I had
  • Tons of new debugging output was added. You can see this output on the console. This makes figuring out what went wrong in a crash so much easier.

Remember, LibreScribe is still alpha quality and should not be used in a production environment. If you have any issues or suggestions, feel free to file a bug report. Or, if you’re skilled enough, I’d appreciate it if you fixed the bug yourself, and submitted a patch. Ah, the benefits of open source coding! This is only just the beginning. Expect tons of new enhancements and bug fixes over the next several months.

FiOS WEP Key Calculator Website Updated

It’s been a very long time since I last worked on my Verizon FiOS WEP key calculator website. Over the last few days, I decided that it looked dated, and I decided to make it look a lot cleaner, using the magic of CSS3. I removed several images from the site, such as the header image, and the background gradient image, and I replaced them with a pure CSS-based approach, reducing the total page size from just above 12Kb to only 6.5Kb, and significantly reducing the already low amount of time taken to load the page, as well as making it feel more modern. The page loads, literally, almost instantly now, even on a dial-up connection, which is rather impressive if you ask me.  I think visitors will like the new look of my FiOS WEP key calculator site, and if you have any feedback about it, feel free to leave a comment on this post.

LibreScribe Progress Update

Since my last post, I have made a lot of progress with LibreScribe. Just a few commits ago, LibreScribe gained the ability to retrieve a list of installed applications on the device, and add them to the list in the applications tab. I also fixed several other significant issues, including:

  • When the smartpen is connected/disconnected, the application no longer crashes, and the status is automatically refreshed
  • Device storage usage is now displayed in MiB instead of in bytes. This makes it a lot less confusing how much space is remaining on your smartpen.
  • A bug, where the Echo Smartpen was detected as an “unknown LiveScribe Smartpen” in certain cases was fixed.
  • All absolute paths have been removed from the project. All resources are now referenced using relative paths.
  • wxFormBuilder has been replaced with wxSmith. The entire user interface has been recreated from scratch (although it’s very similar to the old interface, intentionally)
  • Many C++ source and header files are no longer necessary, so they have been removed, and merged into other files. This makes the codebase a lot more maintainable.
  • Duplicate udev events (such as multiple add events of the same device) are ignored now. Previously, we ended up refreshing the device information up to four times in a row because of duplicate events. This significantly reduces the delay between plugging in a device and seeing a response on the screen.

There are still tons of issues that still need to be fixed before LibreScribe becomes usable in a production environment, but I’ve been steadily making progress, and I hope to have something useful out soon.

Major Bug Fix in LibreScribe

A lot of work on the LibreScribe project has been accomplished since I first wrote about it. Just today, I fixed a major regression which was preventing the device information dialog from being displayed. In addition to that, I now have more work done on the interface, so that when the windows is resized, most of the elements will scale properly to fit the new size. Another major change I made was setting up the layout of the “Audio” and “Applications” tabs, so that there are now lists, with data split into columns. These changes mark a significant improvement in the look and feel of LibreScribe, but it’s only the beginning. Expect a large number of major changes in the not-too-distant future.

LibreScribe, My Latest (and Most Challenging) Project

Image representing Livescribe  as depicted in ...
Image via CrunchBase

Over the past few days, I’ve been working on attempting to code an open source Smartpen Manager for Livescribe devices, based off of the work done in Steven Walter’s libsmartpen project, which hasn’t been updated for months. The project is called “LibreScribe”, and the source code is already on github right now. The code will be written primarily in C++, with limited functionality (such as threads) from the upcoming C++0x standard, and it will use wxWidgets for the graphical user interface, which will be built using wxFormBuilder, attempting to follow the Tango guidelines as close as possible. So far, I have only scratched the surface of all the coding that will be necessary, so it would be great if some of the coders reading this would step up to the plate and help out. Even small things, such as documenting functions, adding comments, ensuring source code style consistency, and making it easier to maintain the source code are incredibly important. Right now, there’s still tons of work to do. So much, in fact, that it’s actually easier to list what’s done than what’s left to do. Right now, I’m focusing on fixing bugs and writing functions to check the status of the connected Smartpen. To be more specific, some of the most important bugs at the moment include:

  • When the user plugs in or unplugs the device, the background thread updates the status of the device behind the scenes, but nothing is reflected in the user interface.
  • Clicking the “Device Information” button twice without closing the program results in a segmentation fault.
  • Currently, only LiveScribe Pulse devices are detected. LiveScribe Echo devices should work, but I can’t check the USB product ID property of them without physical access to one.
  • The program is not currently capable of retrieving the name of the Smartpen. More OBEX analysis is necessary to determine how the official desktop client retrieves the name of the Smartpen.

Once I have all of these bugs fixed, I will begin working on adding more of the code from libsmartpen into the project, fixing up existing code, and writing new code. This is probably one of the toughest coding projects I’ve started, but I enjoy the challenge, and I hope to create something genuinely useful to the open source community, improve my own coding ability, and learn new things. I frequently push changes to github, as long as I don’t notice any significant regressions, so you can track my progress in almost real-time. At the moment, the user interface is far from being finished (link is a screenshot), but it’s not too bad. Also, feel free to fork the code base, and make improvements.

A Simple JavaScript Dice Rolling Site

Portable Network Graphics

Image via Wikipedia

I haven’t been blogging very much about my recent projects lately, and I’ve been putting off writing about this one for a while, but I finally decided to share this. I recently created a JavaScript + SVG dice rolling demo site, roughly based on the work done by Taylor Copeland on his JavaScript dice implementation, as well as a lot of new code written by me, and part of an HTML5 test suite written by Niels Leenheer that detects whether the user’s browser supports inline SVG or not. This code should run just fine on all modern browsers, and if it fails to detect support for SVG images, it should fall back gracefully on pre-rasterized PNG images. The project is open-source, and can be downloaded in it’s entirety as a 7z archive. The source code of the page is dynamically generated using PHP, and it accepts GET parameters that affect the page returned. Also, if you look through the source code, you might just find a secret GET parameter or two… ;)

EDIT: Somehow I managed to forget to link to the actual site, even though I linked to the 7z download. Click here to visit the site. Sorry about that!

Releasing “Capture The Flag”, a simple Java-based game

Capture the flag is the name of a game I programmed in a small team in a Java class in high school. Because I haven’t released any new or interesting content in quite some time, I decided to share this project on my blog, as well as having a copy of the project on a GitHub repository. The project is no longer maintained, but I may decide to clean up the code a bit in the future, or release some bug fixes. The game is written in Java, and it should work just fine on Microsoft Windows, as well as any modern version of Linux using Pulse Audio, as long as a reasonably new version of Java is installed. The game has been tested to work with both OpenJDK and Sun Java 6. I’ve been rather busy with a lot of work lately, but I felt that posting a copy of this code was a good idea. It is likely that some of the assets in the project are copyrighted, as we were looking to create a game that worked well for educational purposes, rather than create a commercial-grade videogame, so all assets [images and audio] are copyrighted by their original owners, and we are not taking credit for creating them. Most of the game’s resources are embedded into the actual source code using Base64 encoding, rather than having separate files for these resources. Anyways, the project is available on GitHub, and you are welcome to fork the code, just let me know if you decide to do so, as I’m interested in knowing if anybody actually uses this in another project. Not all features in the code work properly, but if you leave the code as it is and compile it, it will work just fine. In addition to myself, the game was also designed and programmed by Rhyan Smith, Justin Gompers, and Manny Castillo. If you hit F1 during the game, you can see a list of pieces and game rules.  Enjoy! :)

Working on creating my own “App Store”

Over the past couple of weeks, I have been working on coding my own “App store“, as an alternative to the Android market. It’s been a lot of work, but at the same time, it’s been fun and challenging, and it really helped me get reacquainted with my long-lost PHP skills. Although there are still quite a few problems to solve (such as how users will get updates, and how application purchases will be done), the site itself for the store is finally starting to look great, and in the not-so-distant future, it should serve as a pretty good way to distribute the free versions of my applications. In order to make the user experience as good as possible, I will also be incorporating some of the new features introduced in HTML5. The site as it is takes advantages of exciting new CSS3 techniques, JavaScript, and web fonts.  Personally, I believe that the site will look great when it’s finished, and I can’t wait to release it! There is still a lot more work to be done, but I believe that I have reached a significant milestone in the process of releasing this to the public, and I realized that I haven’t written very much for quite some time now, so I wanted to let you guys know that I’ve been busy coding, and I have no intention of giving up coding. Stay tuned for more updates!

Fun Fact: This post contains the brand new official HTML5 logo, which practically just came out.

I’ve Been Completely BANNED From the Android Market

In case you were wondering where all of my applications went, Google decided to suspend my entire account and all applications on it on December 29th, 2010 at 8:46 PM (UTC). This is very disappointing, frustrating, and depressing, especially since I am no longer allowed to upload any new Android applications. I believe that Google went too far and should have only suspended the infringing applications instead of banning my entire account, since I had many legitimate, non-infringing applications on it, such as EliteGuard, Currency Converter, Simple Dice, Find the Mouse, and InfiniteSMS (I don’t believe simply removing the SMS sending limit qualifies as infringement). Here is the message I have received from the Android Market Support Team:

Hello Dylan,

After a regular account review, your Android Market Publisher account has
been suspended due to multiple violations of our Terms of Service. You may
view these terms here:

http://www.android.com/us/developer-distribution-agreement.html (Section
4.4).
http://www.android.com/market/terms/developer-content-policy.html

Please note that Android Market Publisher suspensions are associated with
developers, and may span multiple accounts.

We are not inclined to reverse this decision.

Regards,
The Android Market Team

An hour after receiving this message from Google, I decided to try to appeal the ban, with an apology letter directed toward the Android Market team. As of January 3rd, 2011, I have not received any reply from them at all. A copy of my response to them is below:

Dear Android Market Support,

In addition to the applications that infringe upon your terms of service, I had many ‘legitimate’ applications listed that cause no harm to any devices or networks, or infringe on your terms of service in any way. I would like to appeal your decision to suspend my account, and I would like to request a specific list of infringing applications and how they infringe upon your terms of service so that I can remove those particular applications from the market if I am given another chance to distribute my applications on the Android market. Although you say that I have multiple violations of your terms of service, the only application I wrote that I am aware may potentially infringe on your terms of service is “EliteBomb”, my text-bombing application, of which I had multiple versions listed. When I uploaded this application, I was not aware that it was against your terms of service, and I would like to apologize for any misunderstandings. I realize that you don’t have to unsuspend my developer account, but given another chance, I would like to keep my applications that do not infringe on your terms of service listed, and upload more applications in the future. I have no intention of abusing the privilege of uploading Android applications. I will not upload another text bombing application, given the chance, without your prior consent.


Dylan Taylor
http://www.dylanmtaylor.com/

Unfortunately at this point, it doesn’t look like I will be able to get my Android market developer account back, and this is really frustrating and depressing. I truly would like to continue to develop and support my applications for Android, but it does not look like Google will allow me the privilege of doing so, so I shall begin to look into alternative means of distribution. This is a truly disappointing and sorrowful moment for me. :-(

EliteBomb SUSPENDED From Android Market

Google has decided to pull all three versions of EliteBomb, “Lite”, “Plus”, and the regular version without any formal notification what-so-ever. In fact, I didn’t even realize that my EliteBomb applications had been pulled this holiday season until I was notified by some of my customers. All I know for sure is that my last EliteBomb Plus order is dated December 22, 2010, which means that the applications were likely pulled between the 22nd and the 23rd. I have no intention of discontinuing support of the applications that have been pulled. I contacted them regarding this matter, but unfortunately, because of the holiday season, or some other unknown reason, I have yet to receive a response from them despite emailing them about it several days ago. Originally, I decided to wait until I received a response from them before writing up anything on my website, but out of frustration and due to emails from some of my over 45,000 EliteBomb users, I decided to post this anyways to let you guys know what happened. I hope to have EliteBomb back up soon, but if that is not possible, I will likely release a modified version that is acceptable on the Android market, under a different brand name. I was thinking along the lines of “Phoenix Text Bomber”. ;)