[07:51] <liuxg> alexabreu, ping
[09:15] <tsdgeos> dednick: ping
[09:16] <tsdgeos> unping
[09:16] <tsdgeos> Saviq: ping
[09:16] <Saviq> tsdgeos, wassup?
[09:16] <tsdgeos> you sure that's the duplicate?
[09:17] <tsdgeos> regarding https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1418505
[09:17] <tsdgeos> i mean the duplicate is marked as fix released
[09:17] <tsdgeos> but this still happens
[09:17] <Saviq> tsdgeos, there's a indicator-messages task that's not fix released
[09:18] <tsdgeos> aahh
[09:18] <tsdgeos> i see
[09:18] <Saviq> which is basically bug #1412779
[09:18] <Saviq> which is a duplicate
[09:19] <tsdgeos> oki
[09:54] <tsdgeos> oh man
[09:55] <tsdgeos> why does platform-api doesn't build parallel?
[10:27] <tsdgeos> greyback: ping
[10:28] <greyback> tsdgeos: pong
[10:28] <tsdgeos> greyback: i built https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 and https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection/+merge/245054 on the pohne and now everything is crashing like mad
[10:28] <tsdgeos> anything i may be missing?
[10:30] <greyback> tsdgeos: you're building the packages I guess. Maybe merge their trunks? Nothing obvious coming to mind
[10:30] <tsdgeos> i think i merged everything
[10:30] <tsdgeos> let me check
[10:31] <greyback> hasn't been any qtubuntu change this year anyway
[10:31] <greyback> platform got a few fixes, nothing I would expect impacts input
[10:32] <greyback> Does every app crash on startup? Or only if you interact with it?
[10:32] <tsdgeos> yeah everything is merged
[10:32] <tsdgeos> well unity8 is crashing
[10:32] <greyback> ah
[10:32] <tsdgeos> so ca'n't see anything
[10:32] <tsdgeos> and i guess the compositor is crashing too
[10:33] <tsdgeos> since i can't even see the spinning ubuntu
[10:33] <greyback> unity8 doesn't use qtubuntu
[10:33] <greyback> but it does use part of platform-api - the sensors bit
[10:33] <greyback> it could be the ABI change requiring qtmir rebuild
[10:34] <tsdgeos> let me see if a qtmir rebuild helps
[10:58] <dandrader> mzanetti, did you see those failures? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/438/?
[10:59] <dandrader> mzanetti, could that be related to the changes in lp:~mzanetti/unity8/saveRestoreWindowSizePosition?
[11:00] <mzanetti> dandrader: no, haven't seem them yet. but yes, I believe it's the same issue as you reported
[11:00] <mzanetti> dandrader: which I just fixed a minute ago
[11:01] <mzanetti> normally on a device ~/.cache/unity8 exists because main.cpp (or something triggered by that) creates it
[11:01] <mzanetti> however, the test alone didn't do that and failed if you ran it on a clean device (or wiped ~/.cache first
[11:15] <Cimi> tsdgeos, how do I create a qvariantmap with a qvariantmap inside?
[11:15] <tsdgeos> just create it?
[11:15] <tsdgeos> QVariantMap a; QVariantMap b; a["moo"] = b;
[11:22] <Cimi> tsdgeos, I was trying http://paste.ubuntu.com/10171978/
[11:23] <tsdgeos> second one doesn't have to be a qvariantmap btw
[11:23] <tsdgeos> it has to be a qvariantlist
[11:23] <tsdgeos> see https://code.launchpad.net/~aacid/unity8/testFor1316660
[11:23] <tsdgeos> https://code.launchpad.net/~aacid/unity8/testFor1316660/+merge/249210
[11:31] <Cimi> tsdgeos, well, I can just reuse that button then
[11:31] <Cimi> as I need one to click
[11:31] <tsdgeos> you'll need to give it some more info though, i didn't fill in the other fields
[11:32] <tsdgeos> since my code is just good enough to have them on screeen
[11:32] <tsdgeos> i mean there's no id for example
[11:32] <tsdgeos> but yeah you can reuse that
[11:32] <tsdgeos> and if you can review the MR it'd be even awesomer :)
[11:42] <Cimi> tsdgeos, can you add buttonData["id"] = "open_click" ?
[11:42] <Cimi> or well, I can since I will need other stuff...
[11:43] <Cimi> nevermind...
[11:43] <tsdgeos> ok :)
[12:07] <mzanetti> dandrader: come one... now approve it already
[12:09] <tsdgeos> greyback: i rebuilt qtmir too
[12:09] <tsdgeos> nothing :/
[12:14] <greyback> tsdgeos: that's v strange
[12:14] <tsdgeos> maybe i messed up somewhere
[12:14] <tsdgeos> will try again
[12:15] <greyback> don't spend too much time at it, the MR needs fixing anyway
[12:15] <tsdgeos> greyback: is UbuntuWindow::moveResize being gone in https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 very bad? or the code that was there basically did nothing and the result is the same?
[12:16] <greyback> tsdgeos: it never did anything. I'd keep the stub in though, as it needs to be implemented once mir supports it
[12:16] <tsdgeos> the stub is there
[12:16] <tsdgeos> just no code
[12:16] <tsdgeos> and a todo
[12:16] <greyback> no change needed there then so
[12:17] <greyback> it's to allow clients resize their own windows
[12:17] <tsdgeos> ok
[12:17] <greyback> which we've never needed on phone/tablet so far
[12:17] <tsdgeos> so from a "i know nothing about this" pov the code looks ok-ish
[12:17] <greyback> sounds good to me
[12:17] <tsdgeos> i've done some comments that are more from the "let's make the code nicer"
[12:18] <tsdgeos> like he has some casts he doesn't need and stuff
[12:18] <dandrader> mzanetti, approved, thanks
[12:18] <greyback> tsdgeos: cool. the functional testing will be the more important part, to ensure gestures and stuff all work as before
[12:20] <tsdgeos> yeah
[13:14] <Cimi> tsdgeos, so something like that is correct? http://paste.ubuntu.com/10172979/
[13:20] <Cimi> I see "no such signal", but should be in the interface... :/
[13:57] <tsdgeos> greyback: now i have it running
[13:57] <greyback> tsdgeos: what changed?
[13:57] <tsdgeos> i installed too many packagers before and something broke when tried to fix it
[13:58] <tsdgeos> like i installed *.deb
[13:58] <greyback> ah
[13:58] <tsdgeos> and it includes qtmir-desktop
[13:58] <tsdgeos> and kaboom
[13:58] <greyback> ah yeah
[13:58] <greyback> have done that myself manys a time
[13:59] <greyback> sorry, should've thought of that as a possible shoot-yourself-in-the-foot
[14:05] <mterry> Woah.  is launchpad down?
[14:05] <greyback> mterry: works for me
[14:05] <mterry> Huh, my browsers can't get to it
[14:05] <MacSlow> mterry, lp works for me too
[14:06] <mterry> Let me try resetting my internet
[14:06] <greyback> larsu: hey, would you have any idea, with the GTK mir backend, is there a way to stop it drawing client-side window decorations?
[14:07] <mterry> Yup, that fixed it
[14:07] <larsu> greyback: tell the app you're running unity. Many apps don't care, though
[14:08] <greyback> larsu: I want to run it with Mir though - but just to play with server-side decoration
[14:09] <larsu> greyback: hm, what do you mean?
[14:09] <larsu> gtk's client side decorations are totally up to the app. It's just another widget you pack
[14:10] <larsu> so there's really no way to disable them for all apps
[14:10] <greyback> larsu: right now, if I run a GTK app on Mir, the app draws it's own decorations. As if the backend decided to do it for the app
[14:10] <larsu> oh wait, really?
[14:10]  * larsu is confused
[14:10]  * larsu asks attente
[14:10] <greyback> that's what I'm seeing anyway
[14:20] <dandrader> mterry, hey, in greeter-refactor, I noticed you removed the behavior that animated the LoginList resize. So when you show the vkb in the test the LoginList jumps up immediately. Is it also like that on a tablet or does it appear to be animated (becasue maybe the reported kbd rect grows and shrinks along with the internal ubuntu-keyboard animation)
[14:20] <dandrader> mterry, I'm asking that because I'm still flashing my tablet :)
[14:29] <Cimi> tsdgeos, did you se before? ^^
[14:29] <tsdgeos> Cimi: hmmm see what?
[14:29] <tsdgeos> i guess not
[14:30] <Cimi> tsdgeos, so something like that is correct? http://paste.ubuntu.com/10172979/
[14:30] <Cimi> I see "no such signal", but should be in the interface... :/
[14:30] <tsdgeos> something like tha tyes
[14:30] <tsdgeos> Cimi: you're getting that error?
[14:31] <Cimi> yes
[14:31] <tsdgeos> void triggered(QString const&, QString const&, QVariantMap const&);
[14:31] <tsdgeos> fix your signature
[14:31] <tsdgeos> in the connection
[14:37] <mterry> dandrader, hrm that may not have been an intentional drop, let me look
[14:38] <Cimi> tsdgeos, yes works, thanks!
[14:38] <Cimi> learning bit of c++ a day keeps saviq away
[14:38] <Saviq> lol
[14:39] <Cimi> :))
[14:40] <tsdgeos> greyback: so anything in particular you'd want me to manual test on that MR?
[14:42] <Cimi> tsdgeos, to get scopes from previewmodel, can I use Scopes *scopes = dynamic_cast<Scopes*>(parent()); ?
[14:43] <tsdgeos> Cimi: no, see who is the parent
[14:43] <tsdgeos> Cimi: pass it down as another param in the constructor and that's it
[14:44] <mterry> dandrader, restored the behavior -- that was just a merge mistake
[14:44] <mterry> dandrader, thanks for the catch  :-/
[14:44] <Cimi> tsdgeos, ok
[14:45] <dandrader> now my N10 won't turn on...
[14:47] <Saviq> dandrader, if it drained, it will take a good half hour on a high-current (2A) charger to recover
[14:48] <greyback> tsdgeos: main things I'b be concerned with are gestures, and keyboard input on desktop. Tapping around should just work as before
[14:48] <Cimi> tsdgeos, in scope.ccp we have this return new PreviewStack; which then creates the previewmodel
[14:48] <dandrader> Saviq, I was flashing it and the flash tool tried to reboot it after pushing the images. that's when the N10 dropped dead. but who knows, maybe it has no battery left indeed. it's been ages since I last played with it
[14:49] <Cimi> tsdgeos, so your advice is calling PreviewStack(this) then moving the parent down the line?
[14:55] <dandrader> Saviq, something is very wrong. while charging, all of a sudden display turns on, big full battery  icon shows up, then big empty battery icon, then rotating ubuntu logo (like from usc), then display turns off
[14:56] <dandrader> Saviq, then the whole things repeats itself after a minute. seem to be in some sort of reboot loop
[14:56] <tsdgeos> greyback: don't have the desktop setup to try
[14:56] <tsdgeos> Cimi: yeah
[14:56] <Saviq> dandrader, the "full" batter is just charging indication probably, it doesn't actually convey the charge level
[14:57] <greyback> tsdgeos: ok, leave that
[14:57] <Saviq> dandrader, try getting it into fastboot (power+vol...left?) and leave it there for a while
[14:58] <dandrader> Saviq, yeah, at least now it's responding to power button presses. got into fastboot
[14:58] <Saviq> dandrader, if you go 'start' it should boot into ubuntu
[14:58] <Saviq> dandrader, it's in a reboot loop because nothing clears the "go into recovery" flag, 'cause recovery dies
[14:59] <dandrader> Saviq, is says "Downloading...." under the robot. is that right?
[14:59] <dandrader> Saviq,  s/right/expected
[14:59] <Saviq> dandrader, no, it went into download mode, I think you might've gotten into download mode instead of fastboot (which are really similar)
[14:59] <Saviq> dandrader, use the other vol button when powering up ;)
[15:00] <dandrader> Saviq, ok, booted into ubuntu successfully now. thanks for the tip
[15:01] <MacSlow> does anyone here know which package provides the python-import-module "ubuntuuitoolkit"?
[15:01] <Saviq> dandrader, think it'd make sense to file a bug, we should not get into a reboot loop like that, our recovery should probably clear the recovery flag as soon as it got it
[15:02] <Saviq> MacSlow, ubuntu-ui-toolkit-autopilot
[15:02] <MacSlow> Saviq, hm... in that case dpkg and grep failed me... thanks
[15:24] <MacSlow> what is "Binder_2" and why would it create a 99% load on the device?
[15:25] <Saviq> MacSlow, it's android's kernel IPC
[15:25] <MacSlow> hm
[15:26] <Saviq> MacSlow, shouldn't hog CPU unless it's actually chugging data around
[15:27] <Saviq> dandrader, there's a conflict on lp:~phablet-team/ubuntu-keyboard/shellRotation
[15:27] <dandrader> Saviq, when merging it with trunk, you mean?
[15:27] <Saviq> dandrader, yes
[15:28] <dandrader> Saviq, ok, if I can't solve it I will ask Eleo
[15:38] <Cimi> tsdgeos, chaining down doesn't seem to work well for me... having issues with parents http://paste.ubuntu.com/10174489/
[15:40] <tsdgeos> Cimi: hmm
[15:40] <tsdgeos> pass it as additional parametero
[15:40] <tsdgeos> otherwise when previewstack creates previewmodel
[15:40] <tsdgeos> this is is not a scopes
[15:42] <tsdgeos> -s
[15:43] <tsdgeos> mterry: tbh i don't think it really matters much, i mean we're swiping the greeter, it's not like it's the most performance critical part of the phone
[15:44] <tsdgeos> Saviq: greyback: performance discussion around clipping in https://code.launchpad.net/~mterry/unity8/bleeding-infographic/+merge/249223 if you want to jump in
[15:51] <tsdgeos> paulliu: there?
[15:52] <paulliu> tsdgeos: yes
[15:52] <tsdgeos> paulliu: did you mention you wanted https://code.launchpad.net/~paulliu/unity8/notification_helper/+merge/249211 to be reviewed by some people from QA? or can i just approve it?
[15:53] <paulliu> tsdgeos: Because they will use it. So I'd like to see if they like it.
[15:53] <tsdgeos> ok
[15:53] <tsdgeos> i'll give my approval but not top approve letting them comment
[15:53] <tsdgeos> paulliu: maybe you should subscribe them
[15:53] <tsdgeos> so they know there's stuff for them to do
[15:53] <paulliu> tsdgeos: yes. ok. I'll do.
[15:54] <Cimi> tsdgeos, changed something, but other c++ errors http://paste.ubuntu.com/10174764/
[15:55] <Cimi> oh no
[15:55] <Cimi> hold on
[15:55]  * tsdgeos holds
[15:55] <Saviq> Cimi, the actual errors are usually more useful than patches, this way tsdgeos doesn't need to compile with his eyes :P
[15:56] <greyback> tsdgeos: I replied to the MR. A single clip shouldn't have any big impact, so I don't object to that change. If doing the same task without clipping is much more complex, it's probably not worth the code complexity
[15:57] <Cimi> Saviq, I want at least give it a try for myself :)
[15:57] <Cimi> but yeah
[15:58] <tsdgeos> greyback: fwiw i wasn't objecting to clipping, i was just arguing to leave the clipping on all the time :D
[15:58] <Saviq> greyback, so, it's probably better to just clip: true
[15:58] <tsdgeos> but it's just arguing for the arguing
[15:58] <Saviq> greyback, no point in turning it on/off?
[15:58] <greyback> Saviq: probably yeah
[15:58] <Saviq> mterry, ↑
[15:59] <greyback> if Greeter offscreen, it should be marked invisible, in which case the whole thing has zero impact
[16:00] <greyback> one thing I keep meaning to do is set everything under the greeter as invisible while greeter is occluding it, would stop that jank in the infographics animation on startup
[16:00] <mterry> Saviq, OK
[16:00] <mterry> greyback, if greeter is offscreen, it is invisible
[16:00] <greyback> mterry: good
[16:01] <greyback> would be even nicer if we unloaded Greeter, to release its resources
[16:01] <greyback> but not a huge deal
[16:01] <Saviq> greyback, yeah, we tried that, but it's not worth it on phone, the greeter is up too often
[16:02] <greyback> sounds likely yeah
[16:02] <Saviq> greyback, destroying it and recreating all the time
[16:10] <tsdgeos> mterry: your greeter-refactor branch is a tag-hell, can you run ./strip-tags.py on it?
[16:16] <Saviq> tsdgeos, when free, you could have a look at https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/452/?
[16:16] <Saviq> tsdgeos, that seems to be our last flaky qml test
[16:18] <Saviq> mzanetti, https://www.youtube.com/watch?v=3J4TWDQDuhU :D
[16:19] <tsdgeos> Saviq: i added a tryCompare in one of my branches
[16:19] <tsdgeos> should maybe hopefully fix that
[16:19] <tsdgeos> gievn that i don't have anything slow enought o reproduce that error
[16:20] <Saviq> tsdgeos, lemme loop
[16:20] <tsdgeos> Saviq: the branch i mean is https://code.launchpad.net/~aacid/unity8/testFor1316660/+merge/249210
[16:20] <Saviq> kks
[16:21] <tsdgeos> Saviq: btw the rtm branch has a few dead tags, not sure we care
[16:22] <Saviq> tsdgeos, they're not dead according to strip_tags actually, bzr weird as usual
[16:22] <Saviq> tsdgeos, meaning that they actually refer to a valid revision
[16:23] <tsdgeos> ok
[16:26] <mzanetti> Saviq: yeah, saw that video :D
[16:27] <Saviq> dandrader|lunch, mterry, lp:~dandrader/unity8/fixSurfaceActiveFocus and lp:~mterry/unity8/tutorial-new-screens conflict, please either rebase one on the other or let me know which should I leave out from the silo
[16:28] <mterry> Saviq, dandrader|lunch: I'll try rebasing mine
[16:29] <Saviq> tx
[16:32] <mterry> Saviq, done
[16:40] <Cimi> tsdgeos, so I sent scopes down, but I also need to emit openScope signal from scope
[16:41] <Cimi> tsdgeos, I might send Scope instead, but I have then the problem of getting Scopes from it
[16:41] <seb128> can I run a qt5 app from a vt and get it to display under the mir demo server?
[16:42] <tsdgeos> Cimi: add a scopes() getter to scope
[16:42] <tsdgeos> return dynamic_cast<Scopes*>(parent());
[16:42] <Cimi> tsdgeos, ok
[16:42] <Cimi> tsdgeos, I was doing dynamic_cast<Scopes*>(m_scope->parent()); inside the previewmodel
[16:42] <tsdgeos> it's not nice, but it's a mock :D
[16:43] <Cimi> tsdgeos, but this was not working, why?
[16:43] <tsdgeos> Cimi: it should
[16:43] <tsdgeos> all the scope objects are forced to have Scopes as parent
[16:43] <tsdgeos> what problem did you have?
[16:43] <Cimi> cannot dynamic_cast ‘((PreviewModel*)this)->PreviewModel::m_scope->Scope::<anonymous>.unity::shell::scopes::ScopeInterface::<anonymous>.QObject::parent()’ (of type ‘class QObject*’) to type ‘class Scopes*’ (target is not pointer or reference to complete type)
[16:43] <Cimi>      Scopes *scopes = dynamic_cast<Scopes*>(m_scope->parent());
[16:44] <Cimi> I suspect I need cast something
[16:44] <tsdgeos> #include "fake_scopes.h"?
[16:45] <Cimi> tsdgeos, this compiles
[16:45] <Cimi> tsdgeos, how did you get it was missing an include?
[16:45] <tsdgeos> Cimi: because it was complaining it can't cast qobject to scopes
[16:45]  * Cimi trying to learn c++ here
[16:46] <tsdgeos> because it didn't know scopes *is* a qobject
[16:46] <tsdgeos> since the include was missing and thus it couldn't
[16:46] <Cimi> tsdgeos, but fake_scope.h was included
[16:46] <tsdgeos> sure fake_scope only defines Scope, not Scopes
[16:46] <Cimi> I see
[16:46] <Cimi> ok
[16:46] <Cimi> gracias
[16:46] <tsdgeos> well there's a forward declaration saying
[16:46] <tsdgeos> "there will be eventually a class named Scopes"
[16:46] <tsdgeos> but that's all
[16:48] <Cimi> tsdgeos, now can I emit openScope from the previewModel?
[16:49] <tsdgeos> Q_EMIT myscope->openScope(something);
[16:49] <tsdgeos> something is probably another scope, no?
[16:50] <tsdgeos> so Q_EMIT myscope->openScope(myscope->scopes()->getScopeFromAll("SomeotherScope"))
[16:50] <tsdgeos> or something like that
[16:50] <tsdgeos> that actually compiles D:
[16:54] <Saviq> mterry, resubmit the MP please
[16:54] <Saviq> with the prerequisite
[16:56] <Cimi> tsdgeos, ok works! tomorrow the test finally :)
[16:58] <tsdgeos> :)
[16:59] <mterry> Saviq, guh right
[16:59] <mterry> Saviq, https://code.launchpad.net/~mterry/unity8/bleeding-infographic/+merge/249223 could also be squeezed in maybe
[17:00] <mterry> Saviq, try now
[19:35] <Encrypt> Hello there o/
[19:35] <Encrypt> Hi tedg o/
[19:35] <Encrypt> Im coming to bother you people with the GMainLoop and the MessagingMenu :D
[19:36] <Encrypt> I thought about what tedg_ told me last time
[19:36] <Encrypt> SO, I think I understood what I have to do to add a gsource to the GMainLoop using an idle_source_add (or something like that)
[19:37] <Encrypt> But, I'm still wondering how to deal with the messaging menu
[19:37] <Encrypt> That is to say how to deal with "messaging_menu_app_append_source()"
[19:37] <Encrypt> Because I noticed that I have to stop the loop to add the event
[19:38] <tedg> You don't have to stop the loop as much as append the source in the same thread.
[19:38] <tedg> So if you do the idle_source_add(), you can append in that function.
[19:38] <tedg> That will execute in the same thread as the mainloop.
[19:39] <Encrypt> Oh!
[19:39] <Encrypt> Ok!
[19:39] <Encrypt> I hadn't understood it like that
[19:39] <Encrypt> Let's give it a try :p
[19:47] <Encrypt> By the way...
[19:47] <Encrypt> I discovered the editor "Atom" yesterday
[19:47] <Encrypt> It works pretty well! :)
[19:47] <Encrypt> For those who want to have a look
[19:47] <Encrypt> https://atom.io/
[20:48] <mterry> Does anyone here run xmir on their desktop?
[20:50] <ChrisTownsend> mterry: Do you mean to run an X app on the Unity 8 desktop?
[20:50] <mterry> ChrisTownsend, I'm just trying to start with running normal unity7 desktop
[20:50] <mterry> ChrisTownsend, I can run that mostly fine
[20:50] <mterry> ChrisTownsend, but it crashes when I start chromium
[20:50] <mterry> ChrisTownsend, and am trying to see if I'm alone or if there are workarounds or what
[20:51] <Encrypt> tedg, Am I doing it right now?
[20:51] <Encrypt> tedg, http://pastebin.com/ZqcLTm31
[20:52] <Encrypt> The only thing I'm not sure about is line 44
[20:52] <ChrisTownsend> mterry: Oh, ok.  I don't do that.  Where are you getting xmir from?
[20:52] <Encrypt> It seems that I can't really give an array of gpointer to this kind of function
[20:53] <Encrypt> BTW, notifications don't work anymore :/
[20:53] <ChrisTownsend> mterry: I run Xmir to run X apps in Unity 8, so it's a different use case than what you are doing.
[20:53] <Encrypt> But that might be related to the data[2] thing
[20:57] <mterry> ChrisTownsend, just getting it from vivid
[20:57] <ChrisTownsend> mterry: Ok, not sure about that then.
[20:57] <mterry> ChrisTownsend, that's fair, thanks anyway!  :)
[20:58] <ChrisTownsend> mterry: Sorry I couldn't be more help:)
[21:00]  * Encrypt should use a structure
[21:01] <tedg> Encrypt, You probably want to create everything on the thread.
[21:01] <tedg> Encrypt, So instead of creating, and then running it. You want the function on the thread to create everything.
[21:01] <Encrypt> Hum
[21:01] <Encrypt> Apparently it work
[21:01] <Encrypt> Fine then
[21:02] <tedg> And yes, a structure would be good. You also need to free some of the memory.
[21:04] <Encrypt> tedg, Then, what I don't understand is how to do that
[21:04] <tedg> Also, you can't pass memory that is allocated in the stack between threads. I needs to be on the heap.
[21:04] <Encrypt> How could an external function call the thread?
[21:04] <Encrypt> I'm confused
[21:05] <tedg> Your mm_notify function would, in theory, be called by the non-Glib thread.
[21:05] <tedg> So then it needs to pass of the data to the GLib thread.
 Also, you can't pass memory that is allocated in the stack between threads. // Are you talking about run_mmloop?
[21:06] <tedg> No mm_notify()
[21:06] <Encrypt> Ok
[21:06] <tedg> An mm_rm_entry()
[22:40] <Encrypt> tedg, It works _o/
[22:43] <tedg> Woot!
[22:43] <Encrypt> Yep :p
[22:44] <Encrypt> tedg, Thanks for your help! :)