| Wizzup | freemangordon: btw, when you have some time later, did you see https://github.com/maemo-leste/qt-platform-maemo/commit/132b47e59dcd49510283eeac11a49c19d56b00cc ? | 02:36 |
|---|---|---|
| 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 | 03:21 |
| Wizzup | the qt4 module seems to do it on handleReparent(), for QMenuBarPrivate | 03:22 |
| Wizzup | but that is a reparent of the menu itself, which I think they specialised | 03:22 |
| Wizzup | freemangordon: OMP + tracker has been good for me since the reset | 04:19 |
| Wizzup | I haven't added any music yet, but still | 04:19 |
| Wizzup | (any more music) | 04:19 |
| Wizzup | it's like on the n900, but faster :) | 04:19 |
| freemangordon | ugh | 07:28 |
| freemangordon | matchbox delivers WM_DELETE_WINDOW only if the close button is clicked, as per specs | 07:29 |
| freemangordon | and our window has no close button :) | 07:30 |
| freemangordon | because it is fullscreen child | 07:30 |
| freemangordon | and it seems gst simply ignores DestroyNotify | 07:32 |
| Wizzup | freemangordon: heh | 15:42 |
| Wizzup | tmlind: btw I got a mz616-32, mz608, and mz615 | 16:04 |
| Wizzup | well, ordered at least.. | 16:04 |
| Wizzup | they come from within europe for so a change the post should actually not get stolen (unlike in the US) | 16:04 |
| tmlind | Wizzup: ok great | 16:05 |
| 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 | 16:06 |
| tmlind | cool :) | 16:10 |
| 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 | 18:14 |
| freemangordon | either matchbox (our WM) or gst misbehave | 18:15 |
| freemangordon | if I read the docs correctly, it makes sense to set WM_DELETE_WINDOW only on top-level window | 18:15 |
| 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 | 18:16 |
| freemangordon | *wrong | 18:16 |
| freemangordon | bencoh: ^^^ | 18:17 |
| freemangordon | OTOH, it seems that at least i3 checks WM_DELETE_WINDOW for each child, not only on top windows | 18:40 |
| freemangordon | https://github.com/i3/i3/blob/next/src/tree.c#L216 | 18:40 |
| uvos__ | freemangordon: so am i getting this correctly?: | 19:00 |
| 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 | 19:02 |
| uvos__ | gst uses WM_DELETE_WINDOW to clean up, free its gl context before the window is distroyed | 19:03 |
| uvos__ | matchbox distroyes the omp window outright since it dosent care about WM_DELETE_WINDOW on children | 19:03 |
| 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 | 19:06 |
| uvos__ | the window may be distroyed for various reasons, not least of which is the socket timeing out on a remote x connection | 19:06 |
| freemangordon | uvos__: I was looking for confirmation that gst is at fault :) | 19:16 |
| freemangordon | because my gut feeling tells me the same | 19:16 |
| freemangordon | and yes, you're getting it correctly | 19:17 |
| freemangordon | ok, so we will have to fork yet another package :( | 19:18 |
| freemangordon | uvos__: I am not sure it is a problem in gst as such, because the segfault happens in mesa (swrast_dri) | 19:22 |
| freemangordon | but nevertheless, it should not happen | 19:23 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!