Exaile still uses PyGTK, which in turn depends on Python 2 and GTK+ 2. Why haven’t we upgraded?
- Python 3: Not even sure PyGI supports it yet. Either way, needs PyGI.
- GTK+ 3: Needs PyGI.
- PyGI (a.k.a. new PyGObject): We’ve been trying. It segfaults randomly. And debugging segfaults from a Python program is… hard.
Update (2015-11): It’s happening; we’re slowly porting Exaile to PyGI. It will be using GTK+ 3 and GStreamer 1, but will still be on Python 2.
This post shows how you can retrieve all window titles in Microsoft Windows using Python’s ctypes module. Moreover, it also acts as a ctypes tutorial, showing how to create and use callback functions.
The following is the full code. Keep reading if you want to understand how it works. (Note: If you are reading this as a ctypes tutorial and are having trouble following the explanation, you may want to go through my previous tutorial first.)
EnumWindows = ctypes.windll.user32.EnumWindows
EnumWindowsProc = ctypes.WINFUNCTYPE(ctypes.c_bool, ctypes.POINTER(ctypes.c_int), ctypes.POINTER(ctypes.c_int))
GetWindowText = ctypes.windll.user32.GetWindowTextW
GetWindowTextLength = ctypes.windll.user32.GetWindowTextLengthW
IsWindowVisible = ctypes.windll.user32.IsWindowVisible
titles = 
def foreach_window(hwnd, lParam):
length = GetWindowTextLength(hwnd)
buff = ctypes.create_unicode_buffer(length + 1)
GetWindowText(hwnd, buff, length + 1)
I’m surprised at how good MP3 can be. I’ve just tried a website that lets you do ABX tests between 128 and 320 kbps MP3 files. Presumably 320 kbps is meant to represent the “known transparent” sample (which should be true for my case). After getting one correct answer out of three, I stopped because it just wasn’t going to work out.
What’s surprising is not really the bitrate (I have previously ABX-tested Vorbis q2 (~96 kbps) and found it to be almost transparent); it’s that MP3 encoders have gone a long way since the last time I tried them. I guess most of their notoriety is carried over from the Napster era which, come to think of it, ended around ten years ago.
On a related note, MP3 and H.264 share an ironic trait: both are patent-encumbered, yet the best encoders for for them are free / open source software (LAME and x264). The difference is that MP3 is inferior to pretty much any of the other formats in use today.
atool is the command-line equivalent to WinZip-style programs—and it just works.
Most importantly, the aunpack tool (for extracting files) will first check the number of items in the archive root. If there is only one item (a directory or a file), it gets directly extracted to the target directory. If there are more than one, they are extracted to a new directory.
For example, if A.tar.xz only contains fileA, aunpack A.tar.xz will extract fileA to the current directory. If B.tar.xz contains fileB1 and fileB2, aunpack extracts them to a directory called B. This has saved me countless times from extracting truckloads of files to my home directory.
Hm, I missed the news about Apple filing a US trademark for WebKit earlier this May. I think it’s not a big deal.
A lot of free software project names are trademarked by the authors in some part of the world. Most are used defensively so that others cannot file the same trademark, but some are used for preserving brand identity (see Iceweasel).
In the worst case, projects have changed names over trademark or even non-trademark name clashes. Phoenix→Firebird→Firefox, Gaim→Pidgin, and Ethereal→Wireshark are three high-profile examples.
If the WebKit trademark is granted, depending on how Apple decides to guard it, others in the US will probably go back to the KHTML name. Considering there are other big stakeholders in the WebKit world now (Google being the biggest one), I don’t think Apple will risk fragmentation, but who knows.
In my opinion, among “intellectual properties”, trademark is likely the least of our concern. I could be wrong though; I haven’t seen much discussion around it.
I have three sound cards (on-board, HDMI, and external) and the only sane way to manage them was through pavucontrol. pavucontrol is amazing, but I wanted a command-line app that I can use in keyboard shortcuts and udev rules.
This bothered me enough that I created one myself. If you’re interested, check out pasink (direct link to code). It’s a Python wrapper to pacmd, the PulseAudio console. I’ve thought of using libpulse through Vala, but it’s probably overkill for now.
The script lets you do things like setting volume on each card and setting a particular card as the main output device. I suppose doing the same on input devices would be useful, but I skillfully dodged that responsibility by naming the app “pasink”. It’s not that I don’t see the value; I simply don’t have the motivation.
If you want to extend pasink to also cover audio sources, feel free. You’ll have to rework the interface; perhaps let the behaviour depend on whether the program is run as “pasink” or “pasource”.
If you’re compiling a piece of code and getting an error message saying something about PUSHL or “invalid suffix for PUSH”, it means you’re feeding x86 assembly code to an x86_64 assembler.
- The code you’re trying to compile really does contain x86 assembly, perhaps inlined from C, but you’re targeting x86_64.
- Your toolchain somehow contains a mix of x86 compiler and x86_64 assembler. Try cleaning up your PATH.