Pausing Vynk for now

written by cryzed, on May 21, 2010 9:35:00 PM.

Now that was quick – didn’t even last longer than my usual projects. The reason I’m pausing Vynk for now is because the java.awt.Robot class apparently isn’t able to send anything besides a subset of the ASCII charset characters to non-Swing windows.

Well… it is possible, but no one in their right mind would even think about using these workarounds. For Windows operating systems that would for example be holding down the CTRL-key and entering some fancy combinations on the numpad just to get an umlaut of some kind let alone accented characters.

Maybe I’m expecting too much – but I also couldn’t find any way to convert a character to a keycode so I could easily send it with java.awt.Robot. That’s why I ended up creating another ugly workaround to get the basic alphanumeric characters into a nice dictionary and additionally had to create a seperate dictionary for special characters so I could later access them easily.

KEY_EVENTS = dict((key[3:], value._doget(None)) for key, value in
                  KeyEvent.__dict__.items() if key.startswith('VK_'))

SPECIAL_CHARACTER_KEY_EVENTS = {
    ' ': KeyEvent.VK_SPACE,
    '!': KeyEvent.VK_EXCLAMATION_MARK,
    '"': KeyEvent.VK_QUOTEDBL,
    '#': KeyEvent.VK_NUMBER_SIGN,
    '$': KeyEvent.VK_DOLLAR,
    '&': KeyEvent.VK_AMPERSAND,
    ...
}

KEY_EVENTS.update(SPECIAL_CHARACTER_KEY_EVENTS)

But even with all that I’m still not able to send simple umlauts, such as ‘ü’, ‘ä’ or ‘ö’ to non-Swing windows or even a simple ‘?’ for that matter. Maybe I’m doing something completely wrong and it’s all my fault or just maybe java.awt.Robot isn’t as well-kept as the other Java libraries… or I simply don’t get Java. It’s probably a bit of everything.1

If I ever start working on it again I’ll probably use python-xlib. Of course it wouldn’t be cross-platform then anymore, but really, it’s not like Windows is in any need of desktop automation software with stuff like AutoIt and AutoHotKey around.

1) If anyone knows how to do these things contact me please or simply leave a comment.

Vynk – A Jython desktop automation library

written by cryzed, on May 18, 2010 8:05:00 PM.

I finally started something worthwile: Vynk, a desktop automation library for Jython. Why Jython you ask? Well for one, it’s Python – just implemented on top of the JVM. Additionally the Java standard libraries already come with java.awt.Robot which makes all the coding a hell of a lot easier since most of it is already done. That’s why Vynk is actually only a really thin wrapper around java.awt.Robot trying to make it all a bit more “pythonic” and organized.

Currently the Vynk-package only consists of four files: __init__.py, keyboard.py, mouse.py and screen.py. __init__.py is currently empty and the other files contain the functionality you would probably expect based on their names. Currently only the module for handling the mouse is “pythonic” – if you want to call it that. The module handling the screen implements the methods exposed by the java.awt.Robot class for now but returns complex java class instances – I’ll probably dumb that down quite a bit. Same goes for the module that handles the keyboard, but the main functionality, pressing and releasing keys, isn’t even implemented yet – so that will have to wait for now.

If you are interested in contributing something to the project you can visit my Bitbucket account and send me some patches if you feel like it – or make a pull request. Also if something is extremely wrong with my code don’t hesitate to tell me please – as mentioned here I don’t consider myself very proficient in Python and neither should you.

The ultimate goal is to have a Jython library which feels “pythonic” and ultimatively exposes the same functionality as the java.awt.Robot class. Similiar projects include, although Windows-only, AutoIt and AutoHotKey.

Great times for GNU/Linux gamers

written by cryzed, on May 14, 2010 2:14:00 PM.

The Humble Indie Bundle

With Wolfire Games’ very recent introduction of The Humble Indie Bundle which lets you pay what you want for the following 6 indie games:

It’s looking really great for the GNU/Linux gaming domain. Even better yet is that Wolfire Games decided shortly after they introduced The Humble Indie Bundle to open-source their game Lugaru HD. Additionally the other game developers participating decided to release the source code of Aquaria, Gish and Penumbra Overture aswell.

Everyone who is familiar with the general GNU/Linux folks and their spirit knows what is to follow: Many contributions and improvements to the released source code. Lugaru HD has already had many contributions within its first day of being open source and I’m sure once the other games have their source code released they will get just as much contributions. Even if not yet shown on The Humble Indie Bundle page you can find the source code for Penumbra Overture here.

I’m already getting my hopes up for a multiplayer version of Lugaru HD – even if it doesn’t look like much it’s unbelievably fun. What I could also imagine is that some people decide to use Penumbra Overture’s physics engine to create some kick-ass shooter or something in that spirit.

Valve’s Steam for Linux

Also currently creating uproar is Telegraph’s article on Steam for Mac where at the end is mentioned that “Valve has also confirmed that it will make Steam available to Linux users in the coming months”. Shortly after that Phoronix says it’s official and with that also mentions more possible proofs regarding the GNU/Linux Steam client.

I’m still a bit skeptic regarding all that though – there wasn’t a “real” official announcement directly from Valve after all, so I’ll keep my joy restrained for now.

Using Bitbucket's free plan efficiently

written by cryzed, on May 13, 2010 8:11:00 AM.

Bitbucket’s free plan might seem a bit limiting by only offering one private repository – but it is, in fact, easy to circumvent these restrictions and enjoy most of the benefits the paid plans have to offer.

Instead of having multiple private repositories you can simply create a new branch for each of your projects and then, depending on what project you are currently working on, simply hg update the project to use the right branch and commit the changes you made only to that branch.

If you use your private repository that way having a default branch may seem useless but I keep it anyways – that way, when cloning the repository, I’m always on the default branch and can then simply hg update to another branch. To create the default branch you need at least one non-empty commit though – so I simply created a .placeholder file in the default branch and made my Initial commit.

Here’s a sample bash-session that should show you how to set up such a basic private repository structure:

hg clone ssh://hg@bitbucket.org/username/private
cd private
touch .placeholder # The work-around for the non-empty commit
hg add .placeholder
hg commit -m "Initial commit" # This creates the default branch
hg branch project
hg remove .placeholder # Remove the .placeholder file from the default branch
touch file
hg add file
hg commit -m "Initial commit" # Initial commit for the project branch
hg push -f # Push the changes to Bitbucket; -f is needed to create a new branch

Now you have successfully set up a private repository with 2 branches: default and project. Try deleting the repository locally and then cloning it again. When listing the directories’ contents you should only see the .placeholder file since you are, by default, always on the default branch after cloning. To get to your project branch simply do: hg update project and you should see the file we added appear in the directory.

Of course there is a big disadvantage using a repository like that which may not be quite apparent at once. Assume you use that private repository to store some of your private projects. And with private I really mean private. What do you do when you want to work on a private project with a team? They would need to clone your private repository and of course all the branches along with it – that means you can’t restrict user access and they could easily browse through all your files by switching to another branch. With multiple private repositores that would of course be no problem: So you may still want to consider buying one of the non-free plans.

That being said, I really don’t want to discourage people from buying the non-free plans, but if you are the only person that needs access to your single private repository, the method shown above is a handy and efficient way of using it.

Thanks to name for proof-reading and suggesting corrections.