BBC Micro

[marnanel]

Ten minutes' hacking around brings the Beeb to the N900. It has some keyboard focus issues which need seeing to. Also, beebem uses f12 to bring up an emulator menu, and the N900 has no f12. But with a little work we could see Elite running on this thing.

(If this was ever a serious project, some serious thought would have to be given to copyright issues about the MOS, the DFS, and BASIC: you can't do anything without the MOS, you can't do much without BASIC, and life without the DFS is painful. But they are all still © Acorn, whoever that is these days.)

[javispedro]

Originally Posted by marnanel

It has some keyboard focus issues which need seeing to.

I'm also having those (DOSBox), and for now I have not yet identified the reason (to be honest I've not put too much though into the issue yet). So if you can guess why it seems to affect some apps only please tell

Other than that, it's a cool app

[marnanel]

Originally Posted by javispedro

I'm also having those (DOSBox), and for now I have not yet identified the reason (to be honest I've not put too much though into the issue yet). So if you can guess why it seems to affect some apps only please tell

Other than that, it's a cool app

Thanks. Fixing window managers is rather an obsession of mine, so I'm certainly going to be looking at that after work tonight.

[TA-t3]

Originally Posted by marnanel

[...] some serious thought would have to be given to copyright issues about the MOS, the DFS, and BASIC: you can't do anything without the MOS, you can't do much without BASIC, and life without the DFS is painful. But they are all still © Acorn, whoever that is these days.)

Well, we have an ARM CPU in our toys, and ARM used to mean "Acorn Risc Machine", so maybe we have an implicit license to use Acorn material

Just kidding (about the implicit license), but Acorn was behind not only the beloved Beeb but also the incredibly successful ARM CPU (almost 3 billion a year sold.. quite a lot more than Intel has managed so far).

[marnanel]

Originally Posted by javispedro

I'm also having those (DOSBox), and for now I have not yet identified the reason (to be honest I've not put too much though into the issue yet). So if you can guess why it seems to affect some apps only please tell

Other than that, it's a cool app

Thank you

The problem is that there's a bit in WM_HINTS which (in both apps) isn't set. You can see this using "xprop -id 0x...":

For Beebem:

WM_HINTS(WM_HINTS):
bitmap id # to use for icon: 0x300000d
bitmap id # of mask for icon: 0x300000b

whereas for, say, mediaplayer we'd get:

WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x2c00001

I believe this is a problem with libsdl, but I haven't dug down any further to find why it's not setting this bit.

[deadmalc]

Whooa! Exile on the n900, that would be so cool!

[javispedro]

Originally Posted by marnanel

The problem is that there's a bit in WM_HINTS which (in both apps) isn't set. You can see this using "xprop -id 0x..."

No, thank you instead, you're completely right (and sorry for dirtying your thread, but at least now I know I should probably file a bug about this...). The problem seems to be the missing WM_HINTS bit, but, while on DOSBox that bit is not set:

...
WM_CLASS(STRING) = "dosbox", "dosbox"
WM_HINTS(WM_HINTS):
		bitmap id # to use for icon: 0xc0000d
		bitmap id # of mask for icon: 0xc0000b

It is definitely set on a simpler SDL testcase I made:

...
WM_CLASS(STRING) = "test-i386", "test-i386"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True

I have this suspicion this may be related to the window icon, but this is a wild guess just by looking at the above.

Yay, confirming: adding SDL_WM_SetIcon call makes the test case lose the input focus.

[marnanel]

Originally Posted by javispedro

The problem seems to be the missing WM_HINTS bit, but, while on DOSBox that bit is not set:

DOSBox (and BeebEm) have neither InputHint nor WM_TAKE_FOCUS, and the ICCCM says explicitly that this means "the client never expects keyboard input".

One rather interesting point is that a very quick perusal of Metacity's sources seems to indicate that Metacity will give focus if WM_TAKE_FOCUS is present or InputHint is set. Matchbox2, however, appears to give focus if and only if InputHint is set (it only checks WM_TAKE_FOCUS in order to tell whether to send WM_TAKE_FOCUS when focussing a window).

According to the ICCCM, having WM_TAKE_FOCUS present but not InputHint means that a client "wants to prevent the window manager from setting the input focus to any of its windows", so Matchbox2 is technically correct here. It is possible, of course, that Metacity behaves that way because it solves some problem in a particular subset of clients, so perhaps it would be good to change Matchbox2's behaviour.

Either way, it wouldn't solve the current problem, since the SDL apps in question set neither WM_TAKE_FOCUS nor InputHint.

[marnanel]

Originally Posted by javispedro

Yay, confirming: adding SDL_WM_SetIcon call makes the test case lose the input focus.

Woot, good catch!

[javispedro]

I believe this is "our man":
SDL_x11wm.c, line 232

As a workaround, ifdef'ing the SDL_WM_SetIcon call out will work, since Maemo gets the icons from other sources either way.

If you believe Matchbox is right here, then this is a SDL bug :S