DBUS-reactor, or AsusOSD must die!
How to write a tiny python app (less than 50 lines) that reacts to events on the DBUS buses. For example, displaying a notification when you press one of your keyboards' special keys.
How to write a tiny python app (less than 50 lines) that reacts to events on the DBUS buses. For example, displaying a notification when you press one of your keyboards' special keys.
I wrote a while ago a RSS program called uRSSus. I expect I am the only user of it because it has some problems (all of them my fault ;-) but I really like it.
For a while now I have wanted it to have podcast support. The thing is... that always seemed like a lot of work. Sure, using phonon I can create an audio player and everything, but...
I am using a HTML widget to display the posts, so I would have to find a way to add the audio player to the UI and ... too much work.
So, today I woke up and thought... wait a minute... Qt's HTML widget is based on Webkit. And Webkit supports HTML5. And HTML5 has an "audio" tag.
So, if I fixed uRSSus to fetch the enclosure links, and added them in the database, and then added this to the post template:
<?py for enclosure in post.enclosures: ?> <audio autobuffer="Yes" controls="controls" src=#{enclosure.href}></audio><br> <?py #end ?>
Wouldn't that actually work? Well, yeah!
So there you have it, I was right not to implement it, because the easiest way is to let Qt do it ;-)
This is not really part of my PyQt by Example series but since it's a totally unrelated topic that would be impossible to connect to it, but is still a PyQt tutorial and shares the concept so, here it is.
No, this is not a post announcing I just wrote my first public python code. This is a post about my first public python code... from 1996!
In 1996, the soon-to-be-here year of the Linux desktop was fueled by one of the marquee open source applications of the time: LyX.
LyX was (is) a sort of word processor where you wrote and generated LaTeX which then produced whatever you used to print. But I am digressing: LyX was cool because it used one of the first good free graphical toolkits: XForms.
Ok, it was not really free, because you couldn't distribute patches.
And it was not all that good either, but we were comparing it with Motif, so it was much more free and much better than that monstrosity.
BTW: The latest release of XForms is from august of 2009.
At the time, a 25-year-old me was in love with Python 1.3. Here's how I described it:
- Python 1.3
It's a beautiful ,free, language. Get it from ftp://ftp.python.org http://www.python.org
Yes, Python 1.3. So, I wanted to use this C GUI toolkit used in this cool app, and this neat language I was learning and use them at the same time.
I ran (not walked) to my faithful Slackware 3.0 ELF in my 486DX2 PC and started hacking. In a weekend or so I had a working binding.
I even started writing the holy grail of desktop applications, a GUI version of Pine, using python and its IMAP module (python mailer, or PyM):
I released version 0.1 alpha in 1996, May 13 ... and a few months later Matthias Ettrich started KDE and I found Qt and never thought about XForms again.
Until this month.
For reasons that don't matter, I mentioned PyM in the PyAr mailing list the other day, and ... well, would pyxforms still work?
Why, pretty much, yeah!
I got the pyxforms-0.1-alpha sources from somewhere in the internet, installed XForms 1.0.92sp2 (yes, the latest release, from three months ago), of course I already had python 2.6.4 installed, added a setup.py, edited 10 lines of code and...
Yes, it works. You can get this 0.2 version (codename "Cthulhu was here") here just 13 years after 0.1.
No, I don't understand the weird rounded corners, or why the cursor looks weird and old when it's inside the window.
It's a REALLY small and fast toolkit, though.
Honestly, is it useful for ayone? Almost certainly not. Am I amazed something I wrote in 1996 still works? Oh, yeah I am.
I have long known that application development is an arduous process. I have also long suspected one of the reasons it's arduous is the developer. I should be more specific, I am one of the reasons.
That's because I don't know what I am doing, and I don't mean that in the "I am a lame programmer" sense (even if that's also true somewhat), but in the sense that I literally don't know what the app should look like, or what its feature set should be.
So, I have decided to embark on a series of experiments I will call 24-hour apps.
Here are the rules:
I shall create a neat application, stable, useful, usable and decent-looking.
I shall do it in no more than 24 hours. After that time, it should be at least good enough for a preview release, if not a beta.
Those 24 hours can be split in two or three sessions
Time spent doing icons, docs, etc, counts.
All development shall be public (I am using github)
I must have a use for the resulting application, and it should be at least an adequate solution for that problem.
So, what's the first project? I call it Die Schere (The Scissors in german) and it's a video editor.
It's not a kdenlive replacement, it's just the video editor I wish I had when I needed to glue a piece of one video with a piece of another.
In the old, pre-digital world, that was done using a cutter and scotch tape. I want Die Schere to be as useful and comprehensible as that was, but useful for clumsy people like myself.
Here is a video after today's session, which lasted 8 hours:
The basic functions are there, even if lots of work is still needed.
You can load clips to work with them
You can cut clips (like using a cutter!)
You can choose the cut points interactively or by editing a time
You can arrange them (like using scotch tape!)
You can generate the output video
As a backend it's using mencoder, but there's no reason it shouldn't work with ffmpeg or melt if someone writes 20 lines of code.