01:36 <Wizzup> freemangordon: btw, when you have some time later, did you see https://github.com/maemo-leste/qt-platform-maemo/commit/132b47e59dcd49510283eeac11a49c19d56b00cc ?

02:21 <Wizzup> I'm mostly wondering if we need to do this somewhere else than in show, I guess technically people could remove the menu while showing the window

02:22 <Wizzup> the qt4 module seems to do it on handleReparent(), for QMenuBarPrivate

02:22 <Wizzup> but that is a reparent of the menu itself, which I think they specialised

03:19 <Wizzup> freemangordon: OMP + tracker has been good for me since the reset

03:19 <Wizzup> I haven't added any music yet, but still

03:19 <Wizzup> (any more music)

03:19 <Wizzup> it's like on the n900, but faster :)

06:28 <freemangordon> ugh

06:29 <freemangordon> matchbox delivers WM_DELETE_WINDOW only if the close button is clicked, as per specs

06:30 <freemangordon> and our window has no close button :)

06:30 <freemangordon> because it is fullscreen child

06:32 <freemangordon> and it seems gst simply ignores DestroyNotify

14:42 <Wizzup> freemangordon: heh

15:04 <Wizzup> tmlind: btw I got a mz616-32, mz608, and mz615

15:04 <Wizzup> well, ordered at least..

15:04 <Wizzup> they come from within europe for so a change the post should actually not get stolen (unlike in the US)

15:05 <tmlind> Wizzup: ok great

15:06 <Wizzup> I also got this a few weeks ago after checking with uvos https://www.ebay.com/itm/305141762174 - but it's still in the us, more for fun

15:10 <tmlind> cool :)

17:14 <freemangordon> uvos: please help, I am not sure I read https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html#Window_Deletion correctly

17:15 <freemangordon> either matchbox (our WM) or gst misbehave

17:15 <freemangordon> if I read the docs correctly, it makes sense to set WM_DELETE_WINDOW only on top-level window

17:16 <freemangordon> if that's true, then gst makes wring assumption, that it will receive ClientMessage/WM_DELETE_WINDOW for a window that is not toplevel

17:16 <freemangordon> *wrong

17:17 <freemangordon> bencoh: ^^^

17:40 <freemangordon> OTOH, it seems that at least i3 checks WM_DELETE_WINDOW for each child, not only on top windows

17:40 <freemangordon> https://github.com/i3/i3/blob/next/src/tree.c#L216

18:00 <uvos__> freemangordon: so am i getting this correctly?:

18:02 <uvos__> omp has a window, no WM_DELETE_WINDOW atom is set, gst renders to a child of this window and sets WM_DELETE_WINDOW

18:03 <uvos__> gst uses WM_DELETE_WINDOW to clean up, free its gl context before the window is distroyed

18:03 <uvos__> matchbox distroyes the omp window outright since it dosent care about WM_DELETE_WINDOW on children

18:06 <uvos__> if the above is correct, regardless how WM_DELETE_WINDOW is supposed to behave i dont see how a segfault is acceptable when the window gets distroyed by something other than gst/omp itself when requested by the wm via WM_DELETE_WINDOW

18:06 <uvos__> the window may be distroyed for various reasons, not least of which is the socket timeing out on a remote x connection

18:16 <freemangordon> uvos__: I was looking for confirmation that gst is at fault :)

18:16 <freemangordon> because my gut feeling tells me the same

18:17 <freemangordon> and yes, you're getting it correctly

18:18 <freemangordon> ok, so we will have to fork yet another package :(

18:22 <freemangordon> uvos__: I am not sure it is a problem in gst as such, because the segfault happens in mesa (swrast_dri)

18:23 <freemangordon> but nevertheless, it should not happen