[08:40] <dednick> mzanetti: ping
[08:41] <dednick> mzanetti: i'm getting strange results from the unitytestcase::findChild function.
[08:41] <dednick> I added a console log to print the array each loop. http://paste.ubuntu.com/8112553/ ever seen something like that?
[08:42] <dednick> mzanetti: find invisible seems to work though
[08:42] <mzanetti> dednick: maybe a loop in some item.children?
[08:42] <mzanetti> dednick: is this your recursive qml hack?
[08:46] <dednick> mzanetti: it is, but same if i remove it
[08:47] <mzanetti> weird...
[08:47] <mzanetti> dednick: well, no, I haven't seen that before...
[08:47] <mzanetti> dednick: let me know if you need me to have a closer look. right now I can't tell much
[08:48] <dednick> mzanetti: hm. it is the children var though. if i remove that it works
[08:48] <dednick> mzanetti: it's a model
[08:49] <mzanetti> dednick: ah, so you have a var named children?
[08:49] <dednick> mzanetti: yes
[08:49] <mzanetti> dednick: ok... findChild() does item.children
[08:49] <mzanetti> dednick: the qml parent mechanism works through a variable named children
[08:49] <dednick> mzanetti: ah. doh
[08:49] <mzanetti> so you might not want to use that name
[08:49] <dednick> stupid
[08:50] <dednick> heh. yeah :)
[09:08] <Cimi> tsdgeos, can you merge scope settings? https://code.launchpad.net/~aacid/unity8/category_view_invisible_in_preview_mode/+merge/231844
[09:08] <Cimi> tsdgeos, as well as adding tests
[09:09] <tsdgeos> Cimi: eh?
[09:09] <Cimi> tsdgeos, https://code.launchpad.net/~cimi/unity8/scope-settings
[09:09] <tsdgeos> which test do you want me to add?
[09:09] <Cimi> tsdgeos, that it turns visible :)
[09:10] <Cimi> tsdgeos, just add a visibility check in openPreview/closePreview and settings
[09:10] <Cimi> tsdgeos, one liner
[09:11] <Saviq> tsdgeos, looks like you forgot a prerequisite, too, since silo 16 didn't land yet
[09:11] <Saviq> and won't, until Daniel shows up :|
[09:11] <tsdgeos> damn
[09:11] <tsdgeos> nah i just had a polluted "clean" unity8
[09:11] <tsdgeos> for some reason
[09:11] <tsdgeos> Cimi: not going to merge it for now
[09:11] <Saviq> *or* I strip the qtmir changes out from the silo...
[09:11] <Saviq> maybe that's more productive actually
[09:12] <tsdgeos> Cimi: i'm in my world of trying to make stuff a bit faster, will care of merging when it's merged :D
[09:13] <tsdgeos> Cimi: i'll add a test, good idea
[09:20] <Cimi> tsdgeos, if you don't merge scope settings I will have conflicts
[09:22] <tsdgeos> well, let's just get scope settings merged first hten
[09:22] <tsdgeos> and i will have conflicts
[09:28] <tsdgeos> lol
[09:28] <tsdgeos> making the thing non visible
[09:28] <tsdgeos> changes its content height
[09:28] <tsdgeos> and stuff breaks
[09:28] <tsdgeos> that is totally unpredicted
[09:28] <Saviq> greyback, bad news in the morning... had to pull qtmir changes from the silo - most probably lifecycle broke trusted prompts
[09:29] <Saviq> greyback, landing just unity8 changes now, will recreate the silo with qtmir back after that
[09:29] <greyback> Saviq: ok
[09:58] <Saviq> Cimi, https://code.launchpad.net/~saviq/unity8/header-customizations/+merge/230719/comments/564353
[10:00] <Saviq> Cimi, had a thought... for the bottom part of the divider highlight
[10:00] <Saviq> Cimi, we could have a shader for one pixel and stretch that
[10:01] <Cimi> Saviq, what's the advantage?
[10:02] <Saviq> Cimi, I've not a good idea how to come up with the right colour for it...
[10:02] <Saviq> Cimi, without introducing nasty apis
[10:02] <Saviq> Cimi, but let me try that first
[10:02] <Cimi> Saviq, the current color is not right?
[10:02] <Saviq> Cimi, it is
[10:02] <Saviq> Cimi, but not when there's departments
[10:02] <Cimi> Saviq, I stop you, shading one pixel is too risky, we need more samples
[10:03] <Cimi> Saviq, what if we have one bg image with some details there (or a origami efect or whatever)
[10:03] <Saviq> Cimi, well, that only depends whether we want to support the highlight to be non-uniform
[10:03] <Cimi> Saviq, it might make the shader change
[10:03] <Cimi> you see the highlight changing color
[10:04] <Saviq> Cimi, well, with the *other* solution, I only go for a flat colour too
[10:05] <Cimi> Saviq, but this does not change
[10:05] <Saviq> Cimi, it doesn't look at the image at all, either
[10:05] <Saviq> Cimi, so what colour do I come up with then?
[10:06] <Cimi> Saviq, either you sample more than 1 pixel, like 1gu
[10:06] <Cimi> at least
[10:06] <Saviq> Cimi, you know well that that's just as prone to failure as anything else
[10:06] <Saviq> Cimi, what if that one gu at the top left is black
[10:07] <Cimi> Saviq, so again, this is broken
[10:07] <Saviq> Cimi, but just next to it something starts happening
[10:07] <Cimi> Saviq, that's why is not a big improvement over the current solution
[10:07] <Saviq> Cimi, yeah, so what then? full shader for just that stupid highlight?
[10:07] <Cimi> Saviq, so let's leave as it is :)
[10:08] <Saviq> Cimi, it can't be left as is
[10:08] <Cimi> Saviq, or just sample 1gu in the middle
[10:08] <Saviq> Cimi, I need to do *something*
[10:08] <Cimi> ahah ok
[10:08] <Cimi> :)
[10:08] <Saviq> Cimi, and either I support an image or not
[10:08] <Saviq> Cimi, if I don't, I might as well just sample the top 1 px (or find out the top color from the background definition)
[10:09] <Saviq> Cimi, if I do, it needs to be a full shader
[10:09] <Saviq> Cimi, truth be told, if it *is* an image, maybe we just require the highlight to be built into it?
[10:09] <Saviq> and just not do anything
[10:10] <Saviq> Cimi, I think that might really be the best thing to do
[10:11] <Cimi> Saviq, we want a solution that we can port to the sdk
[10:11] <Saviq> Cimi, not here we don't necessarily
[10:11] <Saviq> Cimi, that navigation thing does not exist in the sdk
[10:11] <Saviq> Cimi, and if it did, we don't know if it would support images anyway
[10:12] <Saviq> Cimi, *and* if it did, if you wanted an image, just highlight it yourself
[10:12] <Saviq> Cimi, it's not like we're that flexible in the SDK
[10:14] <Saviq> Cimi, ah dammit, it's just freakin' 4 pixels high or something
[10:14] <Cimi> ahahahah
[10:14] <Saviq> Cimi, you are a bastard for forcing me to do this :P
[10:14] <Cimi> Saviq, I like you being perfectionist :)
[10:15] <Saviq> Cimi, *I'm* not, not really, I wanted a compromise :P
[10:21] <mzanetti> oh... only 19 approved branches
[10:21] <mzanetti> seems a review a day just moves the queue to another place :D
[10:23] <mzanetti> zbenjamin: hey, regarding this: https://code.launchpad.net/~zeller-benjamin/unity8/scope-url/+merge/231749
[10:24] <zbenjamin> mzanetti: yes
[10:24] <mzanetti> zbenjamin: is performQuery really what you want?
[10:24] <zbenjamin> mzanetti: thats what Saviq told me to use
[10:24] <mzanetti> in other words, does this what you want?
[10:25] <zbenjamin> mzanetti: well when it shows the scope , it does
[10:25] <zbenjamin> mzanetti: i could not test it because it crashes unity, Saviq told me to upload the branch so he can have a look
[10:26] <mzanetti> ah ok
[10:27] <Saviq> mzanetti, yeah, that should be what he wants, wasn't able to get on it yet
[10:28] <mzanetti> I would have expected to call goToScope()
[10:28] <mzanetti> but I realize that might not work for non-favorite scopes
[10:29] <tsdgeos> soooo, i just discovered we should not make height depend on visible, otherwise when you hide a whole root because you don't want to show it
[10:30] <tsdgeos> the inner parts get all the sizes changed and you get lots of updates for no reason
[10:30] <tsdgeos> you were trying to save rendering and suddently all your nodes moved around
[10:30] <Saviq> tsdgeos, ugh
[10:30] <tsdgeos> and we do that a lot :D
[10:46] <Saviq> Cimi, ok, task for you: find out a shader line I need to use to calculate the highlight color :P
[10:51] <Cimi> Saviq, the line where the shader needs to be? :)
[10:51] <Cimi> the pixels under the divider?
[10:52] <Saviq> Cimi, no, the actual shader code
[10:52] <Cimi> Saviq, same thing we have now
[10:52] <Saviq> Cimi, there is no .lighter() in glsl
[10:52] <Cimi> Saviq, lighter is an algorithm
[10:52] <Saviq> Cimi, yes, find it
[10:52] <Saviq> Cimi, find out how do I, in shader code, do .lighter(1.2)
[10:54] <Cimi> ok
[10:54] <Cimi> Saviq, convert to HSL
[10:54] <Cimi> Saviq, multiply s and l for that argument
[10:54] <Cimi> Saviq, IIRC
[10:55] <Saviq> Cimi, there is no .convertToHsl in gsls
[10:55] <Cimi> Saviq, which colorspace we have?
[10:55] <Cimi> Saviq, frb?
[10:55] <Saviq> Cimi, rgb
[10:55] <Cimi> *rgb
[10:55] <Cimi> ok we need to convert to hsl
[10:55] <Saviq> Cimi, and .lighter in Qt does hsv, and v * argument
[10:55] <Saviq> Cimi, nothing with s
[10:55] <Cimi> you can do hsv then
[10:56] <Cimi> Saviq, changing saturation as well is cool
[10:56] <anpok> better fake with a lightness vector in rgb
[10:57] <anpok> http://en.wikipedia.org/wiki/Luminance_(relative)
[10:58] <Saviq> anpok, yeah, howto? :)
[10:58] <Cimi> Saviq, or http://css-tricks.com/snippets/javascript/lighten-darken-color/
[10:59] <anpok> 1.2 is a lightness factor?
[11:00] <anpok> or increas in luminosity
[11:00] <Saviq> anpok, that's what .v gets multiplied by
[11:00] <Saviq> anpok, in hsv that is
[11:03] <anpok> fragcolor * mat4(1,0,0,0.2126,0,1,0,0.7152,0,0,1,0.0722,0,0,0,1)*1.2; would be my guess.
[11:04] <anpok> + additional fiddling on the vector, gamma correction,...
[11:04] <anpok> oops
[11:04] <anpok> the other way around ofc
[11:04]  * anpok hides in shame
[11:07] <Saviq> anpok, yeah, that became green/yellow from black :)
[11:07] <Saviq> anpok, but you have to bear with me here, I've no idea what I'm doing :)
[11:11] <Saviq> bregma, hey, you around?
[11:12] <Saviq> greyback, did you manage to get a unity8 desktop session on your machine in the end?
[11:12] <greyback> Saviq: yes, I've had it working some time now
[11:13] <greyback> whenver it lets me log in ofc
[11:13] <Saviq> greyback, could you test silo 16 (`citrain host-upgrade 16`) for bugs #1350878 and #1353041 ?
[11:13] <greyback> Saviq: on it
[11:13] <Saviq> greyback, thank youse
[11:15] <anpok> are special qt libs necessary to run unity8 on desktop? (GL vs GLESv2)
[11:16] <greyback> anpok: nothing special no
[11:19] <facundobatista> Holas
[11:19] <Saviq> o/
[11:21] <facundobatista> hola Saviq :)
[11:22] <tsdgeos> Saviq: who wrote the "just run with "QSG_VISUALIZE=batches" and scroll in the dash. You see lots of colours and they change on scroll - which means Qt has to re-batch them each frame, which is very slow. https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1350863" part ?
[11:22] <Saviq> anpok, so, pointers on how to make the lighting happen? You saying "gamma correction of course" didn't really register ;)
[11:22] <Saviq> tsdgeos, greyback
[11:22] <Saviq> I think
[11:23] <greyback> tsdgeos: yes it was I *big reveal*
[11:23] <tsdgeos> greyback: i don't see it happening
[11:23] <greyback> tsdgeos: it was fixed
[11:23] <tsdgeos> ah
[11:24] <tsdgeos> right i should read what ubot5 says
[11:25] <greyback> tsdgeos: you can still see a bit of it in the dash today, but for other reasons I suspect
[11:25] <tsdgeos> greyback: it's because the "dash overview thing in the bottom" changes opacity
[11:25] <tsdgeos> causing the scene graph to rebuild itself
[11:26] <greyback> tsdgeos: yes that would do it, but you see it even just scrolling around. (this was me trying 3 weeks ago though, it may have improved)
[11:27] <tsdgeos> greyback: the "dash overview thing in the bottom" changes opacity while scrolling
[11:27] <tsdgeos> i.e. it deppends if your oon top or not to show itself or not
[11:27] <greyback> tsdgeos: ah I see. I would've expected that to be in a separate batch though, it shouldn't cause the whole SG to be rebatched
[11:28] <tsdgeos> it does
[11:28] <greyback> ouch
[11:28] <tsdgeos> greyback: http://paste.ubuntu.com/8113535/
[11:30] <greyback> so it appears.
[11:32] <anpok> Saviq: fragcolor.r += fragcolor.r*0.21*lightness_factor; fragcolor.g += fragcolor.g*0.72*lightness_factor; fragcolor.b += fragcolor.b*0.07*lightness_factor;
[11:33] <Saviq> anpok, thanks!
[11:33] <anpok> Saviq: with gamma I meant removing gamma correction before applying the ligthness and reappling it afterwards
[11:33] <anpok> not sure how to do that efficient in ges
[11:33] <anpok> *glsl
[11:34] <anpok> factor is maybe the wrong word .. btw it is rather a lightness translation .. means 0 is no change..
[11:35] <Saviq> anpok, ok thanks
[11:36] <tsdgeos> Saviq: do you remember the things that broke here? http://paste.ubuntu.com/8113598/
[11:38] <Saviq> tsdgeos, the sizes were not calculated right
[11:38] <Saviq> tsdgeos, because if invisible, text wasn't laid out
[11:38] <tsdgeos> which may be fixed in my "don't use visible to calculate size" thing?
[11:38] <tsdgeos> i've made it non visible now and can''t find any issue
[11:38] <tsdgeos> was it obvious everywhere?
[11:40] <tsdgeos> let me try it in an unpatched one
[11:40] <tsdgeos> :D
[11:40]  * tsdgeos slot sometimes
[11:41] <tsdgeos> slot -> slow
[11:41] <tsdgeos> oh yes it breaks
[11:47] <Cimi> Saviq, tsdgeos I have an issue with test Card
[11:47] <Cimi> the variables title, art, etc etc
[11:47] <Cimi> inside the testcase
[11:47] <Cimi> they don't get updated quick enough when I change index
[11:47] <Saviq> tsdgeos, well, the calculations were wrong is all
[11:48] <Saviq> Cimi, all the other tests seem to manage?
[11:48] <Cimi> so at the beginning of a new iteration of a test, I might have the old title item
[11:48] <Cimi> Saviq, all other tests seem not to use those
[11:48] <Saviq> tsdgeos, not sure the test actually covered this issue
[11:49] <Cimi> Saviq, I started having this issue using GRID_UNIT_PX different than 8
[11:49] <Cimi> mzanetti, is waitForRendering enough?
[11:50] <mzanetti> Cimi: hmm... isn't that already there?
[11:50] <Cimi> mzanetti, it was
[11:50] <Cimi> mzanetti, not helping
[11:50] <Cimi> a wait(50) helps
[11:50] <mzanetti> Cimi: not happy with wait(50)
[11:50] <Cimi> I tried deactivating the loader at the end of a test
[11:50] <Cimi> no joy
[11:51] <mzanetti> Cimi: right... you could set the vars to null in cleanup()
[11:51] <mzanetti> Cimi: then set them again in init()
[11:51] <Saviq> zbenjamin, did the url dispatcher work for you on desktop?
[11:52] <zbenjamin> Saviq: i tried only on the phone
[11:52] <Saviq> zbenjamin, k
[11:52] <Cimi> mzanetti, not helps
[11:52] <Cimi> mzanetti, there is also cardTool in between
[11:53] <Cimi> mzanetti, giving the sourceComponent to the loader
[11:53] <Cimi> in few words, this testCase is asking for races
[11:56] <Saviq> zbenjamin, hmm I wonder how it even got to your dash... unity8-dash isn't an u-a-l-launched application... so not sure how url dispatcher could get to it :/
[11:58]  * Saviq thinks we need to make it an u-a-l launched one...
[12:00] <zbenjamin> Saviq: ok, did it not happen for you at all?
[12:00] <Saviq> zbenjamin, yeah, url dispatcher just throws stuff around and fails, it never reaches unity8-dash
[12:02] <Saviq> zbenjamin, from dbus-monitor: http://paste.ubuntu.com/8113738/
[12:02] <Saviq> zbenjamin, it tries to launch unity8-dash as an app under u-a-l and that fails
[12:03] <zbenjamin> Saviq: ok :/
[12:03] <Saviq> zbenjamin, I'll have a chat with tedg today how to clear this up
[12:03] <zbenjamin> Saviq: so its not so trivial after all..
[12:03] <zbenjamin> Saviq: ok thx very much for helping with this
[12:03] <Saviq> zbenjamin, it should be possible to make unity8-dash being wrapped with u-a-l, which would also give us lifecycle for it
[12:04] <zbenjamin> Saviq: yes, sounds perfect to me
[12:04] <Saviq> wonder why it does fail actually
[12:09] <kgunn> +1 on landing just the unity8 stuffs
[12:09] <kgunn> ...and i was really suspicious of that pin lock
[12:12] <Saviq> greyback, any feedback on desktop silo 16 yet?
[12:13] <greyback> Saviq: my test machine is a bit on the slow side, it's almost finished updating
[12:13] <Saviq> greyback, ah
[12:15] <Saviq> kgunn, yeah, but I was almost sure we did the same for ap tests that we do for ./run.sh, obviously not, but should be an easy fix
[12:17] <kgunn> sure
[12:39] <Saviq> Cimi, merge prerequisite into scope settings please, there's conflicts or at least --weave is required
[12:39] <Saviq> hmm
[12:39] <Saviq> *or* there's simply a conflict
[12:43]  * tedg is confused, why is URL dispatcher touching the dash?
[12:43] <tsdgeos> Saviq: yeah there's still something wrong
[12:43] <tedg> Saviq, ^
[12:44] <Saviq> tedg, because we want it to support scope:// urls
[12:44] <tedg> Oh
[12:44] <tedg> Hmm, yeah, we can't use the standard mechanisms for that.
[12:45] <Saviq> tedg, well, we could, if unity8-dash would be ual-launched
[12:45] <tedg> Saviq, Yeah, but that's a bad idea :-)
[12:45] <Saviq> tedg, why?
[12:45] <Saviq> tedg, it's just an app these days, only special thing about it is that it starts automagically and respawns
[12:46] <tedg> Because UAL does a bunch of stuff that you don't need and doesn't do a bunch of stuff you want. Setting up environments vs. respawn
[12:46] <Saviq> tedg, right, so that is what I wanted to talk to you about ;)
[12:47] <tedg> I guess if respawn is the only feature you care about, you could do that manually.
[12:48] <Saviq> tedg, or have a task on application APP_ID=unity8-dash stopped ;)
[12:48] <Saviq> tedg, that would start it up again
[12:48] <tedg> Exactly
[12:48] <Saviq> and on unity8 started
[12:48] <Saviq> tedg, so, problem is that we have NoDisplay=true
[12:48] <Saviq> tedg, that seems to make application-legacy unhappy :/
[12:49] <tedg> Yes, because that means it's not an application :-)
[12:50] <tedg> I guess what I don't like is that I like the idea that "application" means something. It's not just "process". I worry about blurring that definition.
[12:50] <tedg> Application means it has an icon in the apps-scope, means it shows up on the launcher, etc.
[12:50] <Saviq> tedg, could application be a wrapper around process then? ;)
[12:51] <tedg> It is, and the process manager is Upstart.
[12:51] <tedg> So that's why it feels more right for me to have the dash be an Upstart job.
[12:51] <Saviq> tedg, ok then, how do we hook up url-dispatcher to the non-application dash then?
[12:51] <Wellark> mzanetti: I trying to get to the pin unlock dialog still later today
[12:51]  * Saviq wanted lifecycle, too :/
[12:51] <tedg> I think that we special case the scope URL.
[12:52] <Wellark> although I've been up for 29h straight, so let's see how it goes
[12:55] <Saviq> ChrisTownsend, oh, just the man I wanted to see
[12:55] <tedg> Saviq, I think the idea that an "application" is wrapper around a process just gave me a slide for my presentation in two weeks on confinement :-)
[12:55] <Saviq> ChrisTownsend, care to test out silo 16 for unity8 on desktop (log in and log out mostly)?
[12:56] <ChrisTownsend> Saviq: Hey, yeah, sure I can do that.
[12:56] <tedg> Saviq, So I guess I'm undecided, I definitely see your point, but I like the idea of application being smaller.
[12:57] <Saviq> tedg, so the only thing that I see as not possible right now
[12:57] <Saviq> tedg, is to launch an app that has NoDisplay=true, which I'm not sure I agree with
[12:57] <greyback> Saviq: both bugs are fixed
[12:57] <Saviq> tedg, we have a launcher for the media player in dash apps
[12:57] <greyback> Saviq: the desktop session ones
[12:57] <Saviq> greyback, awesome, thanks
[12:58] <Saviq> tedg, which is useless, 'cause just says "you didn't pass a file, I'm done"
[12:58] <tedg> Saviq, Yes, media player is an interesting case, because it, for instance shows up on the launcher, what if you pin it there?
[12:58] <Saviq> tedg, sure, you pinned it there, doesn't mean it should be *listed* as an app
[12:58] <Saviq> dunno
[12:58] <tedg> Saviq, It seems to me "if it's an app, it should be an app" so it needs to fix that experience or become a trusted prompt session over the app playing the video.
[12:59] <Saviq> tedg, right, or part of the app simply
[12:59] <Saviq> tedg, as I said, "I'm not sure"
[13:00] <tedg> The problem, of course, with me talking about this is then you can easily ask "what is an application then?" and that's harder to answer :-)
[13:00] <ChrisTownsend> Saviq: greyback: Regarding desktop logout, there is still the issue where it kicks you back to the Unity8 Greeter, but that is a separate issue.
[13:00] <greyback> ChrisTownsend: yep I reproduced that
[13:00] <Saviq> ChrisTownsend, so long as you *can* log in and out, we're in a much better place than we were ;)
[13:01] <greyback> ChrisTownsend: I guessed it was some upstart job mis-behaviour
[13:01] <ChrisTownsend> Saviq: greyback: If I add some pre/post-stop upstart directives that were originally in the unity8-desktop-session upstart stuff, then logout works.  But I'm not sure if those break the phone.
[13:01] <ChrisTownsend> Saviq: Exactly!
[13:01] <Saviq> ChrisTownsend, well, there is not a "log out" option on the phone
[13:01] <Saviq> ChrisTownsend, so unity8 basically never gets stopped there
[13:02] <Saviq> ChrisTownsend, so from a first glance it looks like it could just be there
[13:02] <ChrisTownsend> Saviq: Oh, well then, I'll propose a fix and you guys can ack/nack it.
[13:02] <Saviq> ChrisTownsend, *but*, I must say I dislike the idea of unity8's post-stop job stopping the session
[13:02] <ChrisTownsend> Saviq: Yeah, it seems kind of hack-y.
[13:02] <Saviq> ChrisTownsend, I'd think this is something that should happen by unity8 asking logind or lightdm or something
[13:03] <ChrisTownsend> Saviq: Right
[13:03] <Saviq> ChrisTownsend, but I've not a good idea still what's the real relationship between all those
[13:07] <ChrisTownsend> Saviq: Regarding the logout issue, once this new Unity8 lands, I'll enter a new bug, then we can go from there.
[13:07] <Saviq> ChrisTownsend, yup
[13:08] <Saviq> tedg, ok then, special handling, can we just use UriHandler as everything else does?
[13:08] <Saviq> tedg, or does it not work without APP_ID or so?
[13:08] <Saviq> (we can get it an APP_ID, too)
[13:08] <tedg> Saviq, Yeah, no the appid processing is only in URL Dispatcher.
[13:08] <ChrisTownsend> Saviq: Ok, login/logout work now with package from the silo.
[13:08] <tedg> Saviq, Do you want it send via the FD.o interface on DBus?
[13:09] <tedg> Saviq, It'd be easier for me if it could register for a well known name.
[13:09] <Saviq> tedg, could do, although that means *we* need to do more work ;)
[13:09] <Saviq> tedg, and well, UriHandler registers itself anyway, since it's a singleton?
[13:10] <Saviq> tedg, maybe we could make UriHandler accept a path/name as property?
[13:10] <Cimi> Saviq, there's conflicts where?
[13:10] <tedg> Saviq, I believe so, on /$(appid)
[13:10] <Saviq> Cimi, nowhere
[13:10] <Cimi> Saviq, dash overview is in trunk
[13:10] <Saviq> Cimi, ignore
[13:10] <Cimi> Saviq, I merged trunk
[13:10] <tedg> Saviq, Uhm, probably not good since we don't want most apps registering names, confinement doesn't allow it.
[13:11] <tedg> Saviq, If anywhere in the app you register for a name, everything gets it.
[13:11] <Saviq> tedg, can be hidden api ;)
[13:11] <Saviq> Cimi, yeah, wrong ordering of branches in the train
[13:11]  * tedg prefers non-existant over hidden :-)
[13:11] <Saviq> Cimi, everything's good
[13:11] <Saviq> tedg, same as with NoDisplay=true eh?
[13:12] <tedg> Saviq, Yeah, that's such a BS thing to put in the file.
[13:14] <Saviq> tedg, ok, we'll have to come up with a name for you
[13:15] <Saviq> tedg, or you can come up with one for us (well, we have com.canonical.UnityDash already, so that probably won't change
[13:16] <tedg> Saviq, Oh, if you've got that already I can probably just use that.
[13:16] <tedg> Saviq, See, no work for you ;-)
[13:16] <Saviq> tedg, and UriHandler will just work still?
[13:16] <tedg> Saviq, I believe so, you only get a name per-connection. So as long as you don't have multiple dbus connections it's fine.
[13:16] <tedg> (or that they're using the same one)
[13:17] <Saviq> tedg, ok coolz, /me has no idea about dbus paths, names, interfaces, whatnots
[13:17] <Saviq> tedg, we just need to make sure to keep it, as when we do move to urls, we could've just dropped that name, but won't, in that case
[13:20] <tedg> Saviq, So then what is the appid you're giving to UriHandler ?
[13:20] <Saviq> tedg, you tell me :)
[13:20] <tedg> Saviq, "saviq-rocks"
[13:20] <Saviq> tedg, where does it take it from?
[13:20] <tedg> Saviq, I'm not sure, that's the "Qt Magic" part for me :-)
[13:21] <Saviq> tedg, in any case, it should be unity8-dash
[13:21] <tedg> I think that loicm did that work.
[13:22]  * tedg tries to remember
[13:22] <Saviq> tedg, that's what we get under ~/.cache/ for example
[13:22] <Saviq> as our writable cache dir
[13:22] <Saviq> so that must be it
[13:22] <tedg> Probably the same
[13:22] <tedg> Saviq, So then for the URL format you're looking for "scope:///foo" or should there be more/less restrictions?
[13:23] <Saviq> scope://*
[13:23] <Saviq> tedg, or rather scope://.+ probably
[13:23] <Saviq> as an empty scope://...
[13:23] <Saviq> well, it can just focus the dash is all
[13:23] <Saviq> tedg, so I'm fine with either scope://.+ or .*
[13:23] <tedg> Saviq, The problem with "//" vs "///" is that then the text has to match domain name rules, is that okay?
[13:24] <Saviq> tedg, yes
[13:24] <Saviq> tedg, the first part is fqdn-like always
[13:24] <tedg> K
[13:25] <tedg> We should call it "unity8-" it seems like the second dash is just being repetitive.
[13:27]  * tedg thinks this might have to go into kenvandine_'s "Great Naming Strategies by Ted" book.
[13:36] <dandrader> :)
[13:37] <Saviq> ;)
[13:49] <Cimi> mzanetti, can I add a wait? :)
[13:50] <Saviq> greyback, I'm adding lp:~vanvugt/qtmir/support-non-usr-includes to the silo, too?
[13:51] <greyback> Saviq: go for it
[14:08] <tsdgeos> pstolowski: https://code.launchpad.net/~aacid/unity-scopes-shell/resetMeansCountChanged/+merge/231898
[14:09] <tsdgeos> i spent a while trying to figure out what was wrong in my code to realize for once it wasn't me :D
[14:09] <Cimi> mzanetti, http://paste.ubuntu.com/8114532
[14:09] <Cimi> I know is ugly
[14:09] <Cimi> works though
[14:09] <mzanetti> duuude
[14:09] <mzanetti> no way :D
[14:09] <Cimi> mzanetti, listen I have no other freaking idea!
[14:09] <mzanetti> :D
[14:10] <Cimi> I am accepting suggestions if you want :D
[14:10] <Cimi> I even tried putting a tryCompareFunction waiting for title to change
[14:10] <Cimi> it's a freaking test, we cannot spend hours on it...
[14:11] <tsdgeos> lol
[14:11] <tsdgeos> looks uncool though
[14:11] <anpok> hm i get a runtime_error exception when I start unity8-dash manually
[14:11] <anpok> it says:
[14:12] <anpok> org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[14:12] <tsdgeos> anpok: manually in pc or phone?
[14:12] <Cimi> tsdgeos, you mean that fix?
[14:12] <Saviq> dandrader, unity8 from silo 16 is almost released now, should I build the new silo with lifecycle already or wait for something you've in store?
[14:13] <tsdgeos> Cimi: yep
[14:13] <dandrader> Saviq, kgunn, fixed the prompt surfaces in the lifecycle branch. it was a dead-simple one-liner http://bazaar.launchpad.net/~dandrader/unity8/lifecycle/revision/1159 \o/
[14:13] <anpok> pc in qemu/kvm with unity8 running - started by lightdm
[14:13] <dandrader> Saviq, right on time :)
[14:13] <Cimi> mzanetti, it might not be the mapping
[14:13] <Cimi> mzanetti, it can be the rendering
[14:13] <anpok> byt deactivated unity8-dash as it seems to crash in mesa, which is what I want to debug
[14:13] <Cimi> tsdgeos, it might be slow rendering too
[14:14] <tsdgeos> Cimi: i'm sure a waitForRendering or similar can help
[14:14] <Cimi> tsdgeos, I have one
[14:14] <mzanetti> tsdgeos: its a bit odd indeed
[14:14] <Cimi> mzanetti, ouch
[14:14] <MacSlow> Cimi, even I got rid of all such hacks in the qmltests for notifications
[14:14] <kgunn> dandrader: woo hoo
[14:14] <Cimi> mzanetti, make xvfbtestCard works
[14:14] <mzanetti> tsdgeos: GRID_UNIT_PX=16 make tryCard
[14:15] <Cimi> mzanetti, well, he needs my branch...
[14:15] <mzanetti> ah right
[14:15] <tsdgeos> mzanetti: on master?
[14:15] <tsdgeos> ah :D
[14:15] <Cimi> tsdgeos, lp:~cimi/unity8/overlay-right-padding
[14:15] <mzanetti> tsdgeos: there is a waitForRendering(card) in there already
[14:15] <Cimi> mzanetti, works with xvfbtest
[14:15] <Cimi> mzanetti, not with normal one
[14:16] <mzanetti> Cimi: yeah.. because the rendering is slower, so the waitForRendering does its job there
[14:18] <Saviq> dandrader, awesome
[14:19] <Saviq> greyback, I talked to sil about the staging approach we discussed yesterday
[14:19] <mzanetti> Cimi: waitForRendering(selector)
[14:19] <Saviq> greyback, he's on board, anything you wanted to add maybe?
[14:20] <mzanetti> Cimi: yeah... that makes it work here
[14:20] <mzanetti> Cimi: that waits until the selector has finished updating stuff
[14:20] <Cimi> mzanetti, wil try
[14:21] <mzanetti> Cimi: the waitForRendering(card) passes before the selector starts modifying the card
[14:21] <mzanetti> Cimi: so first do a waitForRendering(selector), and then a waitForRendering(card)
[14:21] <mzanetti> and then we're good
[14:21] <Cimi> mzanetti, we want to update them everywhere maybe
[14:21] <mzanetti> Cimi: very likey
[14:22] <mzanetti> Cimi: you might want to try if we can do the waitForRendering(selector) already inside selector.updateAreas() or similar
[14:22] <tsdgeos> Cimi: mzanetti: GRID_UNIT_PX=16 make testCard works for me in that branch :D
[14:22] <mzanetti> odd
[14:22] <Cimi> tsdgeos, you have a slow pc :P
[14:22] <mzanetti> yeah
[14:23] <mzanetti> size doesn't always matter :P
[14:23] <Cimi> ashahahah
[14:23] <tsdgeos> at most sometimes fails at
[14:23] <tsdgeos> background.color = data.tag;
[14:23] <greyback> Saviq: not at the moment. Good to hear he likes it
[14:23] <tsdgeos> but that's not where it fails for you no?
[14:23] <tsdgeos> or is it?
[14:24] <mzanetti> no... its in test_paddings
[14:25] <tsdgeos> can't help then ;)
[14:25] <Cimi> mzanetti, your pc is too slow
[14:25] <Cimi> mzanetti, mine fails also waiting the selector :P
[14:25] <tsdgeos> branches merged \o/
[14:25] <mzanetti> aw man
[14:25] <mzanetti> maybe we want to put Saviq on the case then :D
[14:26] <Cimi> saviq is wasting time on a pixel because of me
[14:26]  * Cimi runs
[14:27]  * Saviq ignores
[14:28] <Cimi> Saviq, seriously
[14:28] <mzanetti> Saviq: well, testCard has some issues indeed. the way its written its actually surprising it passes
[14:28] <Cimi> Saviq, if you have ideas...
[14:28] <Cimi> Saviq, mumble
[14:30] <anpok> ah had to set DBUS_SESSION_BUS_ADDRESS properly
[14:40] <Cimi> this works though http://paste.ubuntu.com/8114781/
[14:41] <Cimi> mzanetti,
[14:42] <mzanetti> Cimi: +1 from me if this works
[14:42] <Cimi> mzanetti, works on my pc...
[14:42] <Cimi> mzanetti, should not add any issue
[14:42] <mzanetti> Cimi: can you push it so I can try here?
[14:43] <Cimi> mzanetti, pushed
[14:43] <mzanetti> Cimi: +1
[14:44] <Cimi> mzanetti, you can approve then :)
[14:45] <mzanetti> Cimi: yep, on it
[14:45] <Cimi> Saviq, did you see https://code.launchpad.net/~saviq/unity8/fix-empty-attributes/+merge/231076 ?
[14:50] <Saviq> Cimi, yes, and that's kind-of expected
[14:50] <Saviq> Cimi, basically the first row decides on column width
[14:51] <Saviq> Cimi, so because in testData[4] the first row has an empty last column, the second row can't fit the attribute there
[14:51] <Saviq> Cimi, it's a chicken'n'egg problem, because we're eliding as well
[14:52] <Saviq> Cimi, so it'd be a loop of optimizing the column widths
[14:52] <Cimi> Saviq, is this correct though?
[14:52] <Cimi> doesn't seem right to me
[14:52] <Cimi> Saviq, empty attributes break the design
[14:52] <Cimi> visuals
[14:53] <Saviq> Cimi, you'd never put an empty attribute above a non-empty one though
[14:53] <Cimi> so what's the point of supporting them?
[14:53] <Saviq> Cimi, because that already breaks the visual
[14:53] <Saviq> Cimi, but you *would* want to put one under the other
[14:53] <Saviq> Cimi, which means that you need to have 4 in total, N°2 and 4 empty
[14:53] <Cimi> Saviq, so you want to have 1st and 3rd, but not 1st and 4th?
[14:53] <Saviq> 2nd and 4th
[14:54] <Saviq> Cimi, I know it's not ideal, it gets the job done though, and we'll have to revisit the rules for laying them out for sure
[14:54] <Saviq> Cimi, because it's not good enough now
[14:55] <Saviq> Cimi, we might end up putting them in separate RowLayouts instead of a GridLayout, that would end up with uneven centering though
[14:55] <Cimi> Saviq, so shall I approve it despite this issue?
[14:55] <Saviq> Cimi, yes, it's an expected caveat
[14:55] <Saviq> Cimi, I'll put an explanation in the MP
[15:00] <Cimi> Saviq, header customisation is fine or you working on the shader?
[15:00] <Cimi> Saviq, I'd still do it separate
[15:08] <Saviq> Cimi, header one is good
[15:08] <Saviq> Cimi, it's alt_nav that needs the shader
[15:08] <Cimi> Saviq, ok we can approve then
[15:08] <Cimi> Saviq, why that?
[15:08] <Saviq> Cimi, because before alt_nav there's no background on the nav bar
[15:09] <Cimi> ok
[15:10] <Cimi> mzanetti, top approving? https://code.launchpad.net/~cimi/unity8/overlay-right-padding/+merge/231586
[15:10] <mzanetti> Cimi: wanted to wait for jenkins
[15:10] <mzanetti> Cimi: but ok... approved it
[15:11] <mzanetti> Cimi: if jenkins fails on it, please unapprove and fix that
[15:11] <Cimi> ok
[15:21] <tsdgeos> it's sad, there's no way of getting the same rendering you get with width/height when you set sourceSize
[15:21] <tsdgeos> you can get something that is arguably better
[15:24] <Cimi> tsdgeos, what?
[15:25] <tsdgeos> Cimi: get this
[15:25] <Cimi> tsdgeos, setting sourceSize reduces quality?
[15:25] <tsdgeos> changes quality :D
[15:25] <tsdgeos> http://paste.ubuntu.com/8115071/
[15:25] <tsdgeos> Cimi: and http://i.imgur.com/PPz8LWI.jpg as sobrenatural.jpg
[15:26] <tsdgeos> not tell me which is the best from the 12
[15:26] <tsdgeos> s/not/now
[15:26] <tsdgeos> Saviq: ↑↑↑
[15:28] <Cimi> tsdgeos, 1st row second
[15:28] <tsdgeos> eh?
[15:28] <tsdgeos> ah
[15:28] <tsdgeos> no
[15:28] <Cimi> quite comparable with 4th and 6th
[15:28] <tsdgeos> second row 1st?
[15:29] <tsdgeos> that one is horrible :D
[15:29] <Cimi> 1st row
[15:29] <Cimi> second
[15:29] <tsdgeos> ah
[15:29] <Cimi> the second on the 1st row
[15:29] <tsdgeos> that's the best
[15:29] <tsdgeos> we are shoing 4th of 2nd row
[15:29] <tsdgeos> showing
[15:29] <tsdgeos> at the moment
[15:29] <tsdgeos> which is "more crisp"
[15:30] <tsdgeos> sad thing is i can't emulate that one when setting sourcesize
[15:30] <Cimi> tsdgeos, what is difference with mipmap and smooth?
[15:30] <tsdgeos> that is the one without source size
[15:30] <tsdgeos> mipmap is "more" smooth :D
[15:30] <Cimi> tsdgeos, it is too crisp that one imho
[15:31] <Cimi> it looks pixelated
[15:31] <tsdgeos> yeah i can hardly see the difference between smooth and non smooth
[15:32] <tsdgeos> when not setting source size
[15:32] <tsdgeos> i.e. 2nd row 4th vs 6th
[15:32] <Cimi> tsdgeos, maybe it depends on the fact is zoomed in or out
[15:32] <Cimi> smoothj
[15:32] <tsdgeos> may be
[15:35] <tsdgeos> so i guess we should go for first row
[15:35] <tsdgeos> 4th
[15:35] <tsdgeos> which is with sourcesize so uses less memory
[15:37] <tsdgeos> or not
[15:38] <tsdgeos> the crispness helps sometimes...
[15:38] <tsdgeos> let me show you another one
[15:40] <tsdgeos> or not...
[15:42] <Saviq> tsdgeos, it'd help if I knew which image is which ;)
[15:42] <Saviq> tsdgeos, should've went with GridLayout ;)
[15:43] <tsdgeos> Saviq: why? just tell me which one you think it looks better
[15:43] <tsdgeos> looking at the code is cheating
[15:43] <Saviq> tsdgeos, ah
[15:43] <Saviq> tsdgeos, I didn't know what you're after
[15:43] <Saviq> tsdgeos, so which one looks best of all of those?
[15:43] <tsdgeos> yep
[15:43] <tsdgeos> i can tell you what they are
[15:43] <tsdgeos> in groups of 4
[15:44] <tsdgeos> mimap=true, normal, smooth=false
[15:44] <Saviq> tsdgeos, top row 2
[15:44] <Saviq> tsdgeos, is what I think's best
[15:44] <tsdgeos> and then it's sourceSize both directions, best direction, no source size and bad direction
[15:44] <tsdgeos> starting from top left
[15:44] <tsdgeos> Saviq: yep, but that's with mipmap
[15:44] <Saviq> top 4 is almost the same
[15:44] <tsdgeos> so i'm going with top 4
[15:44] <Cimi> Saviq, same here
[15:45] <Cimi> difference between 2 and 4 is mipmap vs smooth
[15:45] <Cimi> mipmap is better
[15:46] <tsdgeos> and slower :D
[15:46] <tsdgeos> i'm trying to make things faster
[15:46] <tsdgeos> not slower ;)
[15:46] <Saviq> tsdgeos, so top 4 is without sourceSize?
[15:46] <tsdgeos> no, bottom 4 is without sourceSize
[15:46] <Saviq> tsdgeos, ah good
[15:46] <tsdgeos> top 4 is with source size only in the width direction
[15:46] <tsdgeos> i.e sourceSize: Qt.size(100, 0)
[15:47] <Saviq> tsdgeos, right, if only we knew which direction is better without loading the image ;)
[15:47] <Cimi> yeah
[15:47] <Cimi> we need to detect aspect ratio
[15:47] <Saviq> that's what I miss in Image actually
[15:48] <Saviq> to say sourceSize: 'best, dammit!'
[15:48] <Saviq> you know whether you're cropping or stretching or whatnot
[15:48] <Saviq> just do the work!
[15:48] <Saviq> kgunn, dandrader, greyback, stuff's building in silo 4
[15:49] <dandrader> Saviq, ok
[15:49] <Saviq> it will get into a dependency wait due to unity-api being there late
[15:49] <Saviq> and I'll upload qtmir-gles in a moment
[15:49] <kgunn> ack
[15:49] <tsdgeos> Saviq: one option is setting sourceSize when sourceSize changes the first time
[15:50] <tsdgeos> it's a bit hacky but should work, no?
[15:50] <Saviq> tsdgeos, yes, and means loading the image twice
[15:51] <tsdgeos> Saviq: loading it where
[15:51] <tsdgeos> ?
[15:51] <Saviq> tsdgeos, http://qt-project.org/doc/qt-5/qml-qtquick-image.html#sourceSize-prop
[15:51] <Saviq> Note: Changing this property dynamically causes the image source to be reloaded, potentially even from the network, if it is not in the disk cache.
[15:51] <tsdgeos> sure
[15:51] <Cimi> Saviq, but we know the card type, no?
[15:51] <tsdgeos> from disk
[15:51] <tsdgeos> that's a given
[15:51] <Saviq> tsdgeos, or network
[15:51] <Saviq> tsdgeos, well, not necessarily
[15:51] <Saviq> tsdgeos, "For some formats (currently only JPEG), the whole image will never actually be loaded into memory."
[15:51] <Saviq> tsdgeos, it could just read the header
[15:52] <Saviq> tsdgeos, and straight away determine what side it should load at
[15:52] <tsdgeos> hmmm
[15:52] <tsdgeos> yeah
[15:52] <Saviq> tsdgeos, but that'd have to happen in QQuickImage
[15:52] <Saviq> or QImageBase or whatever does the loading
[15:52] <tsdgeos> Saviq: right, which means we either live with big images or implement taht in Qt itself
[15:53] <Saviq> tsdgeos, guess what my vote would be ;)
[15:53] <Saviq> but we haven't hired that person yet :D
[15:53] <Saviq> tsdgeos, apart from loading, the other thing is actually scaling the image, takes CPU
[15:54] <Saviq> tsdgeos, which is why I wanted bug #1224998
[15:54] <tsdgeos> well, someone is doing the scaling now too
[15:54] <Saviq> but didn't happen yet
[15:54] <tsdgeos> or maybe it's just textture scaling
[15:54] <tsdgeos> and that's why it looks different
[15:54] <Saviq> tsdgeos, if no sourcesize, it's GPU that's scaling
[15:55] <tsdgeos> right, kind of makes sense
[15:55] <Saviq> tsdgeos, so the least bad way I think we can deal without digging in Qt
[15:55] <Saviq> tsdgeos, is do what you said
[15:55] <Saviq> tsdgeos, but keep the image invisible until that happens
[15:55] <tsdgeos> yeah
[15:55] <tsdgeos> still reloads twice
[15:55] <Saviq> but at least doesn't upload
[15:55] <tsdgeos> which given how bad network/disk can be on the phone
[15:56] <tsdgeos> i'm not sure it's a good idea
[15:56] <Saviq> tsdgeos, I don't think disk is the problem
[15:56] <Saviq> tsdgeos, we'd have all kinds of issues if IO was the reason
[15:57] <tsdgeos> well io is usually slow on phones
[15:57] <tsdgeos> i mean not the case to make everything slow
[15:57] <tsdgeos> but you don't want to abuse it
[15:59] <seb128> hum
[16:00] <seb128> unity8 segfaults on start on my desktop since the update I just did (was working earlier today using the ppa 16 before it landed)
[16:00] <seb128> segfault in QJSValue, qtmir surfaceAboutToBeCreatedCallback from libUnityLauncher
[16:00] <seb128> Saviq, do you know if that's a known issue?
[16:00] <seb128> bregma, ^
[16:01] <Saviq> seb128, where did you update from?
[16:01] <seb128> Saviq, standard utopic
[16:02] <Saviq> seb128, not possible, that symbol's not there yet
[16:02] <seb128> I get the lockscreen but blank
[16:02] <seb128> hum
[16:02] <seb128> maybe I failed to disable the ppa?
[16:02] <Saviq> seb128, likely you have qtmir newer than in distro
[16:03] <Saviq> greyback
[16:03] <Saviq> come back!
[16:03] <seb128> indeed
[16:03] <seb128> I've 21.1-0ubuntu1, wonder from where I got that?
[16:03] <Saviq> seb128, but I'm sure Gerry will be interested in the signature of the crash
[16:03] <Saviq> seb128, silo 16 yesterday
[16:03] <Saviq> seb128, but it didn't get released
[16:03] <seb128> I see
[16:04] <seb128> it was working this morning :p
[16:04] <Saviq> seb128, because you had unity8 from the silo too
[16:04] <seb128> right, I though the silo landed earlier today
[16:04] <Saviq> seb128, yeah, without qtmir
[16:04] <seb128> but I guess that was different content
[16:04] <Saviq> seb128, had to pull
[16:04] <seb128> I see
[16:04] <seb128> thanks
[16:04] <Saviq> seb128, you can upgrade from silo 4 in like half an hour
[16:04] <Saviq> seb128, or downgrade to distro version
[16:05] <seb128> yeah, doing that
[16:05] <seb128> Saviq, works after downgrading qtmir, thanks!
[16:06] <dandrader> dednick, ping
[16:06] <Saviq> seb128, still that suggests to me there's something wonky in silo 4 now, it shouldn't crash
[16:06] <Saviq> seb128, will have to verify
[16:06] <dednick> dandrader: yo
[16:06] <seb128> Saviq, I'm happy to give debug info
[16:06] <seb128> Saviq, I'm going to try the silo once it's built
[16:06] <Saviq> seb128, yeah, but that will force a unity8 bump, too
[16:07] <Saviq> seb128, so yeah, well, you shouldn't get into a situation like you did
[16:07] <Saviq> seb128, which, btw, is weird
[16:07] <seb128> what is weird?
[16:07] <Saviq> seb128, you shouldn't have been able to upgrade unity8 without downgrading qmitr
[16:07] <Saviq> qtmir
[16:07] <Saviq> unless
[16:07] <seb128> why not?
[16:07] <seb128> is there a soname change?
[16:07] <Saviq> seb128, you probably have unity8-fake-env installed?
[16:07] <dandrader> dednick, should the surface in SurfaceContainer match the size of the SurfaceContainer? (hope that questions is comprehensible :) )
[16:08] <seb128> Saviq, I do indeed
[16:08] <Saviq> seb128, so that's what satisfied the dep
[16:08] <Saviq> seb128, unity8 depends on unity-application-impl-$version
[16:08] <dandrader> dednick, thinking about the prompt sessions here, as they also use SurfaceContainers
[16:08] <Saviq> seb128, and both qtmir and -fake-env provide that
[16:08] <seb128> I see
[16:08] <dednick> dandrader: prompt sessions should match size of the main surface
[16:09] <Saviq> seb128, I just wonder, did you have -fake-env installed before? can you check in apt-history whether it got upgraded or installed?
[16:09] <dandrader> dednick, hmm, ok.
[16:09] <dednick> dandrader: they take into account the margins applied on the app session
[16:09] <dednick> *app surface
[16:10] <dednick> dandrader: ie. if a app is fullscreen, it's prompt should be, and same for non-fullscreen
[16:10] <dandrader> dednick, right
[16:11] <dandrader> dednick, because currently SurfaceContainer doesn't do anything about the size of the surface it contains
[16:11] <tsdgeos> Saviq: yeah is reading the file twice
[16:11] <dandrader> dednick, so I was thinking about changing that. Making  the "contained surface" follow the size of its container
[16:11] <dandrader> binding it
[16:12] <tsdgeos> but one after the other, we can expect linux caches are smart enough to give it again from memory and not disk
[16:12] <tsdgeos> let's see what happens with the internets
[16:12] <dandrader> and was wondering if it would wreak havoc to the prompt stuff. but seems not
[16:12] <Saviq> seb128, so what happened for you I think, is that you had qtmir installed at -impl-3, the unity8 you got from distro wanted -impl-2 but either you had -fake-env installed and that upgrade satisfied -impl-2, or, worse, it would install -fake-env satisfying -impl-2 instead of downgrading qtmir
[16:12] <seb128> Saviq, it got installed as part of the dist-upgrade I just did, likely to resolve the depends
[16:13] <Saviq> seb128, right, but that's just because you had qtmir at a higher version than distro
[16:13] <dednick> dandrader: what about the fullscreen stuff?
[16:13] <Saviq> seb128, otherwise it would not have installed -fake-env but upgraded qtmir
[16:13] <Saviq> so yeah, it's ~ok
[16:13] <seb128> Saviq, right
[16:14] <Saviq> seb128, on that note, I think we can drop fake-env actually
[16:14] <dednick> dandrader: i did that when i first did prompts, and it screwed up the sizing of spread items when they were transformed.
[16:14] <Saviq> it would mean you can't run it under x11... but it's way past being easy to run under x11 anyway...
[16:14] <dandrader> dednick, the lifecycle branch changed things quite a lot
[16:14] <Saviq> or, well, useful
[16:14] <dednick> dandrader: mk.
[16:14] <dednick> dandrader: i'm changing things up again as well.
[16:15] <dednick> dandrader: we're probably going to conflict massively
[16:15] <dednick> surfaces are no longer on applications.
[16:15] <dandrader> dednick, yeah, but this time you're the one that's gonna have to rebase :D
[16:15] <Saviq> breakfast!
[16:16] <dandrader> if all goes well and silo 4 lands, that is
[16:16] <tsdgeos> he
[16:16] <tsdgeos> i can't find the syscalls qt does to download from the interwebs
[16:17] <tsdgeos> any other suggestion?
[16:17] <tsdgeos> wireshark it?
[16:17] <Saviq> tsdgeos, remember it's caching it
[16:18] <tsdgeos> Saviq: is it?
[16:18] <Saviq> tsdgeos, ~/.cache/unity8-dash/network
[16:18] <tsdgeos> Saviq: not my dummy qml
[16:18] <Saviq> tsdgeos, right, no ;)
[16:19] <tsdgeos> yes, does the download twice
[16:19] <tsdgeos> good thing we are caching then :D
[16:20] <tsdgeos> ok, this would be the code http://paste.ubuntu.com/8115422/
[16:20] <tsdgeos> will see how integrate it into the card on monday
[16:21]  * tsdgeos waves
[16:23] <dandrader> dednick,  "surfaces are no longer on applications." You mean there's no ApplicationInfo::surface?
[16:23] <dednick> dandrader: nope
[16:23] <dandrader> in your branches
[16:24] <dandrader> dednick,  oh, that big. How do you match an app with its surface now?
[16:24] <dednick> dandrader: Application::session
[16:24] <Cimi> Saviq, scope settings? :)
[16:24] <Saviq> Cimi, next week
[16:24] <Cimi> ok
[16:25] <dednick> dandrader: and sessions have a surface + child sessions
[16:26] <dandrader> dednick, hmm. ok
[16:26] <dednick> dandrader: aka. a prompt-in-a-prompt
[16:26] <dednick> in a application
[16:26] <dednick> in a dream
[16:26] <dednick> in a taco bell
[16:26] <dandrader> I sense it's gonna be trio of big fat patches (unity-api, unity8, qtmir) like with lifecycle...
[16:27] <dandrader> hehehe
[16:27] <dednick> the unity-api doesnt seem to know anything about surfaces at the moment.
[16:28] <dednick> it's all add-ons from qtmir at the mo
[16:46] <anpok> is there a known issue with physical keyboards in side stage appilcations?
[18:06] <rcspam> hi all, my script : http://pastebin.com/9TrZi9NL
[18:07] <rcspam> I dont understand why 'launcher.set_property("urgent", True)' line 20 doesn't work. Is it a bug? I'm on ubuntu 12.04, thanx!
[18:09] <rcspam> if it is before 'the line 19's if', it works !! Why not in the 'if' !
[18:52] <Saviq> rcspam, it looks like you're looking more for python support rather than here
[18:52] <Saviq> rcspam, but from a quick look, you shouldn't do len(line) == 0 (which, btw can be just "if line")
[18:53] <Saviq> rcspam, you should rather catch EOF
[19:10] <rcspam> Saviq: ok i agree what you say about if line..., but the script works and there are no error given bye the interpretor, if  i put a 'print something" after 'if' condition, it works, the only thing that doent work is 'launcher.set_property("urgent", True)'
[19:13] <rcspam> Saviq: i ve replaced 'len(line) == 0' by 'not line', it works well but "urgent" doesnt "knocked at the door" ;)
[19:21] <anpok> hm what could be missing from my installation when unity8 dash from the archive does not show the apps scope?
[19:21] <anpok> (pc desktop)
[19:25] <rcspam> Saviq, Do you know, where find python unity chanel or list, where post my ask ?