Okay, found the "what" but not the "why"... I don't quite know what to make of this, but I'll write it down here in case it happens to someone else.

So, after ruling out toolbars and menus, I looked into signals and slots, specifically the "dialog code" generated by eric4 from the Designer .ui file.

For QActions, eric4 offers to generate code stubs for a number of signals, the first of which is "activated()". Checking this for an action named "Open" creates a stub slot method, say in mainwindow.py, named:

on_actionOpen_activated(self):

Then in the Python version of the UI file also generated by eric4 (Ui_mainwindow.py) is the magic command:

QtCore.QMetaObject.connectSlotsByName(MainWindow)

This automagically connects the "activated()" signal of the "actionOpen" object to the slot above.

I've used this technique in several previous projects before and never had a problem with it, at least under Windows. But under Maemo5 it doesn't work. Not even if I explicitly connect signal and slot (it then fires twice in Windows, logically, but still not in Maemo).

On a hunch I looked at the (Py)Qt documentation for QAction - which I'd never had to do before because everything was automated by Designer/eric4.

And the strange thing is, if I read correctly, QActions have an "activate()" method, but no "activated()" signal... Their only signals are: changed(), hovered(), toggled(), triggered()... the latter being described as "emitted when an action is activated by the user". Duh.

So I changed the slot name to on_actionOpen_triggered(), and of course now the code works both under XP and Maemo...

Still, I'm left with more questions than I started with:

- is eric4 wrong about QAction signals ?
- if so, why does it work under Windows ?
- else is it a specific Qt/PyQt bug in Maemo ?
- or a known difference between Windows and Linux window managers ?
etc.

Any ideas ? :-)