=== thomi_ is now known as thomi [08:12] Mirv, hey, do you think there will be a rc2 of Qt 5.2? [08:13] Mirv, also, do you have branches for all the packages in qt5-beta2 somewhere? === iahmad is now known as iahmad|afk [08:22] Saviq: [08:22] Hi all, [08:22] We have new packages available for your testing & verification in http://download.qt-project.org/snapshots/qt/5.2/5.2.0/2013-12-09_204/ [08:23] subject: Qt 5.2 final candidate packages available [08:23] tsdgeos, right ;) [08:23] doesn't look like there'll be an RC2 [08:23] tsdgeos, "final candidate" sounds very much like rc2 ;D [08:24] maybe [08:24] i just think it's packages we'll flip the switch tomorrow if noone complains about [08:24] and not a more formal RC2 [08:24] but i'm still not at 100% :D [08:24] tsdgeos, ;) [08:24] so may not be reading it correctly [08:25] tsdgeos, good news, at least, is that both crashes we've encountered (unity-api and my test with JSON parsing) [08:25] tsdgeos, are gone with release [08:25] Saviq: no formal rc release I think (http://download.qt-project.org/development_releases/qt/5.2/). all packaging is under https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging [08:25] Saviq: awesome [08:26] Saviq: that's great news. [08:26] Mirv, seen there's a "final candidate" tarballs around? [08:26] Saviq: tsdgeos: I have set around 50+ recipe builds to qt5-beta2, a lot of build failures in some packages, at least something has changed regarding running tests (opengl tests are tried to be run in gsettings-qt on builders) [08:27] Saviq: sure, there are tarballs, but no rc release tarballs [08:27] Mirv, right, only snapshots [08:28] Saviq: yeah, date coded snapshots which all are called "final candidate builds" [08:28] Saviq: it seems the patched qtdeclarative is now there, so I'm clicking rebuild for unity-api [08:28] Mirv, next time we need to make it so we have a recipe just following the release branch ;) [08:28] Mirv, cool [08:29] Saviq: the problem with automated Qt packaging is that during development the files tend to change all the time in at least qtbase/qtdeclarative, so *.install files are outdated, and same goes for symbols files (which I've now mostly temporarily removed simply until final release) [08:30] Mirv, yeah, I know, just a dream there :) [08:30] Saviq: I'll probably cc: you later today with my tinkerings around the opengl es on x86.. [08:30] Mirv, great, thanks [08:31] tsdgeos, there's like 6 newer builds in here http://download.qt-project.org/snapshots/qt/5.2/5.2.0/ - does it go regardless of the lack of changes? [08:31] tsdgeos, i.e. is 204 that you linked different from 209 do you think? [08:32] hmm [08:33] no commits in qtdeclarative at least since 5.12 [08:33] i guess they might change [08:34] no idea how to find out which one though [08:35] other than git logging [08:39] Cimi: did i convince you in https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position ? [08:40] Cimi: also do you have time for https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714 ? [08:40] Mirv, segfault :/ [08:40] Mirv, built fine here yesterday with that patch... [08:43] so it seems :( === iahmad|afk is now known as iahmad [08:46] Mirv, hum [08:46] Patch correct_geometry_for_2x_pixmaps.patch does not apply (enforce with -f) [08:46] Mirv, that's on freshly branched lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src [08:46] Mirv, how could it build, then... [08:47] Mirv, [08:47] Mirv, it's only the packaging branch :) [09:05] Saviq: yes, that's still how all Qt packaging is handled also in Debian :) wget .orig.tar.xz from qt5-beta2 PPA [09:05] Mirv, yeah, never did much with merge-style packaging [09:05] Mirv, but managed my way around it [09:06] Saviq: btw regarding qtwebkit 5.2, add_experimentalDevicePixelRatio.patch is again disabled since it didn't apply.. I guess rsalveti or someone should look at it [09:07] Saviq: interesting. there was an autobuild of webbrowser-app in qt5-beta2 with the latest 5.2 fix, and it seems it also segfaults on i386 and armhf, but not on amd64 when running tests [09:07] Mirv, right, sounds like unity-api then [09:15] Mirv, aah, so it never segfaulted on amd64 did it? [09:15] Mirv, I'm on amd64 :/ [09:17] Mirv, anyway - you might find http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/95 useful - the patch conflicted with the 209 snapshot, so once there's a proper release, that patch should apply fine [09:23] Saviq: :) yep, never segfaulted on amd64. [09:23] thanks for that, I'll fetch that already so that I don't forget about it, because maybe I won't build another qtdeclarative until the final is out [09:24] Mirv, cheers [09:24] merged and pushed [09:30] mzanetti, pushed a fix to new-scopes-integrate-card [09:31] mzanetti, apparently 38/2 != 18.5, but 19! [09:31] :D [09:31] Saviq: cheers. will give it another run [09:31] ah... wait [09:31] did you see the other one? [09:32] mzanetti, looking [09:32] mzanetti, that you mean https://code.launchpad.net/~saviq/unity8/new-scopes-integrate-card/+merge/197930/comments/459628 ? [09:32] mzanetti, that's what I just fixed [09:32] mzanetti, doesn't segfault when passing... [09:32] yip. all passing here [09:32] Saviq: ok. good to go I'd say [09:32] mzanetti, hit it! [09:33] Saviq: happroved [09:33] mzanetti, thanks /me merges [09:34] Saviq, got any tasks floating around? [09:35] nic-doffay, yeah, review https://code.launchpad.net/~bfiller/unity8/fix-password-autocaps/+merge/198319 please? [09:35] Saviq, cool [09:35] nic-doffay, test on the phone please [09:35] Saviq, yep [09:36] there's no default implementation of qhash for strings? [09:36] as in std::string [09:37] mhr3, I'd imagine they want QString... [09:38] tsdgeos, feelin' better btw? [09:38] yeah [09:38] not 100% [09:38] but rest really helped [09:38] Saviq, they do, but i dont [09:38] mhr3: then define your qHash operator for std::string [09:38] ↑ [09:38] that just wraps it into QString ;) [09:38] lol [09:38] slow++ [09:39] think i'll just go for std::map [09:39] or that [09:39] oh wait, there's unordered_map now [09:40] that should have the algorithmic complexity as qhash, no? [09:40] the same* [09:40] mhr3, card integration landed [09:40] mhr3: yeah [09:41] mhr3, yeah sounds sane [09:41] Saviq, coolio, lp:unity8? :) [09:41] mhr3, weell now let's not get ahead of ourselves ;) [09:41] Saviq, would be nice to get it in there ;) [09:41] mhr3, there's too many FIXMEs in there still [09:41] mhr3, that need to go before getting into trunk [09:41] Saviq: want me to add the code for the case in which you change the width of a column in a vJournal with items on it and so i need to force resize on them? [09:42] or we're not planning to do that and i can leave a TODO? [09:42] Saviq, so chop, chop, fix them ;P [09:42] tsdgeos, I think it'd be good, as we might scale the window without refreshing the model [09:42] ok [09:43] doing [09:43] mhr3, s/icon/art/ anyone? [09:43] Saviq, got it in a branch, but adding real tests in the same branch... so it's... "fun" [09:43] mhr3, OMG REAL TESTS? [09:44] RIGHT?! [10:00] mhr3, btw, so if you export the FORCE_NEW_SCOPES=1, Unity 0.1 becomes the same as Unity 0.2? [10:01] Saviq, pretty much, yea [10:01] mhr3, so if we wanted to merge new-scopes into unity8, how could we differentiate between the two when selecting a renderererererer? [10:02] mhr3, we could just go for .hasOwnProperty("template") or so [10:02] Saviq, well the new scopes give you the an object for category.renderer, old ones just a string :) === rachelliu_ is now known as rachelliu [10:03] mhr3, yeah, which should not be "renderer" btw, but "template" :P [10:03] Saviq, i thought it wouldn't like undefined [10:03] mhr3, it can deal fine with undefined [10:03] but sure, if a bit of code is added to handle it [10:03] mhr3, or we can make it deal with it [10:03] mhr3, yeah, that [10:04] Saviq, but yea, the ultimate idea is to have all the code sitting in trunk but disabled by default [10:05] makes dev on it easy [10:05] mhr3, I'm just worried that will hold us back too much [10:06] mhr3, like the above ↑ you'd name it template, but didn't want to break old stuff, so went for renderer [10:06] right [10:06] there are pros and cons [10:06] mhr3, and then we'll build all kind of bolierplate code to make it work both ways [10:06] as always :) [10:06] and then after we flip the switch we'll have to rip that all out again [10:07] Saviq, ultimately in unity8 pretty much all the changes will be limited to the new card renderer [10:07] mhr3, that is true, but that's the thing - we could rip out half of the code there already [10:08] this renderer <> template snafu doesn't sound like a big deal [10:08] mhr3, sure, that's just one example [10:08] Mirv: hey, are the QtQuick Controls packaged in the Qt5.2 PPA? [10:09] Saviq, imo the cost of keeping compability with both isn't that high [10:09] at least not right now [10:09] things will get more fun once we do previews and stuff [10:10] for me it's the classical let's not diverge from trunk unless we have to [10:11] mhr3, yeah of course - but that's what I mean is holding us back, for which I'm not sure we have time - or want it to [10:12] * tsdgeos finds a bug in the verticalJournal implementation [10:12] damn unittests! [10:13] Saviq, i can work eitherway really, it's a have-a-look-dear-manager feature :P [10:14] greyback: no, sorry. raising on my todo list. [10:14] Saviq, so if you want to do gutting of code from the branch, feel free to [10:15] Saviq, i don't think that's worth it, will just complicate merging [10:15] Mirv: it's not critical for me, so no need to re-prioritize just for me [10:15] i mean, it should be right before merging to trunk [10:18] ok, only slightly notching it up then ;) [10:23] mhr3: ping [10:23] dednick, pong [10:25] mhr3, yeah [10:26] mhr3: howdy. just looking back into the dee thing i left off. I agree with not linking having a new base class. [10:26] mhr3: although i may have to change the DeeModelface if we want to do it properly [10:27] mhr3: so that we can get the multiplexer from the filter model backend. [10:27] dednick, what do you have in mind? cause yea, i'm not sure what would be the nice way to do it [10:28] dednick, also, how was capetown? [10:28] mhr3: nice and warm. although i was only there for 2 days. Hiked table mountain. [10:30] dednick, oh? just 2 days? did the city frighten you or something? :) [10:31] mhr3: hehe. no, just had other places to go :) Want to spend more time there next time around though. Really good climbing on table mountain. [10:32] did you do actual climbing there as well? [10:32] mhr3: no, just some hiking. [10:32] Mirv, .install updates for qtdeclarative: http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/97 [10:34] dednick, will want some more tips, heading there as well in a month ;) [10:34] Saviq: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/?#showFailuresLink still happening? [10:34] tsdgeos, that's new actually [10:34] is it? [10:34] tsdgeos, if you look at the videos [10:34] tsdgeos, unity8 never shows up [10:34] ok [10:34] tsdgeos, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/artifact/results/autopilot/artifacts/ [10:34] may be that i broke something in the merge [10:35] tsdgeos, I don't think so, seen that for other branches yesterday [10:35] mhr3: awesome. you going for sprint? [10:35] dednick, yep [10:35] Saviq: ah [10:35] tsdgeos, "init: unity8 main process (11206) killed by TERM signal" [10:35] tsdgeos, is what ends up in .xsession-errors [10:35] tsdgeos, no idea where that comes from :/ [10:36] Saviq: so we're crashing again? [10:36] tsdgeos, TERM, not crashing [10:36] tsdgeos, and there's no .crash file around [10:36] right [10:36] tsdgeos, it's like it's killed before it really starts [10:36] Cimi: so what comment would you add? [10:36] Cimi: are you going to ask for a comment in all the lines that do something right? [10:36] mhr3: lucky! You must hike up a route called India Venster. book through http://www.hiketablemountain.co.za/ . They are really nice guides. [10:37] greyback, ↑ [10:37] because i am a bit against literate programming tbh [10:37] Saviq: thanks [10:37] mhr3, you staying past the sprint? [10:38] Saviq, nope, but will be there the whole weekend before it [10:38] mhr3, cool, we're staying a few days past with greyback [10:39] Saviq, and arriving on sunday? [10:39] mhr3, yes [10:39] mhr3: yep [10:39] can I come? [10:39] :) [10:39] its cold here [10:39] i'm flying there on friday, so should have most of saturday and whole sunday free [10:40] a few more designers are doing that as well [10:41] You guys have *another* sprint? [10:41] RAOF, design one [10:41] RAOF, we're just there to say NO [10:42] from time to time [10:42] :) [10:42] and get fired [10:42] All of the things we saw last week looked perfectly fine from Mir's point of view (ie: they didn't involve us doing anything different ☺). [10:42] As the people implementing them you may have other ideas :P [10:43] RAOF, yes, there's kgunn that will be saying NO for you guys ;) [10:46] nice summary :) [10:48] dednick, the link looks good, will check it out :) [10:48] dednick, anyway back to dee, i was thinking about something like - http://paste.ubuntu.com/6550461/ [10:49] dednick, the nice thing about it, is that the usage of a FilterModel is just an impl detail [10:50] and there could even be a "demultiplex-changeset" property [10:50] default TRUE [10:53] the not-so-nice thing is that doing things a bit more lazily would need more thought [10:54] so for example the impl wouldn't keep a filtermodel unless you called _get_bin for it yet [10:54] s/yet// [10:55] tsdgeos, link to bugreport [10:55] tsdgeos, on that line [10:55] Cimi: why do you want a link to a bugreport that has nothing to do with the code? [10:55] the code is not a workaround [10:55] the code is correct code that works by itself [10:56] sure it happens that the old code should have worked and does not [10:56] and that is a bug [10:56] tsdgeos, ah [10:56] but the new new code is correct [10:56] as i already mentioned in the comment i made [10:56] ok so don't add comment [10:56] I thought was a workaround [10:58] Cimi, hey, could you review/ack the change on https://code.launchpad.net/~larsu/overlay-scrollbar/hide-scrollbars-before-unmapping/+merge/197415 ? [10:59] seb128, I wasn't a fan of that but I'll have a look [10:59] Cimi: https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position/+merge/197423/comments/457546 [10:59] Cimi, if you are not a fan please find another way to fix bug #1086494, those warnings are annoying [10:59] Cimi, thanks [10:59] bug 1086494 in overlay-scrollbar "GtkScrolledWindow is mapped but visible child GtkScrollbar is not mapped" [Undecided,In progress] https://launchpad.net/bugs/1086494 [10:59] seb128, yeah will think about it [10:59] Cimi, thanks [11:00] seb128, it's weird [11:00] seb128, dunno why mapped children should be mapped if parent is mapped :-\ [11:01] mzanetti, what we talked about yesterday https://qt.gitorious.org/qt/qtdeclarative/commit/75a6f86f685f1a5ce6cb91212641fe446a37be2e [11:01] larsu, ^ [11:01] seb128, if that's the warning, you should unman not hide [11:01] *unmap [11:01] Saviq: nice one :) [11:01] mzanetti, we need a qmltryrunner that does that [11:02] Cimi, well, I'm running larsu's fix for a week and it made those warning go away without side effect [11:02] but maybe [11:02] I'm not picky on the solution [11:02] seb128, hide unmaps and change visible flag as well [11:02] Saviq, is this still the same write issue as before? (Getting this on run_on_device -s) W: Not using locking for read only lock file /var/lib/dpkg/lock [11:02] I just want gedit to stop spamming stdout [11:02] seb128, unmaps just unmaps but does not change visible gtk flag [11:02] nic-doffay_, very possible, did you make your device writable? [11:02] ok [11:02] seb128, better to use unmap if possible [11:02] let's way for larsu to comment [11:03] he understand those stuff better than me [11:03] Cimi: unmap is not enough, you'd also need to unrealize [11:03] Saviq, no I assumed that step wouldn't be required... [11:03] Saviq: you mean exporting the QTestRootObject? [11:03] What's the command? [11:03] Cimi: that's what the warning is about [11:03] nic-doffay_, it alwaysis [11:03] nic-doffay_, building unity8 on the device requires installing packages on the phone - so you need writable [11:03] mzanetti, yeah [11:04] mzanetti, although... that might mean the tests will actually run under qmlscene, too ;) [11:04] Saviq: hmm... but shouldn't happen in the QtTest import? [11:05] mzanetti, oh well, right [11:05] mzanetti, it's interesting why they'd do it in the runner and not the plugin indeed [11:05] larsu, it's about map, not realize [11:06] Saviq: not sure what I'm missing... but I think this commit does it in QtTest [11:06] so I'm not sure why exactly it fails [11:06] unless we have a version where this commit is just not in yet [11:06] mzanetti, we do [11:07] mzanetti, right, so... more investigation to be had [11:09] * Saviq finds it confusing that libqt5declarative5 comes from qtquick1.... [11:09] Cimi: I think it complains about realize when only unmapping and remapping (I vaguely remember trying that first) [11:09] Cimi: feel free to fix it differently, but I don't want to spend more time on it, as the solution I proposed seems to work fine [11:09] larsu, Cimi: bug #1086494 (the title has it) [11:09] bug 1086494 in overlay-scrollbar "GtkScrolledWindow is mapped but visible child GtkScrollbar is not mapped" [Undecided,In progress] https://launchpad.net/bugs/1086494 [11:09] and makes seb128 happy :) [11:10] mhr3: why are there void func pointers on the end of interfaces in dee? [11:10] seb128: ya, I think I tried unmapping-only first and then it complains about realize [11:10] mhr3: is it byte alignment? [11:10] /food [11:10] dednick, it's for extending the interface without having to break the abi [11:11] larsu, +1 on not spending more time on it, that solution works, if Cimi has a better one I guess you are fine commenting on it though? [11:11] mhr3: ah, so add a function and remove a void? [11:11] dednick, yep [11:11] mhr3: smartypants [11:11] seb128, larsu I just don't see the point why we should change visible gtk flag for that [11:11] dednick, seen the pastebin? [11:11] I guess we can play with realise and map as well [11:12] dednick, that wouldn't need changes to DeeModel itself [11:12] if we call unrealise, we call unmap [11:12] Cimi, can you propose a patch with what you describe? [11:12] Cimi: okay, please do that, then [11:13] mhr3: ah, no i hadnt seen it. [11:13] seb128, can do later [11:13] thanks [11:13] dednick, so stop ignoring me! :P [11:14] Saviq, yeah it's working now, that's weird though because usually I haven't had any write issues after a flash. [11:15] mhr3: so basically just keep a static map of backend->Demultiplexer? [11:16] dednick, not exactly, this allows you to even have multiple demultiplexers on top of the same model [11:17] dednick, and you'd get the individual FilterModels by calling the _get_bin() method [11:17] dednick, eh yea, i'm missing self ptr in the get_bin() === rachelliu_ is now known as rachelliu [11:21] mhr3: um, so how do we use the same demultiplexer across multiple filter models if it's not using the same one for the given backend? [11:23] since we're not exposing DeeDemultiplexer to unity anymore that is. [11:23] dednick, since the usage of FilterModel is just an impl detail, it's up to the Demultiplexer itself to ensure that the models(bins) have proper data [11:24] dednick, and eh, the idea is that the Demultiplexer itself would be a public class in the lib [11:25] but it's a generalized data demultiplexer, not just a changeset-* signals demultiplexer [11:25] mhr3: so we're still creating the demultiplexer in unity? [11:25] yes [11:26] and using it to get the per-category models using its get_bin() [11:26] mhr3: then what is the point of changing it? who cares if it's generalised? [11:27] it's just an idea [11:27] mhr3: "on the other it's very specific functionality which is now exposed as a base dee class" :) [11:28] mhr3: i thought the idea was not to expose. [11:28] splitting data from one model into multiple is a valid use case [11:28] and the demuliplexer seems like a correct way to do it [11:29] what i didn't like about the previous approach is that it was too loose - just demultiplexing the signals, and having to manually "tag" each model that should use it [11:30] mhr3: i c [11:31] dednick, that all being said, maybe you have a better idea with the change to DeeModel? i'm not sure what exactly you want to do there [11:31] mhr3: i'm still unclear as to how the FilterModel knows it has a demultiplexer if it isn't told. [11:33] dednick, fwiw the usage of filtermodel is optional, it's up to the demultiplexer to split the data, it could just as well create new DeeSequenceModels and maintain the rows itself (using the bin_func) [11:33] of course that would be silly and expensive :) [11:34] but the point remains, the split is up to it, not necessarily the submodel [11:35] and since this will be inside dee, you could just add internal methods to filtermodel === _salem is now known as salem_ [11:54] mhr3: i'm still confused... How would we create the demultiplexer in unity (using dee_multiplexer_new) and have the BinFunc in dee if it's internal to FilterModel. [11:54] mhr3: you are very confusing... [11:55] dednick, would be easy with a whiteboard, how come you're not at the office? [11:55] and how come i'm not at the office? :P [11:56] dednick, the bin func is something the user of the demult has to provide [11:56] otherwise it'd be pretty useless [11:56] mhr3: right. but then what are the internal methods in FilterModel? [11:56] mhr3: because i'm lazy [11:57] maybe i'll just leave this and come in tomorrow [11:57] dednick, dunno really what the internal method would be, whatever is needed to make it work :) [11:58] afaict it might not even be necessary to add an internal method [11:58] mhr3: lol. ok [11:59] dednick, but agreed, let's postpone till tomorrow [11:59] i'll have a deeper look at it meanwhile :) [12:07] Saviq, want to top approve this? The fix is working for me. [12:07] errrrr [12:07] nic-doffay_, sure, can you add a "needs-ap-test" to the bug pleaes [12:07] please, even [12:07] un errrr [12:07] tsdgeos, ? [12:07] tsdgeos, - [12:13] dednick, added more data to https://bugreports.qt-project.org/browse/QTBUG-34351 [12:13] dednick, btw, there's "provide missing info" at the top, that changes the status back from NEEDINFO to REPORTED [12:13] dednick, it might slip through the cracks otherwise [12:14] Saviq: ah. thanks [12:15] dednick, btw, https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 is correct still, is it? meaning we haven't decided on anything that would make this not needed? [12:17] Cimi: mzanetti: we broke the delegateRange stuff when merging the dashrenderer stuff [12:17] dednick, only question there - will this work fine with encoding? as in does g_date_time_format cough up UTF8 - and if so, shouldn't we go for QString::fromUtf8? [12:17] delegaterange? [12:17] meh [12:18] delegateCreationBegin [12:18] really? [12:18] yep [12:18] it's assigned in the wrong direction [12:18] never gets to the filter grid [12:18] :/ [12:19] i guess i'll go over all the changes from that merge [12:19] because it's broken lots of things [12:19] so a post review won't hurt [12:19] tsdgeos, list down what test could be added please [12:19] Saviq: my opinion is that it's the correct way to do it. But yes, should be using fromUtf8 [12:20] Saviq: it's hard to test what test could be added [12:20] because the test would be "make sure the item of the list gets that assigned" [12:20] and that is happening [12:20] tsdgeos, I understand [12:20] is just that the item is not correctly passing that to its children [12:20] which is an implementation detail [12:20] tsdgeos, just when going over it again - try to see if there's anything else worth testing [12:20] i.e. we could not have had that test before the change because the change is that introduced it [12:20] tsdgeos, not necessarily that particular thing [12:21] sure [12:21] larsu, dednick, where does the time format come from, btw? locale? are the choices hardcoded in the indicator? [12:22] larsu, I mean for the datetime indicator, sorry for the lack of context [12:23] Saviq: don't know, let me check [12:23] nic-doffay_, you can add tags to bugs, just below the description [12:24] nic-doffay_, this way you can then find all of them with that tag by: https://bugs.launchpad.net/bugs/+bugs?field.tag=needs-ap-test [12:24] Saviq: ugh, right now datetime sends a string :( [12:24] containing the time itself [12:25] larsu, do you know about the messaging indicator then? [12:25] larsu, I'm looking at https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 [12:26] Saviq: messaging indicator sends unix timestamps [12:26]