[08:47] <tsdgeos> ltinkl: do you have a sec?
[09:18] <ltinkl> tsdgeos, ye sure
[09:18] <tsdgeos> hmmm
[09:18] <tsdgeos> will come to you in a bit
[09:18] <tsdgeos> sorry :D
[09:24] <tsdgeos> ltinkl: you've got mail
[09:24] <ltinkl> tsdgeos, got it
[09:24] <tsdgeos> ltinkl: please uncompress
[09:25] <tsdgeos> run qmake && make in the ManglingImport folder
[09:25] <tsdgeos> and then from the root run
[09:25] <tsdgeos>  qmlscene -I . main.qml
[09:26] <tsdgeos> both with the Image { } from MySingleton commented and not commented
[09:26] <tsdgeos> i think both show bugs :D
[09:26] <tsdgeos> but i'd like you to have a look at all the code and tell me what you think before i convince you
[09:27] <ltinkl> tsdgeos, convince of what? :)
[09:27] <tsdgeos> that it's a bug in both cases (two different bugs)
[09:27] <ltinkl> ah
[09:27] <ltinkl> I get "QML Image: Cannot open ..." in both cases
[09:28] <tsdgeos> that's not the bug
[09:28] <tsdgeos> read the code please
[09:28] <tsdgeos> though you're doing it wrong
[09:29] <tsdgeos> if you comment the Image  {} from MySingleton you should not be getting that
[09:29] <tsdgeos> but
[09:29] <tsdgeos> $ qmlscene -I . main.qml
[09:29] <tsdgeos> Ignoring the url you set to  QUrl( "file:///home/tsdgeos_work/extendedTypeBug/RegularImage" )
[09:29] <tsdgeos> Ignoring the url you set to  QUrl( "file:///home/tsdgeos_work/extendedTypeBug/thisShouldBeIgnoredByImport" )
[09:29] <tsdgeos> qml: MoMoMoMo MoMoMoMo
[09:30] <tsdgeos> ltinkl: do you get that?
[09:31] <ltinkl> tsdgeos, yup I'm getting qml: MoMoMoMo MoMoMoMo
[09:31] <tsdgeos> and if you uncomment the image
[09:32] <tsdgeos> you get the "cannot open" variant
[09:32] <tsdgeos> right?
[09:32] <ltinkl> yup
[09:33] <tsdgeos> do you agree that both behaviours are wrong?
[09:34] <ltinkl> not sure, it's either getting the image from the C++ plugin or from the Image QML class right?
[09:37] <tsdgeos> the problem is
[09:37] <tsdgeos> that if the singleton loads an image
[09:37] <tsdgeos> the qmlRegisterExtendedType that gets loaded later is ignored
[09:37] <tsdgeos> that's problem A
[09:37] <tsdgeos> problem B is
[09:37] <tsdgeos> if the singleton is not loading the image
[09:38] <tsdgeos> the loading of ManglingImport in MyItem.qmll viralizes to the Image in main.qml that knows nothing about such import
[09:39] <ltinkl> problem A - perhaps it's designed that way, so that QML imports get precedence over C++ imports
[09:39] <ltinkl> problem B - ye, I get that, this is eird
[09:39] <ltinkl> w
[09:40] <ltinkl> but understandable imho, you're extending the QQuickimageBase, so basically Image is no longer the one shipped by Qt but your provided by the plugin
[09:40] <ltinkl> no matter where you import it
[09:41] <ltinkl> so once you import it, there's no going back to the original Image imo
[09:42] <ltinkl> how would QML know then which one to use?
[09:42] <tsdgeos> because it knows
[09:42] <tsdgeos> it has different metaobjects
[09:42] <tsdgeos> for different imports
[09:43] <tsdgeos> i.e. the image of 2.0 is different from the image of 2.4
[09:43] <tsdgeos> it has a different metaobject *
[09:43] <tsdgeos> they just need to also extend that for extended stuff
[09:43] <tsdgeos> i agree it's hard
[09:43] <tsdgeos> but not undoable
[09:43] <tsdgeos> and A it can't be designed that way
[09:44] <tsdgeos> it's a oversight i'd say that they forgot about it
[09:44] <tsdgeos> anyway will file two bugs and see what happens
[09:44] <tsdgeos> BTW A+QMLcache is what is making us crash in unity8 some cases
[09:45] <ltinkl> aha I see
[09:45] <ltinkl> ye definitely ask those 2 basic questions (bug reports) and see what they have to say
[11:26] <tsdgeos> pstolowski: greyback landed something so you need to rebuild the silo
[11:28] <greyback> and hopefully there's no conflicts
[11:29] <tsdgeos> greyback: can you do https://code.launchpad.net/~aacid/unity8/workaround_qt47709/+merge/267647 ?
[11:32] <greyback> tsdgeos: lgtm
[11:43] <tsdgeos> greyback: i think the last landing makes a test crash
[11:43] <tsdgeos> let me confirm
[11:43] <greyback> tsdgeos: which test?
[11:43] <tsdgeos> LauncherModelTest
[11:44] <tsdgeos> http://paste.ubuntu.com/12055032/
[11:44] <tsdgeos> not sure if it's new though
[11:44] <tsdgeos> how nice would be to have cI back ...
[11:44] <greyback> hmm, that's an old one
[11:44] <greyback> somehow has resurfaced
[11:44] <greyback> I recall there were times "app" was null
[11:45] <greyback> which didn't make sense
[11:47] <tsdgeos> greyback: do i open a bug? assign it to who?
[11:47] <greyback> tsdgeos: open bug anyway, will give it to dandrader
[11:48] <tsdgeos> isn't he off for like the next two weeks?
[11:48] <greyback> I *think* that's from tomorrow
[11:48] <tsdgeos> oki
[11:49] <pstolowski> tsdgeos, rebuilding
[11:50] <pstolowski> tsdgeos, have you found anything about the error i had?
[11:51] <tsdgeos> pstolowski: hadn't had time to test, promise first thing after lunch
[11:51] <tsdgeos> lunch now!
[11:51] <tsdgeos> greyback: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1483675
[11:52] <greyback> ta
[12:48] <tsdgeos> dandrader: vivid or wily?
[12:49] <dandrader> tsdgeos, vivid
[12:49] <tsdgeos> dandrader: weird, dist-upgraded?
[12:49] <dandrader> tsdgeos, yes
[12:50]  * tsdgeos scratches head
[12:54] <tsdgeos> pstolowski: you mentioned some issues with the silos not installing properly
[12:54] <tsdgeos> pstolowski: what do i do to fix it? or should work?
[12:54] <pstolowski> tsdgeos, yeah, you need to make sure you get versions from the silos
[12:55] <tsdgeos> oki
[12:55] <pstolowski> tsdgeos, apt-cache policy <foo> for every package
[12:55] <pstolowski> tsdgeos, then apt-get install foo=<version> using versions from ppa if needed
[12:56] <pstolowski> tsdgeos, but i'm still battling with silo 4. rebuilt failed
[12:56] <pstolowski> tsdgeos, looks like something landed also in unity api, so rebuilding
[12:56] <tsdgeos> k
[13:08] <tsdgeos> pstolowski: i guesswe need that rebuild
[13:08] <tsdgeos> i'm getting
[13:08] <tsdgeos> [1439298272.585212] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-VroDxW/mir-0.14.0+15.04.20150722/src/client/rpc/stream_socket_transport.cpp(168): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_m
[13:08] <tsdgeos> essage(const std::vector<unsigned char>&, const std::vector<mir::Fd>&)^M
[13:08] <tsdgeos> and unity8 restarts/crashes
[13:10] <tsdgeos> let me try to see on the desktop
[13:26] <tsdgeos> pstolowski: yeah can reproduce this Playlist thing on the desktop, investigating
[13:26] <pstolowski> tsdgeos, ok
[13:30] <tsdgeos> pstolowski: pushed a change, sorry
[13:31] <pstolowski> ok
[13:31] <pstolowski> tsdgeos, only unity8?
[13:31] <tsdgeos> yes
[13:32] <tsdgeos> how do i test it, the music scope was empty
[13:32] <tsdgeos> am i supposed to get something?
[13:32] <pstolowski> tsdgeos, do you have local music?
[13:32] <tsdgeos> pfff
[13:32] <tsdgeos> probably not
[13:32] <pstolowski> phew
[13:32] <tsdgeos> i mean i do have it
[13:32] <tsdgeos> but not where media-scanner wants it i guess
[13:32] <tsdgeos> i'll copy some stuff to ~/Music
[13:32] <tsdgeos> is it?
[13:33] <pstolowski> tsdgeos, yes
[13:33] <pstolowski> tsdgeos, then go to Tracks department in My Music
[13:34] <tsdgeos> ok
[13:35] <tsdgeos> hmm wait
[13:35] <tsdgeos> i do actually have stuff in ~/Music
[13:35] <tsdgeos> Caught an error from create_query(): unity::scopes::MiddlewareException: unity::ResourceException: RegistryObject::ScopeProcess::exec(): exec aborted. Scope: "mediascanner-music" took longer than 4000 ms to start.
[13:36] <tsdgeos> pstolowski: ↑ ?
[13:36] <pstolowski> tsdgeos, do you have all the versions from ppa? including mediascanner2.0 and unity-scope-mediascanner2?
[13:36] <tsdgeos> yeah
[13:36] <tsdgeos> http://paste.ubuntu.com/12055524/
[13:38] <pstolowski> tsdgeos, hmm. need to wait for rebuild. what phone image do you have?
[13:38] <tsdgeos> pstolowski: this is on the pc
[13:38] <tsdgeos> pstolowski: on the phone can't test because the mir crash/restart
[13:38] <pstolowski> tsdgeos, ah... i can't test on the PC ;)
[13:39] <pstolowski> tsdgeos, waiting for the build, will check on the phone
[13:39] <tsdgeos> ok
[13:39] <tsdgeos> i'll uninstall the stuff from the PC
[13:39] <tsdgeos> and do something else while waiting for the rebuild :)
[13:41] <pstolowski> tsdgeos, keep fingers crossed for the build if your hands are free ;)
[13:43] <tsdgeos> he he
[14:07] <pstolowski> tsdgeos, can you check if https://code.launchpad.net/~aacid/unity8/dash_activation_no_special_casing/+merge/264024 merges ok with trunk?
[14:08] <tsdgeos> hmm
[14:08] <tsdgeos> it should
[14:08] <tsdgeos> let me check
[14:08] <tsdgeos> pstolowski: yeah merges fine here
[14:08] <pstolowski> tsdgeos, ok thanks
[14:18] <pstolowski> tsdgeos, silo 4 built
[14:19] <tsdgeos> pstolowski: cool
[14:44] <tsdgeos> pstolowski: seems to "do things" :D
[14:44] <tsdgeos> pstolowski: if i play the first track is it supposed to play the next?
[14:44] <pstolowski> tsdgeos, only if from same album
[14:44] <tsdgeos> ok
[14:44]  * tsdgeos waits 2:20
[14:45] <pstolowski> tsdgeos, does it integrate with indicator?
[14:47] <tsdgeos> pstolowski: not yet, jhodapp said he wanted to wait for something that used it to enable it
[14:47] <tsdgeos> or that's what i understood
[14:50] <tsdgeos> doesn't seem the play next song worked
[14:50] <tsdgeos> let me add some console.log
[14:52] <jhodapp> tsdgeos, correct
[15:00] <tsdgeos> jhodapp: so silo 4
[15:02] <jhodapp> tsdgeos, silo 4?
[15:03] <tsdgeos> jhodapp: if you join it with silo 38 has a somewhat working audio card support on the dash
[15:03] <jhodapp> tsdgeos, oh very nice
[15:03] <jhodapp> tsdgeos, thanks
[15:03] <tsdgeos> for some reason playing the first time fails
[15:03] <tsdgeos> you have to play twice
[15:03] <jhodapp> tsdgeos, so I assume you can't land silo 4 until the indicator controls work?
[15:03] <tsdgeos> and the playlists don't work either
[15:04] <tsdgeos> but not sure whose fault it is
[15:04] <tsdgeos> debugging a bit
[15:04] <tsdgeos> jhodapp: correct
[15:04] <pstolowski> jhodapp, also we need to wait for silo 27 to land and then rebuild
[15:04] <jhodapp> tsdgeos, let me give you a Test.qml file that you can use to compare things against
[15:05] <pstolowski> tsdgeos, last time i checked with scopes-client it was exposing playlists as expected. perhaps we have a mismatch in names or something trivial like that somewhere
[15:05] <pstolowski> tsdgeos, i mean between dash and scope
[15:06] <jhodapp> tsdgeos, alright, shared with you on google drive
[15:06] <tsdgeos> pstolowski: sure, also debugging that
[15:07] <jhodapp> tsdgeos, just use qmlscene Test.qml --desktop_file_hint=/usr/share/applications/mediaplayer-app.desktop
[15:07] <jhodapp> tsdgeos, and make sure to change the sources listed in there to ones you have on your test device
[15:07] <tsdgeos> k tx
[15:07] <jhodapp> *music sources
[15:10] <tsdgeos> pstolowski: yeah looks good, seems i'm losing it somehow at some point
[15:16] <tsdgeos> booo me
[15:16] <tsdgeos> you can't obviously store an array in a url :D
[15:16] <pstolowski> boo
[15:16] <tsdgeos> if the sdk wasn't overflowing us with warnings
[15:16] <tsdgeos> maybe even the qml interpreter told me
[15:16] <tsdgeos> at some stage
[15:20] <tsdgeos> also the song i'm trying is longer that it says it is?
[15:20] <tsdgeos> pstolowski: 2:47 vs 2:45 ?
[15:20] <tsdgeos> wooo, works :)
[15:20] <pstolowski> \o/
[15:20] <pstolowski> tsdgeos, afaik the duration is read from mp3 tags or some such, may not be precise?
[15:21] <tsdgeos> may be
[15:21] <pstolowski> alecu, ^^^
[15:22] <tsdgeos> the file doesn't seem to have that in the tags
[15:22] <tsdgeos> http://paste.ubuntu.com/12056055/
[15:22] <alecu> pstolowski: is that inline playback?
[15:22] <pstolowski> tsdgeos, hmm in any case this is what mediascanner backend tells me. probably it gets it from gstreamer
[15:23] <pstolowski> alecu, yes
[15:23] <alecu> pstolowski: what's the silo number?
[15:23] <alecu> pstolowski: wonderful
[15:23] <pstolowski> alecu, 4 + 38. but indicator intergation is not enabled yet
[15:26] <tsdgeos> it's pretty nifty going back and forth
[15:26] <tsdgeos> and still works :D
[15:27] <tsdgeos> even on the album preview
[15:27] <tsdgeos> even if you played it from the tracks list
[15:27] <tsdgeos> cool
[15:35] <tsdgeos> jhodapp: the debug is weird
[15:35] <tsdgeos> the first time i add things to the playlist i have
[15:36] <tsdgeos> http://paste.ubuntu.com/12056136/
[15:36] <tsdgeos> while the second i have
[15:36] <tsdgeos> http://paste.ubuntu.com/12056137/
[15:36] <tsdgeos> but i'm passing the urls the same way
[15:36] <tsdgeos> let me console.log them
[15:40] <tsdgeos> jhodapp: can it be that addSources to a playlist are ignored if it's not part of a player?
[15:40] <tsdgeos> that may explain why the second time works
[15:40]  * tsdgeos tries
[15:41] <jhodapp> tsdgeos, yes there's a possible bug in the QDeclarativePlaylist impl
[15:41] <jhodapp> tsdgeos, let me get back to you in a little bit, on a hangout
[15:46] <tsdgeos> yeah i sthat
[15:46] <tsdgeos> i guess i can workaround it in my code easily
[15:46] <tsdgeos> i mean i just did
[15:46] <tsdgeos> but would make sense fixing it anyhow
[15:49] <tsdgeos> pstolowski: can you rebuild the silo so that it includes the two last fixes i made?
[15:49] <tsdgeos> pstolowski: unity8
[15:49] <pstolowski> tsdgeos, ok
[15:53] <jhodapp> tsdgeos, yes indeed, there will be several bugs to fix
[15:53] <jhodapp> tsdgeos, can you file that bug against qtmultimedia-opensource-src package?
[15:54] <pstolowski> tsdgeos, rebuilding
[15:58] <tsdgeos> jhodapp: https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src/+bug/1483806
[15:58] <tsdgeos> pstolowski: cool
[15:58] <jhodapp> tsdgeos, thanks!
[15:59] <jhodapp> tsdgeos, oh right, yes it clears the playlist when it attaches to a player
[15:59] <jhodapp> tsdgeos, I didn't realize that's what you were trying to do...this is on purpose
[15:59] <tsdgeos> ok
[15:59] <tsdgeos> it's not a big thing i just did it the other way around
[16:00] <jhodapp> well actually no this is a valid bug, nm
[16:00] <tsdgeos> but if that's the behaviour, make sure it's documented :D
[16:00]  * tsdgeos eods
[16:00] <jhodapp> it will clear any existing playlist attached to the player
[16:07] <pstolowski> davmor2, does silo 27 work for you now?
[16:15] <davmor2> pstolowski: I'm on another silo currently will return to that after
[16:16] <pstolowski> davmor2, ok
[16:16] <pstolowski> anyway, eod. cu
[19:02] <dandrader> josharenson, ping
[19:18] <josharenson> dandrader: pong
[19:20] <dandrader> When I run "make tryWideView" all users have a "Tap do unlock" button. Some of them should display a text entry for instance, for typing the password
[19:21]  * josharenson runs that test
[19:21] <dandrader> josharenson, do you know what's wrong there (with the mocks most likely)
[19:21] <dandrader> ?
[19:24] <josharenson> sorry didn't have a good build, compiling now
[19:28] <josharenson> dandrader: ah I see. Nothing happens when you "tap to unlock" but there should be a text box, yes?
[19:29] <josharenson> does it hang for you?
[19:31] <dandrader> josharenson, yeah, nothing happens.
[19:31] <josharenson> looking into it, either a problem with the mock, or the wrong lib is being loaded in the test I would imagine
[19:31] <dandrader> josharenson, The "Has Password" user should naturally display a message box for typing the password, for instance
[19:33] <dandrader> josharenson, I wanted to debug that login message box and because of this bug in the test there's no easy way to do so :/
[19:33] <josharenson> dandrader: ok, give me a few, I'll ping you when I find something
[20:46] <dandrader> josharenson, hey
[20:46] <josharenson> dandrader: hi
[20:46] <dandrader> josharenson, does PhysicalKeysMapper have some logic to ensure you don't change the volume while your'
[20:47] <dandrader> josharenson,  you're pressing the volume keys to get a screenshot?
[20:47] <josharenson> dandrader: it should, saviq/I fixed that a while ago I thought
[20:47] <josharenson> dandrader: I honestly don't remember what the exact solution ended up being, I'd have to look at it
[20:53] <dandrader> josharenson, we just don't have a test guarding this feature
[20:54] <josharenson> dandrader: I could swear I wrote some... let me look
[20:54] <dandrader> josharenson, I bet https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/267188 will inadvertently break it
[20:58] <josharenson> dandrader: I see. Either that code needs logic to handle not showing volume notifications, or it needs to let volume key events through, which is a bad idea
[20:59] <dandrader> josharenson, just commented there that it might break this behavior
[20:59] <josharenson> dandrader: I'll try and do a review if I have some time later
[21:00] <dandrader> josharenson, if you want to. I already did my second pass over there
[21:00] <josharenson> ok
[21:00] <dandrader> or third, actually
[21:02] <dandrader|afk> josharenson, but it would be great if you could confirm me whether we have a test for this screenshot vs. volume case. I didn't find any in tst_PhysicalKeysMapper.qml
[21:03] <josharenson> dandrader|afk: ok ill look for it for sure. Also, before you go away, I can't find anything wrong w/ the greeter wide view
[21:03] <josharenson> oh wait
[21:03] <josharenson> hang on
[21:12] <josharenson> dandrader|afk: ah, there was a negative test when the screenshot sequence was Power+VolDown but it looks like it never changed when we reverted to VolUp+VolDown
[21:20] <dandrader|afk> ok. see you next week