Shallow Thoughts : : Jan
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Thu, 28 Jan 2010
I've written in the past about Python GUI programming using the GTK and
Tk toolkits, and several KDE fans felt that I was slighting the much
nicer looking Qt.
So my latest article on Linux Planet,
Make
Pretty GUI Apps Fast with Python-Qt,
shows how to develop a little poker game using the python-qt toolkit.
I didn't want to dwell on it in the article (and didn't have space anyway),
but pyqt turned out to be a bit of a pain.
There's no official documentation -- or at least nothing
that's obviously official -- and a lot of
the examples on google are out of date because of API changes.
None of the tutorial examples explain much, and they never demonstrate
the practical features I'd want to do in a real app.
It was surprisingly hard to come up with an application idea
that worked well, looked good and was still easy to explain.
And don't get me started on this whole "Slots and signals are
revolutionarily different even though they look just like the callbacks
every other toolkit has used for the last three decades" meme.
I'm sure there is a subtle technical difference -- but if there's
a difference that matters to the average UI programmer, their
documentation sure doesn't make it clear.
All that aside, PyQt (and Qt in general) does produce very pretty apps
and is worth trying for that reason.
The suit images in the article are adapted from some suits I found on
Wikimedia Commons
(the "Naipe" set).
I wanted them to look more 3-dimensional, so I applied my
blobipy GIMP
script as well as scaling and resizing them.
I really liked those shiny-looking Tango heart and spade emblems (also
on the Wikimedia Commons page) but I couldn't find a diamond or club
to match.
The poker program I wrote has menus and a second round of dealing,
where you can mark off the cards you want to keep.
I couldn't fit all that in a 700-word article, but
the complete program is available here:
qpoker.py
or you can get it in a tarball along with the suit images at
qpoker.tar.gz.
Tags: programming, writing, qt, python-qt
[
10:53 Jan 28, 2010
More programming |
permalink to this entry |
]
Mon, 25 Jan 2010
Ever since I upgraded to Ubuntu 9.10 "Karmic koala", printing text files
has been a problem. They print out with normal line height, but in a
super-wide font so I only get about 48 ugly characters per line.
Various people have reported the problem -- for instance,
bug 447961
and this
post -- but no one seemed to have an answer.
I don't have an answer either, but I do have a workaround. The problem
is that Ubuntu is scaling incorrectly. When it thinks it's putting
10 characters per inch (cpi) on a line, it's actually using a font that
only fits 6 characters. But if you tell it to fit 17 characters per inch,
that comes out pretty close to the 10cpi that's supposed to be the default:
lpr -o cpi=17 filename
As long as you have to specify the cpi, try different settings for it.
cpi=20
gives a nice crisp looking font with about 11.8
characters per inch.
If needed, you can adjust line spacing with lpi=NN
as well.
Update: The ever-vigilant Till Kamppeter has tracked the problem
down to the font used by texttopdf for lp/lpr printing. Interesting details in
bug
447961.
Tags: printing, ubuntu, linux, tips
[
16:36 Jan 25, 2010
More linux |
permalink to this entry |
]
Wed, 20 Jan 2010
Last weekend, on a tip posted on a local birding list, we hiked up to
the little pond at Lake Ranch, above Sanborn county park, where a
major California newt orgy is in progress.
There were thousands of newts throughout the lake, but especially by
the dam, where they were mating and laying eggs.
I had never realized how much the male newts' appearance differs from
the females -- or possibly, it doesn't except at this time of year.
Most of the year, when we see newts they look like these females, with
orange-red skin and lizard-like feet. But here the males look very
different: larger, darker, often patterned with stripes or spots,
with huge flipper-like feet and greatly flattened tails.
Most of the females were gravid with eggs already. The males seem to
be able to tell when a female has already been fertilized, but only
from up close: they'll pursue a female to a few inches away, then turn
back if she's recently mated.
We saw some multi-newt orgies, with two or three males nosing each
other to get access to a female; but mostly we saw pairs clasped in
long-lasting embraces. We watched a few pairs for five or ten minutes.
Some of the females laid their grape-sized egg sacs near where they
mated, by the dam; but upstream, closer to the Black Rd end of the
pond, we found a nursery where the pond floor was just covered with
egg sacs. Is it safer for the eggs here, away from the newt festivities?
Or is the temperature or oxygen content different?
Photos are a bit challenging.
There's a lot of reflection off the surface of the water.
The raw photos are just a sea of murky green, but a little contrast
boosting in GIMP, and sometimes a bit of layer mode/layer mask work,
brings out a lot more detail than I expected.
There were a few frogs singing, too. We couldn't see the frogs, but we did
see a few schools of what might have been tadpoles (or else tiny fish).
We also saw one huge tadpole, with a head like a squashed ping-pong ball.
I hope the bullfrogs from Walden West pond haven't migrated up to
Lake Ranch. It's fun to watch them at Walden West, but bullfrogs could
wreak havoc on the pond's other wildlife. (Can bullfrogs eat newts?
Most animals can't -- newts have poisonous skins.
But we've never seen any newts at Walden West.)
If you go to see the newts, watch your step on the trails.
After egg-laying, the females apparently leave the pond and go wandering
cross-country. (Where do the males go?)
We saw at least three females heading down the steep trail toward
Sanborn, and a couple more on the flat trail above the lake that heads
toward Black Rd. They move slowly and purposefully, and can't scurry out of
your way to keep from getting stepped on. So be careful, and enjoy the show!
Newt nookie photos here.
Tags: nature, newts
[
12:06 Jan 20, 2010
More nature |
permalink to this entry |
]
Sun, 17 Jan 2010
(despite Firefox's attempts to prevent that)
My Linux Planet article last week was on
printing
pretty calendars.
But I hit one bug in Photo
Calendar.
It had a HTML file chooser for picking an image ...
and when I chose an image and clicked Select to use it.
it got the pathname wrong every time.
I poked into the code (Photo Calendar's code turned out to be
exceptionally clean and well documented) and found that it was
expecting to get the pathname from the file input element's
value attribute. But input.File.value was just
returning the filename, foo.jpg, instead of the full pathname,
/home/user/Images/yosemite/foo.jpg. So when the app tried
to make it into a file:/// URL, it ended up pointing to the
wrong place.
It turned out the cause was a
security
change in Firefox 3. The issue: it's considered a security
hole to expose full pathnames on your computer to Javascript code
coming from someone else's server. The Javascript could give bad
guys access to information about the directory structures on your disk.
That's a perfectly reasonable concern, and it makes sense to consider
it as a security hole.
The problem is that this happens even when you're running a local app
on your local disk. Programs written in any other language and toolkit
-- a Python program using pygtk, say, or a C++ Qt program -- have
access to the directories on your disk, but you can't use Javascript
inside Firefox to do the same thing.
The only ways to make an exception seems to be an elaborate procedure
requiring the user to change settings in about:config.
Not too helpful.
Perhaps this is even reasonable, given how common
cross-site scripting bugs have been in browsers lately -- maybe
running a local script really is a security risk if you have other
tabs active.
But it leaves us with the problem of what to do about apps that need
to do things like choose a local image file, then display it.
And it turns out there is: a data URL. Take the entire contents of
the file (ouch) and create a URL out of those contents, then set the
src attribute of the image to that.
Of course, that makes for a long, horrifying, unreadable URL --
but the user never has to see that part.
I suspect it's also horribly memory intensive -- the image has to be
loaded into memory anyway, to display it, but is Firefox also
translating all of that to a URL-legal syntax? Obviously, any real
app using this technique had better keep an eye on memory consumption.
But meanwhile, it fixes Photo Calendar's file button.
Here's what the code looks like:
img = document.getElementById("pic");
fileinput = document.input.File;
if (img && fileinput)
img.src = fileinput.files[0].getAsDataURL();
Here's a working
minimal demo of
using getAsDataURL() with a file input.
Tags: javascript, web, programming
[
14:57 Jan 17, 2010
More programming |
permalink to this entry |
]
Thu, 14 Jan 2010
Didn't get the calendar you wanted for Christmas this year?
Print your own, with your choice of photos and holidas.
My Linux Planet Photo
Calendar article shows how.
Tags: writing, linux, calendar
[
17:53 Jan 14, 2010
More writing |
permalink to this entry |
]
Wed, 13 Jan 2010
To wrap long lines, or not to wrap? It's always
a dilemma. Automatic wrapping is great when you're hammering away
typing lots of text. But it's infuriating when you're trying to format
something yourself and the editor decides it wants to line-wrap a
little too early.
Although of course you can set the wrapping width, Emacs has a tendency
to wrap early -- especially when you hit return. All too often, I'll
be typing away at a long line, get to the end of the sentence and
paragraph with the last word on the same line with the rest -- then
realize that as soon as I hit return, Emacs is going to move that
last word to a line by itself. Drives me nuts!
And the solution turns out to be so simple. The Return key,
"\C-m". was bound to the (newline)
function (you can find out
by typing M-x, then describe-key
, then hitting Return).
Apparently (newline)
re-wraps the current line before
inserting a line break. But I just wanted it to insert a line break.
No problem -- just bind "C-m" to (insert "\n")
.
But there's a second way, too, if you don't want to rebind:
there's a magic internal emacs table you can change.
(set-char-table-range auto-fill-chars 10 nil)
But wait -- there's one other thing I want to fix in text mode.
Automatic indent is another one of those features that's very
convenient ... except when it's not.
If I have some text like:
First point:
- subpoint a
- subpoint b
then it's handy if, when I hit Return after
subpoint a,
emacs indents to the right level for
subpoint b.
But what happens when I get to the end of that list?
First point:
- subpoint a
- subpoint b
Second point:
- subpoint c
When I hit Return after subpoint b, Emacs quite reasonably
indents two spaces. If I immediately type another Return,
Emacs sensibly deletes the two spaces it just inserted, opens a
new line -- but then it indents that new line another two spaces.
After a blank line, I always want to
start at the beginning, not indented at all.
Here's how to fix that. Define a function that will be called
whenever you hit return in text mode. That function tests whether the
caret comes immediately after a blank line, or at the beginning of
the file. It indents except in those two cases; and in neither case
does it re-wrap the current line.
;; In text mode, I don't want it auto-indenting for the first
;; line in the file, or lines following blank lines.
;; Everywhere else is okay.
(defun newline-and-text-indent ()
"Insert a newline, then indent the next line sensibly for text"
(interactive)
(cond
;; Beginning of buffer, or beginning of an existing line, don't indent:
((or (bobp) (bolp)) (newline))
;; If we're on a whitespace-only line,
((and (eolp)
(save-excursion (re-search-backward "^\\(\\s \\)*$"
(line-beginning-position) t)))
;; ... delete the whitespace, then add another newline:
(kill-line 0)
(newline))
;; Else (not on whitespace-only) insert a newline,
;; then add the appropriate indent:
(t (insert "\n")
(indent-according-to-mode))
))
Then tell emacs to call that function when it sees the Return key in
text mode:
(defun text-indent-hook ()
(local-set-key "\C-m" 'newline-and-text-indent)
)
(setq text-mode-hook 'text-indent-hook)
Finally, this is great for HTML mode too, if you get irritated at
not being able to put an <a href="longurl"> all on one line:
(defun html-hook ()
(local-set-key "\C-m" (lambda () (interactive) (insert "\n")))
)
(setq sgml-mode-hook 'html-hook)
Tags: emacs, editors, tips
[
11:29 Jan 13, 2010
More linux/editors |
permalink to this entry |
]
Fri, 08 Jan 2010
We just had the second earthquake in two days, and I was chatting with
someone about past earthquakes and wanted to measure the distance to
some local landmarks. So I fired up
PyTopo as the easiest way
to do that. Click on one point, click on a second point and it prints
distance and bearing from the first point to the second.
Except it didn't. In fact, clicks weren't working at all. And although
I have hacked a bit on parts of pytopo (the most recent project was
trying to get scaling working properly in tiles imported from OpenStreetMap),
the click handling isn't something I've touched in quite a while.
It turned out that there's a regression in PyGTK: mouse button release
events now need you to set an event mask for button presses as well as
button releases. You need both, for some reason. So you now need code
that looks like this:
drawing_area.connect("button-release-event", button_event)
drawing_area.set_events(gtk.gdk.EXPOSURE_MASK |
# next line wasn't needed before:
gtk.gdk.BUTTON_PRESS_MASK |
gtk.gdk.BUTTON_RELEASE_MASK )
An easy fix ... once you find it.
I filed
bug 606453
to see whether the regression was intentional.
I've checked in the fix to the
PyTopo
svn repository on Google Code.
It's so nice having a public source code repository like that!
I'm planning to move Pho to Google Code soon.
Tags: programming, python, pygtk, mapping
[
14:20 Jan 08, 2010
More programming |
permalink to this entry |
]