#ubuntu-unity 2012-01-19
<mhall119> I can't say I've missed the 'minimize' option
<mhall119> really, I'm not sure it has a purpose anymore
<masterjb> yello
<mhall119> hi masterjb
<masterjb> hi
<masterjb> why are there so many people but no one talking?
<mhall119> masterjb: it's after-hours for all of Europe and the east-coast of the USA
<masterjb> so I am guessing you are in the USA
<masterjb> ?
<mhall119> yes
<mhall119> east-coast, so it's technically after-hours for me too
<masterjb> dev forum or just about unitry? do you compiz with unity options?
<masterjb> im east-coast, but learnin never is an after-hour thing hah
<mhall119> I'm not one of the Unity developers, just an advocate :)
<mhall119> but you can ask about Unity or compiz in here
<masterjb> do you use compiz with the extra addons with ubuntu 11.04+
<masterjb> how it glitches but I eventually got it working
<mhall119> me?
<mhall119> I'm on 11.10
<mhall119> if you have just general compiz questions (not related to Unity), you might find more help in #compiz
<masterjb> same here i was asking if you are using compiz with the extra addons
<masterjb> kk
<masterjb> thanks
<masterjb> but i have others
<masterjb> for instance, in ubuntu 10, we could have or create icons on the top bar
<masterjb> is that functionality gone in 11+
<mhall119> I think I have the extras plugins installed, not sure if I'm using any of them though
<mhall119> launcher icons, or the compiz tray icon?
<masterjb> top bar, where battery and wifi signal is
<masterjb> before we could add usefule buttons up top
<mhall119> ah, the old gnome2 systray is disabled by default
<mhall119> in Unity
<mhall119> I think there's a way to add it back in, but it's recommended to have apps use indicator icons instead
<masterjb> yeah but i like them both hah
<masterjb> --help
<bgois> Hey guys. I really like the latest updates to unity. I feels a lot faster and better.
<masterjb> yeah
<njotta> hi all
<masterjb> hi
<njotta> so, any good ideas discussed?
<jono> bgois, :-)
<mas> i need to talk to a unity developer immediately!~
<mas> facebook led me here!
<bgois> 12.04 is the first Alpha release that i use. And it still pretty much stable. I think it's more stable than my old oneiric.
<mas> who else keeps accidentally going too far to the left with mouse when using a touchpad causing the launcher to pop out?
<mhall119> mas: lol
<AlanBell> mas: you can set the launcher to stay out all the time
<mhall119> mas: unfortunately they're probably all done working for the day
<AlanBell> I find it much much much easier to use
<mas> oh no don't get me wrong...i like it
<mas> but that one thing keeps getting in the way when i'm working fast
<AlanBell> I set mine to 32 px size (smaller than the default 48) and never to hide
<mhall119> mas: they are experimenting with different ways or preventing the launcher from appearing when you don't want it
<mas> oh coo, thanks mhall
<mas> *cool
<jono> mhall119, can you give me admin access to the sumo server?
#ubuntu-unity 2012-01-20
<mhall119> mas: you might be interested in http://design.canonical.com/2012/01/launcher-reveal-prototype/ and leaving your preferences in the comments
<mhall119> jono: shell or django?
<jono> mhall119, django
<mas> i've been contemplating it myself, i was thinking moving it to the bottom might help but shuttleworth keeps has some obsession with everything having to be to the left. it would also be nice to see some sort of feedback from the buttons in the launcher, like when the mouse is over them they glow or hover. they feel so "static"
<mhall119> jono: sure, give me a minute
<jono> mhall119, thanks!
<mas> oh thanks mhall, i'll leave some comments
<mhall119> mas: it's not so much wanting it on the left, it's wanting it to use up the dimension you have the most space in
<bgois> mas, some hover or glow might be really good for button feedback.
<mhall119> I'd rather lose 48px of 1024, than 48px of 786
<bgois> If my opinion and experience with unity on corporate machines. The launcher hidding and revealing it self on left side confuses people.
<bgois> I wonder my self, if the launcher be moved to bottom it could looks a lot like the win7 bar. But it would be a lot easier to switch betwen tasks.
<mas> hmm, i've heard that argument before about losing in the horizontal versus the vertical. not to say i disagree...however i never hear anybody talk about symmetry. it can sometimes be visually unpleasant. also the space argument doesn't really matter when you maximize as the launcher disappears anyway
<bgois> mhall119, your observation makes sense in the logical point of view. But, from a usability vision, users are used to look at the bottom bar and find its running apps and menu. i think.
<mas> what has confused me about the entire argument is why the option of not being able to move it around to any side the user wants is not desired. that was something i always admired about *nix desktop environments. i rarely deviate from the default desktop, but sometimes one or two tweeks depending on the end user's workflow can make a world of difference
<mas> i mean even mac, the ultimate in controlling the end user's experience let you move the dock around
<htorque> i wonder how RTL language users feel about it
<w3r3wolv3s> quit
<mhall119> bgois: it doesn't take that long to learn to look on the left
<mhall119> we shouldn't treat users as if they are incapable of learning a better experience
<mhall119> htorque: that's an interesting question
<thumper> hi mhall119
<thumper> are we moving all ayatana chatter here?\
<thumper> what else what talked about on ayatana?
<thumper> htorque: I'd love to see some research on RTL languages and launcher expectations
<mhall119> thumper: moving it here
<mhall119> we'll put in a redirect on #ayatana in about a week
<thumper> mhall119: we should have a call next week
<thumper> I'm not actually working today
<mhall119> thumper: yes please
<thumper> 62 hours travelling home
<thumper> just back this morning
<mhall119> eeew
<mhall119> sure, I'm pretty flexible, so whenever is good for you
<thumper> mhall119: where are you based?
<mhall119> USA, east-coast
<thumper> ah cool
<thumper> just 3 hours different then
<thumper> perhaps Monday afternoon your time
<mhall119> I assume you're west-coast then
<thumper> that matches up with after lunch tuesday for me
<mhall119> or the middle of the atlantic
<thumper> Nope
<thumper> NZ
<mhall119> wait...
<thumper> well three hours + one day
<thumper> three hours ahead and a day behind
<mhall119> that still doesn't sound quite right, what time is it there now?
<thumper> 13:47
<thumper> damn
<mhall119> ok, so 6 hours different
<thumper> east and west mix up again
<mhall119> that sounds better
<thumper> I do that all the time
<mhall119> no problem
<thumper> you are in the same tz as lamalex, DBO, and jay
<mhall119> and I don't know any of them.... :(
<thumper> you were ISD before?
<mhall119> yup, until the end of December
<thumper> just looked you up on the directory
<mhall119> thumper: give me a ping monday morning (your time) and we'll setup a time for a call
<thumper> I don't think we've met have we?
<mhall119> maybe in passing at UDS
<thumper> I've not been to a UDS since Boston
<mhall119> ok,then not in passing at UDS
<thumper> even then, it was a co-located launchpad sprint
<mhall119> you were in the launchpad team?
<thumper> for 4.5 years
<thumper> switched last April to DX
<mhall119> then it's very possible that I've bugged you about something before ;)
<thumper> which is now product strategy
<thumper> maybe
<mhall119> summit or loco-directory perhaps
 * thumper has to head off for stuff
<thumper> we'll chat next week
<Justinba1010> hello
<Justinba1010> anyone here?
<Caio> Hello. Is here the best place to give suggestions about Unity?
<marcosroriz> Hi guys
<marcosroriz> I'm running natty here, I think I found a 'security' bug in Unity
<marcosroriz> Can someone confirme me if it happens on oneiric??
<vadi2> Sure.
<marcosroriz> The bug is the following:
<marcosroriz> 1 - Press the super key  (will launch unity 'default' view)
<marcosroriz> 2 - Wait to computer to block
<vadi2> block?
<marcosroriz> As in session block
<marcosroriz> As you can see, you can still do a one time usage of unity.
<vadi2> Ah so the lock screen?
<marcosroriz> yep
<marcosroriz> the lock screen dont appear directly, you can 'use' unity for a command
<marcosroriz> I think what happen is that the unity launcher stays on top of the gnome-lock-screen
<marcosroriz> and you can use unity one time, once it dissapears (the unity windows) it goes to the password of the lock screen
<vadi2> I'll see
<marcosroriz> Try it :)
<marcosroriz> Put your comp session lock < 2 min
<marcosroriz> and press the super :)
<marcosroriz> wait, and profit
<marcosroriz> you'll get the chance to explore unity hehe, once you get out of the unity screen the computer goes to the lock screen (session)
<marcosroriz> :~
<marcosroriz> I don't know if this is a security bug, but IMO after the period that you specified (for instance, 2min) your computer should go automatically to the gnome-session screen with the pass.
<vadi2> Did you hold the super key, or press and let go?
<vadi2> my screen turned off and locked, it came back to the lock screen though, not unity
<marcosroriz> press and let it go
<vadi2> Yeah that's what I did, didn't happen here
<marcosroriz> Strange :~
<guest____> hi all
<guest____> anybody here?
<guest____> whois JanC JanC
<vadi2> hello
<vadi2> bye
<aslamckra> hello
<kamstrup> does anyone know how we sort the lenses in the lensbar in the dash?
<Saviq> kamstrup, preliminary look at 2d code says that we do whatever you guys give us
<kamstrup> Saviq: yeah, and u3d also seems to take whatever comes out of the FilesystemLenses class
<Saviq> kamstrup, yup, same here it seems
<kamstrup> but the sorting order in the dash seems to be stable, so there must be something sorting it
<Saviq> kamstrup, "m_unityLenses = new unity::dash::FilesystemLenses("/usr/share/unity/lenses"); for (unsigned int i=0; i<m_unityLenses->count(); i++) [...]"
<kamstrup> maybe it's really just sorting on inode accurence within the /usr/share/unity/lenses dir...
<kamstrup> Saviq: which order are your lenses in?
<kamstrup> i have home, apps, files, music
<Saviq> same here
<Saviq> any additional get added later
<kamstrup> hmmm, so something is likely to sort it
<kamstrup> s/likely/certain
<Saviq> yup
<kamstrup> Saviq: AHA! vvvv
<kamstrup> /FIXME: We don't have a strict order, but alphabetical serves us wonderfully for
<kamstrup>     // Oneiric. When we have an order/policy, please replace this.
<Saviq> ookies
<kamstrup> in FilesystemLenses
<Saviq> yup, was just going there
<Saviq> except the app lens seems to be forced first
<kamstrup> ok, I am actually implementing that policy in my home-lenses branch, so I'll put it on my todo
<kamstrup> right
<Saviq> and we probably want the home lens to be first in Precise
<Atem18> Hi
<Saviq> hey greyback
<gord> mhr3, so your icon loading branch is great, but i think it needs tests - just one that loads a bunch of icons and makes sure they all come in
<greyback> Saviq: morning
<mhr3> gord, i knew you'd said that
<Saviq> frck!
<nerochiaro> Saviq: I think I have addressed all your concerns in the shape tests branch. just pushed the last changes now
<Saviq> greyback, we need to set locale to en_something in the tests..
<Saviq> otherwise I'll waste many more hours wondering what the frck
<Saviq> or at least require a "en_*" locale for the tests
<nerochiaro> Saviq: yep. but then we should also have some localization tests
<greyback> Saviq: yeah. Getting tests running on every developers machine correctly is a pain. Why I want to use VBox
<greyback> nerochiaro: agreed, and also needed for RTL tests
<Saviq> greyback, still, I've changed the locale on my vbox to check out RTL yesterday
<nerochiaro> greyback: Saviq: i'm also worried about some tests that will require resolution changes (for example to test the min size of the dash)
<Saviq> and since then I couldn't, for the life of mine, understand why the tests failed
<nerochiaro> (min size before it goes fullscreen by default)
<greyback> Saviq: yep, my idea was to have a VBox Snapshot that everyone just uses and won't be changed
<Saviq> greyback, that's not safe
<Saviq> greyback, tests should work on virtually every machine
<nerochiaro> greyback: yeah, but what do you do for tests where a certain feature is for a configuration that is impossible to obtain on a certain machine ?
<Saviq> if we just have a snapshot that noone changes, the tests won't get enough coverage, tbh
<nerochiaro> Saviq: ^
<Saviq> nerochiaro, example?
<greyback> nerochiaro: you'll have to add checks to ensure the resolution is big enough for the dash not to be full-screen, and bypass the test with a warning maybe
<nerochiaro> Saviq: multimonitor tests ?
<Saviq> nerochiaro, true, what greyback said - just check whether the env is ready for the test
<Saviq> and bypass it
<Saviq> exactly what I want to do for locale
<Saviq> check if it's en_whateveryouguysuse.UTF-8
<Saviq> and drop out of the test suite
<Saviq> or change the locale for the duration of the tests
<dyams> nerochiaro: saviq: In the shape-tests branch i checked move the dash bit away from launcher
<dyams> nerochiaro: saviq:actually to the second screen
<dyams> nerochiaro: saviq: the dash is no more visible there
<Saviq> dyams, meaning multimonitor?
<dyams> saviq: yes
<Saviq> dyams, we didn't yet do anything re multimonitor in -shell
<Saviq> dyams, but you need to remember there is no "dash" and "launcher" anymore
<nerochiaro> yep, no multimonitor support in shell for now
<Saviq> there's just a single window
<Saviq> which has both the dash and the launcher
<Saviq> so if you've moved the dash over screen, it will just go overscreen, not to the next screen
<dyams> saviq: sure, but if i move the window bit away from launcher, then any portion of the dash falling outside the current screen is cut off
<dyams> nerochiaro: saviq: Yes, I didn't expect it will work perfectly by just reposition it
<dyams> nerochiaro: saviq: yet i didn't expect it will be clipped either.
<Saviq> dyams, what are you repositioning? the whole shell window or just the dash inside?
<Saviq> dyams, yes it will be clipped
<Saviq> our window is the size of your current screen's available geometry
<dyams> saviq: I reposition dash only
<Saviq> if you go over that, it will get clipped, yes
<Saviq> dyams, there's simply no support gone into -shell yet
<dyams> saviq: i see , height: screen.availableGeometry.height
<dyams>     width: screen.availableGeometry.width
<dyams> saviq: Ok
<Saviq> nerochiaro, that fits into the merge-todo, do we have that there yet?
<Saviq> nerochiaro, at least getting on-par with trunk
<Saviq> nerochiaro, so you didn't manage to work with _NET_WORKAREA in the end?
<nerochiaro> Saviq: i don't think we have it yet
<Saviq> nerochiaro, ok I'll add it
<nerochiaro> Saviq: i decided not to, it was quicker this way and i'll also be forcing the panel to be there for the dash button tests, so i thought might as well do the same in that case
<Saviq> lazies :P
<Saviq> ok
<nerochiaro> Saviq: i'll add the test to verify the correct shape in absence of the dash when i add the ability for the shell window to correctly adjust in case the panel appears and disappears
<Saviq> k
<dyams> nerochiaro: saviq: 1) Invoke dash, 2) invoke spread,
<dyams> 3) Cancel the spread
<dyams> Now dash is reappearing
<dyams> moreover now dash is not closing either
<greyback> didrocks: welcome ;)
<Saviq> hey didrocks
<nerochiaro> dyams: sounds like a bug in shell. let's add to the TODO in the wiki please
<didrocks> greyback: hey ;) Seems I need to add the autojoin here ;) the super + keynum seems to not work with the numpad in 2d, do you have a bug report on that? :)
<greyback> didrocks: designers say it's not supposed to
<greyback> dyams: ^^
<didrocks> hum?
<didrocks> a lot of people marks the tests are failed because they try to use it
<dyams> didrocks: greyback is correct
<dyams> greyback: didrocks: actually super + numpad with launcher? Or with windows?
<didrocks> dyams: launcher
<didrocks> oh that will be the shortcut for maximinizing the window now
<didrocks> forgot about it
<Saviq> dyams, you need to run the spread from the shell branch
<Saviq> nerochiaro, ^^
<greyback> didrocks: https://bugs.launchpad.net/unity-2d/+bug/750514
<dyams> didrocks: Super + Numpad [1] [2]....[0] Is not supported by launcher
<didrocks> hey Saviq ;)
<Saviq> nerochiaro, dyams: works fine for me, but you need to run the spread from the shell branch
<nerochiaro> Saviq: oh, right, forgot that might be the issue
<Saviq> not the installed one
<dyams> saviq: trying again..
<didrocks> dyams: well, it was for Natty, but the design changed :)
<greyback> didrocks: so no Super+numpad does same as Super+num ?
<greyback> s/no/now
<didrocks> greyback: in 3D right
<dyams> didrocks: oh they changed it..? Or is it a bug in 3D?
<nerochiaro> Saviq: let me know when you are done with the review, so i can pull it into another branch if it's ok, or fix what's wrong if not. thanks.
<didrocks> dyams: I can tell for sure it's not a bug in 3D and they ask for it as I spent time to support it :)
<gord> stop assuming things are bugs in 3d you guys :P
<didrocks> anyway, there is this new shortcut stuff where it should maximize/semi-maximize window now
<Saviq> nerochiaro, seems right already, I'm just verifying that the tests fail without the shell being shaped
<dyams> didrocks: lemme crosscheck with the shortcuts gdocs once
<greyback> didrocks: am consulting with design now :)
<didrocks> thanks :)
<didrocks> dyams: John showed me this gdocs, but I can't find it anymore
<dyams> didrocks: hrer https://docs.google.com/a/canonical.com/document/d/1jqeKtIJwqLtl58Wk_fqjr9Rrgxn9zsouCYOo-cZsLSE/edit?authkey=CLGG9NkJ&hl=en_GB
<didrocks> dyams: thanks
<didrocks> dyams: hum, no, it's ctrl + alt in fact
<didrocks> so nothing on super + numpad
<didrocks> seems a lot of people expect it to do the same than super + keynum
<greyback> didrocks: see the other channel :)
<greyback> dyams: dust off that Super+keypad branch, it's going in :)
<dyams> greyback: :) sure, I can do it... :)
<dyams> greyback: should we wait for shell work or we merge it current trunk already?
<greyback> dyams: as ultimately we'll be using shell, there's little point in merging it to trunk only.
<greyback> dyams: see how easy it ports to shell
<dyams> greyback: Ok, I'll work on shell branch
<greyback> Saviq: I think adding features should be done to shell, if they don't apply cleanly to both branches. Otherwise we're making more work for ourselves
<dyams> saviq: Yes, Spread works better if I launch it from shell itself
<Saviq> dyams, "better"? not "correct"?
<dyams> saviq: but that didn't solve the issue either
<Saviq> greyback, true
<Saviq> greyback, if they fit nicely in both - then both
<Saviq> otherwise - shell it is
<dyams> saviq: two issues i noticed.
<greyback> Saviq: agreed
<dyams> saviq: 1) Launcher won't stay open when spread is active, it disappears after a few seconds
<Saviq> weirds, should be forcedVisible, add to the wiki please
<dyams> 2) after 3-4 attemps dash stays open and won't go away
<dyams> saviq: sure
<dyams> nerochiaro: You already added the Dash clipping issue in wiki?
<dyams> nerochiaro: Or is it not required?
<Saviq> dyams, there's no "dash clipping"
<Saviq> that is not an issue
<dyams> saviq: Ok
<Saviq> dyams, why would you move the dash itself anyway?
<Saviq> the dash is supposed to be stuck to the launcher, and proper multimonitor support will come later
<dyams> Saviq: multi-monitor
<Saviq> dyams, we won't be moving it
<Saviq> we will have a dash per-screen
<Saviq> just as we will a launcher per-screen
<dyams> Saviq: no
<Saviq> dyams, I know, it will just be shown on one screen
<Saviq> current screen
<Saviq> but that doesn't mean we will necessarily move the window around
<dyams> saviq: Ok
<dyams> saviq: then it is like shell per monitor. no?
<Saviq> dyams, yes
<dyams> saviq: i got it :)
<kamstrup> booyacacha mhr3, gord! nailed the home-lenses despite njpatel trying to trip me up with his tricks! :-D
<gord> woohoo
<gord> he's trixy
<kamstrup> just adding some tests
<kamstrup> then mp
<gord> kamstrup,  you know omg already wrote about this stuff right? can't disappoint them now ;)
<kamstrup> gord: indeed :-) that kinda upped the pressure a bit...
<kamstrup> gord: as you'll learn soon enough, this was not exactly trivial to get right
<kamstrup> I basically wrote an in-memory relational db :-)
<gord> oh dear, /me gets his finger over the rejected button
<kamstrup> lol
<gord> comment: stop re-writing mysql every six months
<kamstrup> boring
<kamstrup> it would actually be interesting to rewrite the internal lens handling by using in-mem sqlite tables. Will be quite fast, and actually not too ugly
<mhr3> kamstrup, so... i suppose the the merge diff in counted in dozen thousands lines?
<mhr3> is counted in*?
<kamstrup> indeed
<Saviq> nerochiaro, I'm pushing just the input shaping tests to lp:~saviq/+junk/shell-shapetests
<Saviq> nerochiaro, can you try them? I can't seem to be able to fail them even without input shaping..
<nerochiaro> Saviq: how do you remove input shaping ?
<Saviq> nerochiaro, still pushing, though
<Saviq> nerochiaro, I just merged the commits that did the tests
<Saviq> not those that actually implemented the feature
<Saviq> nerochiaro, pushed
<nerochiaro> Saviq: on top of unity-2d-shell ?
<Saviq> nerochiaro, yes
<Saviq> nerochiaro, btw, -shell has stuff merged from trunk again this morning
<nerochiaro> i saw that
<nerochiaro> let me try
<Saviq> I freakin' can't fail those tests... wth
<nerochiaro> Saviq: checking. might be something wrong with waht i do
<Saviq> nerochiaro, btw that's why it's good to write the tests first, too ;)
<Saviq> otherwise you never know if they actually fail :]
<Saviq> or at least make it easy to only merge the tests and not the fix itself
<Saviq> brb
<nerochiaro> Saviq: you have a point
<nerochiaro> Saviq: they don't seem to fail here neither. i'm looking into why
<nerochiaro> Saviq: are you sure you picked up all my changes ? in your branch there's some commits missing it seems. i'm double checking i pushed all
<nerochiaro> Saviq: revision 934 (which i added this morning) is the one that should make the tests properly fail
<Saviq> nerochiaro, oh
<Saviq> nerochiaro, will check out again in a bit
<nerochiaro> Saviq: okies
<nerochiaro> Saviq: i double check and i pushed all of them. the last on top of my branch should be 935 now
<nerochiaro> greyback: Saviq: or anyone: panel buttons for dash submitted as an MR, for whoever wants to take it: https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons/+merge/89414
<nerochiaro> i'll bbiab
<davidcalle> kamstrup, about matching the sorting of lenses in the Home Dash to the lens bar. Would it mean that the lens bar wouldn't be sorted alphabetically on the lens name anymore?
<kamstrup> davidcalle: depends... :-)
<kamstrup> davidcalle: it could be, but not if we let users override
<mhr3> i can imagine that in some languages the ordering isn't what we want
<mhr3> unless it's being sorted on non-localized name
<mhr3> kamstrup, anyway so what was the thing you wanted me to look at yesterday?
<kamstrup> mhr3: some tweaks to the music lens
<davidcalle> kamstrup, ok. I'm just going to make an Aardwark lens to mess with you guys. ;-)
<davidcalle> Aardvark*
<mhr3> kamstrup, oh dear :P
<mhr3> is there a bug opened?
<kamstrup> mhr3: when doing global search, we need to collate the Songs and Albums categories into one Music category (with albums first)
<kamstrup> mhr3: it's in relation to the new homescreen, it's mentioned briefly there
<kamstrup> mhr3: I talked with JohnLea about it
<kamstrup> mhr3: I have a partial branch ready... hold on I'll upload it
<mhr3> Dee.Transaction comes to rescue us :)
<kamstrup> mhr3: you can save yourself a bit of time if you start from lp:~kamstrup/unity-lens-music/home-lenses
<Saviq> nerochiaro, so here's what I'm doing: `bzr branch lp:~unity-2d-team/unity-2d/unity-2d-shell-shaped-testability-shapetests`
<Saviq> nerochiaro, `bzr merge -r 913..907 .`
<Saviq> there are two small conflicts
<Saviq> but that gets rid of the actual shaping code
<nerochiaro> Saviq: I don't understand why you do that merge
<Saviq> nerochiaro, I want to get rid of the actual shaping
<nerochiaro> Saviq: to test that the tests fail ?
<Saviq> I want to have shell with shape tests on top
<Saviq> yes
<Saviq> and they don't
<nerochiaro> Saviq: ok
<Saviq> nerochiaro, http://pastebin.ubuntu.com/
<Saviq> facepalm
<Saviq> nerochiaro, http://pastebin.ubuntu.com/810617/
<nerochiaro> Saviq: only one fails
<nerochiaro> hmm
<nerochiaro> Saviq: can you check that the function to compare window shape in the input_shaping.rb tests don't compare the sizes of the windows anymore ?
<nerochiaro> Saviq: if it does, then something is messed up again and the branch is not current
<nerochiaro> Saviq: but honestly to test that the tests fail if the shaping isn't there, i'd just remove the call for XShapeCombine...
<nerochiaro> even though i understand why you're doing it that way
<Saviq> standup
<nerochiaro> sure
<nerochiaro> i'm there already
<Saviq> Kaleo, you comin'?
<Saviq> nerochiaro, lp:~saviq/+junk/shell-shapetests
<nerochiaro> Saviq: looking into it now
<nerochiaro> Saviq: it looks like on my machine it actually hangs when comparing the images in one case, i'm trying to find out why
<nerochiaro> Saviq: hangs as in IM compare takes 100% cpu seemingly forever
<Mart_ini> hi all
<Saviq> nerochiaro, isn't that why you were comparing the dimensions of the images?
<Saviq> that imagick hanged when they were different?
<Saviq> and also, they shouldn't ever be different, should they?
<Mart_ini> I have a problem with Windows Theme.... Here is a screen shot with current look:http://imageshack.us/photo/my-images/209/zrzutekranu201201201327.png/ ... is there any posibility to change it?:/
<nerochiaro> Saviq: no, i was comparing the sizes because IM returned 0 difference when the sizes were different, and instead i should've checked the error code. but i guess it's a good thing to have both the size check and the error code check
<nerochiaro> Saviq: they should be different in the case when you want the tests to fail: without shaping applied the size of the window is not fullscreen
<Saviq> Mart_ini, looks like your gnome-settings-daemon crashed, did you try to log out and back in?
<Mart_ini> yeah:/
<Mart_ini> and didnt help:/
<Mart_ini> even restart of whole system
<Saviq> Mart_ini, you can change the theme in gnome-control-cente
<Saviq> r
<Mart_ini> yes I can but it didnt work
<Saviq> Mart_ini, try in #ubuntu, here isn't really the place for that
<Mart_ini> There I have few options like Ambiance , radiance, high contrast but even one of it changes nothing
<Mart_ini> ok
<Saviq> there's more people there that will be able to help
<Mart_ini> no problem, thanks:)
<Saviq> nerochiaro, sure, but the test should only pass if the images are the same size _and_ the input shapes are correct, right?
<Saviq> nerochiaro, I removed the unlinks, the masks you generate look ok
<Saviq> except
<Saviq> let me just have one at a time
<Saviq> ah no, ok - there's four
<Saviq> launcher, launcher + dash, launcher + collapsed dash, fullscreen
<nerochiaro> Saviq: to your first question, yes
<nerochiaro> and yes 4 tests
<Saviq> nerochiaro, they're not the same size, though
<Saviq> only the fullscreen one is
<Saviq> the rest are only bounding-box sized
<nerochiaro> Saviq: let's mumble a moment please
<Saviq> i.e. launcher is only the size of the launcher, shouldn't it be a white rectangle with a black rectangle on the left?
<Saviq> sec
<mhall119> didrocks: will you have time today to talk about singlet and quickly, or early next week perhaps?
<didrocks> mhall119: early next week
<mhall119> ok
<mhall119> I'll ping you Monday then?
<nerochiaro> Saviq: i'm a moron,i was using verify() { somevalue } instead of verify_equal('true') { somevalue }
<Saviq> or verify_true() {} ?
<nerochiaro> or that
<Saviq> nerochiaro, okies, good thing we caught that
<Saviq> that would be a non-useful test
<nerochiaro> Saviq: yeah. so i'll fix that and put back the size check
<nerochiaro> Saviq: push and let you know
<Saviq> nerochiaro, thanks
<nerochiaro> Saviq: thanks to you
<Saviq> sometimes I'm being an a$$ for a reason :]
<Saviq> good
<nerochiaro> Saviq: generally you aren't one
<Saviq> yeah, generally
<Saviq> ;)
<nerochiaro> well we all have our moments of assitude ;)
<nerochiaro> Saviq: pushed fixes. hopefully for the last time ;)
<Saviq> nerochiaro, cool, checking now
<Saviq> nerochiaro, yup, much better!
<nerochiaro> Saviq: awesome
<mhall119> kamstrup: https://launchpad.net/unity-lens-sample contains some very old code, what's the plan for that project?
<Saviq> nerochiaro, http://pastebin.ubuntu.com/810671/
<Saviq> launcher+dash failed
<Saviq> that's with shaping
<nerochiaro> wtf, everything worked here
<nerochiaro> Saviq: ^
<nerochiaro> Saviq: can you post the pngs somewhere, like imgur.com ?
<Saviq> nerochiaro, yup
<Saviq> nerochiaro, looks like it's comparing launcher against launcher+dash
<Saviq> might be it's trying to get the shape too fast
<Saviq> nerochiaro, yup
<nerochiaro> Saviq: sleep in the middle ?
<Saviq> nerochiaro, ye
<Saviq> s
<nerochiaro> Saviq: are you pushing that one yourself ?
<Saviq> nerochiaro, no, push
<Saviq> I need to straighten up my branches here first
<Saviq> don't want to push something weird
<nerochiaro> Saviq: 2 secs sleep ok ?
<Saviq> nerochiaro, 0.5 was fine here
<Saviq> nerochiaro, but 2 is fine
<nerochiaro> i'll do 1 then, if 0.5 was fine
<Saviq> I wonder if we can actually use the verify()s timeout here somehow
<Saviq> no idea how that works, though
<nerochiaro> Saviq: better not risk for now
<Saviq> but yeah that won't help either
<Saviq> since what will we verify
<Saviq> the image is there
<Saviq> just not up to date yet
 * Saviq needs to read about the verifies and stuff
<nerochiaro> Saviq: in any case it's a bit weird to do these kinds of tests because ultimately you're still bound by the speed of the machine
<Saviq> nerochiaro, sure, that's why the verify_ stuff helps
<Saviq> I'm not sure how it works, though - will it check every second or?
<nerochiaro> Saviq: yeah, but it works only for things you do in the SUT IIRC
<Saviq> ok
<nerochiaro> it's syncronized somehow
<nerochiaro> Saviq: pushed the sleeps for now
<Saviq> that's why I said /me needs to reda about that
<Saviq> nerochiaro, cool, checkinf
<Saviq> -f
<Saviq> +g
<snadge> :D
<Saviq> nerochiaro, "4 tests, 8 assertions, 0 failures, 0 errors" yay
<snadge> im running precise on a few systems.. including this one which i installed from a daily build
<Saviq> approving
<snadge> anyway.. on this system.. i cant visually tell the difference between a focussed window and a non focussed one
<snadge> they all appear to have focus even if they dont
<snadge> is there a ccsm setting for that?
<Saviq> nerochiaro, on a related note, did you get an answer about the actual input shape of the dash? should it incorporate the shadow or not?
<Saviq> nerochiaro, as the images now very clearly show it's wrong how it is now :)
<nerochiaro> Saviq: i don't think i did. and i didn't go check unity3d yet
<Saviq> let me
<nerochiaro> Saviq: but this is what we had in unity-2d
<nerochiaro> Saviq: so please let's commit this, then fix it in another MR
<Saviq> nerochiaro, already merged
<Saviq> I was curious..
<Saviq> nerochiaro, aaand anyway...
<Saviq> 3d behaves completely different - it takes the whole screen when dash is active
<nerochiaro> Saviq: it's always fullscreen ?
<Saviq> nerochiaro, when the dash is open there's no interaction with the windows below
 * snadge cries
<nerochiaro> Saviq: eww
<nerochiaro> Saviq: well, we're not going back
<Saviq> nerochiaro, not going back, but we might need to revisit our shapes later
<nerochiaro> Saviq: but how do they exit ? clicking outside of the dash area should close it
<Saviq> like have a fullscreen mousearea behind the dash
<Saviq> nerochiaro, yes, the lighter border already does that
<nerochiaro> does what ?
<Saviq> exits the dash
<Saviq> clicking on the lighter border around the dash will exit it, as will clicking anywhere outside
<nerochiaro> Saviq: but that border doesn't have a drop shadow ?
<Saviq> nerochiaro, it does
<snadge> http://askubuntu.com/questions/70071/wrong-window-focus-behaviour-in-unity-but-not-gnome-shell
<Saviq> snadge, sounds compiz-related
<nerochiaro> Saviq: so clicking on the shadow exits. then it's what we need to do in unity-2d too
<snadge> yeah .. only one of my systems does it
<Saviq> greyback, -qt's dash corner has much bigger radius than unity's does, do you know which is correct?
<nerochiaro> regardless of the shaep
<Saviq> nerochiaro, yeah we need a mousarea covering the whole thing
<snadge> but im trying to figure out which ccsm option would be related to window focus appearance
<htorque> didrocks: hi! can you please make sure the old test case in bug 913569 works for you (reveal launcher bar, click on the ubuntu/dash launcher, don't move the mouse outside of the launcher bar area, press alt+f1 â launcher bar should be saturated)? it's not working here.
<Saviq> snadge, I'm not saying it's an option
<htorque> no ubot? well: https://bugs.launchpad.net/unity/+bug/913569
<snadge> looks like its an fglrx problem
<nerochiaro> Saviq: that's two separate issues: one is the non-interaction with the stuff below, the other is what part of the dash should trigger the dash to close
<Saviq> nerochiaro, yes
<nerochiaro> Saviq: i'm focusing only on the latter question
<Saviq> nerochiaro, both minor issues for later
<nerochiaro> Saviq: indeed
<snadge> i need to enable unity switcher apparently
<didrocks> htorque: oh interesting, I found another case then
<Saviq> snadge, tried `unity -reset` to reset your environment?
<didrocks> htorque: try right-click on bfb -> dash home
<didrocks> htorque: alt + F1
<didrocks> it saturated then, isn't it?
<Saviq> greyback, dyams, Kaleo, tiagosh: input shaping merged, yay :)
<Saviq> nerochiaro, can you resubmit the buttons branch so that tarmac won't die?
<nerochiaro> Saviq: will do shortly
<snadge> hmm.. actually that bug seems to describe the fix
<dyams> saviq: very nice
<nerochiaro> Saviq: https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons/+merge/89436
<Saviq> nerochiaro, thanks
<Saviq> greyback, one thing I noticed - press super, alt+f1 - dash goes away
<Saviq> bug? feature?
<dyams> saviq: Atleast I can say its not reported as bug so far :)
<Saviq> dyams, checking with unity
<dyams> saviq: Ok
<Saviq> dyams, unity does not do that
<Saviq> dyams, I say we fix along with the shell work
<dyams> dyams: Ok, sure
<dyams> saviq:^^
<Saviq> dyams, trying to talk to someone smart here? ;)
<dyams> saviq: ;)
<Saviq> dyams, do you confirm that bug, though?
<greyback> Saviq: dyams: nice find, but I'd like to check with design what is the right thing to do.
<Saviq> greyback, sure, another thing is keyboard nav between the dash and the launcher
 * dyams greyback is right 
 * greyback only learns now that nick changes have to be done for each server
<Saviq> greyback, ?
<greyback> Saviq: example?
<Saviq> greyback, go left from search entry
<snadge> ok unity --reset doesnt help.. deleting my .compiz .config and .gnome2 dirs didnt help
<greyback> Saviq: maybe it's xchat
<Saviq> greyback, I don't think it is, you can have different nicks per server
<Kaleo> Saviq: rock
<Saviq> ...and a hard place
<greyback> paper scissors
<greyback> lizard spock?
<Saviq> greyback, you can't have two
<Saviq> paper _or_ scissors
<Saviq> but hey, you lost with yourself :D
<greyback> Saviq: hmm, again I'd like to check. If you're editing text in that box, going left too many times to focus BFB might be confusing too
<greyback> or won :P
<Saviq> greyback, depends how you look on it ;)
<greyback> Saviq: yep, hence asking design ;)
<Saviq> greyback, that was re paper scissors
<Saviq> greyback, but sure, for tv we have going left from dash content
<greyback> that's my answer to everything :)
<Saviq> lol
<Saviq> a good one, too
<greyback> Saviq: yeah that consistency would be nice alright
<Saviq> greyback, except I hate it that I can't go left from search entry to launcher ;)
<Saviq> so yes, that needs design
<Saviq> JohnLea, we need you here :D
<JohnLea> Saviq; where are you?
<Saviq> here
<JohnLea> ;-)
<Saviq> JohnLea, like, on IRC ;)
<Saviq> JohnLea, two things: open dash, press alt+f1
<Saviq> right now the launcher gets focus
<Saviq> but the dash disappears
<Saviq> (in unity other weird things happen, but dash does not disappear)
<Saviq> (that's just the first thing)
<Saviq> I have a bug ready that I can affect to ayatana-design, if you'd like
<JohnLea> bug #?
<Saviq> none, right now
<Saviq> 'cause we weren't sure it's a bug
<Saviq> I can file and affect you guys
<JohnLea> yup, ping me the bug number when you have filed it
<JohnLea> thx
<Saviq> JohnLea, bug #919209
<Saviq> I said I have it ready
<greyback> Saviq: ooh you're kidding! https://bugs.launchpad.net/ayatana-design/+bug/919211
<greyback> Saviq: grrr, you & your efficiency
<Saviq> greyback, no that's fine
<Saviq> I only filed the dash, alt+f1 one
<greyback> Saviq: yep just saw that, pfew
<Saviq> greyback, we need one the other way around, too
<greyback> Saviq: yep
<Saviq> except that going right from the launcher gives you the menu
<greyback> which is pointless
<Saviq> so it might be that we shouldn't have any keynav between launcher and dash
<Saviq> to have it consistent
<Saviq> just use super / alt+f1 to be sure where you'll end up
<greyback> Saviq: yep, hence asking design ;)
<Saviq> yeyp
<JohnLea> Saviq; the dash should hide, current behaviour in Unity2d is correct (but this needs fixing in unity3d)
<snadge> gah... all my windows look like they have focus
<Saviq> JohnLea, ok, so that kind of solves part of #919211
<greyback> JohnLea: woo :)
<Saviq> greyback, I'll cook up a test for that :)
<snadge> probably an fglrx issue.. sigh
<Saviq> snadge, try with radeon
<Saviq> if you can, that is
<JohnLea> Saviq, greyback; take a look at bug #919209 now ;-)
<Saviq> take that!
<Saviq> mwahahahaha
<snadge> ok
<htorque> didrocks: yeah, but again: not when the mouse doesn't leave the launcher bar area
<Saviq> greyback, we do have a bug there, though - go super, alt+f1, then try to dismiss the launcher
<didrocks> htorque: yeah, I misread that part, I edited it, sorry :)
<htorque> didrocks: thanks, and no problem! :-)
<greyback> Saviq: Alt+F1 again, or Escape. You want to click away?
<Saviq> greyback, mine doesn't hide
<greyback> Saviq: hmm, you running shell?
<Saviq> I have to alt+tab / click away to get out of the launcher
<Saviq> greyback, nope, oneiric
<Saviq> wrong
<Saviq> staging
<Saviq> greyback, it works if I just go alt+f1, alt+f1 or alt+f1, esc
<Saviq> but not if I go super, alt+f1, [esc,alt+f1]
<greyback> Saviq: yep, confirmed. I can click away though
<greyback> Saviq: logging bug
<Saviq> greyback, do you think that belongs to launcher or dash tests?
<dyams> greyback: while testing { Super+Num_Key }, I assume that application launched successfully if the tile has atleast one pip
<JohnLea> Saviq, grayback; also see bug https://bugs.launchpad.net/ayatana-design/+bug/869122
<snadge> ok getting somewhere now.. fglrx has the window focus bug.. but radeon does not
<dyams> greyback: i.e to check the application is running status
<greyback> Saviq: yep I know the cause. A bad bit of code from me :(
<greyback> Saviq: launcher I'd say. Other apps can cause it
<Saviq> greyback, oks
<Saviq> JohnLea, apart from point 3. looks fixed in unity-qt
<Saviq> (see how I've sneaked the non-2d name there? ;>)
<greyback> Saviq: oO
<smspillaz> njpatel: comments on https://code.launchpad.net/~vanvugt/unity/fix-742544-alt-trunk/+merge/86779
<smspillaz> snadge: dri drivers do not have the no-damage-events-on-non-window-pixmaps bug anymore
<snadge> dammit.. its an fglrx problem
<njpatel> smspillaz, jasons' work will fix this
<snadge> smspillaz: Im using the latest drivers from amd :|
<njpatel> we can't just revert without having a proper fix
<smspillaz> njpatel: for 4.0 ?
<smspillaz> njpatel: ok, can you leave  comment then ?
<njpatel> not for 4.0, we don't need this in 4.0
<smspillaz> the fix seems to make sense, always picking the "primary" monitor. unless I missed something
<snadge> fglrx_8.920 aka catalyst 11.12
<snadge> installed with --buildpkg Unity/precise
<Saviq> greyback, so I'm thinking separate tests - one that verifies that the launcher behaves correctly when the dash is open (not caring about what the dash does)
<Saviq> and the other just for the dash
<Saviq> (two for the first case)
<greyback> Saviq: yeah that's more comprehensive
<Saviq> - one for alt+f1, one for esc to dismiss
<snadge> smspillaz: i cant find any references to that bug on google
<njpatel> smspillaz, you can't open the launcher when it's hidden on 4.0 if it's not on the left screen easily
<njpatel> that's why it picks 0 (it used to always pick primary)
<njpatel> jason's multimonitor work fixes that
<Saviq> greyback, hmm we actually don't have a test to just check whether launcher shows after dash has been invoked
<Saviq> I'll have one for that, too
<greyback> Saviq: not yet, lots of things to test :(
<Saviq> greyback, yup
<mhall119> does http://blogs.gnome.org/carlosg/2012/01/20/multitouch-is-near/ use any uTouch technology?
<greyback> Saviq: shell in a usable condition now?
<Saviq> greyback, yup
<Saviq> cnd, ^
<greyback> Saviq:  ok, I'll focus more on that for tests in future
<Saviq> greyback, I'll do the four I mentioned
<smspillaz> njpatel: ok, can you comment on the merge then ?
<Saviq> mhall119, cnd will be best to answer that, but he's hard asleep now, I'm afraid
<mhall119> when he wakes up, will it be Friday or Saturday?
<Saviq> Friday
<Saviq> mhall119, but from what I can see there won't be any utouch happening behind that
<Saviq> mhall119, all the work that's gone into X re multitouch while utouch was in the works will, of course
<mhall119> ok, so some of the work that Canonical did for uTouch is helping enable GTK+ touch
<mhall119> that was really my question
<njpatel> smspillaz,  i did
<smspillaz> njpatel: yep, saw, thanks
<smspillaz> just so it didn't look dodge when I abstain for no reason XD
<smspillaz> mhall119: cnd works upstream with XInput2 - some of XInput2 is used for the Gtk+ touch stack. you'll have to ask him on the specifics
<Saviq> greyback, do we want any tests that we know will fail in trunk submitted there?
<Saviq> greyback, the actual question is whether we want _any_ tests that fail in the suite? or do we keep them somewhere in a branch and only merge with the fix?
<Saviq> 'cause I can easily imagine (and not only imagine) people writing tests not being those that actually fix the issues
<greyback> Saviq: can add tests that are skipped by defining them as "xtest something" instead of "test something"
<greyback> so they can be enabled later
<Saviq> greyback, oh cool
<Saviq> greyback, is there a way to actually run them, too?
<nerochiaro> greyback: Saviq: any idea on how to test that the dash will go fullscreen when the resolution changes to resolution that's too small ?
<Saviq> nerochiaro, you could test the dash mode and its height / width?
<greyback> Saviq: no unfortunately, it's just a little bit of syntactic sugar
<Saviq> greyback, ok nvm
<nerochiaro> Saviq: yes but how do i change the resolution in the test ?
<Saviq> nerochiaro, xrandr?
<nerochiaro> Saviq: to what resolution ? each system is different in what it does allow ;)
<nerochiaro> Saviq: and actually on my machine for some reason just right now xrandr isn't working
<nerochiaro> also, do we want to fuck around with resolution on people's machiens ?
<Saviq> nerochiaro, as greyback mentioned earlier - skip the test with a warning
<Saviq> nerochiaro, we can have them separate
<Saviq> greyback, what do you think?
<greyback> I think fucking about with people's resolution is dodgy
<nerochiaro> my suggestion here is to test at whatever resolution we are right now and check the dash in the correct shape
<greyback> Best detect in the test what resolution they have, and just return if it's not suitable
<greyback> nerochiaro: yeah, I think that's ok
<nerochiaro> greyback: or test that we do the right thing at that resolution, knowing that maybe at another resolution we will fail
<Saviq> nerochiaro, btw, it doesn't, not in my VBOX at least
<nerochiaro> Saviq: doesn't what ?
<Saviq> nerochiaro, doesn't adapt
<nerochiaro> Saviq: no it doesn't, i'm working on it now :)
<greyback> nerochiaro: exactly. I don't see how to change resolution safely
<Saviq> at 640x480 the launcher is resized, but the dash doesn't change modes
<Saviq> nerochiaro, ok
<Saviq> greyback, nerochiaro: maybe we could have an env var
<Saviq> that says "RUN_DISRUPTIVE_TESTS"
<nerochiaro> greyback: it would be great to be able to run the tests in an instrumented environment where ScreenInfo returns whatever we want it to return
<nerochiaro> Saviq: ^
<Saviq> nerochiaro, that might make sense
<nerochiaro> so we would be able to fake changes in the resolution
<Saviq> nerochiaro, can't we hack ScreenInfo already?
<Saviq> nerochiaro, from testability
<Saviq> nerochiaro, just write to the properties
<nerochiaro> Saviq: hmm, it's a singleton class, not part of the object tree
<nerochiaro> doubt it can reach it
<Saviq> nerochiaro, oh :/
<nerochiaro> Saviq: but aren't we running unity-2d-shell with -testability ?
<Saviq> nerochiaro, yes, we are
<nerochiaro> we can check that and use the fake ScreenInfo in that case
<Saviq> yup, we probably coudl
<Saviq> *could
<nerochiaro> but i'm not sure it's a great idea from another standpoint because it's just adding an extra code path _in_ the app under test
 * nerochiaro got an idea
 * greyback pondering how evil Xephyr would be for this
<Saviq> greyback, too evil
<nerochiaro> why ?
<Saviq> unless we decide to run everything under xephyr, that i
<Saviq> s
<greyback> Saviq: just for resolution tests, why so evil
<greyback> ?
<Saviq> dunno, I kind of hate xephyr for some reasony
<Saviq> -y
<Saviq> might have had issues with it before or something
<Saviq> nigthmares maybe
<Saviq> and simply unsure if we really need that
<nerochiaro> Saviq: i guess it's the same feeling i have for vbox ;)
<Saviq> nerochiaro, true, true
<greyback> I think it's an option, but not a great one. It means installing more crap on the machine under test
<nerochiaro> surely running the tests under xephyr will be closer to the real system than vbox
<Saviq> nerochiaro, how so?
<Saviq> nerochiaro, as far as the system knows, vbox is just different hardware
<Saviq> as far as an application knows, xephyr is just a different X server/client/whatever
<Saviq> so the difference is just at a different level
<Saviq> can't we just skip the tests that are disruptive unless there's an env var set?
<Saviq> and those that we can't run (like when Ugo's xrandr is broken)
<nerochiaro> Saviq: sure, if you know xrandr is broken ;)
<greyback> Saviq: yep, do-able
<Saviq> nerochiaro, how does your broken xrandr show it's broken?
<nerochiaro> Saviq: in general i agree, in this particular case i dunno even if xrandr works, how do we know which resolution to change to ?
<Saviq> it probably doesn't display the res or something?
<nerochiaro> Saviq: it just say it faield to change the res
<nerochiaro> might be i'm using nvidia drivers or something
<Saviq> nerochiaro, I'm on nvidia too
<Saviq> nerochiaro, just run xrandr, find one that fits, change
<Saviq> change back
<Saviq> +test in between
<greyback> nerochiaro: this is the reason why VBox is good idea IMO. If something core is broken on your machine, then test will fail because of it . At least in a VBox instance, it should be a clean install & everything working
<nerochiaro> Saviq: "find one that fits" ?
<Saviq> nerochiaro, it will list you available resolutions
<Saviq> just find one that's low enough that the change will happen
<Saviq> if any of that fails, the test failed, but will tell you why
<Saviq> it
<Saviq> shit will happen, yes - tests will sometimes fail due to <input_your_favourite_reason_here>
<nerochiaro> greyback: Saviq: what i'm really thinking is that we should take a step back and define who are the tests meant for. if they are meant for any random user to run,it's one thing, if they are meant to be run on jenkins for verification before release,it's another
<Saviq> nerochiaro, they're primarily based for automated testing
<Saviq> but if we can make them work for user x then cool
<Saviq> greyback, unless I'm mistaken with that?
<greyback> that's my priority list, yeah
<greyback> nerochiaro: I do want test to run on your machine, without VBox. But there's only so much time I can spend thinking of every possiblt thing your machine might have different to work around
<nerochiaro> greyback: i agree. i'm not necessarily against vbox or xephyr
<nerochiaro> bbiab
<greyback> nerochiaro: in fact, I prefer when they can run inside some virtualised thing, so I can do other stuff as they run
<greyback> VBox has a headless mode too, which I want to play with in future
<Saviq> greyback, yeah I do the same, they just run away, I'm doing other things, when I get back I have a result ready
<greyback> Saviq: yep, perfect, that's what I'm trying to get going
<greyback> Amazing all the little things that can get in the way
<Saviq> yup
<greyback> Saviq: nerochiaro: But I have to say, this week with you all using Testability, your comments about problems, stuff that's missing, etc, have been bloody useful
<greyback> Great to get proper feeedback
<greyback> feeeedback
<Saviq> greyback, for me it's awesome to see that we can actually test stuff
<Saviq> before your Testability talk I was scared as hell
<Saviq> easy peasy now
<greyback> Saviq: it is nice, with a few painful exceptions. XDotool stuff needs a lotta loving (in progress)
<Saviq> sure, but we can already do a lot
<greyback> and we're really pushing what the tool can do. It wasn't meant for testing a desktop environment
<greyback> Yep, I'm pretty pleased with it
<Saviq> I love it how we can hack a test up, make it fail (well, error at this point :P) and the fix it, pass the test
<Saviq> done!
<Saviq> no f*cking about
<greyback> Yep. It's a good way to work
<Saviq> that's what Ugo failed to do with the shaping work - he built tests on top of a working feature
<Saviq> it was difficult to actually see whether the tests fail when the feature was broken (or not there)
<Saviq> greyback, you sir need to settle on a nick, too :P
<greyback> Saviq: eh?
<Saviq> you're greyback here, gerboland on LP
<Saviq> greyback, you got a MR waiting, sorry
<greyback> Yeah, always meaning to get that changed
<greyback> Saviq: np, looking
<Saviq> greyback, we (by we I mean you with a little help from your friends) need to define a process for working with tests
<Saviq> like whether we want separate branches for tests
<didrocks> Saviq: bug #919209 is a duplicate
<Saviq> submitted with xtest to disable them initially
<Saviq> didrocks, couldn't find one, sorry
<didrocks> bug #885304
<greyback> Saviq: I see. My concern is someone writing a disabled test will then forget to do the fix and enable the test.
<greyback> So I want fix+test
<Saviq> greyback, well, the bug will be open all the time
<Saviq> so as long as someone is assigned to the bug...
<Saviq> greyback, fix+test has the added issue of not being able to test the test
<Saviq> or making it difficukt
<Saviq> s/k/l/
<greyback> Saviq: sure
<Saviq> exactly our issue with Ugo today
<greyback> Yeah, that I saw
<Saviq> I spent several hours to verify that the tests actually fail without the fix
<Saviq> that should be easy as pie
<greyback> True
<Saviq> I'm not requiring for people to go TDD
<Saviq> but a separate test / fix branch might be useful
<Saviq> and easy to work with, really
<Saviq> since they're separate enough, merging the tests into your fix branch to test would be very easy
<Saviq> problems arise when you need to fix your tests
<Saviq> but they're even bigger when you only have one branch where the history gets intertwined
<greyback> Let me recap. You have a bug to fix. You first write a test for the fix in one branch
<greyback> In second branch you do the fix.
<greyback> You try to have both merged into trunk simultaneously
<greyback> Test-only branch will cause Jenkins to lockout, unless test is disabled.
<Saviq> that's TDD, I'm not set on whether you should write the test first or the fix
<greyback> Yeah, I'm pondering out loud ;)
<Saviq> that's irrelevant, really
<Saviq> but there are two approaches here
<Saviq> 1) you merge xtests and not tests
<Saviq> then you merge the fix, actually enabling the tests
<nerochiaro> Saviq: greyback: re
<Saviq> 2) merge the fix and the test before merging into trunk
<Saviq> 2) has issues with MRs
<Saviq> 1) does not
<greyback> Yeah option 1 is what I'm thinking is good
<Saviq> two separate MRs - one for the test, the other for the fix - only thing we need to remember is that the test one needs to be merged first
<nerochiaro> at this point i'm actually starting to think that TDD might be a better option (not mandatory, just saying for me for some cases)
<Saviq> nerochiaro, !!!!!
<Saviq> D:
<Saviq> :D
<Saviq> ;)
<greyback> Saviq: yep
<greyback> nerochiaro: omg!
<greyback> :)
<nerochiaro> yeah, shocking i know
<Saviq> I think he's been bitten by me being an a$$ today
<Saviq> and even more by me being an a$$ rightly so
<nerochiaro> by you being very rigorous, sir. that's differnet
<greyback> nerochiaro: you have opinion on what we're discussing above. A test-driven workflow process
<greyback> ?
<mhr3> gord, question about the views that displays stuff from lenses
<mhr3> gord, it seems like they just append the results, no matter the position in the model
<mhr3> gord, do they support inserting at proper position?
<greyback> Saviq: nerochiaro whatever you two get up to in private has no business on this channel ;)
<mhr3> gord, like i have 5 results in the view already and then i want to insert something at pos 0
<nerochiaro> greyback: i'm not much in favor of a tests branch and a feature branch, MR'd separately. adds lots of overhead imho
<Saviq> greyback, right, we should take that to #unity-qt
<Saviq> nerochiaro, yes, the overhead is definitely an issue
<Saviq> nerochiaro, but how else do you think we can make sure it's easy to verify the test itself?
<nerochiaro> i've gotta think about it a bit
<greyback> Saviq: LP can have one branch depend on another. Might help prevent fix being merged before test
<gord> mhr3, are you talking about per category views?
<Saviq> greyback, yeah, but tarmac pukes with that
<greyback> Saviq: ahh, I didn't know
<nerochiaro> if bzr made it easier to reorder the history i would suggest that when you commit you move them as the first commit of your MR
<mhr3> gord, yea
<Saviq> sure, if we were using git I would just rebase my fix on the test
<Saviq> but we're not :P
<nerochiaro> yeah, a man can dream right ;)
<mhr3> gord, oh right the model is then split to categories... so no straight mapping from the model positions...
<gord> mhr3, yeah, we go in order iirc, but the only signals the views get are row_added/row_removed so any changes are appended/removed
<nerochiaro> Saviq: if the commits about the tests are not mixed with the commits about the feature one can just revert the block of commits about the feature when reviewing,no ?
<nerochiaro> Saviq: what you did in my case
<mhr3> gord, ok then, i'll pre-sort it in the lens, that will surely be easier...
<nerochiaro> Saviq: so maybe we can either do the 2 branches thing or the grouping thing, and each dev choose which one they prefer
<Saviq> nerochiaro, meeting, will get back to you
<greyback> nerochiaro: sorry, grouping thing? You mean merge test into fix before MR?
<nerochiaro> greyback: i mean that all commits that are not tests should not be mixed with the commits (or hopefully, single commit) that are tests
<davidcalle> mhr3, wouldn't that hurt lenses with scopes with different latencies? As the result would have to wait for the slowest scope to pass results before being displayed?
<nerochiaro> greyback: so one can do "bzr merge -r X..Y ." where X and Y are the non-test commits, to revert the feature but keep the tests
<nerochiaro> greyback: i think it works well for small bugfixes
<nerochiaro> greyback: larger bugfixes might want the split branches
<greyback> nerochiaro: true. I think it's valuable to keep them separate
<greyback> nerochiaro: just trying to figure out best way so there's not too much overhead
<nerochiaro> greyback: yeah, and i think the overhead of splitting is ok with a large branch (like -shaped) but not ok with a small fix
<greyback> say if a fix is bad, but the test is good, having them separate in trunk is great
<nerochiaro> greyback: so for the small fix we can just have one single branch with feature commits and test commits cleanly separated
<mhr3> davidcalle, well, yes, in some way
<nerochiaro> greyback: well, if the commits are not mixed, it's easy to merge just a part of them,as if they were from 2 separate branches
<greyback> nerochiaro: I dunno, then we've got 2 policies which adds confusion
<greyback> nerochiaro: sure
<nerochiaro> greyback: right. i just feel neither works well for all commits
<nerochiaro> greyback: for all MRs, sorry
<mhr3> davidcalle, i'll be actually sorting the results within one scope, so no big deal
<greyback> nerochiaro: Yeah, I'm torn myself. I'd rather not the pain for every little bugfix
<greyback> nerochiaro: but I don't like there being 2 policies either
<mhr3> davidcalle, but now that i think about it, the merge strategy might actually not work at all
<nerochiaro> greyback: frankly i wouldn't want to make any of these policies mandatory either
<mhr3> and kamstrup's gone already :/
<davidcalle> mhr3, why?
<greyback> nerochiaro: it wouldn't be a policy if it's not enforced :)
<greyback> nerochiaro: guidelines are a nicer term
<mhr3> davidcalle, cause you are sorting the model, but the dash won't care about the order of the model
<nerochiaro> greyback: right
<mhr3> it's appending latest results at the end
<davidcalle> mhr3, indeed...
<davidcalle> mhr3, can the Dash be changed in time for Precise?
<mhr3> that's a topic for next week's discussions :)
<mhr3> i suppose 2d has the same issue?
<mhr3> greyback, ^^?
<didrocks> greyback: bug #919226 is another duplicate you just opened of bug #919209 ? (which I signaled as a duplicate of bug #885304 ?
<greyback> mhr3: yes I believe so
<greyback> didrocks: 919226 != 919209 - it's a different bug
<didrocks> urgh, yeah
<didrocks> 919226 is the duplicate of bug #885304
<didrocks> not 919209
<didrocks> isn't it?
<greyback> didrocks: in the code, it's actually a different issue
<mhr3> greyback, one can totally tell that you studied maths ;)
<mhr3> (919226 != 919209)
<greyback> mhr3: 8 years of university baby!
<didrocks> greyback: can you please dup 919226 to 885304?
<didrocks> greyback: I'll undup 919209 and say "sorry" to Saviq :)
<didrocks> or are those you mean, "it's different bugs?"
<greyback> didrocks: yep, 919226 != 885304
<greyback> didrocks: it's a problem determining which window to give focus back to
<didrocks> hum, weird ;)
<didrocks> ah ok
<Saviq> guys, straighten your maths up and let me know ;)
<mhr3> greyback, i'm just waiting while you get to a dupe and type 9098 == 9172
<greyback> didrocks: tho there should be a different bug it is a dup of, am searching
<didrocks> anyway 919209 is a different one as well, undupping
<greyback> mhr3: I... just ... can't  gaah
<Saviq> nerochiaro, problem with "grouping" is that after review you will fix the test, then you will fix the feature... and then you're not grouped anymore
<mhr3> greyback, so it'll be "~=" ?
<nerochiaro> greyback: do you mind if i rename tests/places to tests/dash ? we can finally get rid of that old name now
<Saviq> that's never gonna work
<nerochiaro> Saviq: ah, good point. keep thinking in terms of git
<nerochiaro> Saviq: feh
<greyback> nerochiaro: please do!
<greyback> awww
<nerochiaro> Saviq: but i really hate forcing separate branches even for small bugfixes
<nerochiaro> grrr
<nerochiaro> and bzr support for in-place branches ain't that great either so i have to keep them in two dirs, and rebuild all two times
<nerochiaro> bleh
<Saviq> nerochiaro, well, colo-branches work ~fine for me
<nerochiaro> it's the ~ that bites me at the wrong moments
<Saviq> unless I move the whole repo around, when it dies completely <headdesk>
<nerochiaro> or rather, bit me
<Saviq> well, ok, the only real issue I've had is moving the repo around
<Saviq> it's got absolute paths saved in there
<greyback> Saviq: I am thinking for a bug fix, the overhead of 2 branches is too much. As long as test and fix are separate commits, it should be ok
<Saviq> which is :O
<nerochiaro> i dunno, it might have been me being stupid, but sometimes switching between branches confused it immensely
<greyback> Saviq: problem is defining "just a  bugfix" :)
<nerochiaro> i'll give it another go i guess
<nerochiaro> or just suck up the overhead
<Saviq> greyback, ok so maybe the guideline would be: every MR needs to have a clear way to get rid of the fix to be able to test the test
<Saviq> how you achieve that is the dev's responsibility
<greyback> Saviq: yeah, that's my thinking
<Saviq> nerochiaro, yeah I can't understand why once `bzr switch trunk` works and once it does not
<Saviq> and then list out the recommended approaches
<greyback> If you write something that needs more than 1-2 tests, then the tests should be separate
<Saviq> `bzr rebase` might be your friend there, too
<Saviq> aanyway, EOD for me guys
<Saviq> we'll talk on monday, have a great weekend
<greyback> Saviq: thanks for good discussion
<greyback> Have a good one!
<nerochiaro> have a good weekend
<nerochiaro> Saviq: one last thing, if you have a sec
<Saviq> nerochiaro, yup
<nerochiaro> do you know if when i overwrite a branch with --overwrite and you want to pick up what i did, but preserve the build in your local tree, how to do that ?
<nerochiaro> say you branched earlier, then i overwrote the branch, then you want to pick up my overwritten branch
<nerochiaro> but in the same dir as the previous branch
<Saviq> nerochiaro, `bzr pull --overwrite` should do, no?
<nerochiaro> Saviq: i didn't know it existed :)
<Saviq> :)
<nerochiaro> Saviq: because with push --overwrite is permissible, then we can relatively easily reorder the history git-style with bzr uncommit and a few helper scripts
<nerochiaro> s/with/if
<nerochiaro> and ask the reviewer to pull --overwrite again
<Saviq> nerochiaro, yeah sure, but I'm too afraid to do that in bzr
<nerochiaro> Saviq: i've been using uncommit a bunch and it's really sae
<nerochiaro> safe
<nerochiaro> but YMMV
<Saviq> we basically need a `bzr rebase -i`
<nerochiaro> Saviq: ok i'll think about it
<nerochiaro> Saviq: have a good weekend
<Saviq> cheers
<nerochiaro> greyback: that's funny, i'm fixing something where the test is actually longer than the fix
<nerochiaro> greyback: also the test depends on something that's in gsettings, do i hardcode these values in the test file or read them from gsettings
<nerochiaro> ?
<greyback> nerochiaro: oops sorry, reading
<nerochiaro> greyback: np
<greyback> yeah I can see lots of tests longer than the fixes ;)
<greyback> Especially with my demand for a nice long comment at the top
<greyback> Oh gsettings grr, another thingy on my list to figure out a proper test system for dconf stuff
<greyback> nerochiaro: reading from gsettings risky?
<nerochiaro> greyback: didn't say risky, just wondering what i should do. in the end the test will mostly mirror the fix, since we can't change the resolution on the user's machien
<nerochiaro> greyback: i mean, i will read the min resolution, check what the user has, and test what the dash does. the dash will read the min resolution, check what the user has, and do something. i mean, it's pretty much the same ;9
<nerochiaro> ;)
<greyback> nerochiaro: lol ok so. Go for gsettings then
<burli> does someone use unity-2d? or is maybe a developer?
<burli> I want to know why unity-2d does not support the shortcuts for the lenses
<burli> like Super+a or Super+f
<nava_> i use it
<nava_> i dont know wht
<nava_> why
<nava_> but you can mail them to why they dont develop it
<burli> and I want to replace Metacity with Mutter
<nava_> why ?
<burli> With Metacity I have problems with tearing
<nava_> ok
<nava_> did u try unity 2d 5.2 ?
<nava_> its new
<nava_> just 1 week release
<burli> It looks good so far. The only downside is, that the window decorations is not hidden at maximized windows
<burli> yes, I have Precise
<nava_> good
<nava_> enjoy it
<nava_> and also u can report bugs in lunchpad
<burli> I can, and I do
<nava_> good
<burli> nava_, why do you use unity-2d?
<vadi2> Does unity 2d allow you to re-order icons?
<vadi2> I cannot seem to be able to drag the icon out. (using 2d for performance reasons)
<kenvandine> mhall119, did you say that i should be able to add/remove filter options now?
<mhall119> kenvandine: on what?
<kenvandine> a scope
<kenvandine> whoops
<kenvandine> completion fail
<kenvandine> mhr3, ^^
<kenvandine> sorry mhall119 :)
<mhall119> ah, ok
<mhall119> no problem :)
<mhr3> kenvandine, that's right
<kenvandine> mhr3, well it doesn't blow up if i do it
<kenvandine> but the lens doesn't see it
<mhr3> nooo, dont tell me it doesn't work
<kenvandine> mhr3, i wish i wasn't telling you that :)
<mhr3> kenvandine, could you just restart unity while your lens is up?
<mhr3> see what happens
<kenvandine> i tried, restarting unity makes it show up
<mhr3> cause i have a feeling that at some point unity no longer cares about changes to the model
<mhr3> but that'd be a bug in unity
<mhr3> kenvandine, anyway now that it's restart does it react to changes in the filters?
<kenvandine> i didn't try that, let me do that
<kenvandine> actually, maybe it isn't unity's fault
<kenvandine> i don't get the filter.changed signal
<kenvandine> i connect to the signal before i add options, and get the signal when it is first populated
<kenvandine> but later if i remove or add an option i don't get the signal
<kenvandine>         var filter = scope.get_filter ("account_id") as CheckOptionFilter;
<kenvandine>         filter.add_option (account.id, account.service + "/" + account.username);
<kenvandine> is what i am doing
 * kenvandine restarts unity
<kenvandine> ok... that doesn't really help... i have an unrelated crasher when interacting with those filters :)
<kenvandine> but am am not getting filter.changed signals after i initially populate them
<jasox> hey guys
<snadge> gday
#ubuntu-unity 2012-01-21
<mhr3> do we have a bot here that does !later ?
<mhr3> !help
<mhr3> +help
<mhr3> guess not
<mhr3> will have to catch ken some other time
<snadge> negus!
<BerndSch_> hello, where do I find Unitys log messages? I would like to know why a lens I installed will not load successfully
<mick0> BerndSch_: I did a grep on unity in /var/log and found most mentions in dpkg.log, some in kern.log and a few in auth.log
<mick0> I don't know if messages related to your problem will be mentioned there though.
<BerndSch_> mick0: thanks for you answer, but I didn't found usefull information in /var/log
<mhall119> calmpitbull: are you using the latest Unity in precise?
<calmpitbull> hello guys, how to change color in panel
<calmpitbull> 5.0
<mhall119> ok, just checking
<mhall119> not sure if there's anyone in right now who can help you (it is a saturday afterall)
<calmpitbull> i know :)
<mhall119> but this is the new place to ask about Unity stuff
<calmpitbull> nice, im big unity fan
<Daekdroom> calmpitbull, install compizconfig-settings-manager
<Daekdroom> run 'ccsm', go to Ubuntu Unity Plugin, and change it under experimental tab.
<Daekdroom> Hm.
<calmpitbull> no
<Daekdroom> To be honest, the panel you can only change opacity.
<calmpitbull> u can change only launcher not panel
<Daekdroom> The panel is tied to the theme you're using.
<calmpitbull> i know, but where is the setting for pannel
<calmpitbull> it has to be for each theme the same, not color of corse
<Daekdroom> What do you mean where is it?
<Daekdroom> It's within the theme.
<Daekdroom> In a css file.
<calmpitbull> ok
<calmpitbull> gtk-3
<calmpitbull> ?
<calmpitbull> in this file
<Daekdroom> It depends on the theme.
<calmpitbull> thx man ill report back if i did it
<Daekdroom> calmpitbull, it's somewhere inside gtk-3.0 folder, that I know for sure
<calmpitbull> maybe gtk.css
<calmpitbull> ill look for it
<Daekdroom> calmpitbull, gtk-3.0/apps/unity ?
<calmpitbull> why apps
<Daekdroom> Not sure why it's inside that folder, but I think it's it.
<calmpitbull> no apps, but there is gtk-widgets.css
<Daekdroom> But there is a folder called apps.
<calmpitbull> no
<Daekdroom> You're not using Ambiance, are you?
<calmpitbull> no
<Daekdroom> Ah.
<calmpitbull> :)
<calmpitbull> but maybe that is the best way to go
<calmpitbull> i think i found it, thx for the help man
<calmpitbull> i did it
<calmpitbull> :)
<Omega> How hong have we been in this channnel?
<mhall119> Omega: days
<Omega> I just don't pay attention to channel topics.
<Daekdroom> Me neither.
<Daekdroom> I think I changed my auto-join to this channel yesterday.
<Omega> Hey Daekdroom, I remember you.
<Omega> Anything memorable happen to you?
<Daekdroom> None comes up to my mind right now
<Daekdroom> None relevant to this context, that is
<Omega> (that was my way of asking you how you were)
<htorque> hi all! is anyone here using the xorg-edgers ppa and seeing this weird issue with the unity-greeter's dot overlay? â http://img.xrmb2.net/images/715175.jpeg
<Daekdroom> I'm fine.
<Daekdroom> htorque, I'm using xorg-edgers and that happens to me too.
<htorque> good to know, thanks! :-)
<Daekdroom> htorque, r600g mesa driver.
<htorque> that's ati? i'm using intel hd 3000 here.
<Daekdroom> Yes. ATI.
<Daekdroom> HD5450
<mgedmin> new unity fun: there's an application I cannot switch to by pressing <Super>-number or selecting it via Alt-Tab
<mgedmin> I can switch to it if I trigger Scale and click on it
<mgedmin> and this is not the transparent wide border/window shadow touching screen edges bug
<mgedmin> the app window is small and is in the middle of my first workspace
<smspillaz> mgedmin: which window is it ?
<mgedmin> gtimelog's
<mgedmin> this is the first time it has happened with gtimelog
#ubuntu-unity 2012-01-22
<vadi2> Is anyone else extremely bothered by 2D unity refusing to hide from the mouse if there is a pending notification - forcing you to click on the notification first if you want to see the content the panel is hiding?
<BerndSch_> hi, what's the best way to debug Lenses? Where can I find which lenses are loaded? Where can I find why the search signal don't trigger for my lens?
<mhr3> BerndSch_, debug prints + running the lens from console works fine
<Petko10> hey guys , I don't see too much action going on , but I'll guess I'm in the right place . I want to get some feedback on my idea for the calendar applet here : http://brainstorm.ubuntu.com/idea/29130/
<Petko10> if anyone would be kind enough to review it
<mhall119> Petko10: I've been wanting an indicator for notes/tasks for a while now
<mhall119> I'm not sure the clock applet is the right place for it though
<BerndSch_> mhr3: no, sadly not. The lens+scope works fine. I see the debug output in the init method. But I see no lens (no icon) and there is no debug output from my search method (enabled global search)
<BerndSch_> mhr3: I think this all has something to do with the apparmor stuff I integrated in my source because I submitted my lens to the Software Center. This all works fine with 11.10, but don't work now with 12.04
<Petko10> mhall119: well the applet now has some sync with mail clients (frankly I haven't tried it :?) so I guess it has some functionality like that . all I really want is to make it big , so it's more usable than a pocket calendar (and that one could annotate in it)
<mhr3> BerndSch_, if you dont see the lens in the bottom bar of unity that's pretty bad
<BerndSch_> mhr3: yes, and so I would like to know how I can debug wich lenses are loaded at startup and how I can debug the search behaviour. My lens connects to the search signal, but why the callback method get never called?
<mhr3> BerndSch_, running unity itself in console might reveal something
<BerndSch_> mhr3: I think debugging lenses and scopes are a mess at the moment?! Why is there now documentation how to debug them? Gnome it's easier with this think. There you can see why an extensions isn't loaded and it's easier to see the debug output
<BerndSch_> mhr3: I think it's the apparmor think that blocks my lens, but how I can debug that?!
<mhr3> sorry i know nothing about apparmor
<BerndSch_> mhr3: ok, no problem
<thumper> morning
<Saviq> thumper, it's monday already?
<Saviq> jeez
<Saviq> you guys have it tough...
<thumper> Saviq: yes... yes it is
<smspillaz>  thumper morning
<smspillaz> (night)
<smspillaz> Saviq: its uh
<thumper> smspillaz: hi
<smspillaz> early here
<smspillaz> hey hey
<thumper> bschaefer: feel free to chat about normal untiy stuff here :)
<bschaefer> thumper, alright
<thumper> :)
<bschaefer> thumper, so sam and andyrock both reviewed the alt+f1 nav mode bug so I would say that bug looks fixed
<thumper> awesome
<bschaefer> thumper, and the ibus problem is slightly weird. I am not sure how far I should be going on it
<thumper> is it unity specific?
<thumper> or ibus in ubuntu in general?
<bschaefer> thumper, well if setting IBUS_ENABLE_SYNC_MODE causes the problem but the problem is that the IMs can't handle all the input
<bschaefer> so it gets sent to gtk then it commits the letter but there is still preedit left around so that is a bug in the IM
<thumper> IMs?
<bschaefer> input method
<bschaefer> like hangul or pinyin
<bschaefer> umm so if the IM cant handle an input char such as space it returns FALSE and lets gtk handle it; the bug is it leaves the preedit around
<bschaefer> It is not unitys problem; but im not sure who to blame
<bschaefer> because I don't know the specs for what an IM should do. Should it be able to handle all the input? Or is that ibus problem? Or should ibus not even offer IBUS_ENABLE_SYNC_MODE
<bschaefer> thumper, sorry, spent a while digging though ibus, ibus-hangul and libhangul code. I was able to get the space working correctly though; in libhangul
<thumper> hmm...
<thumper> I'll escalate this through the distro
<bschaefer> thumper, alright. I just wish ibus and unity could be friends :)
<bschaefer> I need to talk with jay about how far he has gotten on the TextEntry in nux. With ibus support
<thumper> bschaefer: do you have the bug number to hand?
<bschaefer> 880876
<bschaefer> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/880876
<bschaefer> there is more info from me in there too
<thumper> ta
<bschaefer> thumper, also to prove this isn't unitys fault you get the same results in GNOME if you set the env var
<bschaefer> or force ibus to set it to true. So it is a bug with that env var and ibus and the specific IM engine being used
 * thumper nods
<thumper> I've asked for some distro help on the ibus stuff
<bschaefer> if it isn't in unity fault should I set the bug to invalid for unity of leave it? As it does effect unity but it isn't unitys fault
<bschaefer> thumper, and thanks
<bschaefer> hey mhr3
<mhr3> sup bschaefer
<bschaefer> mhr3, I did some testing
<bschaefer> and when you kill the say the applications daemon and then search (it restarts it self) the init does nothing
<bschaefer> it still has a problem when you kill the lens and then your next search does nothing
<mhr3> bschaefer, init?
<bschaefer> it comes up empty
<bschaefer> sorry, umm in LensView the initial_activation_ bool
<bschaefer> that is used when a lens connects and it calls Search("");
<bschaefer> but that Search(""); does not actually reset the lens
<mhr3> yea, there's something odd
<mhr3> i'll have to look at it closer
<bschaefer> alright, because that line of code causes a problem with my branch for the no-results-hint
<bschaefer> but cool, let me know if you find something. Another thing I noticed was unity --reset does not cause the problem. Only on a fresh login or reboot
<bschaefer> mhr3, with the Search (""); call emitting OnSearchFinished with 0 results.
<mhr3> i also noticed some problem with models, when lens restarts they sometimes dont see to work properly
<bschaefer> mhr3, let me know if you find something :). Ill leave my branch as is because I still need to wait for mikkel to finish the new home view.
<bschaefer> also it is looking a lot nicer, the home view
<mhr3> bschaefer, sure, i hope we'll merge his branch soon, the diff is becoming too huge
<bschaefer> mhr3, haha. Yeah. I  might want to split mine up into one for LensView/DashView and one for the HomeView...
<bschaefer> I dont like getting the diff to large
<bschaefer> mhr3, I also added a manual test for it in unity. Not sure how you would test for this else where...
<mhr3> yea, good idea, the lens tester will probably test it too, but sending the hint doesn't mean that unity is displaying it, right? :)
<bschaefer> mhr3, correct :) It sends it when it is == 0 then unity does a check because the lens might not have a no-result-hint
<bschaefer> mhr3, but if you emit the OnSearchFinished with 0 results unity should always display something
#ubuntu-unity 2013-01-14
<sil2100> Trevinho: ping!
<mterry> cyphermox, bam, libappindicator builds for both i386 and amd64 in my ppa now
<mterry> let me give you branch link
<mterry> cyphermox, lp:~mterry/libappindicator/fix-tests
<cyphermox> mterry: I'd kiss you :P
<mterry> cyphermox, well, several of those fixes were making timeouts longer.  We'll see how armhf does...
<cyphermox> yeah :/
<mhall119> cwayne: ping
<cwayne> mhall119: pong
<davmor2> mhall119: nice way to blag cwayne into do some work on something :D
<mhall119> :)
<mhall119> davmor2: you scared him off
<davmor2> it's that work word
<didrocks> mterry: hey, around?
<cwayne> mhall119: ping
<mterry> didrocks, hi
<mhall119> cwayne: welcome back
<didrocks> mterry: i think you saw that unity didn't migrate to the release pocket
<mhall119> cwayne: jvrbanac and I are starting work on https://wiki.ubuntu.com/DeveloperNetwork
<mhall119> which can provide a REST/JSON API for things like Gtk and Qt once it's done
<mhall119> if you want to help :)
<didrocks> mterry: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems to show it's because of bamf bin package change
<didrocks>     * i386: ginn, gnome-pie
<didrocks> ginn and gnome-pie seems to need a rebuild
<didrocks> do you have time to rebuild them?
<didrocks> for ginn, it needs merging back to trunk (you can autoapprove the rebuild I guess)
<mterry> didrocks, OK
<didrocks> mterry: do you have the time? I can try doing it between 2, but it would be great to have unity in hands of people today :)
<cwayne> mhall119: sure, ill help :)
<didrocks> mterry: also, do you have any news on libappindicator?
<mterry> didrocks, yeah I think I fixed the amd64 issue this morning, gave cyphermox a branch
<didrocks> mterry: \o/
<didrocks> cyphermox: oh, FYI, autopilot-gtk lost his libindicate dep
<didrocks> cyphermox: I think you saw the MR, maybe we can daily release it now?
<didrocks> mterry: so yeah, for ginn, feel free to autoapprove it. I hope that a rebuild will suffice :)
<cyphermox> yeah, it should be good now
<cyphermox> didrocks: fwiw, same kind of thing for autopilot-qt, they removed the qt5 dep
<didrocks> cyphermox: sweet! 2 more soon then? \o/
<cyphermox> yup
<didrocks> I just overflight over the autopilot-qt one
<didrocks> I'll blame that on jetlag :p
<cyphermox> let me ship you the MP for indicator-sesion so we can get that out of the way
<didrocks> cyphermox: with the autopkgtest, rocking! :)
<mterry> didrocks, catching up on this unity thing...
<cyphermox> didrocks: wait wait, not sure it actuall yworks right now the autopkgtest
<didrocks> mterry: thx ;)
<cyphermox> I'm having some wifi issues so it will be hard to test for now
<didrocks> cyphermox: can wait for tomorrow :)
<didrocks> we are not in a day-range for indicator-session, but good to see progresses
<cyphermox> it would still be nice to close it up
<mterry> didrocks, I'm a touch confused.  What sort of error is keeping unity from migrating?  How does one get notified?  I can't make sense of this proposed-migration report
<didrocks> mterry: ahah, same for me, seb128 helped me :)
<didrocks> mterry: so the story is that we have libbamf3-0 -> libbamf3-1
<didrocks> I promoted it to main on Friday
<didrocks> but then libbamf3-0 is NBS
<mterry> sure
<didrocks> and the migration don't accept creating new NBS
<mterry> woah
<didrocks> so remaining rdepends on libbamf3-0 are shown in this line:
<seb128> transitions need to be complete ... that sucks a bit
<mterry> We have to solve all NBS issues for a library before it gets upgraded?
<didrocks> * i386: ginn, gnome-pie
<mterry> that's intense
<didrocks> mterry: yep
<didrocks> so, meaning that the debian way of having soname in bin package is useless now
<didrocks> we are like fedora, everything on the same version of a library
<seb128> yes, I tried to argue with cjwatson about that, but they fell like that's a good "feature", reduce the archive churns and the +1 team work
<mterry> didrocks, that section of the report does not look like it has much to do with the bamf transition
<seb128> mterry, how so?
<seb128> mterry, it's listed in the "Trying easy from autohinter: nux/4.0.0daily13.01.11-0ubuntu1 unity/6.12.0daily13.01.11.2-0ubuntu1 bamf/0.4.0daily13.01.11-0ubuntu1 " section
<mterry> seb128, yeah, but no indication that it's because of an NBS from libbamf3-0 to -1
<mterry> seb128, just lists two package names
<jibel> didrocks, hey, auto upload of unity broke this morning because utah failed to provision the systems to run autopilot
<seb128> right, that report is hard to read
<didrocks> jibel: yeah, I saw that you made some retrial, thanks!
<jibel> didrocks, I restarted the test late afternoon
<didrocks> jibel: I've mentionned it to gema
<seb128> mterry, not sure I follow you, do you just point that the report is hard to read, or are you unsure we need to rebuild those?
<didrocks> jibel: it's now copied over the archive
<mterry> seb128: just that the report is hard to read
<jibel> didrocks, ok, cool.
<seb128> mterry, yeah, I agree with that :-(
<didrocks> mterry: yeah, that's why we need to know the context of the change upstream :(
<mterry> didrocks, regardless, sure, I can do rebuilds for those two
<didrocks> mterry: perfect :) don't forget the approved MP on ginn so that it doesn't show tomorrow that the version is higher in the distro :)
<mterry> didrocks...  where is this approved MP?  I can't see anything in https://code.launchpad.net/ubuntu/+source/ginn/+branches
<mterry> Is there some branch upstream that I need?
<didrocks> mterry: oh, I meant, you need to propose one
<didrocks> after the rebuild upload :)
 * mterry is having a fuzzy-brain day
<didrocks> against lp:ginn
<didrocks> mterry: rather me having fuzzy-explanation, sorry :)
<didrocks> but you know, it's late in europe, hem hem :p
<mterry> didrocks, ah-oh.  this is an ubuntu-is-upstream package
<mterry> didrocks, hm.  ginn isn't an inline package.  Do you know what team owns this?
<didrocks> oh, are you sure it's not part of the touch stack?
 * didrocks checks
<didrocks> mterry: oh sorry, brainfuck, it's not in the touch stack anymore
<didrocks> so yeah, just a straight ubuntu-rebuild :)
<mterry> didrocks, is it orphaned upstream then?
<didrocks> mterry: right
<didrocks> we used to be upstream for it
<didrocks> but not touching it anymore
<mterry> didrocks, should we remove it from the archive?
<didrocks> mterry: TBH, I would be in favor, but maybe check with bregma
<didrocks> not sure if it's even working anymore
<mterry> bregma, ^ is ginn a useful thing to have in the archive anymore?  We apparently don't work on it anymore?
<bregma> it is sotr of moribund
<bregma> it needs some lovin' but it's just a touch client, not part of the stack
<mterry> bregma, do you recommend we keep it in the archive?
<bregma> I'd rather keep it in the archive, it should be in universe though
<mterry> bregma, it is
<mterry> didrocks, how does one notice that there is a proposed-migration issue?  Just check daily to see if it migrated yet?
<bregma> OK, then ginn should just limp along until I or someone else gets an itch to improve it
<didrocks> mterry: yeah, I looked at the unity package and saw that it was in proposed
<bregma> it's not broken, it's just hasn't realized its full value at the moment
<didrocks> mterry: not the release pocket
<mterry> bregma, OK
<mterry> didrocks, :-/  OK.  Maybe I'll spend a couple minutes trying to get a script to poll a set of packages for pocket status
<didrocks> mterry: yeah, that can be handy
<didrocks> mterry: thanks :)
<mterry> didrocks, http://paste.ubuntu.com/1532756/
<mterry> didrocks, that has a script for telling if something is stuck in proposed
<mterry> pass it source or binary package names and it will let you know
<didrocks> mterry: This looks good. I'm wondering at some point if we don't need in fact some kind of dashboard for monitoring stacks and this kind of things, wdyt?
<mterry> didrocks, probably yeah
<didrocks> mterry: I'll add a note I guess :)
<mterry> didrocks, all sorts of things can go wrong, and it'd be nice to have one place to see them all
<didrocks> agreed
#ubuntu-unity 2013-01-15
<xnox> would developers who do indicators can merge lp:~psusi/ubuntu/raring/indicator-power/show-ups into lp:indicator-power at all? (for auto landing)
<larsu> xnox, charles applied it upstream here: https://code.launchpad.net/~charlesk/indicator-power/lp-1007095/+merge/143138
<larsu> xnox, I just approved it, it'll land soon
<agsel> hi. how do I reset my unity conf?
<xnox> awesome
<larsu> conscioususer, hey, I heard you might know the bug number for which bug #1078694 is a duplicate (about disabling the global menu when a modal dialog pops up)
<ubot5> bug 1078694 in appmenu-gtk (Ubuntu) "Modal dialog broken on Unity" [Undecided,Confirmed] https://launchpad.net/bugs/1078694
<conscioususer> larsu: I originally filed this one: https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/775969 but then was informed that modal dialogs shouldn't inherit parent menus AT ALL, so it was made a duplicate of this one: https://bugs.launchpad.net/indicator-appmenu/+bug/674605
<ubot5> Launchpad bug 674605 in Application Menu Indicator "duplicate for #775969 Transient window wrongly shows menus for its parent" [Medium,Confirmed]
<ubot5> Launchpad bug 674605 in Application Menu Indicator "Transient window wrongly shows menus for its parent" [Medium,Confirmed]
<larsu> conscioususer, that's the one. Thank you!
<conscioususer> larsu: no prob
<didrocks> hey sil2100, how are you?
<davidcalle> Hey didrocks, how is the jetlag?
<didrocks> davidcalle: well, as supposed to be :) waken up 3 hours ago, and it's 6:15 now :)
<davidcalle> didrocks, nice :)
<sil2100> didrocks: hello!
<sil2100> didrocks: wow, you're up early ;)
<didrocks> sil2100: how things are going? :)
<didrocks> sil2100: well, it's half past 6 now, but has been waken up at 3:30 :/
<didrocks> so yeah, not quite funny, will be tired later on I guess
<didrocks> how are things going?
<didrocks> sil2100: FYI, run 67 of the indicator unity autopilot tests failed on intel (and only on intel), flacky tests?
<didrocks> run 68 running right now
<sil2100> didrocks: let me check that
<didrocks> thanks :)
<didrocks> run 68 worked on intel now
<sil2100> Have some VPN problems
<sil2100> didrocks: I have to jump out to the store for lunch provisions, but once I'm back I'll try doing what I can ;)
<didrocks> sil2100: sure :)
<fginther> didrocks, good morning!
<didrocks> hey fginther :)
<fginther> didrocks, I have some code ready to test the changelog only merges. Can you please ping me next time you have some branches ready to merge?
<didrocks> fginther: sure, should be in the next couple of hours
<didrocks> fginther: will ping you back!
<fginther> didrocks, excellent! just send me one or two of the project names before you push the branch. I'll need to modify the jenkins job before the approved branch exists.
<didrocks> sure
<didrocks> mmrazik: hey, around?
<didrocks> mmrazik: can you have a look at this log: /job/ps-indicators-autopilot-release-testing/label=autopilot-nvidia/69/, it seems that tests stopped to run (may be gtk-recordmydesktop crashed?)
<didrocks> mmrazik: there are utah-jenkins/test_unity/autopilot/collect_crash_data.sh for the crash attached to it, do you mind having a look?
<mmrazik> didrocks: looks like an Xorg crash
<didrocks> mmrazik: shouldn't it just abort this tests?
<mmrazik> didrocks: https://pastebin.canonical.com/82037/
<didrocks> mmrazik: and not the whole test suite?
<didrocks> being back in 30 minutes
<didrocks> but the tests should finish I guess
<sil2100> Strange thing, apview stopped working for me
<sil2100> ;(
<sil2100> Oh, ok, it works now
<sil2100> mmrazik: regarding the ps-indicators-autopilot-release-testing job, it seems that the 70th build test has one failure, but the desktop recording is not there
<sil2100> didrocks: looking at the faiulre, but hm, it seems to be a single strange failure - it seems more like a regression than an autopilot problem
<sil2100> At least from the movie
<didrocks> sil2100: the next run didn't trigger it
<didrocks> but yet another one showed a failure
<didrocks> see run 69 and 70
<didrocks> on intel
<sil2100> Strangeness, maybe I'll find something that might be causing it
<sil2100> Maybe I'll rewrite the test a bit
<sil2100> didrocks: on another note - if I have some SRU packages to release to quantal this week, should I ping you about them? Or pester someone else ;p ?
<didrocks> sil2100: yeah, I'm afraid that's something which will be needed
<trijntje> Hi all, is https://wiki.ubuntu.com/Unity/Lenses still up to date? I noticed the code on there is C, while the wikipedia-lens tutorial uses Python
#ubuntu-unity 2013-01-16
<Nico__> hola
<trijntje> Hi all, is https://wiki.ubuntu.com/Unity/Lenses still up to date? I noticed the code on there is C, while the wikipedia-lens tutorial uses Python
<sil2100> hm
<sil2100> larsu: indicator-appmenu is failing to build in staging for quantal it seems
<sil2100> Trevinho: ping
<Trevinho> sil2100: pong
<sil2100> Trevinho: it seems that (probably) after commit 227 to lp:indicator-appmenu, indicator-appmenu stopped building for staging - do you know what could be the reason?
<Trevinho> sil2100: looking
<sil2100> It can't seem to find references to g_object_unref and etc.
<sil2100> https://launchpadlibrarian.net/126400947/buildlog_ubuntu-quantal-amd64.indicator-appmenu_12.10.4daily12.12.14-0ubuntu1%2Bbzr226pkg0quantal2_FAILEDTOBUILD.txt.gz
<larsu> sil2100, PKG_CHECK_MODULES for HUD is missing gobject-2.0
<larsu> which is weird, I would have thought gio pulls that as a dependency
<larsu> or dbusmenu ..
<sil2100> Didn't know you had to explicitly ask for gobject-2.0, since I saw gio-2.0 deps in the configure's
<larsu> yeah I don't think its necessary, let me dig deeper :)
<larsu> no its not necessary, `pkg-config --libs gio-2.0` gives -lgobject
<larsu> (among others)
<larsu> sil2100, is there a way to rerun this with `make V=1`? I can't reproduce it locally
<sil2100> larsu: I was able to reproduce it on my quantal system, when I did apt-get source from staging and tried building it with bzr bd
<larsu> oh, thanks
 * larsu only tried building upstream
<sil2100> Maybe it's a packaging problem, but I didn't see anything strange
<larsu> sil2100, I still can't reproduce it :-(
<sil2100> larsu: are you using quantal?
<larsu> no, raring
<larsu> which might be the issue?
<sil2100> I think so, hm, since latest indicator-appmenu seems to build correctly on raring
<sil2100> `pkg-config --libs gio-2.0` on quantal gives -lgio-2.0 -lgobject-2.0 -lglib-2.0
<sil2100> So hm, not sure what might be wrong?
<larsu> sil2100, can you compile it with `make V=1` (or configure with --disable-silent-rules)
<larsu> so that we can see whether the right libs get passed
<sil2100> gcc -I/usr/include/libdbusmenu-glib-0.4 -I/usr/include/libbamf3 -I/usr/lib/x86_64-linux-gnu/libbamf3/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wall -Werror -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,defs -Wl,--as-needed -o hud-verify-app-info hud_verify_app_info-create-db.o hud_verify_app_info-load-app-info.o 
<sil2100> Ok, here it doesn't seem to add -lgobject-2.0, so maybe I'll have to add it to the dependencies indeed
<larsu> hm, all libraries are missing from that line
<larsu> except glib
<larsu> oh, no, that's include as well
<sil2100> Ah, wait, I think I see the problem
<larsu> sil2100, wait! this build is 12.12.14, which is *before* the 227 commit
<sil2100> (not sure why it works for raring)
<sil2100> larsu: it's hm, based on revision 226 - strange thing!
<sil2100> You're right
<sil2100> So it doesn't have Trevinho's latest commit that adds the deps
<larsu> yep, gio isn't in there yet
<larsu> dbusmenu should pull it I think, but it doesn't: `pkg-config --libs dbusmenu-glib-0.4` --> -ldbusmenu-glib
<lborda> Hi Guys, does anybody have a clue about this issue on precise? This happens on precise https://bugs.launchpad.net/ubuntu-advantage/+bug/1090919
<ubot5> Error: launchpad bug 1090919 not found
<lborda> sorry that's the right one: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1096954
<ubot5> Launchpad bug 1096954 in unity (Ubuntu Precise) " Enabling Xinerama causes Unity Panel/Dash to become all black" [Medium,Confirmed]
<didrocks> hey sil2100, how are you?
<didrocks> sil2100: didn't check the merge request, going to have a breakfast right now, but can you please refresh me by email on the flackyness of the indicator test?
<didrocks> sil2100: hey, I'm back :)
<cwayne1> davidcalle: ping
<davidcalle> cwayne, pong
<davidcalle> cwayne1, pong
<cwayne1> davidcalle: hey!  just wondering if theres anything i can do to help on ubuntu-scopes
<fginther> mhr3, ping
<mterry> Two hud autopkg tests are failing
<mterry> https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/76/
<sil2100> Yes, the one failed once before in the past
<sil2100> The first one I mean
<sil2100> The second, well...
<mhr3> fginther, pong
<sil2100> Trying to find what happened that suddenly those autopilot tests stopped being reliable
<fginther> dee-ci job is fixed
<fginther> mhr3, ^^
<thomi> sil2100: one of those tests (this one: https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/76/label=autopilot-ati/testReport/junit/unity.tests.test_hud/HudBehaviorTests/test_app_activate_on_enter/) is poorly written
<mhr3> fginther, great, thx
<thomi> sil2100: it uses assertFalse, where it should use Eventually
<thomi> (and assertThat)
<thomi> (or assertProperty)
<sil2100> thomi: right, that's true - but test_super_h for instance looks fine, but still it seems to not change the keybinding correctly
<sil2100> Not much debugging for that though
<thomi> sil2100: yeah, I don't know why that one's not passing...
<sil2100> thomi: and for instance, in failure 75, test_hud_to_dash_has_key_focus fails even though the vid shows that everything is ok
<thomi> sil2100: possibly you can increase the verbosity of unity for that test - that way you'll get some more information
<didrocks> sil2100: you should go to bed :)
<didrocks> sil2100: did you see that this test is not the only one failing?
<sil2100> It fails on hiding the dash during cleanup!
<didrocks> sil2100: if you switch back to some runs, some other tests are failing
<sil2100> didrocks: yes, that's what I just told thomi - since those are really mostly different tests failing, which means that something is unreliable
<didrocks> you're right
<sil2100> thomi: maybe in the set_compiz_option the time.sleep(0.5) is not enough?
<sil2100> thomi: not much we can do here, we could increase the wait here, but this would impact the speed and not give any guarantee, and still we won't have 100% certainity that it would help anyway
<didrocks> sil2100: oh btw, if you need to launch the autopilot tests, just do it
<didrocks> sil2100: don't wait for me on that, the machine are yours :)
<sil2100> didrocks: you mean, on jenkins? ;)
<didrocks> yep :)
<didrocks> you can do it, right?
<sil2100> didrocks: not sure, never tried before! ;p Is it done through jenkins?
<didrocks> sil2100: yep, just this test
<didrocks> sil2100: empty the package list if you want to test with the whole ppa content
<didrocks> sil2100: meaning, unity
<sil2100> didrocks: ok, I'll be firing tests there then
<didrocks> sil2100: excellent!
<sil2100> See you tomorrow!
#ubuntu-unity 2013-01-17
<smspillaz> duflu: I think you have a really old version of xorg-gtest installed. See the bug report
<duflu> smspillaz: It's raring's
<duflu> How much newer can I get?
<smspillaz> duflu: git
<duflu> Not realistic
<smspillaz> yes, realistic
<duflu> I just won't flag it when building
<duflu> But how did it work before ?
<duflu> Did you only ever use git?
<smspillaz> I probably updated the client code for the git version when it stopped working some time ago :)
<smspillaz> yeah, it wasn't even packaged until very recently
<smspillaz> gotta run
<duflu> smspillaz: Ok well I don't need to block it if it's not built, and unbuildable for most
<smspillaz> its a good thing to keep around in any case
<smspillaz> dunno what the opposition is to just building it -.-
<smspillaz> duflu: the reason why I use the git version is because most of the older versions have a bug that causes tests to fail randomly
<smspillaz> because there was a race condition between the client going away and the server process being terminated or something
<smspillaz> anyways, gotta run have a class
<smspillaz> yeah, the version in raring is like 7 months old :P
<duflu> bschaefer: I will try to make a video of the bug. But rebuilding first
<duflu> Also, it seems I can only stay connected to freenode reliably when sleeping/resuming
<bschaefer> duflu, alright, im messing around with moving all the opacity changes into the animation class
<bschaefer> that sounds about right for me as well
<duflu> bschaefer: Not fading out properly might be solved by removing the curve
<duflu> (will)
<bschaefer> duflu, so the animation would have an inverse opactiy and normal opacity, so when they disable the window stretching atm the glow is still inverse the curve
<duflu> bschaefer: Yes, 1.0 - progress
<bschaefer> duflu, hmm well it gets down to about 0.028 before it stops drawing the window
<bschaefer> which is pretty low, but I can still notice a pop when the window goes away
<duflu> bschaefer: Hmm sounds like we're just missing the final step. So not really a bug that needs fixing in reality at normal speed
<bschaefer> duflu, well the step at the end (atm) is when the timer reaches 0.0f stop drawing the window
<bschaefer> which the curve is at about 0.028f, so it doesn't keep going down to zero
<duflu> bschaefer: Yeah ignore the fadeout cos it's invisible at normal speed. But the second texture indicates something worth fixing. Trying to build and video now
<bschaefer> duflu, it actually looks pretty cool if you keep drawing the window like that
<bschaefer> duflu, that would be awesome, as I only see 1 texture, unless I hit another edge but that should happen
<bschaefer> as the fade out is still going on, on the first animation
<bschaefer> duflu, o and removing the alpha * color[0..2] and the box turns into an ugly box
<bschaefer> http://i.imgur.com/70keg.jpg
<duflu> bschaefer: Yeah the calculation is wrong but would change the appearance now :P
<bschaefer> haha yeah, I can go in and fix it later, as it would nice to remove some of the magic number in there atm
<duflu> bschaefer: Nah, you'd have to choose the default colour as the dark inside and brighten for the border. Requires config changes so we can't do it
<bschaefer> oo
<bschaefer> i see, well I want to remove the 65535.0f and use OPAQUE
<duflu> bschaefer: What we have is configuration of the border colour and darken for the inside
<duflu> Oh
<bschaefer> well the OPAQUE is a double but ... if it needs to be casted to a float so be it, we shouldn't use the hard coded number
<duflu> bschaefer: Or better yet calculate alpha once and reuse
<bschaefer> duflu, o yes, that would be better
<duflu> bschaefer: But don't now. we want a small diff
<bschaefer> duflu, also something is add with if (!animating)
<bschaefer> that statement is never true
<bschaefer> duflu, yeah, ill save it for later
<bschaefer> on line ~523
<bschaefer> the only time it ever gets set to false is after the glPaintOutputSetEnabled gets set to false...so it will never be false while it is drawing
<duflu> bschaefer: Can't reproduce dual textures after rebuilding/restarting
<bschaefer> yay
<bschaefer> hopefully
<bschaefer> duflu, i even turned my nivida card on to test :)
<duflu> At least it will keep you warm
<bschaefer> haha yeah, its been a bit cold around here lately
<bschaefer> duflu, hows SF weather?
<duflu> bschaefer: No idea. Doesn't change inside
<bschaefer> well thats nice
<bobweaver> hello to all hope all are good !  Is there anyone here that use to work on Unity 2d that would like to talk to me about easing.type:  and why canonical or Ubuntu made the choice to use a certain easingtype. I am making a phone app and starting to tie in animations and easing so I want it to be like Ubuntu but I would also like to know the reasons behind why they where using things like Easing.OutQuint or Quad thanks
<rye> mandel: that will do too
<mandel> :)
<rye> Hi all, unity-team/staging ppa has all packages built but compiz does not seem to be loading unityshell for me - the only thing it prints is compiz (core) - Info: Unity is fully supported by your hardware. - twice and then nothing. ccsm does not list unityshell either, am I missing something big?
<sil2100> Hello
<rye> unity, unity-common are installed (and I am on Raring)
<sil2100> rye: ok, do you have the latest unity and compiz installed from staging?
<sil2100> Since there might have been an inside ABI break between unity and compiz, so you need to have both as the newest versions
<rye> sil2100: yes, yes and yes - everything is fresh from staging ppa
<rye> the second yes is for unity-common
<rye> http://paste.ubuntu.com/1541527/
<rye> sil2100: ^ for package versions
<rye> LOL
<rye> compiz (core) - Info: Unity is fully supported by your hardware.
<rye> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<rye> mandel: is this what you are getting ^'
<mandel> rye, yep
 * rye tries to relogin after resetting /org/compiz
<rye> ok, now i have these two lines in a different order
<sil2100> heh
<rye> sil2100: I know these packages haven't passed acceptance tests, should I file a bug?
<sil2100> rye: you can, but I'll try looking into this in a moment - looks like another ABI break again
<sil2100> rye: can you pastebin me your whole .xsession-errors ?
<rye> sil2100:  http://paste.ubuntu.com/1541543/
<sil2100> huh
<sil2100> rye: is this the whole file?
<sil2100> Since from the looks of it, it doesn't even *attempt* to load unityshell
<rye> sil2100: yup
<sil2100> So it looks as if it's not in compizconfig loading configuration
<mandel> sil2100, I can confirm i have the same issue as rye
<sil2100> Could you open up ccsm and check if it's enabled?
<sil2100> Unity, that is
<rye> sil2100: it is not there, there is no Unity module in ccsm
<rye> ah
<sil2100> Could you check `echo $COMPIZ_CONFIG_PROFILE` ?
<rye> sil2100: wait, something is wrong locally
<sil2100> It's strange that it's not there, this would mean unity is not installed - could you check dpkg -L unity to see if it installed unityshell.so into /usr/lib/compiz ?
<rye> sil2100: ok, I can't understand why, but all the plugins were disabled
<sil2100> rye: check what $COMPIZ_CONFIG_PROFILE you have on your system
<sil2100> It should be 'ubuntu'
<rye> sil2100: it is ubuntu, I re-enabled unity (by going to the config panel, there is no checkbox outside and i got unity shell
<sil2100> rye: ok, so hm, so it's a configuration corruption
<sil2100> mandel: is it the same for you?
<sil2100> I wonder if the packages do the corruption, or something else is modifying/overriding/messing with compiz config
<mandel> sil2100, yes, exact same problem
<mandel> sil2100, AFAIK we both had it working and then after the update boom!
<rye> sil2100: I guess this was caused by unity not being present at some time after compiz was already present in the PPA. I wonder whether this could have disabled unityshell plugin. Then unity got rebuilt but we still kept running w/o unityshell enabled
<rye> mandel: just re-logged into unity and it works
<rye> sil2100: ok, so sorry about the hassle, compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow). is still being printed but it does not seem to affect anythin
<rye> g
<sil2100> Yes, I noticed it being a bit misinforming - the 'Unity is not supported' thing
<mterry> Hello all!  I notice that unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down is failing
<mterry> https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/77/label=autopilot-intel/testReport/junit/unity.tests.test_hud/HudBehaviorTests/test_closes_then_focuses_window_on_mouse_down/
<sil2100> mterry: yes, I saw that - but the test seems fine, it looks more like a bug in unity
<sil2100> mterry: since from the movie I clearly saw that autopilot is clicking on the fullscreen charmap, but calculator gets the focus (huh?)
<sil2100> mterry: although I can't reproduce it here on my system
<mterry> sil2100, maybe a timing thing, where the autopkgtest goes faster than a human?
<sil2100> mterry: maybe, I noticed that strangely the mouse moves faster on that movie than on my system when using autopilot, hmm
<sil2100> mterry: new indicator autopilot build - 2 failures, again new ones
 * sil2100 sighs
<sil2100> Again random failures
<didrocks> hey hey
<didrocks> sil2100: trying to catch up before your EOD, how is it going? :)
<sil2100> didrocks: heya!
<didrocks> how is the weather in Europe? SFO is quite cold surprinsingly :)
<sil2100> didrocks: we retried the indicators and again completely different failures, 2 this time - still trying to find out what the heck is going on
<sil2100> Since sometimes the failures look more like regressions than AP problems
<sil2100> For instance, with the 78'th build, undo failed again
<sil2100> (only on ati)
<didrocks> sil2100: are there anything new in Unity?
<didrocks> sil2100: because there are two kinds of runs
<didrocks> sil2100: one, having unity-stack raring (not the ppa)
<didrocks> sil2100: and we can retry "with the whole ppa"
<didrocks> so unity ppa + indicators ppa
<didrocks> instead of just indicators ppa
<didrocks> sil2100: do you think mterry can be of help (hey mterry!)
 * mterry reads
<didrocks> mterry: to sum up, we have intermittant failure on autopilot for the indicator integration tests
<didrocks> mterry: this is blocking daily release since Monday
<mterry> Yeah, sil2100 mentioned he was looking at them
<didrocks> yeah, but as we didn't get any progress since Monday
<mterry> But looks like we can't reproduce
<didrocks> I think we can help him
 * mterry puts on his reproducing gloves
<didrocks> mterry: sil2100: I'll be online back in 40 minutes
<sil2100> Ok!
<didrocks> mterry: sil2100: I can help you on the jenkins side, running the tests you want
<didrocks> mterry: sil2100: do you want that I retrigger the tests with the whole ppa content?
<didrocks> so indicator stack + unity stack?
<sil2100> didrocks: please do, it's always good to have the latest one even now
<didrocks> ok
<didrocks> sil2100: mterry: run 79 on ps-indicators-autopilot-release-testing
<didrocks> ok, back in 40 minutes ;)
<sil2100> The other failure, well, this one looks more like a failure, trying to help with that one too
<sil2100> didrocks: thanks!
<didrocks> sil2100: I'm sure mterry always can retrigger issues
<didrocks> seems he has some good karma!
<didrocks> thanks sil2100, mterry ;)
<sil2100> hehe
<sil2100> mterry: what worries me the most is ;p Why are only HUD tests failing?
<sil2100> hm, I see something strange
<mterry> sil2100, I can get the gedit test to fail
<mterry> sil2100, but the dash emblem one passes locally
<mterry> Though...  the gedit test fails differently
<sil2100> mterry: oh! How?
<mterry> sil2100, the gedit window isn't focused at the end
<mterry> sil2100, dash doesn't give it back focus
<sil2100> Ah, hm, I remember a failure like that in the past
<mterry> (no window has visible focus)
<sil2100> But still good to know you can make it fail! Not sure how you're doing this magic ;)
<mterry> :)
<mterry> sil2100, the one failing test in 77 (different from 2 failing tests in 78) has my error
<mterry> let me see if I can repro that too
<mterry> No, that passes for me
<mterry> Sigh
<mterry> But at least it's similar error around hud behavior
<sil2100> This is strange indeed, looks like some strange race condition with focus
<sil2100> Since many random failures are caused by wrong application focus
<sil2100> Let me check if there's anything suspicious
<mterry> sil2100, these feel like more uninitialized variables (hard to reproduce)
<sil2100> Indeed, that's what I'm looking for now again ;)
<didrocks> sil2100: mterry: so, again a random failure on one arch
<sil2100> didrocks: mterry was able to more-or-less reproduce one issue - as mterry mentioned, 'somehow' it might be an uninitialized variable related to focusing applications again
<mterry> didrocks, not completely random.  That's the same single failure from 77
<mterry> sil2100, doesn't gcc spit out warnings about uninitalized vars like that?
<didrocks> sorry, connexion is quite flacky here
<didrocks> sil2100: mterry: any help needed?
<mterry> As far as I can tell, we have a set of focus-related hard-to-reproduce failures.  sil2100 is investigating for possible uninitialized variables
<didrocks> ok, keep me posted, daily release doesn't happen since Monday because of that one, not sure if we should just raise the trigger to 1 temporarly
<bschaefer> sil2100, mterry hello, there is another focus issue? Is it with unity?
<mterry> bschaefer, seems like it.  See https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/78/ for example
<mterry> bschaefer, I can reproduce the gedit test failure locally, but not the other
<bschaefer> mterry, and gcc will try to spit out warnings about uninitialized vars, but being able to detect 100% accuracy you would need a solution to the halting problem
<bschaefer> mterry, hmm the hud one
 * bschaefer start up the vpn
 * mterry files bug for PS to solve halting problem
<bschaefer> haha
<mterry> :)
<didrocks> mterry: assign it to bschaefer, with priority critical :p
<didrocks> (and next close milestone ;))
<bschaefer> mterry, sil2100 oo hmm, I think I was able to reproduce losing focus from the hud at one point
<bschaefer> didrocks, haha, if only, I've tried before
<didrocks> ;)
 * bschaefer was a naive CS student 
<bschaefer> mterry, sil2100 so i've noticed with the hud, it loses focus when you have to windows on workspace 1, and start in workspace 0 (which has a window)
<bschaefer> then move to workspace 1
<bschaefer> and open the hud
<bschaefer> open/close
<bschaefer> sorry, I missed an alt+tab after the switching of workspaces
<mterry> bschaefer, when I reproduce locally, I only have one workspace.  so maybe those are two separate bugs
<bschaefer> mterry, could possibly be a different issue
<bschaefer> mterry, how are you reproducing it locally?
<mterry> bschaefer, with autopilot running in a shell
<bschaefer> o nice
 * bschaefer goes to run the test
<bschaefer> mterry, actually if you have 1 workspace...there was this old bug
<bschaefer> mterry, where the gtk-window decor was being counted as window
<bschaefer> Hmm never mind, I just reproduced it on more then one workspace
<sil2100> didrocks: bschaefer and me (with a less specialised eye) are trying to find the root cause of the problem, since it seems compiz is the problem here, as Brandon noticed it seems not to focus sometimes when asked to
<didrocks> sil2100: great to see it can trigger real issues \o/
<bschaefer> yeaah, it seems when you mix workspace switching/alt+tab/hud I can get it to not focus often, but still figuring out if its a different problem or the same :)
<didrocks> good luck bschaefer ;)
<bschaefer> didrocks, thanks!
<sil2100> huh, I think I reproduced the issue you mentioned bschaefer
<sil2100> Strange things are happening in compiz/unity ;p
<bschaefer> sil2100, yeeah
<bschaefer> sil2100, im hoping its the same problem :)
<sil2100> bschaefer: when I look at it, hm, if it can be *somehow* triggered without switching workspaces, it might be actually the problem that for instance made the test_closes_then_focuses_window_on_mouse_down test to fail
 * didrocks crosses fingers
<bschaefer> sil2100, well I was kind of wonder if we could link the test that happened before and after each test
<sil2100> Still, the undo failure is different ;p Damn you undo!
<bschaefer> that way we can see what test was ran before which could have possibly done something to the state of the system
<sil2100> I wonder how are the tests ran in jenkins exactly
<bschaefer> as maybe a test before we doing heavy alt+tabing + workspace switching which caused a problem with the undo test
<bschaefer> sooo it can still possibly be the same problem
<bschaefer> sil2100, im not 100%, I know there is no order...
<bschaefer> it would be nice if each test had an ID that was based on the order it went
<sil2100> To me it looks as if each test is ran on a clean session, at least that was my understanding in the past
<didrocks> sil2100: apparently, it's not totally true
<didrocks> sil2100: check with mmrazik, but the tests are ran by batch
<sil2100> didrocks: ok, that makes more sense now then
<bschaefer> sil2100, each arch is run on a clean session
<bschaefer> so intel, amd, etc
<bschaefer> opps
<bschaefer> ati, nividia
<bschaefer> yay http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/80/
<bschaefer> haha
<sil2100> Ok, but we still need to fix that ;p
<bschaefer> yes we do :p
<didrocks> yeah, I just published with that
<didrocks> ironically, I put the trigger to 2% of failure
<sil2100> didrocks: look look! It's all ok ;p
<didrocks> and for the first time, after 15 runsâ¦ all pass
<didrocks> sil2100: no no no no no ;)
<sil2100> didrocks: we fixed it by not fixing anything! :D
<sil2100> :(
<sil2100> ;p
<didrocks> sil2100: well, thanks my retrial :p
<didrocks> but yeah, those kinds of $random is ackward
<sil2100> I know, that's why it's still bothersome
<sil2100> Maybe in the meantime bschaefer tries to find the focus issue, he has more experience so he'll be able to find it faster - I'll concentrate on the sometimes-failing gedit undo, which might be an HUD issue
<bschaefer> sounds good
<bschaefer> sil2100, one thing you should check (if you can reproduce that hud/gedit problem) is to figure out what window has focus
<bschaefer> when the panel is empty, as I just checked with the focus problem im looking into, and it is actually focusing the window behind the one it should...
<bschaefer> ie. a window does have focus
<sil2100> bschaefer: but with the gedit problem, hm, actually gedit has the focus, so I think that it *might* be unrelated
<sil2100> But of course, it might not have focus when doing the HUD command
<bschaefer> sil2100, o gedit still has focus after hitting undo?
<bschaefer> and the panel has an empty title?
<bschaefer> i've also noticed that it sometimes focuses a window on a different workspace...
<sil2100> bschaefer: yes, but the panel has the title 'Text Editor' and the gedit command flies into nothingness
<bschaefer> sil2100, o I though the last time I saw the video, after the undo command was enter the panel title became empty
 * bschaefer watches the new one
<sil2100> So the right window seems focused, just the command ignored
<sil2100> bschaefer: the new one has focus after the hud is dissolved
<sil2100> bschaefer: since in the past I think the reason was the switcher stealing focus ;p
<sil2100> Check build 78
<bschaefer> sil2100, oo, that is why I was thinking it was the same problem haha
<bschaefer> yeah I believe that was a bug I did :)
<bschaefer> or introduced
<bschaefer> sil2100, hmm im getting a 404 error on the video :(
<sil2100> bschaefer: you using apview?
<bschaefer> yup
<sil2100> bschaefer: there is a thing that changed... use my version of apview
<sil2100> https://code.launchpad.net/~sil2100/+junk/apview
<bschaefer> oo cool
 * bschaefer is using thomis' old one
<sil2100> Since I had the same thing, and I fixed it temporarily today
<bschaefer> cool, yeah it also said the video was unsupported, so I went to the direct link
<bschaefer> and the link was a 404 not found error
<bschaefer> o wow, thats a different failure...odd!
<bschaefer> also that is a lot better video support
<bschaefer> sil2100, haha...im thinking the focus bug im running into is a unity bug
<bschaefer> compiz does focus the correct window its told
<bschaefer> the problem is the switcher saves the current focused window before going into the switcher and if you don't cancel the switcher it will focus a new window
<bschaefer> but the problem is the _last_focus_window is set to the incorrect window...
<bschaefer> so when you open then close the hud, it thinks the _last_focused_window is the window you used before the alt+tab
<bschaefer> yay, that seems to be the problem...now for a correct fix....
<sil2100> huh
<sil2100> That's unexpected!
<sil2100> But hm, so maybe indeed it's caused by previous switcher usage?
<bschaefer> yeeah, I think it could actually be because the Hud isn't saving the current focused window before it becomes the active window
<bschaefer> (possibly)
<bschaefer> possibly!
<bschaefer> so it could be a UBUS race condition, but when I saved the input of the window after switcher didn't restore the window everything worked correctly
<bschaefer> sooo ill check to see if its a race condition
<didrocks> fginther: btw, you probably saw all the latestsnapshot MP, some are failing due to g_type_init
<didrocks> fginther: if you want to test the "rapid merge" of those, please doâ¦
<fginther> didrocks, thanks, I will
<bschaefer> sil2100, yup, the Hud does not save input before going into the hud, but it attempts to restore the last focused window (oddly...))
<bschaefer> so no race condition...
<bschaefer_> sil2100, soo the fix is just to have the Hud save input focus before it opens the hud :)
<bschaefer_> (which I thought it was...)
<sil2100> \o/
<bschaefer> sil2100, was this causing AP test failures?
<bschaefer> or do I need to write one haha
<bschaefer> though the test should just be...open 2 programs, alt tab, open hud, assert w2 has focus
<sil2100> heh ;) It was *probably* causing some failures, but it would be nice to have an explicit test written
<sil2100> Is there a bug for this? Or should I fill one?
<sil2100> Thanks for finding the cause!
<bschaefer> sil2100, no problem :), if you feel like filing one
<bschaefer> sil2100, I can also make a bug
<sil2100> bschaefer: I don't think we had an explicit test like this, no - I'll fill  the bug then in the meantime!
<bschaefer> sil2100, alright, ill go prepare the branch!
<bschaefer> and make the test, thanks!
<sil2100> That's the least I can do to help ;)
<bschaefer> haha, well we still need to fix that hud gedit problem as well :)
<sil2100> bschaefer: this fix might be even good for backporting to quantal and precise! Since probably those stacks also suffer from the same problem ;)
<sil2100> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1100962
<ubot5> Launchpad bug 1100962 in Unity "HUD does not save the current input focus correctly" [Low,In progress]
<bschaefer> sil2100, awesome, yeah, its a one liner as well :)
<bschaefer> well that AP tests makes it a little longer
<sil2100> You can edit the title if you think it's not correct ;)
<bschaefer> nope sounds perfect
<bschaefer> sil2100, https://code.launchpad.net/~brandontschaefer/unity/lp.1100962-fix-hud-focus-problem/+merge/143780
<bschaefer> sil2100, also how would I also add 6.0 on that bug report? I seem to not have the correct permission to edit bugs...
<sil2100> bschaefer: ok, will add! And review the branch ;)
<bschaefer> sil2100, alright :), Ill make a 6.0 branch
<sil2100> bschaefer: strange, I thought you have all the power ;p
<bschaefer> sil2100, so did I! I guess im still not apart of the Ubuntu-BugSquad
<bschaefer> im just waiting to be approved...
<sil2100> bschaefer: hah! Excellent, I just was able to reproduce the problem with your autopilot test ;) (without unity with your fix of course) Awesome!
<bschaefer> sil2100, :)
<bschaefer> yeah I was surprised how easy it was to reproduce once you understood what was going on
<bschaefer> its a nice small AP test as well
<bschaefer> sil2100, https://code.launchpad.net/~brandontschaefer/unity/lp.1100962-fix-hud-focus-problem-6.0
<bschaefer> :)
<didrocks> sil2100: bschaefer: rocking!
<bschaefer> didrocks, :), though the gedit/undo problem still exist as far as I know
 * bschaefer can't reproduce that
<didrocks> yep, but sil2100 is on it, right?
<bschaefer> yup!
<bschaefer> sil2100, isn't it getting late for you?
<didrocks> I think it is late :)
<sil2100> zZzzZ ;)
 * bschaefer needs to eat some food
<didrocks> fginther: any luck on the latestsnapshot branches not merged into trunk?
<didrocks> bregma: bschaefer: I think you saw that the nux branch failed to biuld (the one fixing the g_type_init())
<didrocks> because of an unused variable
<didrocks> andyrock shouldn't be around, maybe it worth taking over the branch?
<andyrock> didrocks, failed to build?
<didrocks> andyrock: yep, https://code.launchpad.net/~andyrock/nux/deprecated-glib-fun/+merge/143755
<andyrock> didrocks, it works here
<didrocks> see the FAILURE in jenkins
<andyrock> http://paste.ubuntu.com/1542848/
<andyrock> let me see
<fginther> didrocks, no real progress, fighting with jenkins at the moment
<didrocks> fginther: ok, some branches are stuck, can you push them manually if no solution in the nex 30 minutes?
<didrocks> fginther: are stuck or seems to :)
<didrocks> fginther: because this will prevent next daily release, those components will be "stuck"
<andyrock> didrocks, oh "make" does not build tests?
<didrocks> (ignored/put on shelf)
<didrocks> andyrock: can it be a regression of the precompiled header?
<fginther> didrocks, yes, I will try plan B and give you an update
<didrocks> fginther: thanks!
<andyrock> didrocks, does nux use precompiled header?
<didrocks> andyrock: I'm unsure, I think not in fact
<didrocks> gtest-nuxcore-logger.cpp:336:14: warning: unused variable 'the_func' [-Wunused-variable]
<didrocks> andyrock: is that the case? I didn't look at the code
<andyrock> didrocks, copy-paste + typo issue :( #else is not #endif
<didrocks> andyrock: they should be equivalent! :-)
<bregma> andyrock, tests should only be built by 'make check'
<didrocks> andyrock: ok, at least easy fix, can you push and I'll approve :)
<didrocks> or bregma
<didrocks> even better ;)
<bregma> not me, I have to head out for a few hours
<didrocks> andyrock: btw, thanks for this fix!
<didrocks> ok, will do then
<didrocks> bschaefer: btw, I think the "make check" for building tests will interests you ^
<andyrock> didrocks, np :)
<andyrock> bregma, yeah nux just builds test on 'make check'
<andyrock> didrocks, pushed
<andyrock> but i get: "Fatal error: Features.h: No such file or directory
<andyrock> compilation terminated."
<andyrock> with or without my branch
<andyrock> so it should be fine
 * bschaefer as arrived back
<bschaefer> didrocks, I compiled that nux branch and it worked for me
<andyrock> bschaefer, yeah but nux does not build test with 'make'
<andyrock> unity does
<bschaefer> andyrock, opps, yeah I just compiled and ran it
<andyrock> bschaefer, me too ;)
<bschaefer> andyrock, :), do you have a fix for it?/
<andyrock> fixed
<bschaefer> awesome!
<andyrock> stupid typo :)
<bschaefer> haha, well I missed it as well
<bschaefer> it looked correct, if/else haha
<andyrock> yeah my fault :)
<bschaefer> haha, well yay for jenkins catching it
<didrocks> bschaefer: andyrock: nice work!
<bschaefer> didrocks, it was all andyrock :)
<fginther> didrocks, I manually merged nux, compiz merged on it's own and indicator-power is in the build queue
<didrocks> fginther: sweetness! Thanks :)
<fginther> yw
#ubuntu-unity 2013-01-18
 * hyperair wishes indicator-sound took control of the media keys.
<hyperair> that way media keys could work on youtube videos playing in the background.
<hyperair> or grooveshark for that matter.
<rperier> Hey, I would like to contribute to the development of unity. I have already discussed with didrocks , he shown me this link http://unity.ubuntu.com/getinvolved/development/unity (thanks to him) . I have also built unity from trunk, I did read a bit of documentation, etc...
<sil2100> rperier: hello!
<sil2100> rperier: tell me, what Ubuntu version are you currently using?
<rperier> I am running 13.04
<rperier> at home and 12.10 at work
<sil2100> rperier: ok, good, remember that all the unity work that is in lp:unity is related to 13.04
<rperier> sil2100: you mean that all the unity used in 13.04 is a daily built from lp:unity ?
<sil2100> rperier: yes
<rperier> ok it's noted
<sil2100> If you want to propose a fix for 12.10 or 12.04, you should consider backporting to lp:unity/6.0 and lp:unity/5.0 respectively - those are the quantal and precise source trunks
<rperier> sil2100: ok, there is junior bugs on LP for unity ?
<rperier> I code in C,C++ and python (it's is my job), I might be useful :)
<smspillaz> rperier: search for "bitesize" tagged ones
<smspillaz> they might be out of date though
<rperier> ok looking
<sil2100> rperier: if the bitesize bugs are out of date, you can always try looking for recent bugs that are low priority and trying to resolve them - that's the best way of familiarizing with the code
<rperier> sil2100: I will probably look for recent bugs with low priority. thanks
<rperier> unity should depend on bamf 0.4.0 right ? otherwise it causes FTBFS on quantal (at least the build system should ensure that bamf >= 0.4 is found), I am talking about bug 1086276
<ubot5> bug 1086276 in Unity "lp:unity FTBFS on quantal: error: âbamf_view_is_user_visibleâ was not declared in this scope " [High,New] https://launchpad.net/bugs/1086276
<rperier> this function was added to the trunk branch between the tag 0.3.2 and 0.4.0-daily-xxxxx
<sil2100> rperier: let me check
<rperier> sil2100: still checking ? :)
<sil2100> rperier: ah, sorry! ;) I got preempted to something else, I'll do it in a moment ;)
<rperier> sil2100: sure, np :)
<sil2100> eh eh, always something to do ;)
<sil2100> rperier: ok, so, maybe indeed we should bump the build-system to require bamf >= 0.4
<sil2100> rperier: but the packaging already has that dependency
<sil2100> So, if unity is being built as part of a package, we're sure that it will fetch bamf >= 0.4
<rperier> but if unity is built from another distro or from a user using quantal , it won't work :)
<sil2100> rperier: might be a good first patch ;)
<rperier> :)
<sil2100> lp:unity is to be supported for building on raring anyway - we like it to build on one older version too, but the rule is that we *should* only really care about quantal in the lp:unity/6.0 branch
<sil2100> But anyway, rperier prepare a branch, a merge request and let's get your first (?) patch rewieved and discussed ;)
<sil2100> Trevinho: could you re-merge https://code.launchpad.net/~3v1n0/unity/launchers-resize-new/+merge/135816 ?
<bregma> rperier, we'd welcome a patch to fix that
<sil2100> rperier: and it's a good way to familiarize directly with how to contribute to unity through launchpad
<rperier> I will write a patch this evening in the train ;)
<bregma> rperier, we'll look forward to your merge proposal
<sil2100> :)
<rperier> thanks
<sil2100> mterry: I fired up a new autopilot test of indicators and 2 failures again, some of those that we already know of
<sil2100> Trying to do something about them, adding more sanity checks - but still not sure what's going on
<mterry> sil2100, build 82?
<rperier> for the beginning, I will look at FTBFS and SEGFAULT I think, and then I will increase difficulty
<sil2100> mterry: yes
<sil2100> mterry: can you try your magic to get any of those reproduced ;) ?
<mterry> sil2100, :)
<sil2100> rperier: ok, slowly but surely - start off from some small things, get to know the process, then you can take on something more complicated
<mterry> sil2100, I feel like some idiot cousin.  "Go send Mike out there, he's sure to fuck something up"
<mterry> "Disaster follows him everywhere"
<sil2100> mterry: hehehe, nooo! It's not like that!
<mterry> :)
<mterry> sil2100, no, can't reproduce
 * sil2100 is shocked
<sil2100> :o
<sil2100> ;) Thanks!
<rperier> sil2100: this is exactly what I had in mind :)  (and this is the right way to start on a new project)
<rperier> ;)
<rperier> branch pushed on my LP account ;)
<rye> hi, is unity dash supposed to be full screen/regular size or it should be possible to maximize it / restore? A while ago it was maximized only and the minimize button did nothing (just closed the dash). Now it is of a standard size and maximize button does nothing
<sil2100> rye: since when did you notice this problem? Since I'm using week-old staging unity and everything seems fine here
<sil2100> rye: since the maximize/restore buttons should work as for normal windows, i.e. maximize and restore
<rye> sil2100: today - for unity being always "Restored", and I guess 4 days already for it being always maximized (but I failed to tell about this). I am using latest and greatest unity-team/staging on raring
<sil2100> rye: might be a nasty regression - I'll try upgrading and checking that as well
<rye> for dash being always "Restored"
<sil2100> rye: in the meantime, you might anyway fill in a bug - paste the bug link here so I can 'confirm it' if anything
<rye> sil2100: hmmmmm, i found the sensitive area for the button - it's starting from the left border till the image of the square
<sil2100> Oh, hm
<sil2100> Is the dash looking differently than before?
<rye> sil2100: define: differently
<bregma> actually, it looks like the button pres is getting sent in behind
<bregma> I clicked on the min/max button on the dash and it made the (maximized) terminal in behind go back to non-maximized state
<bregma> but didn;t affect the dash
<bregma> soudns like a definite bug to me
<rye> bregma: nope, does not work this way for me, if i click at the square or to the left/up/down of the square image of maximize/restore button - the dash simply closes
<bregma> oh, now it's not doing it for me, either
<rye> ok, filing-a-bug
<bregma> I guess I clicked twice, and first one closed the dash
<bregma> either way, it's a bug
<rye> bregma: is it restoring/maximizing if you click slightly to the left on that maximize/restore button?
<bregma> yep
 * rye is running libc 2.17 and it already broke ubuntuone-syncdaemon's metadata so just to make sure it's not a weird error there...
<rye> bregma: great!
<rye> sil2100: https://bugs.launchpad.net/unity/+bug/1101310
<ubot5> Launchpad bug 1101310 in Unity "[staging][raring] Maximise/Restore button sensitive area is only 1/4th of an image" [Undecided,New]
<sil2100> rye: thanks
<mhall119> can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1096708 and see if we can backport a fix?
<ubot5> Launchpad bug 1096708 in dee (Ubuntu) "'SharedModel' object has no attribute 'append' using Python 3 on 12.04" [Undecided,New]
#ubuntu-unity 2013-01-19
<sabotage> any way to launch a unity lens from cli?  trying to map a keysym to open a specific lens
<bschaefer> sabotage, hmm well the shortcuts for each lens is in here
<bschaefer> /usr/share/unity/lenses
<bschaefer> just open up the file and under Shortcut=<letter>
<bschaefer> and the shortcut is Super + <letter>
<om26er> is there a public mailing list for webapps ?
<Controlsfreek> I'm new to this, but I'm looking at https://bugs.launchpad.net/~unity-community-hackers/+bugs. Are all these bugs related to Ubuntu+1? How do i know which release I need to be testing in? Thanks for the newbie help!
<mhall119> Controlsfreek: you can ignore the unity-2d bugs, since that codebase isn't maintained anymore
<mhall119> unless specified otherwise, those bugs would affect current and +1 releases
<Controlsfreek> mhall119, Oh good to know. I was just going off of that web page as a place to start. Is there a better place to start?
<Controlsfreek> Also the mailing list link at https://launchpad.net/~unity-community-hackers seems to be dead. Looking for the correct place to join the mailing list
<mhall119> https://bugs.launchpad.net/unity has all the unity bugs
<Controlsfreek> mhall119, I'm running 12.10. Should I upgrade to +1 before starting/
<mhall119> it would be more useful, yeah
<mhall119> plus, 13.04 is really nice :)
<Controlsfreek> okay great. thanks!
<Controlsfreek> I'm trying to build Unity for the first time. I've built nux successfully. Still getting errors: http://pastebin.com/1dnHXwk7
<Controlsfreek> For some reason it gives "--   package 'nux-4.0>=4.0.0' not found" but then later on it says "--   found nux-4.0, version 4.0.0" I'm a bit confused
<tgm4883> Controlsfreek, that is an unknown paste ID
<tgm4883> not that I'll know the answer, but it makes it difficult to look
<Controlsfreek> tgm4883, sorry, had set it to expire after an hour. Here it is again: http://pastebin.com/rnuh7GZf
#ubuntu-unity 2013-01-20
<Controlsfreek> Hi all- I'm still having trouble building unity- even after a successful build of nux: http://pastebin.com/rnuh7GZf
<rperier> Controlsfreek: did you execute "unity-env" before ?
<rperier> it's required, because this function export a variable called PKGCONFIG_PATH which is used to detect the right version of nux installed into $HOME/staging :)
<rperier> exports*
<rperier> so "unity-env; remake-unity" should work
<Controlsfreek> rperier, YES that worked. Thank you. I thought i had earlier in the setup process... apparently not! Its building right now.
#ubuntu-unity 2014-01-13
<MacSlow> Greetings folks!
 * greyback waves from Cape Town
<MacSlow> greyback, enjoying the sun? :)
<greyback> MacSlow: yep, it's warm & sunny. We're inside working hard however
<MacSlow> greyback, I know :)
<greyback> MacSlow: welcome back. Have a good holiday?
<MacSlow> greyback, thanks... basically yes... but my moving-plans didn't work out as planned... so it's a bit of a mixed bag :)
<greyback> MacSlow: ah, I wasn't aware you were planning to move. Same city? Same country? :)
<MacSlow> same city... but now after more than seven weeks still no i-net in the new flat :/
<kgunn> MacSlow: you surface...welcome back
<MacSlow> kgunn, thanks
<tsdgeos> guys
<tsdgeos> are you having scoperegistry at 100% too?
<MacSlow> hey tsdgeos
<tsdgeos> MacSlow: welcome back
<MacSlow> tsdgeos, thanks
<tsdgeos> MacSlow: have you dist-upgaded? can you reproduce the cpu usage of scoperegistry being at 100% all the time?
<MacSlow> tsdgeos, just doing all the updating right now... I'll report back if I see that too here
<MacSlow> tsdgeos, getting > 1GBytes work of updates :)
<tsdgeos> lol
<MacSlow> tsdgeos, typical for a frist day after holiday :)
<tsdgeos> pstolowski: hi ho, can you reproduce the cpu usage of scoperegistry being at 100% all the time?
<pstolowski> tsdgeos, hi! i don
<tsdgeos> missing 't or extra n?
<tsdgeos> :D
<pstolowski> tsdgeos, i don't have the full setup with unity8 atm, so I can't right now
<tsdgeos> pstolowski: this is on the desktop
<tsdgeos> happens both in unity7 and kde
<tsdgeos> s/kde/plasma
<tsdgeos> D:
<pstolowski> tsdgeos, ah, so it's not when real client talks to it?
<tsdgeos> i haven't tried starting unity8 tbh
<tsdgeos> let me see if that makes it happy
<pstolowski> tsdgeos, ok, I'll take a look and let you know
<tsdgeos> unity8 is segfaulting now :-S
<tsdgeos> come on!
<tsdgeos> hmmm
<tsdgeos> i have http://ppa.launchpad.net/unity-team/demo-stuff/ubuntu/
 * tsdgeos bets something went wrong in there
<sil2100> jamesh: hi! Just a note - when testing mediascanner2 on Friday, I noticed that it was using far more CPU than mediascanner
<jamesh> sil2100: in general use, or when idle?
<jamesh> I mean, when scanning or when idle?
<sil2100> jamesh: I guess that when it was idle as well, top was mentioning a 3-4% CPU usage all the time, and my phone strangely started generating more heat then usually on idle
<jamesh> sil2100: okay.  I'll take a look.
<sil2100> jamesh: thanks
<tsdgeos> pstolowski: MacSlow: purging ppa:unity-team/demo-stuff from my system made stuff go back to normal
<MacSlow> tsdgeos, thanks for the hint!
<pstolowski> tsdgeos, ok. i'm not using this ppa atm
<tsdgeos> i was because i was told it was needed for the new scopes to work or something
<tsdgeos> but may have changed
<tsdgeos> let's see if the capetown people show up and we can ask them
<pstolowski> tsdgeos, don't get me wrong, this ppa is ok and the way to go. but perhaps something broke there
<jamesh> sil2100: out of interest, if you stop the upstart job and run mediascanner-service-2.0 from a terminal, do you see the same CPU usage problems?
<sil2100> jamesh: will check a bit later, I just clean-flashed my device with the newest image
<jamesh> sil2100: thanks
<sil2100> jamesh: but I only tried running mediascanner through upstart on Friday, so no direct-launching
<jamesh> sil2100: yep.  I've done most of my testing from a terminal, so I was wondering if the different environment triggers the problem.
<jamesh> I'll test it out myself, but thought I'd mention it up front as a possibility.
<pstolowski> tsdgeos, I can confirm 100% cpu with scoperegistry in trunk
<tsdgeos> cool, tx
<didrocks> hey Saviq
<didrocks> Saviq: we have 2 reliable autopilot tests failures on unity8 since Friday evening
<didrocks> happened on the 4 images produced on mako
<didrocks> http://ci.ubuntu.com/smokeng/trusty/touch/mako/125:20140113:20140107.1/6032/unity8-autopilot/ on the last run for instance
<Saviq> mzanetti, can you have a look please â
<Saviq> mzanetti, or delegate at least
<Saviq> didrocks, can you get us a list of packages that changed? u8 wasn't released for a few weeks now
<didrocks> sure, one sec
<didrocks> Saviq: /!\ the list is big, but it seems mostly gstreamer related
<didrocks> (opencv)
<didrocks> Saviq: it started with those changes: http://people.canonical.com/~ogra/touch-image-stats/20140110.1.changes
<didrocks> I don't see anything striking me though
<didrocks> as you are not using python3-autopilot I guess
<Saviq> didrocks, yeah, not yet
<didrocks> Saviq: keep us posted, we are not promoting any image before having your expertise on what regressed (if it's a real issue) you
<Saviq> didrocks, will do, running the suite on my mako now
<didrocks> thx!
<Saviq> tsdgeos, mzanetti, bug #1268525 btw
<ubot5> bug 1268525 in Unity 8 "There's no build-dep on liblightdm-qt5-*-dev and -2 is hardocoded" [Critical,Triaged] https://launchpad.net/bugs/1268525
<Saviq> we  got FTBFS
<tsdgeos> booo
<tsdgeos> Saviq: do you want us to fix it *now* or can we wait for mterry?
<Saviq> tsdgeos, it can wait, just making you aware
<tsdgeos> okidoki
<dednick> Saviq: what's USC in terms of unity/mir?
<anpok> unity system compositor
<tsdgeos> E_TOO_MANY_ACRONYMS
<anpok> :)
<tsdgeos> dednick: can you review https://code.launchpad.net/~allanlesage/unity8/autopilot-indicator-page-title-matches-widget/+merge/196991 ? seems your name is in there :D
<dednick> ahha, yeah, that would make sense
<dednick> tsdgeos: ok
<tsdgeos> dednick: since the running of autopilots seems to be borked on the CI at the moment please make sure you run the whole autopilot suite and it succeeds for you
<Saviq> pete-woods, any idea how https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7 could be happening?
<Saviq> greyback, https://errors.ubuntu.com/oops/86923190-7b60-11e3-978e-2c768aafd08c ideas about this stacktrace?
<pete-woods> Saviq: that's weird, there hasn't been a new release of libusermetrics in quite a while
<Saviq> pete-woods, well, we might have never seen that, simply - whoopsie upload got enabled on the phones very recently
<Saviq> tsdgeos, we saw https://errors.ubuntu.com/problem/06fd8687e02be79bfdb8ed6a820caf9f727581ed before didn't we?
 * tsdgeos clicks
<greyback> Saviq: never seen that before. Nothing obvious comes to mind
<tsdgeos> yes
<tsdgeos> i do remember that
<tsdgeos> was a total red herring
<tsdgeos> got fixed by just making the shutdown stuff happen correctly
<tsdgeos> is it back?
<tsdgeos> seems so
<Saviq> tsdgeos, last example is January 2
<tsdgeos> well we never made shutdown really work well
<Saviq> tsdgeos, https://errors.ubuntu.com/oops/a339c5de-742a-11e3-893e-e4115b0f8a4a
<Saviq> didrocks, it's python-gi/python-gobject
<Saviq> mzanetti, you're off the hook for the ap failure
<didrocks> Saviq: do you have more infos that we can share with pitti?
<didrocks> (maybe on #ubuntu-touch?)
<mzanetti> Saviq: thanks
<tsdgeos> Saviq: yeah it's one of the multiple "we still don't shutdown correctly all the time" crashes
<tsdgeos> Saviq: do we want to put more effor in getting that fixed now?
<didrocks> Saviq: ah, or the issue is in the test itself and the warning is triggering an issue?
<tsdgeos> dednick: you have a few branches up for review, want me to tackle some of those? or you have someone in mind to check them?
<didrocks> Saviq: the commit is https://git.gnome.org/browse/pygobject/commit/?id=7193f050
<didrocks> Saviq: I guess you have an implicit type conversion in your test?
<dednick> tsdgeos: be my guest!
<Saviq> didrocks, here's the failing thing: http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tests/autopilot/unity8/shell/tests/test_notifications.py#L291
<didrocks> nothing shocking on first look
<Saviq> didrocks, but it might actually be the script that's failing
<didrocks> Saviq: that sounds more plausible
<Saviq> didrocks, I'm digging more
<didrocks> thanks! good hunt :)
<tsdgeos> dednick: how does https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 relate to https://bugs.launchpad.net/ubuntu-ux/+bug/1253804 and https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/fix_tabs_ordering ?
<ubot5> Ubuntu bug 1253804 in Ubuntu UX "[regression] Indicator icons don't match the settings they display" [Undecided,New]
<tsdgeos> are they both fixing the same? or is it different issues that trigger a similar problem?
<dednick> tsdgeos: hm... looks like it, but the mp for that bug doesnt seem to be the same.
<tsdgeos> dednick: two questions
<tsdgeos> dednick: can you reproduce the errror somehow? and is that something we can unittest?
<dednick> tsdgeos: yeah, give me a minute and i'll work out the steps. I'll have to investigate possible unit test, only happens under certain circumstance
<tsdgeos> dednick: oki, it'd be cool if we could get a unittest
<tsdgeos> to proof the code indeed fixes something, since the change seems mostly a code shuffling to my untrained eye
<tsdgeos> dednick: maybe explain in the commit log why this shuffling actually fixes it?
<dednick> tsdgeos: essentially the fix is 116-118 :)
<tsdgeos> ah
<tsdgeos> dednick: looking at 116-118 don't you think this is something that should be fixed at the Tabs level?
<tsdgeos> i mean if the model changes the Tabs should react to it automatically, don't see why you should tell it to update
<dednick> tsdgeos: no, it's to do with the filtermodel data changing because of an indicator visiblity change.
<tsdgeos> but still
<tsdgeos> you have
<tsdgeos> model: filteredIndicators
<tsdgeos> why doesn't Tabs update itself?
<tsdgeos> though i see you're using the "old" Tabs
<tsdgeos> you can feed it a model now instead all those weird Tabs thing
<tsdgeos> i guess the old tabs as not very good
<dednick> tsdgeos: it's because of this line: readonly property int currentMenuIndex : filteredIndicators.mapToSource(tabs.selectedTabIndex)
<dednick> the currentMenuIndex needs to change when the visibility of an item with a lower index changes.
<tsdgeos> dednick: still not convicing me :D
<dednick> tsdgeos: hm
<tsdgeos> sure i agree that has to update
<tsdgeos> ahh
<tsdgeos> or maybe yes
 * tsdgeos looks at it again
<dednick> tsdgeos: actually, i've unconviced myself now..
<dednick> *unconvinced
<dednick> not that it's a word..
<dednick> tsdgeos: while this way works, it's a bit roundabout and not very efficient
<tsdgeos> i got it now
<tsdgeos> it's not that you want selectedTabIndex to "change", it's that you want currentMenuIndex to get updated
<tsdgeos> right?
<dednick> tsdgeos: yeah
<dednick> tsdgeos: but i think IndicatorRow should probably be doing the updating and notifying the MenuContent.
<tsdgeos> dednick: you lost me there :D
<tsdgeos> dednick: so i get you're reworking it?
<dednick> tsdgeos: investigating it :) i'll try work on a unit test as well
<tsdgeos> cool!
<tsdgeos> dednick: i can't reproduce https://bugreports.qt-project.org/browse/QTBUG-34351 with my self compiled 5.2.1
<tsdgeos> dednick: what were you using? ppa 5.2.? can you try again?
<dednick> tsdgeos: i'm back on 5.0.2 now
<tsdgeos> ok
<tsdgeos> let's put a reminder then :D
<dednick> tsdgeos: when did 5.2.1 become available? Saviq tried with 5.2 before i think
<tsdgeos> dednick: it did not, i'm compiling from git
<dednick> tsdgeos: ok
<dednick> hmm. damn, cant remember how to reproduce this damn bug
<tsdgeos> :/
<tsdgeos> dednick: you have lots of  enabled: menuData && menuData.sensitive || false that could just be  enabled: menuData && menuData.sensitive
<tsdgeos> no
<tsdgeos> ?
<dednick> umm... maybe? not really sure about the qml && evaluation. Saviq told me to use the || ,  although that may have been for string and such.
<dednick> tsdgeos: is it actually documented somewher?
<tsdgeos> dednick: for a string makes sense, but for a bool?
<tsdgeos> i mean you are doing bool || false
<tsdgeos> which is always the first bool, no?
<tsdgeos> anyway doesn't hurt either
<tsdgeos> so if it works
<tsdgeos> let leave it there :D
<dednick> :)
<tsdgeos> hmmm
<tsdgeos> what's causing https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/900/console ?
<Saviq> greyback, ideas â? something changed in mir's headers?
<greyback> looking
<tsdgeos> and why it works for me
<greyback> ricmm_: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/900/console
<tsdgeos> what's libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1  ?
<tsdgeos> unity-mir only has 162 revs
<tsdgeos> Â¿?
<tsdgeos> greyback: i repeat
<tsdgeos> <tsdgeos> what's libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1  ?
<tsdgeos> <tsdgeos> unity-mir only has 162 revs
<tsdgeos> <tsdgeos> Â¿?
<greyback> tsdgeos: sorry, network here dodgy
<greyback> tsdgeos: that's a mystery to me
<tsdgeos> it's coming from somehwre called  http://naartjie/archive//head.unity8/
<tsdgeos> fginther: do you know what's that â ?
<tsdgeos> Saviq: â ?
<greyback> tsdgeos: so hte path /usr/include/mirserver is missing as a header include path, seeing why
<tsdgeos> greyback: my current thinking is that somehow that unity-mir package is picking up the cmake stuff from tvoss and it's broken because of that
<tsdgeos> but i'd like to know what that bzr168 mean
<tsdgeos> s
<greyback> tsdgeos: that's my suspicion yeah.
<Saviq> tsdgeos, that's a local archive that's built when autolanding unity-mir
<tsdgeos> Saviq: any idea why the bzr rev is off?
<Saviq> tsdgeos, it's a per-stack (hence head.unity8) - all packages that are built in -autolanding jobs get put there
<tsdgeos> ahhhh
<Saviq> tsdgeos, good question, it should be 162
<tsdgeos> so basically the cmake port broke unity-mir it seems :D
<tsdgeos> bad us all for not anticipating it
<Saviq> tsdgeos, so cmake's not installing that header?
<tsdgeos> Saviq: i think the problem is that the pkg config of old unity-mir included more includepaths than the new one
<tsdgeos> checking
<Saviq> tsdgeos, ah possible
<tsdgeos> yepp
<tsdgeos> the
<tsdgeos> Requires: ubuntu-platform-api mirclient mirserver Qt5Core
<tsdgeos> is gone
<tsdgeos> which most probably causes that include stuff missing
<tsdgeos> Saviq: greyback: https://code.launchpad.net/~aacid/unity-mir/requires_pkg/+merge/201385
<greyback> tsdgeos: heh, beat me to it :)
<tsdgeos> and now
<tsdgeos> food!
<greyback> tsdgeos: approved
<Saviq> Cimi, ping
<Cimi> Saviq, pong
<tsdgeos> Saviq: i'll continue landing stuff manually while otto is borked
<Saviq> tsdgeos, yup
<tsdgeos> mterry: hi ho, make sure you have a look at the bug Saviq assigned you
<Saviq> tsdgeos, you know how to kick generic-land?
<tsdgeos> Saviq: not really, i was planning of just doing it manually :D
<tsdgeos> Saviq: but if there's a better way, i'm all ears
<Saviq> mterry, bug #1268525
<ubot5> bug 1268525 in Unity 8 "There's no build-dep on liblightdm-qt5-*-dev and -2 is hardocoded" [Critical,Triaged] https://launchpad.net/bugs/1268525
<Saviq> tsdgeos, you find the autolanding job that failed: http://s-jenkins.ubuntu-ci:8080/job/unity8-autolanding/933/console
<Saviq> tsdgeos, and you restart the generic-land job: http://s-jenkins.ubuntu-ci:8080/job/generic-land/21153/rebuild/?
<Saviq> tsdgeos, approve the branch first
<Saviq> tsdgeos, and then change FAILED to PASSED when restarting the job
<tsdgeos> ok, letme see if i can do it :D
<mterry> tsdgeos, Saviq: that should be fine.  We don't actually link against liblightdm-qt5 yet.  Not until we split
<mterry> tsdgeos, Saviq: we just staticly link against the fake -2 version we make
<Saviq> mterry, hmm right
<Saviq> mterry, somehow I can't build it on device because of that :?
<mterry> Saviq, alright looking
<didrocks> Saviq: any news on the test failing? (Didn't get a chance to read scrollback)
<Saviq> didrocks, pitti's filed a bug upstream
<didrocks> Saviq: do you have the ref?
<Saviq> didrocks, bug #1268578
<ubot5> bug 1268578 in pygobject (Ubuntu) "Notification callback causes exception in gi" [High,Triaged] https://launchpad.net/bugs/1268578
<Saviq> didrocks, and there's a workaround
<didrocks> Saviq: do you plan to implement the workaround?
<Saviq> didrocks, yeah, doing so now
<didrocks> thanks!
<didrocks> then, please put a landing ask for unity8 if good
<mzanetti> MacSlow: hey, you're back
<MacSlow> mzanetti, yup
<Saviq> didrocks, tsdgeos, https://code.launchpad.net/~saviq/unity8/workaround-1268578/+merge/201420
<Saviq> MacSlow, welcome back!
<mzanetti> MacSlow: welcome back
<MacSlow> mzanetti, but still burried in catch-up on everything :)
<MacSlow> Saviq, thanks :)
<MacSlow> let's see if mumble still works ;)
<mzanetti> MacSlow: I guess so... I received 123 mails in the last 4 hours... don't wanna know how many there are after 4 weeks :D
<MacSlow> mzanetti, more than I feel is healthy ;)
<tsdgeos> Saviq: you joning?
<tsdgeos> greyback: â  ?
<Saviq> tsdgeos, not really
<tsdgeos> okidoki
<greyback> tsdgeos: ah ok, it's the sidestage code causing this problem, not trunk
<tsdgeos> good! (or not)
<tsdgeos> :D
<Saviq> mterry, http://pastebin.ubuntu.com/6744944/
<Saviq> mterry, the failure on device U
<Saviq> -U
<didrocks> Saviq: ok, so no need for unity8 workaround I guess for now
<fginther> tsdgeos, regarding libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1. The bzr version is based on the MP being merged, so it can be higher then the trunk branch. The package in the naartjie archive is also built from the last MP that passed autolanding (so the latest builds always replaces the last one regardless of the version number).
<fginther> tsdgeos, This number is at least misleading, I'll see if I can find a way to improve it.
<tsdgeos> fginther: that'd help, now that the number did not exist one could guess it was the latest, but if the number had existed one could have assumed the wrong code was in there
<fginther> tsdgeos, I agree, it's a recipe for disaster
<mterry> Saviq, I just build unity8 fresh on mako with debuild fine
<tsdgeos> dandrader: do you have a sec?
<dandrader> tsdgeos, yes
<tsdgeos> dandrader: so i'm doing the organicgrid
<tsdgeos> and since it's mostly "lineal" i'm doing the same deal of storing the m_firstVisibleIndex and a list of QList<QQuickItem*>
<tsdgeos> now the thing is that due to the ordering inside a 6-module of the indexes
<tsdgeos> when i'm going down in index number to find which index is not visible anymore
<tsdgeos> it may happen that the index 4 of the "6-module" is not visible but the index 5 is
<tsdgeos> see the UX spec for the positioning
<tsdgeos> so i was thinking that maybe i should create the delegates in the modules of 6
<tsdgeos> and not individually
<tsdgeos> what do you think?
<dandrader> didn't get this "6-module" story
<tsdgeos> do you have the ux spec open?
<dandrader> trying to open it but google drive seems very slow
<dandrader> tsdgeos, it's the "Future Dash : UX spec"?
<tsdgeos> dandrader: yep
<dandrader> tsdgeos, so, what about it
<dandrader> ?
<tsdgeos> dandrader: so in the organic grid
<tsdgeos> each 6 delegates for a module
<tsdgeos> and are positioned in that 3x2 way
<tsdgeos> yes?
<dednick> tsdgeos: that MP is ready with tests now. Few changes though... now "realigns" if the visibility of indicator which is currently open changes.
<tsdgeos> dednick: oki, will check tomorrow
<dednick> tsdgeos: ta
<dandrader> tsdgeos, what do that ux text mean by a "module"?
<tsdgeos> "a module is all the cards needed for the repeating pattern, 6 cards"
<tsdgeos> it's in the description
<dandrader> ah
<tsdgeos> ok, so now read again what i wrote at the beginning and see if it makes sense
<tsdgeos> if not i'll try to rephrase it
<tsdgeos> <tsdgeos> ok, so now read again what i wrote at the beginning and see if it makes sense
<tsdgeos> <tsdgeos> if not i'll try to rephrase it
<dandrader_> tsdgeos, so this organic grid can scroll horizontally or vertically?
<tsdgeos> in the dash vertically
<tsdgeos> i'll adapt it later for scrolling horizontally so we can reuse it in the gallery-app
<tsdgeos> but for now asume it's only vertically
<dandrader_> tsdgeos, I got the scenario but didn't get what's your problem
<tsdgeos> my problem is what should i do :-)
<tsdgeos> when index 3 is not in the vertical area we create
<tsdgeos> but index 5
<tsdgeos> is
<tsdgeos> do i create index 3, 4 and 5?
<tsdgeos> or do i create 6 too?
<tsdgeos> and the same when deleting up
<dandrader_> tsdgeos, ah, ok. I don't think there
<dandrader_> there's a problem
<tsdgeos> because something got out of bounds
<tsdgeos> so i'm suggesting to treat the modules as single entities for "bounds" checking
<dandrader_> in creating the items between indexes 2 and 5
<tsdgeos> so that i either create the 6 module
<dandrader_> even though they're not yet visible
<tsdgeos> or delete the 6 module
<dandrader_> if that makes the code simpler
<tsdgeos> certainly does
<tsdgeos> and it should not incur in a huge memory "waste"
<dandrader_> it's no waste. it's similar to the "buffer" technique, where you also create the delegates that are very close to the visible rect
<tsdgeos> sure
<tsdgeos> that's of course buffering
<tsdgeos> it's just a "more generous" buffer :D
<tsdgeos> ok, i'll do that then
<karni> Anyone flashed trusty-proposed today? I'm having problems starting the phone after having installed the demo-stuff ppa along the instructions (as usual after flashing the phone).
<karni> It seems the backlit is on, and it briefly flickers something (anything) on every 8 seconds or so. Can't restart unity from shell, core dumped.
<karni> not even sure if whatever it's blicking is meaningful, because I can only tell *something* blinks.
#ubuntu-unity 2014-01-14
<otaku> Hey I need a hand with making script button with unity.  I have made the button however I think my problem it requires root priv to exec
<otaku> these are my scripts
<otaku> http://pastebin.com/mhayTXeG
<otaku> http://pastebin.com/LGGXbWGS
<otaku> I have to go, but i anyone can help and sees this message could you pls email at mac.tzu@gmail.com
<tsdgeos> dednick: did you finish running the tests for https://code.launchpad.net/~allanlesage/unity8/autopilot-indicator-page-title-matches-widget/+merge/196991 ?
<dednick> tsdgeos: yeah, but i had some random failures in non-related tests, so I need to run again
<tsdgeos> dednick: seen the comment i made on the other indicator test? can you repro the issue?
<dednick> tsdgeos: will take a look now
<tsdgeos> oki
<dednick> tsdgeos: was that on device?
<tsdgeos> dednick: no
<dednick> tsdgeos: and I'm presuming the thing you're talking about is the tab bar?
<tsdgeos> dednick: yes, the text is cut as you see on the screenshot
<dednick> tsdgeos: what happens when you move?
<dednick> tsdgeos: i can't repro
<dednick> in other words
<dednick> oh, it just happened. weird
<tsdgeos> well if i move it moves to a different indicator
<tsdgeos> and when i'm back it works
<dednick> tsdgeos: hm. it only happened once... finding hard to repro
<tsdgeos> happens 90% of the cases here
<tsdgeos> the other times it travels from the right
<tsdgeos> which is also unxpected
<dednick> tsdgeos: which qt ver you on?
<dednick> 5.2.1?
<tsdgeos> no
<tsdgeos> 5.0.2
<tsdgeos> as everyone is
<dednick> hmm
<dednick> tsdgeos: does it happen when you don't unlock?
<tsdgeos> yes
<tsdgeos> seems the unlock step is not needed
<dednick> so litterally just "press hold on the messaging icon without move"?
<tsdgeos> yep
<tsdgeos> otoh it's an improvement
<tsdgeos> since if i doo that on the current master
<tsdgeos> i get the networking tex
<tsdgeos> t
<dednick> ehhe
<dednick> tsdgeos: and only first time you open indicators?
<tsdgeos> yes
<dednick> tsdgeos: i think it may be a bug in the tabs
<dednick> tsdgeos: i think because tabs are being inserted dynamically before the one which is currently selected, it's not adjusting.
<dednick> tsdgeos: let me just confirm in a separate test
<kgunn> greyback: ricmm_ so we're gonna promote latest mir, looks like client abi broke...so just
<kgunn> need to invoke a rebuild for clients
<kgunn> is it only papi & unity-mir ?
<kgunn> or...does something else use client api?
<greyback> kgunn: nothing else uses it
<Saviq> didrocks, hey, if you have a sec, can you tell me who to talk to about PPA issues?
<didrocks> Saviq: depends on the ppa, is it a general launchpad issue or something else ?
<Saviq> didrocks, rather general: https://launchpadlibrarian.net/162419907/buildlog_ubuntu-saucy-amd64.capnproto_0.4.0-0ppa~5~ubuntu13.10.3_UPLOADING.txt.gz
<Saviq> didrocks, it's running kernel 2.6
<Saviq> didrocks, it's a virt ppa
<Saviq> didrocks, and tests fail there because of the old kernel
<didrocks> Saviq: ok, you need to ping the soyuz support channel then
<dednick> tsdgeos: it's a ubuntu-ui-toolkit bug. I'll raise it with sdk
<tsdgeos> dednick: oki
<tsdgeos> dednick: can you link the bug in the review?
<tsdgeos> as a comment
<dednick> tsdgeos: sure
<tsdgeos> dednick: do you have a simple test you can attach to that bug?
<dednick> tsdgeos: test for what?
<tsdgeos> dednick: for the misalignment
<dednick> oh, you mean the sdk bug?
<tsdgeos> yep
<dednick> tsdgeos: yeah
<tsdgeos> dednick: then you should probably add it to make it easier for the sdk guys to test it instead of them having to start unity8
<dednick> well - "simple"
<tsdgeos> simpler than compiling unity8 for someone that doesn't do it very often i hope :D
<dednick> tsdgeos: I'm trying to add the test directly into the sdk branch, so they can just fix it from there...
<tsdgeos> ok
<sil2100> greyback: hello!
<greyback> sil2100: hey
<sil2100> greyback: just wanted to get a big upper confirmation - are all components for the dimention support for sidestage landed and ready for release?
<sil2100> greyback: since we saw the unity-mir merge landing already
<greyback> sil2100: correct. unity-mir would need to released too, as without the experience is broken
<sil2100> greyback: ok, so the components to release are: platform-api, qtubuntu and unity-mir, right?
<greyback> sil2100: correct
<Saviq> tsdgeos, organicgrid conflicted
<tsdgeos> booo
<tsdgeos> Saviq: tx
<Saviq> mhall119, good news, we found the issue with u8 deps on saucy
<tsdgeos> come on
<tsdgeos> 1: /home/tsdgeos_work/phablet/unity8/organicgrid/plugins/DashViews/organicgrid.cpp: multiple new lines at end of file
<tsdgeos> :D
<Saviq> tsdgeos, ;)
<Saviq> tsdgeos, should've `make testwhitespace` before ;)
<Saviq> or whatever
<tsdgeos> yeah i did before actually
<tsdgeos> the test still didn't get there
<tsdgeos> dandrader: organic grid is up at https://code.launchpad.net/~aacid/unity8/organicgrid/+merge/201586 you taking care of it?
<dandrader> yes, I can review it.
<tsdgeos> Saviq: ah one thing i wanted to ask you, in the journals i print a warning when the delegate width/height do not match the width/height set to the journal
<tsdgeos> but in the organicgrid i think it's better not to do that, since you don't know if it'll end up in a big or a small delegate spot (well you know but it'd mean add an if in the qml side that i don't think gives us much)
<tsdgeos> Saviq: opinion?
<tsdgeos> dandrader|lunch: ââ
<mhall119> Saviq: \o/
<mhall119> Saviq: so can I build it now?
<Saviq> mhall119, would be great if you tried
<Saviq> https://code.launchpad.net/~unity-team/+archive/ppa
<mhall119> Saviq: will do
<MacSlow> Saviq, my main system is bricked atm and I can't connect to mumble atm as I'm missing the certificat password...
<tsdgeos> MacSlow: ?Â¿
<tsdgeos> ouch
<tsdgeos> MacSlow: ok, fill in your stuff in the document :D
<MacSlow> tsdgeos, I have kernel-panics all over the place after trying to update the UbuntuTouch emulator... fighting with this the whole day to solve... and on my laptop my mumble-setup only has the old certificate for mumble
<karni> You guys keeping some SU notes, right? I've been to a team that did Mumble standup, another one did IRC standup, current one does Hangout, and this one does Mumble again :)
<tsdgeos> karni: yes, we keep standup notes
<karni> good :)
<Saviq> mhall119, ah, and you need the sdk-team PPA, but that you probably have already
<mhall119> Saviq: the unity-team ppa isn't going to break my desktop unity is it?
<Saviq> mhall119, no
<dandrader> tsdgeos, can't run DashViews tests anymore
<dandrader> tsdgeos, $/builddir/make [try|test]Foo fails
<dandrader> (missing make targets)
<tsdgeos> ?Â¿
<tsdgeos> really
<tsdgeos> ?
<tsdgeos> i did use that :D
<karni> tsdgeos: I noticed verticaljournal extends QQuickItem, thus does not have properties like: interactive, flicking, moving, pressDelay from Flickable (i.e. like GridView). Do we care?
<dednick> dandrader: ping
<dandrader> dednick, pong
<tsdgeos> karni: yes, the vertical journal is not flickable, you have to put it inside a list to move it
<karni> tsdgeos: gotcha
<tsdgeos> karni: basically if you look at the dash, it's a list with things inside
<tsdgeos> the journal is one of those things
<karni> tsdgeos: ACK :)
<tsdgeos> dandrader: make testOrganicgrid just worked here
<tsdgeos> dandrader: doesn't work for you?
<karni> tsdgeos: Since I already have your attention - verticaljournal keeps track of it's implicit height, right?
<tsdgeos> karni: yes
<karni> so that I can tell whether it's clipped or not. great.
<dednick> dandrader: howdy. just noticed something a bit odd with the DragHandles when using a hint. It looks like if you click for hint, then drag, the displacement is getting reset to 0. causes a bit of a flash as you drag.
<dandrader> ahhhhhhhh
<dednick> dandrader: can see it either in indicators or tryDragHandle
<dandrader> its testOrganicgrid, not testOrganicGrid
<dednick> dandrader: want me just to log a bug?
<dandrader> tsdgeos, can you fix that (and for the others as well)?
<tsdgeos> dandrader: actually i can't
<tsdgeos> since the name is autogenerated
 * karni agrees testOrganicGrid would be more intuitive, that'd bite me too :)
<karni> oh :(
<tsdgeos> that's why you guys use the tab to autocomplete
<karni> hahah
<tsdgeos> make testO<TAB>
<dandrader> tsdgeos, everywhere else is testFooBar, not testFoobar
<tsdgeos> dandrader: i know
<dandrader> tsdgeos, if there's a will, there's a way
<tsdgeos> dandrader: there is a way, i don't feel like doing it, moreover when you already approved the current naming
<tsdgeos> moving the goal posts is not fun
<dandrader> dednick, can you reproduce it with "make tryDragHandle"?
<dednick> dandrader: ya
<dednick> dandrader: i'll just create a bug and assign you.
<tsdgeos> bah
 * tsdgeos shuts up and changes the capitalization
<dandrader> dednick, yeah, just saw the bug you described
<dandrader> with make tryDragHandle
<dandrader> that's definitely a regression
<dandrader> wasn't there before
<dednick> dandrader: cool. i'll log it.
<Saviq> mhall119, there's a package missing in the ppa, just setting up the recipe
<tsdgeos> dandrader: pushed
<dandrader> tsdgeos, It slipped past me. If I had noticed it before I would not approve it :)
<karni> tsdgeos: verticaljournal has no currentIndex, like GridView in grid layout would, to track hilight/currently selected item. Do we care? :)
<dandrader> tsdgeos, the whole point of standardized make test/try targets is to make them predictable so that you don't have to look at the corresponding CMakelists.txt to find out how the heck to summon it
<karni> tsdgeos: Sorry for those questions, I'm just going through that code and saying out loud if I have any worries/doubts :)
<tsdgeos> karni: that's a good question, yes it has no index concept
<dandrader> you just have to known the name of the class and that's it
<karni> tsdgeos: Should I file a bug, so we don't forget?
<karni> tsdgeos: OR, it does not and will not have index concept?
<karni> Maybe that's what you meant.
<tsdgeos> karni: don't know, i guess we will need one to do keyboard navigation
<tsdgeos> other than keyboard navigation i don't see us needing one
<tsdgeos> maybe for previews too
<tsdgeos> since you can switch to next/previous there
<karni> tsdgeos: ok. I'll log a bug, just in case. Should I assign you, or leave it be for someone to pick it at some point?
<Saviq> tsdgeos, so... we don't need the workaround that you've merged yesterday any more...
<Saviq> tsdgeos, I'm tempted to uncommit it...
<tsdgeos> Saviq: the one for the python stuff?
<Saviq> tsdgeos, yes
<Saviq> tsdgeos, got fixed since yesterday...
<tsdgeos> karni: yeah file a bug, assign it to me, will think about it
<karni> okay
<tsdgeos> Saviq: is the change wrong?
<Saviq> tsdgeos, it's not, but unnecessary
<Saviq> tsdgeos, ok never mind, will put it in my "various fixes" branch
<tsdgeos> Saviq: well, reverting it is another unnecessary change then :D
<tsdgeos> but yeah, don't have an opinion
<Saviq> tsdgeos, that's why I'm saying uncommit ;)
<tsdgeos> ah
<Saviq> not revert
<tsdgeos> you mean uncommit and force push
<Saviq> since it's still the tip
<Saviq> tsdgeos, yes
<tsdgeos> brrrrrr
<Saviq> ok then no
<Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/clean-deps/+merge/201608 though
 * tsdgeos clicks
<tsdgeos> Saviq: don't need unity-mir at all?
<tsdgeos> ah
<tsdgeos> the libunity-mir-dev thing already wroks
<Saviq> tsdgeos, yup
<tsdgeos> Saviq: approved
<Saviq> tsdgeos, thanks, let's see what CI says
<tsdgeos> fail in otoo :D
<tsdgeos> otto
<fginther> Saviq, the recent unity8 otto runs have unity8 crash files now. Unfortunately, I don't think they've been retraced so probably of no use
<mhall119> Saviq: just let me know when it's ready and I'll update/upgrade/rebuild
<fginther> Saviq, wow, that last message I sent you was completely wrong. The unity8 otto tests are now passing. I was looking at a mako test and saw the crashdump.
<tsdgeos> fginther: are they? i saw lots of red
<fginther> tsdgeos, I guess I may have jumped to soon, but the most recent run passed the otto test: http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/2060/console
<tsdgeos> interesting
<tsdgeos> well maybe as it came it went away?Â¿
<fginther> tsdgeos, another recent run also had just one failure: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/2044/testReport/
<tsdgeos> why was i away?Â¿ D:
<dandrader> tsdgeos, in make tryOrganicGrid, press "add" until you have 10 items (up to index 9)
<tsdgeos> do i make the window bigger?
<dandrader> tsdgeos, I wonder if the designer considered this situation
<dandrader> tsdgeos, looks bad if you ask me
<dandrader> this meaningless void on the right hand side
<tsdgeos> dandrader: the same whole that if you only have 4 items, no?
<dandrader> tsdgeos, yes
<dandrader> tsdgeos,  but it just looks worse when you have that on the second component
<tsdgeos> dandrader: the "real" sizing of the delegates will probably make it a bit less bad
<tsdgeos> but yeah it's not ultra cool
<tsdgeos> i guess the designers idea is that it'll always there be "enough" stuff
<dandrader> tsdgeos, I don't know. it feels like its working against usability
<tsdgeos> but let me see what the gallery does
<tsdgeos> if i can start the phone :D
<dandrader> tsdgeos, maybe the order of items in a "module" should be different if there are less than 6 items
<dandrader> tsdgeos, because the layout when there are only 4 items in the module just doens't make sense
<dandrader> tsdgeos, and I'm starting to think designers out to agree on that point
<dandrader> s/out/ought
<karni> tsdgeos: thanks for looking into the currentIndex thing already.
<tsdgeos> dandrader: if you have the phone working (i need to reflash it) take 4 pictures with the camera and see what the gallery shows
<dandrader> tsdgeos, hmm, I also think I have to reflash mine (galaxy nexus). didn' t touch it since I got the nexus 10 on last sprint
<tsdgeos> dandrader: use the nexus10 then :D
<tsdgeos> should have the gallery app too
<dandrader> tsdgeos, I'm using it for the qml mir compositor work
<tsdgeos> ah
<tsdgeos> ok
<tsdgeos> well then let's wait 10 min until mine gets flashed
<dandrader> I'm flashing mine as well
<dandrader> tsdgeos, btw, the filling order works very well horizontally (if you make the tryOrganicGrid window very wide and start adding items to it)
<tsdgeos> the gallery-app is horizontal
<tsdgeos> maybe that's why it doesn't look bad there
<karni> tsdgeos: I wonder if it would be worth to expose columns (count) in vertical journal. It has the columnWidth property, but that means 'columns' has to be calculated in QML, even though you already do that in cpp.
<tsdgeos> karni: isn't it backwards? you know how much space you have and how much columns you need and then set the columnwidth?
<tsdgeos> well not really that
<tsdgeos> as far as i understand
<tsdgeos> you know the width
<tsdgeos> and you know your columns have to me between 10 and 20, so you calculate the proper sizes (10 and 20 are random numbers i just invented)
<tsdgeos> at least that's how i understand it
<karni> brb standup, sorry!
<tsdgeos> fginther: yeah the organicgrid otto tests passed :o
<tsdgeos> Saviq: do you have katie in there?
<dandrader> tsdgeos, I believe they've reached EOD there
<tsdgeos> but aren't they behind?
<karni> tsdgeos: d'oh, sure. you're right :)
<tsdgeos> dandrader: ok, i'll take a screenshot and send it via email to saviq, katie, you then, ok?
<dandrader> tsdgeos, ok, thanks!
<greyback> tsdgeos: yep, we've hit eod
<karni> tsdgeos: Can I ask one question about your code? http://paste.ubuntu.com/6751191/
<karni> tsdgeos: In my understanding, in RespGridView we subtract spacing/2 from width (say, left margin), and divide the rest over colWidth+colSpacing() (so, this excludes right margin, because that is included in the added columnSpacing already)
<karni> tsdgeos: If that doesn't make mush sense, or you don't feel like talking about pixel perfect shit, just be honest with me :D I'll leave hahah.
<karni> I just thought I'd bring up that small inconsistency I noticed.
<tsdgeos> karni: i think the difference is that responsivegridview takes into account the outer spacing while the journals do not
<tsdgeos> i.e. journal will put stuff at 0,0
<tsdgeos> and responsivegridview probabbly not
<tsdgeos> the journal way is a bit more versatily since it allows you to have a different inner spacing and outer spacing
<tsdgeos> in case you want that
<tsdgeos> am i making sense?
<karni> oh, that makes sense. I must have not realized journal could put stuff at 0,0 instead spacing/2, 0
<karni> tsdgeos: yes, makes sense. thanks
<karni> Wouldn't then
<karni> const int nColumns = qMax(1., floor((double)(width() + columnSpacing()) / (m_columnWidth + columnSpacing())))
<tsdgeos> dandrader: mail sent, does it make sense to you?
<karni> be
<karni> const int nColumns = qMax(1., floor((double)(width()) / (m_columnWidth + columnSpacing())))
<tsdgeos> nope
<karni> If you can put stuff at 0,0 (no left margin)
<tsdgeos> the last column doesn't get a columnspacing
<karni> oh
<karni> :D thanks tsdgeos
<tsdgeos> width = ncolumns * columnWidth + ncolumns * (columnSpacing -  1)
<tsdgeos> now do the math
 * karni is really enjoying exploring this code base
<tsdgeos> and you end up with the other formula
<karni> correct
<tsdgeos> karni: cool, hope that it means the code is not so bad :D
<karni> tsdgeos: hahahahah, it's gooooooooood /me makes Bruce Almighty impression
<karni> :)
 * tsdgeos pretends to know who is that Bruce something
<karni> tsdgeos: https://www.youtube.com/watch?v=nVCe0oWdnrE
<tsdgeos> ahh
<karni> :)
<tsdgeos> title translations always are creative here
<tsdgeos> that movie was called "Like God"
<karni> tsdgeos: I guess. That's why I always hunt for original titles :)
<karni> translation to Polish was, in this case, very adequate to the original. but yeah, I get your point, some are really terrible :)
<tsdgeos> dandrader: right the docu is missing
<tsdgeos> and the ascii art too
<tsdgeos> will do tomorrow
<tsdgeos> getting eod'ed here
<dandrader> ok
#ubuntu-unity 2014-01-15
<greyback> ricmm_: https://docs.google.com/a/canonical.com/document/d/1HwxEhrZ45WDngypEmGLW1lHXqf6nLKqdnYORwTALo8E/edit
<tsdgeos> Saviq: why the preference for null over undefined?
<Saviq> tsdgeos, return null vs. failure
<Saviq> tsdgeos, don't remember now why, but that reduced some warnings for me, let me check
<Saviq> tsdgeos, but anyway, null has more "value" than undefined
<Saviq> tsdgeos, ah I know now
<Saviq> property Item header: findChild(card, "cardHeader")
<Saviq> was warning when undefined
<tsdgeos> ok
<tsdgeos> change looks ok to me, was just wondering the reason :)
<Saviq> tsdgeos, generally, undefined is... undefined
<Saviq> tsdgeos, while null has a value... of null...
<Saviq> so the function returns nothing now, as opposed to not knowing what it returns (of sorts)
<tsdgeos> Saviq: and the otto thing fixed itslef :D
<Saviq> tsdgeos, indeed it did
<Saviq> tsdgeos, fginther was baffled
<Saviq> tsdgeos, he couldn't find any reason why it started, or any reason why it stopped again...
<Saviq> tsdgeos, we stopped crashing during smoke tests, too, though
<tsdgeos> :D
<tsdgeos> ah wait
<tsdgeos> i wonder if it's the /proc thing
<tsdgeos> or not, the /proc thing was only for Qt5.2
<tsdgeos> and we're not using 5.2 in there
<tsdgeos> dednick: so you think we should merge https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 even with the sdk bug you found?
<tsdgeos> dednick: also seen my comment at https://code.launchpad.net/~nick-dedekind/unity8/indicator.ubuntu-settings-components/+merge/199311 ?
<dednick> tsdgeos: um, i think the bug is in trunk as well isnt it?
<dednick> or i thought it would have nbeen...
<tsdgeos> the on for the messaging?
<tsdgeos> it's different but yes it's there
<tsdgeos> ok
<dednick> tsdgeos: i think we should merge. IMO...
<tsdgeos> so you think we ought to merge it
<tsdgeos> ok, i'll have a new look
<dednick> tsdgeos: ta
<tsdgeos> dednick: do we want to merge https://code.launchpad.net/~nick-dedekind/unity8/indicator.ubuntu-settings-components/+merge/199311 before that thing you say is fixed?
<dednick> tsdgeos: um, i should probably make sure all is still well and nothing has regressed.
<dednick> i'll put it back down to WIP
<tsdgeos> oki
<tsdgeos> dednick: https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 needs remerging
<dednick> tsdgeos: ok
<dednick> thanks
<tsdgeos> arg
<tsdgeos> how do i tell cmake to use my custom installed qt
<tsdgeos> can't seem to convince it to use PKG_CONFIG_PATH nor PATH (in case it's looking for qmake)
<tsdgeos> ah wait, PATH worked now
<tsdgeos> Mirv: ./tst_components -input tst_datepicker.qml
<tsdgeos> is working for me
<tsdgeos> Mirv: does it crash for you if run standalone?
<dednick> tsdgeos: fixed merge
<tsdgeos> oki
<Mirv> tsdgeos: no, on my computer I did not get the problems the PPA builders are (reliably) getting, instead TextAreaAPI failed for me http://pastebin.ubuntu.com/6749529/
<tsdgeos> :/
<Mirv> tsdgeos: but the PPA builders stop before that, amd64 at DatePickerAPI and i386 at AlarmAPI
<Mirv> almost like random but environment specific (so reproducable, but only on that machine) corruptions or such
<tsdgeos> elopio: seen the comment i made on your search branch?
<tsdgeos> Mirv: you should update the /proc patch to the new patch in https://codereview.qt-project.org/75282 that has now been merged and will be part of 5.2.2 (yeah missed 5.2.1 by one day)
<Mirv> tsdgeos: ok
<tsdgeos> Mirv: i can use the qt daily ppa to build the SDK
<tsdgeos> do you have any other ppa around?
<tsdgeos> Mirv: qtdeclarative5-unity-action-plugin doesn't want to install
<tsdgeos> Qt5 Beta2  seems to have it
<tsdgeos> let me switch to that ppa
<Mirv> tsdgeos: qt5-beta2 PPA has the rebuilds of other packages (required, because of the libqt5core5a transition)
<tsdgeos> Mirv: should i have both or just the qt5-beta2 PPA ?
<Mirv> tsdgeos: if you want to test also qtbase stable branch snapshot in addition to the qtdeclarative snapshot that is already in qt5-beta2 PPA, keep the qt5-daily enabled
<Mirv> tsdgeos: ^
<tsdgeos> ok
<Mirv> I didn't see difference however
<Mirv> tsdgeos: you do know that some packages conflict if you plan use on your main desktop?
<tsdgeos> Mirv: i'm using a chroot
<Mirv> right, good
<dednick> sil2100: I need a new release for ubuntu-settings-components. Still safe as it's not used.
<dednick> larsu: can you sort a release for indicator-messages? need the fix for menu sensitivity
<sil2100> dednick: I'll try, but will have to consult didrocks to maybe consider releasing it, as it has no affect on ubuntu-touch
<sil2100> *effect
<dednick> sil2100: hm. ok
<dednick> tsdgeos: ok, that ubuntu-settings-component branch in unity8 is all set.
<larsu> dednick: hm, I'd have thought that it gets released automatically again. seb128, do you know what's up?
<seb128> larsu, no, we need a landing ask on the gdoc they have, let me add one for indicator-messages (and check other indicators)
<tsdgeos> Mirv: so there's a known issue with 32 bit machines
<seb128> dednick, ^
<tsdgeos> Mirv: https://bugreports.qt-project.org/browse/QTBUG-35917
<larsu> seb128: thanks!
<dednick> seb128: thanks
<tsdgeos> Mirv: that is causing one of the problems for me in my 32bit chroot, now i'll create a 64bit chroot and see how it oes
<karni> Saviq: tsdgeos: any chance you guys could help me out with (supposedly) not having DashViews built? lp:~unity-team/unity8/new-scopes-vj-integration http://paste.ubuntu.com/6755972/
<karni> I got blocked on that bit yesterday, and it's holding me back. meh.
<tsdgeos> karni: does it work if you cd builddir and then run the make ?
<tsdgeos> ah wait that is your new stuff
<tsdgeos> not mine
<tsdgeos> give me a sec
<karni> I could try that, sure
<tsdgeos> karni: are you setting all the paths and stuff?
<karni> tsdgeos: That I may not know. I tried to add ResponsiveVerticalJournal to the appropriate CMakeLists, but I have a feeling that might be the problem.
<tsdgeos> karni: what branch?
<karni> lp:~unity-team/unity8/new-scopes-vj-integration
<karni> tsdgeos: this is WIP, don't try too much ^ ^ I just want to get the make -C builddir/ tryResponsiveVerticalJournal not spit out compilation issues
<tsdgeos> sure
<tsdgeos> sorry lunch is calling, i'll try later, ok?
<karni> sure thing :)
<karni> enjoy your lunch
<Mirv> tsdgeos: ok, interesting. that might explain some of eg. click-update-manager failure which only fails on i386. then again libhud-qt only fails on amd64..
<Saviq> karni, FWIW, until you actually get to integrating it with the new scopes (i.e. building a CardVerticalJournal.qml), you could base on lp:unity8
<Saviq> karni, but it's fine, we can make it so later as well
<karni> Saviq: I see, I could try that
<Saviq> karni, http://paste.ubuntu.com/6756080/ is what you're missing I'd say
<karni> Saviq: will that now, thank you :)
<Saviq> karni, and it's fine, work on what you have right now, we can split it out from new-scopes later
<karni> okay
<Saviq> karni, what I want is limit the diff between trunk and new-scopes
 * karni nods
<Saviq> karni, but new-scopes is an ok stop-gap anyway
<Saviq> karni, only thing we'll lose is some history, potentially
<karni> Understood :) I do see what yo usuggested helps, thank you
<karni> tsdgeos: Saviq helped me out with import paths :)
<elopio> tsdgeos: I did. Thanks for taking a look. I'm trying to fix that branch in
<elopio> https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/textfield_emulators/+merge/189796
<karni> tsdgeos: Not sure if that's my fault somewhere
<karni> ASSERT: "m_indexColumnMap.contains(*modelIndex)" in file /home/karni/src/canonical/unity8/new-scopes/plugins/DashViews/verticaljournal.cpp, line 101
<karni> Aborted (core dumped)
<karni> make -C builddir/ tryResponsiveVerticalJournal from lp:~unity-team/unity8/new-scopes-vj-integration
<tsdgeos> karni: having a look
<karni> tnx
<karni> tsdgeos: There's one thing I don't understand well. Does Journal have a concept of delegate?
<tsdgeos> yes
<karni> ok then : )
<tsdgeos> same as for the listview or gridview
 * karni nods
<karni> tsdgeos: FTR don't try to run the tests of responsive vertical journal, that's not ready. I just wanted to be able to *see* it through tryResponsiveVerticalJournal
<tsdgeos> sure
<karni> And I thought it was high time for me to share whatever I had to keep things moving.
<karni> Even if it's a core dump haha
<seb128> MacSlow, hey, could you review https://code.launchpad.net/~townsend/notify-osd/remove-mouse-bubble-timer/+merge/193353 when you have some spare cycles?
<MacSlow> seb128, noted
<karni> tsdgeos: Please lemme know if you find anything, I'd love to help (if I can :) )
<seb128> MacSlow, thanks
<tsdgeos> karni: know what's wrong alrady
<karni> tsdgeos: \o/
<tsdgeos> karni: btw unfortunately the views we have don't support qml listmodels
<tsdgeos> karni: since they are not abstractitemmodel
<karni> tsdgeos: oh. that doesn't sound good.
<tsdgeos> karni: so you'd have to wrap your ListModel in a SortFillterProxyModel or in a LimitModel
 * karni looks at the docs
<tsdgeos> they are our stuff
<tsdgeos> not qml stuff
<tsdgeos> just grep our source code
<karni> okay
<dandrader> tsdgeos, so unity8 uses ubuntumirserver qpa?
<karni> tsdgeos: Meaning, I'd have to wrap my the ListModel { id: fakeModel ... } in tst_ResponsiveVerticalCournal with SortFilterProxyModel, and pass that as the test model?
<dandrader> because I run it from the terminal, which has "QT_QPA_PLATFORM=ubuntumirclient" and it just worked. so I wonder what's happening
<tsdgeos> karni: yep
<karni> tsdgeos: thanks, I'll give it a shot
<tsdgeos> dandrader: tbh i am not sure i know the answer to that question
<tsdgeos> karni: that won't fix the crash
<karni> tsdgeos: oh. can I do something about the crash as well?
<tsdgeos> sure
<tsdgeos> karni: if (!isComponentComplete() || height() < 0) { to ::refill in abstractjournal.cpp
<karni> tsdgeos: If it gets too complex, I could continue work on the Card Header instead. That depends if I can pull it off haha :)
<karni> tsdgeos: to.. call refill() ?
<tsdgeos> karni: no in the refill call
<tsdgeos> change the if
<karni> oh gotcha
<tsdgeos> to that
<karni> tsdgeos: ack
<tsdgeos> dandrader: seen the comments i made in the organic grid review?
<tsdgeos> you did :D
<tsdgeos> dandrader: can you review https://code.launchpad.net/~aacid/unity8/journal_misc_fixes/+merge/201785 ?
<tsdgeos> oh man our friend test_Dash_Shown is back
<karni> tsdgeos: wohoo. no crash, now wrap that model and hope to see something show up ;)
<tsdgeos> cross fingers
<tsdgeos> nic-doffay: standup
<elopio> tsdgeos: do you know who can help me with the tests for the scopes and previews?
<tsdgeos> me or mzanetti
<elopio> tsdgeos or mzanetti: I will need big help with this branch:
<elopio> https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
<elopio> because the code I'm doing is not testable. Please take a look at the line 107, and ping me back when you have some time to discuss.
<karni> topic: '[Ubuntu-phone] ANN: Ubuntu Core/Touch Android 4.4 support [..]'
<Saviq> didrocks, /me needs help with sane versioning in recipes, if you have 5 minutes
<karni> Saviq: there's a question from my team - do we know if the Carousel has any limitations, like if it could not work in some template parameter combination?
<Saviq> karni, there's a few, all should be listed in the spec
<Saviq> karni, like there's a minimum of items, it can't have summary, it has to be vertical I believe
<karni> Saviq: thanks, I'll follow up with him/see the spec
<mzanetti> elopio: hey. so what exactly are you trying to do?
<mzanetti> you writing tests for the tests? :)
<elopio> mzanetti: hell yeah! I like danger.
<mzanetti> but then, who is going to write the tests for those? :P
<elopio> mzanetti: when writing the test helpers for the SDK, we found that they need tests inside the project.
<mzanetti> ah... hmm, ok
<elopio> otherwise, they would be tested indirectly by the projects using them, and it's caos.
<mzanetti> yeah, I guess makes sense
<elopio> mzanetti: the problem with testing the DashApps and AppPreview is that we can currently access them only through the click scope
<elopio> and that means external communication with a server we don't control, so we will end up with a test we don't control.
<elopio> does that make sense?
<mzanetti> mhm
<mzanetti> elopio: but why would you need to access those from the sdk helpers?
<elopio> mzanetti: for example, I need to check that the helper called get_applications actually returns the list of app names displayed on the scope.
<elopio> for that, I need to have a scope with a list of know apps.
<elopio> what would be great is that instead of accessing DashApps through the click scope, we have an alternate scope only for testing with hardcoded values.
<mzanetti> elopio: I think I'm missing something
<mzanetti> elopio: you said you need to do this for the test helpers in the sdk
<mzanetti> but I don't really see why another app would need to deal with the dash contents
<mzanetti> shouldn't those helpers just be there for lets say, unlocking the greeter and such stuff?
<karni> Saviq: Should I file a bug? spec "minimum number of items in the carousel is 5", code if (results.count <= 6) layout = "grid";
<karni> Saviq: Or is the spec not up to date?
<karni> (that's why I asked if I should file it)
<elopio> mzanetti: the DashApps helpers and DashPreview helpers should be inside unity8, because the code for them is in unity8.
<elopio> Then we will have tests in the project unity-scope-click that will use those helpers in order to test the functionality provided by the click scope.
<Saviq> karni, I don't think the spec should say that - 5 might not be enough
<elopio> mzanetti: are you with me there?
<karni> Saviq: I'll leave a comment in the spec
<Saviq> karni, thanks
<karni> np :)
<mzanetti> elopio: I don't think that makes much sense tbh
<elopio> mzanetti: oh, this might help:
<elopio> https://code.launchpad.net/~elopio/unity-scope-click/autopilot-open_preview/+merge/201797
<elopio> that's the test I'm writing, that needs helpers from unity.
<mzanetti> elopio: all this causes are more fragile tests
<elopio> line 103
<elopio> that code, in my opinion, should be part of unity8, not of the click scope.
<elopio> mzanetti: why more fragile?
<mzanetti> elopio: because if we mess up in unity, your scope tests will fail
<mzanetti> elopio: imho the scope tests should just tests the scope, not unity
<elopio> mzanetti: no, because if you mess in unity, the self-tests for the helpers will fail and you won't be able to merge.
<elopio> mzanetti: well, that would be nice too. But how do I open the scope without unity?
<mzanetti> yeah... its like having tests for tests for tests for nothing. why not just test the scope itself?
<mzanetti> elopio: I'm sure there is a way
<elopio> mzanetti: ok, lets say that you change the objectName titleLabel
<elopio> you do that change in unity.
<elopio> and if we don't have tests in unity to catch that change, it will result in a failure in unity-scope-click
<mzanetti> elopio: exactly. the unity-scope-click tests should not depend on some objectName in unity
<tsdgeos> Saviq: what do you think about forcing the bad loop for that test?
<elopio> mzanetti: oh, but that's unavoidable. Because the code for the UI unity-scope-click is using lives in the unity project.
<Saviq> tsdgeos, not sure what you mean?
<elopio> mzanetti: what we need to do is provide helpers from unity, so unity-scope-click uses those helpers and doesn't have to take care about objectNames.
<tsdgeos> Saviq: the testDashShown, does not fail if you force the non threaded scenegraph loop
<Saviq> tsdgeos, ah
<elopio> and if we change an objectName, or layout, or even some functionality, we change the helper and it will be transparent for unity-scope-click
<Saviq> tsdgeos, yeah, that could be useful
<mzanetti> I'm still not convinced. can't we just fire up that scope alone, without unity and test it?
<mzanetti> Saviq: ^?
<elopio> mzanetti: I would love that
<tsdgeos> Saviq is working on that in the dash tool, no?
<elopio> but the code for the UI would still live in the unity project.
<mzanetti> elopio: you shouldn't test the ui
<Saviq> tsdgeos, I did, but then you broke it with the dashbar
<mzanetti> elopio: just do queries on the scopes api
<tsdgeos> ^_^
<mzanetti> there are tests inside unity8 which test the ui
<Saviq> tsdgeos, PROPERTIES ENVIRONMENT... in CMakeLists.txt should do what we need for the env
<elopio> mzanetti: eventually, we will need to test the integration of unity, unity-scope-click, the search server and the software center agent server.
<tsdgeos> Saviq: oka, gonna try that, ideally i'd like it to be inside a "if qt 5.0" so if we update to 5.2 and still happens we really need to look at it
<elopio> if we don't do autopilot tests for that, we will have to do it manually.
<Saviq> tsdgeos, should be doable in CMake
<Saviq> mzanetti, elopio, we should only test a few journeys, and then through actual unity8 shell
<mzanetti> elopio: sure, but that's another thing
<elopio> mzanetti: that's what I'm doing here.
<Saviq> mzanetti, elopio, a very high level test
<mzanetti> elopio: yeah, what saviq said, those full stack integration tests should live inside the unity8 repo
<elopio> mzanetti: I'm testing a user journey to buy an app.
<Saviq> mzanetti, should they? I don't think so
<Saviq> mzanetti, they're ubuntu tests, not unity8 tests
<mzanetti> hmm...
<elopio> agree to that.
<mzanetti> Saviq: but them being part of unity-scope-click feels wrong too
<elopio> and those ubuntu tests need helpers to interact with unity8, and with unity-scope-click.
<tsdgeos> pstolowski: is this yours? https://bugs.launchpad.net/bugs/1269456
<ubot5> Ubuntu bug 1269456 in Unity 8 "Infographic doesnât seem to be translatable" [Undecided,New]
<tsdgeos> or was that pete-woods'? â
<pete-woods> tsdgeos: the strings are in the apps providing the data
<pstolowski> tsdgeos, not mine
<tsdgeos> pstolowski: you start with p too so you and pete-woods are the same person in my mind ^_^ :D
<elopio> mzanetti: for now, what we have in unity-scope-click are also helpers.
<elopio> Maybe the test for the whole journey should live in a project with a bigger scope, I like that.
<mzanetti> elopio: ok... I'm convinced now... we need those helpers.
<elopio> where I think we disagree is that I say the helpers need to be next to the code that implements their functionality.
<pete-woods> tsdgeos, pstolowski: http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/view/head:/camera-app.qml
<pstolowski> tsdgeos, :)
<elopio> mzanetti: ok, so we disagree even before that :)
<elopio> mzanetti: how would you do it without helpers?
<mzanetti> as I said, I agree now that we need those helpers
<mzanetti> let me check the code again
<elopio> ahh, sorry.
<elopio> mzanetti: I got it backwards :)
<mzanetti> elopio: ok... so your problem now is that the test for the helpers (not the actual full stack test) is using the real scope backend instad of some mock, right?
<mzanetti> tsdgeos: do we have any mocks for scope backends yet?
<tsdgeos> we do
<mzanetti> for which ones?
<tsdgeos> ./mocks/Unity/moc_fake_scope.cpp
<tsdgeos> in tests
<mzanetti> ah right, of course
<mzanetti> elopio: so, what you'd need to do is to start unity with the fake plugins for that test
<Saviq> mzanetti, (got busy, but) I think such high level tests deserve a completely separate project
<mzanetti> Saviq: yeah, +1
<mzanetti> meh.. hes gone
<mzanetti> elopio: welcome back :)
<mzanetti> elopio: how far did you follow?
<elopio> sorry
<elopio> [09:41:32] <mzanetti> Saviq: yeah, +1
<elopio> that was the latest I got.
<mzanetti> elopio: ah ok. you got everything then
<mzanetti> elopio: so, what you'd need to do is to start unity with the fake plugins for that test
<mzanetti> this is the bottomline
<elopio> mzanetti: yes, I want that!
<elopio> do you know how to do it?
<mzanetti> elopio: you can do this by exporting an env var before starting unity
<mzanetti> iirc its LD_LIBRARY_PATH
<elopio> :D:D:D
<mzanetti> or QML2_PLUGIN_PATH
<elopio> I thought I would be stuck with this for a couple of weeks :D
<mzanetti> check out run.sh
 * elopio checks.
<mzanetti> elopio: so if you just run ./run.sh, then you'll have those fake backends
<mzanetti> elopio: autopilot should normally _not_ use them.
<mzanetti> elopio: but your case makes a valid exception
<elopio> ok, I'll play with it and be back with the branch finished probably tomorrow.
<mzanetti> elopio: please add comments on those tests on why you do "unit tests" with autopilot
<elopio> mzanetti: I'll try to explain what I explained to you in test_emulators.py, sure.
<elopio> Saviq: can you please explain to me what's the dash tool? It sounds like something I will enjoy.
<Saviq> elopio, you'll be able to tweak the display of the scopes live
<Saviq> elopio, and then paste the result into your $scope
<elopio> Saviq: is that something for users, or for developers?
<Saviq> elopio, scope developers
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bad_loop_dash_test/+merge/201802
<elopio> I need help again.
<elopio> when we run the tests from jenkins, will that builddir exist?
<elopio> or are we just running from the installed deb?
<tsdgeos> i think we run them on compile time
<tsdgeos> but not totally sure
<elopio> I'll just mark the branch as ready to review to see if jenkins complaints.
<bregma> Saviq, I finally got Unity8 not crashing on Mir on the desktop, but I get 'file:///usr/share/unity8/Shell.qml:20:1: module "Unity.Application" is not installed' ... where should this be pulled from (assuming no fake env)?
<seb128> bregma, hey, could somebody look at https://launchpadlibrarian.net/162536013/buildlog_ubuntu-trusty-ppc64el.unity_7.1.2%2B14.04.20131106.1-0ubuntu2_FAILEDTOBUILD.txt.gz ?
<bregma> seb128, I think ChrisTownsend is already on it
<seb128> great
<bregma> https://code.launchpad.net/~townsend/unity/fix-zeitgeist-build-failure/+merge/201791
<seb128> bregma, ChrisTownsend: thanks
<tsdgeos> bregma: isn't that unity-mir?
<tsdgeos> bregma: Unity.Application i mean
<bregma> tsdgeos, I dunno, that's why I'm asking
<tsdgeos> bregma: should be
<tsdgeos> bregma: do you have unity-mir installed?
<bregma> tsdgeos, hmm, doesn't look like it
<tsdgeos> get it then
<bregma> if it's required, shouldn;t it be a package dependency?
<bregma> ah, I see the binary package name is libunity-mir1, it's already installed
<bregma> fingers point at the usual suspect of assuming an Android/Linux system
<tsdgeos> i guess
<karni> tsdgeos: Do we want a minimumColumnWidth property for VerticalJournal? It's not always the case that if dev sets maximumNumberOfColums in ResponsiveVerticalJournal to 100 - that it actually makes sense, right? What should be the sanity measure?
<bregma> is there an environment variable that needs to be set to make Qt pick up a nonstandard plugin path?
<karni> tsdgeos: a fixed minimumColumnWidth?
<tsdgeos> bregma: QT_PLugIN_PATH and loads of otehrs, depend of what you want to do
<bregma> it's a start
<karni> tsdgeos: Honestly, I'm having a problem coming up with formula for case when the no. of visible columns should actually be smaller than maximumNumberOfColumns set. Does that make sense?
<tsdgeos> karni: i think that if someone wants to shoot himself on the foot
<tsdgeos> it's his fault
<karni> tsdgeos: That makes my life easier, lol ;)
<karni> Guess thats' too much thinking on my end. Aight.
<tsdgeos> bregma: there's also QML_IMPORT_PATH i think is called
<tsdgeos> bregma: what are you trying to do?
<bregma> tsdgeos, I am trying to get a Unity8 user session running on the Ubuntu Trusty desktop, as part of the ongoing convergence effort
<tsdgeos> bregma: sure, i mean right now, what plugin you want to force?
<bregma> tsdgeos, I want to get the Unity.Application to be found ...  I recall having to set the environment variables before
<tsdgeos> bregma: if it's installed in usr/lib/*/qt5/ you should not need to set anything
<tsdgeos> it's just picked as the other billions of plugins we use
<karni> tsdgeos: I see your verticaljournal in its full glory. Success :) Thank you!
<bregma> well, QML_IMPORT_TRACE will give me data
<tsdgeos> karni: cool
<tsdgeos> dandrader_: seen the misc fixes branch for the journals?
<bregma> well, the magic incantation is QML2_IMPORT_PATH=/usr/lib/x86_64-linux-gnu/qt5/imports/Unity-Mir ... which means arch-specific config files hashtag sadface
<bregma> but at least I now get a purple box in the lower left corner of my screen when loggin in to unity8 on the desktop
<bregma> on to the next great adventure
<bregma> ah, so my new problem is that all the shaders are failing to compile, such fun, wow, very setback
<bregma> anyone have any clue about QOpenGLShader in the Unity8 stack
<bregma> ?
<dandrader> bregma, you might have better luck asking in #ubuntu-mir. guys there know much more about GL stuff (even if they lack in Qt knowledge)... and there's a GL debug log object in Qt you could use to get a hint of what's going on the GL side
<dandrader> namely QOpenGLDebugLogger
<dandrader> so hopefully an error message will show up in there
<bregma> dandrader, it's obvious why the shaders aren't compiling, I need to figure out where the shaders come from and why the wrong ones are being picked up by Qt ...  probably another environment variable needs to be set somewhere
<dandrader> ah ok
<elopio> mzanetti: still around?
<mzanetti> elopio: yep
<elopio> mzanetti: the mock is using the generic DashPreview instead of AppPreview. How can I change that?
<mzanetti> elopio: hmm... I think you'd need to create a new one. but I'd need to look it up myself
<mzanetti> let me just finish this task here and I'll have a look
<elopio> mzanetti: yes, thanks, because I have no idea how to create one.
<bregma> ah, OK, my problem is that Qt5 is built on desktop to always assume an OpenGL context, and the quubuntu project used in Unity8 forces an OpenGL|ES context, giving a fundamental impedence mismatch
<bregma> so Qt itself feeds GLSL into GLSL|ES and everyone ends up unhappy and eating ice cream from the bucket
<mzanetti> elopio: hi. I have time for you now
<mzanetti> elopio: so, I see there is already a fake_application_scope
<elopio> mzanetti: yes, I'm using it right now.
<elopio> the thing is that it's not using the right preview.
<mzanetti> elopio: mhm... that seems to be a bug
<mzanetti> probably in the fake scope, as it does work in the real thing
<elopio> mzanetti: a bug on the fake?
<elopio> yeah, the real thing is using AppPreview.
<mzanetti> let me check how we determine which preview to use
<mzanetti> elopio: hmm... seems that DeeModel which is created lacks some inforamtion about rendererid and contentType
<elopio> mzanetti: which file are you looking at? I didn't even could find the fake source code.
<mzanetti> elopio: tests/mocks/Unity/fake_applications_scope.cpp
<mzanetti> so far I have no idea where that DeeModel is filled
<elopio> mzanetti: alecu might be able to help us with this.
<elopio> he's having lunch though.
<elopio> mzanetti: I'm not sure if you are close to EOD, but please don't stay just for me, we can continue tomorrow.
<mzanetti> elopio: no worries....
<mzanetti> elopio: got it
<mzanetti> elopio: tests/mocks/Unity/fake_preview.cpp
<mzanetti> elopio: in there is a method rendererName()
<mzanetti> elopio: it always returns generic-preview
<mzanetti> elopio: the proview is created in in tests/mocks/Unity/fake_scope.cpp line 50
<mzanetti> elopio: try doing something like if (m_id == "applications.scope") { preview->setRendererName("preview-application"); }
<mzanetti> that should do I hope
<elopio> mzanetti: let me try that.
<alecu> hi mzanetti, elopio: anything I can help with?
<mzanetti> alecu: hi. I think we found everything
<alecu> great
<mzanetti> elopio: does it work?
<elopio> mzanetti, alecu, sorry, some real life stuff came up.
<elopio> mzanetti: I don't really now where should I put that code.
<elopio> I don't see any preview variable in the Scope.
<elopio> and there's one inside the connect statement, but  p->setRendererName says there's no setRendererName member.
<elopio> I'm sorry, this is the first line of c++ code I've written in like 5 years :)
<mzanetti> :)
<elopio> mzanetti: what about this? http://paste.ubuntu.com/6757904/
<elopio> it works, but is that good c++ code?
<mzanetti> elopio: hmm... might work... but not nice
<mzanetti> one sec, I'll push something for you
<elopio> yeah, I bet I need more patience than what you thought first when volunteering to help me :D
<elopio> well, at least I made it work.
<mzanetti> elopio: do you have a branch where you push this stuff?
<mzanetti> ah this one https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
<elopio> mzanetti: that one, yes.
<mzanetti> elopio: https://code.launchpad.net/~mzanetti/unity8/fake-application-previews/+merge/201836
<elopio> mzanetti: so simple :D thank you very much.
<mzanetti> no
<imlostbro> I'm having trouble getting 'Details' to open in System Settings. Nothing pops up and when I go to Task Manager, I see gnome-control-center gradually hogging up ram. Does anyone know a fix??
#ubuntu-unity 2014-01-16
<tsdgeos> mzanetti: ping
<tsdgeos> mzanetti: goint to need a qmluitests VM detached when you have time to try to repro that test that is now suddenly blocking us from out of the blue
<mzanetti> tsdgeos: hey
<mzanetti> tsdgeos: I'll get you the vm now
<tsdgeos> tx
<mzanetti> tsdgeos: ps-trusty-server-amd64-1 it is
<mzanetti> kgunn: o/
<tsdgeos> tx
<kgunn> mzanetti: \o yo!
<mzanetti> kgunn: fixed the last glitches
<kgunn> cool...i'm all set up...i'll resync this afternoon
 * tsdgeos does the evil eyes at Saviq
<tsdgeos> :D
 * tsdgeos does the evil eyes to himself
<tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/fix_test_dash_shown/+merge/201899
<mzanetti> :D
<tsdgeos> mzanetti: you can bring back the vm to the pool
 * mzanetti wonders why tsdgeos doesn't do the evil eyes to him
<mzanetti> vm is back in pool
<tsdgeos> mzanetti: you didn't do nor review the change, no?
<mzanetti> ah right... no, I didn't do that change
<tsdgeos> you're saved from evil eye-ing
<Saviq> tsdgeos, uh oh, sorry
<tsdgeos> Saviq: there's a few more checks against undefined that should be probably null
<tsdgeos> but they are == or != and that still works
<tsdgeos> it's === or !== that doesn't
<mzanetti> tsdgeos: hmm... but how could this have gotten merged? I mean, shouldn't those tests have failed already with the bad commit?
<tsdgeos> mzanetti: because it's a timing thing
<mzanetti> ah
<tsdgeos> that function there
<tsdgeos> checks that everything we're going to need is loaded
<mzanetti> oh, I got it
<tsdgeos> by making sure they are there
<tsdgeos> i guess we were unlucky and the merge ran on a fast machine :D
<mzanetti> yeah, the vm's performance is quite variable depending on how many jobs are running
<seb128> MacSlow, hey, could you review https://code.launchpad.net/~sam92/notify-osd/focusfollowdefault/+merge/198541 as well?
<mzanetti> greyback: hi
<mzanetti> greyback: just merged trunk and as I feared,everything broke badly
<mzanetti> TaskController::startApplication appId='dialer-app' FAILED
<mzanetti> Asking Upstart to start application 'dialer-app' failed
<mzanetti> any idea? ^
<mzanetti> greyback: if I try for a second time it crashes: (null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Name "com.ubuntu.Upstart" does not exist
<MacSlow> seb128, ok
<seb128> MacSlow, thanks
<MacSlow> seb128, but mpt also approved it already... but it's good to go from my side too
<MacSlow> seb128, I can top-approve it
<MacSlow> seb128, done
<seb128> MacSlow, thanks
<mzanetti> greyback: forget about the above... no idea what went wrong, now it works - sorry about the noise
<Saviq> mzanetti, hey, you happy to show what you have for right edge?
<mzanetti> Saviq: yip yip
<Saviq> mzanetti, what do I do?
<mzanetti> Saviq: when did you last flash your phone?
<mzanetti> Saviq: do you already have the sidestage code from ricmm on your device?
<Saviq> mzanetti, I don't think so, checking
<Saviq> I'm at image 127
<mzanetti> Saviq: hmm.. no idea which one that is
<mzanetti> Saviq: better flash it with a fresh one to be on the save side
<Saviq> mzanetti, 0.2+14.04.20140108.1-0ubuntu1
<Saviq> mzanetti, will do, thought it was "you should have an old one"-type of a problem
<mzanetti> Saviq: I just merged everything with trunk
<mzanetti> Saviq: if your image is an older one you could use my branches before the "merge trunk" commit
<Saviq> mzanetti, upgrading now
<mzanetti> ack
<mzanetti> Saviq: so, you need this branch: lp:~mzanetti/unity-api/new-screenshot-and-focusing-api unity-api
<mzanetti> it's enough if you copy the Application*.h files to /us/include/...
<mzanetti> then you need this one: bzr branch lp:~mzanetti/unity-mir/screenshotting-focusing-api unity-mir
<mzanetti> need to compile + install
<greyback> mzanetti: hey, sorry was away, that error sounds like upstart broke a bit, as that message says the dbus message to upstart failed to send
<mzanetti> and then this one: bzr branch lp:~mzanetti/unity8/appmanager-rework
<mzanetti> you can run_on_device this one ^
<mzanetti> greyback: no worries. I still don't know what happened, at some point it was working again... the first 2 reboots I always got this error
<mzanetti> greyback: but can't reproduce it any more. so everything fine I guess
<greyback> mzanetti: I had it once before too
<Saviq> ricmm_, greyback https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1269414 you saw that?
<ubot5> Ubuntu bug 1269414 in unity-mir (Ubuntu) "Sound is cut when another application is launched" [High,Triaged]
<Saviq> tsdgeos, mzanetti, can you please do https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/201817 ?
<Saviq> we should add an ap test for that...
<mzanetti> Saviq: ack
<kgunn> greyback: so i was trying to build unity-mir on my device...which i did yesterday, i just updated
<kgunn> the branch....but now, when i hit qmake...it spews the help
<kgunn> seemingly
<kgunn> ever seen this
<ricmm_> kgunn: migrated to cmake
<ricmm_> build with dpkg
<kgunn> thanks
<greyback> yeah, we switched to cmake
<greyback> need to see if I can X-compile it now
<mzanetti> greyback: if you manage to, let me know
<mzanetti> last time I tried click chroot didn't like my system at all
<greyback> mzanetti: will do
<Saviq> mzanetti, FOOK 6k diff? think we could split it up in smaller chunks?
<mzanetti> Saviq: no
<Saviq> :/
<mzanetti> Saviq: and it'll get about double the size
<mzanetti> Saviq: because we're not supposed to break anything
<mzanetti> Saviq: so the new sidestage has to be in this too
<mzanetti> Saviq: but most of it is dropping old FIXME's :)
<Saviq> mzanetti, we're hammering out the side stage case this week, too, so hopefully there will be direction (or there might be an interruption anyway)
<mzanetti> Saviq: yeah, I heard. vesar is busy prototyping it. looking forward to it
<tsdgeos> mzanetti: you doing mterry's review, then, right?
<mzanetti> tsdgeos: yes, can do
<mzanetti> Saviq: where did you see a 6k diff btw?
<Saviq> mzanetti, unity8
<mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/appmanager-rework/+merge/199815
<mzanetti> 1.5, no?
<Saviq> mzanetti, against your branch
<Saviq> mzanetti, hmm wait
<Saviq> mzanetti, merged on wrong branch
<Saviq> mzanetti, 1.5k is fine
<mzanetti> Saviq: yeah. it's ok. so this is only the Phone stuff... the tablet will come in with another 500 - 1000 lines approx
<mzanetti> Saviq: does it work?
<Saviq> mzanetti, not yet, couldn't cross-build :/
<tsdgeos> noOoOOoOoO
<tsdgeos> whitespace
<tsdgeos> :D
<tsdgeos> Mirv: if you have not started a qtdeclarative rebuild
<tsdgeos> you want to include this one
<tsdgeos> Mirv: https://codereview.qt-project.org/#change,75689
<Mirv> tsdgeos: ok. well I "started" but KDE is eating all the builders so it has not started yet. reuploading with that added.
<tsdgeos> Mirv: awesome, it should fix that crash in i386
<Mirv> tsdgeos: do you have qtdeclarative release branch git checked out? could you check if I should update from the cb78684ae or if the 10 commits on top of that are not crucial? like by looking at the commit descriptions.
<Saviq> xnox, hey, something changed and Qt cmake modules are not found any more when cross-building :/ any idea?
<tsdgeos> Mirv: sure, let me check
<Mirv> to me maybe thiago's d580411ca looks important, but not much else
<Mirv> on the other hand if it doesn't look too important, it shouldn't hurt either...
<tsdgeos> Mirv: 2f9099443d9acd6583e92785afbb38b2e4dcbfd5 looks like something we want to have (no clue what it does but sounds complicated, i.e. could break/fix stuff :D)
<tsdgeos> Mirv: if updating to current tip of release is not hard i'd do it
<Mirv> ok then :)
<Saviq> mzanetti, ApplicationImage.qml: File not found?
<Saviq> damn ^W
<mzanetti> salem_: where do you get this?
<mzanetti> Saviq: ^ (sorry salem_)
<Saviq> mzanetti, hmm it didn't build, let me
<Saviq> mzanetti, ah that's "real" u8
<mzanetti> Saviq: ?
<Saviq> mzanetti, distro u8 with new libunity-mir1
<Saviq> mzanetti, so makes sense
<mzanetti> ah ok, yeah
<mzanetti> I dropped AplicationImage.qml
<Saviq> mzanetti, yup
<mzanetti> Saviq: btw... u8 trunk won't start with my libunity-mir, which causes libhud to go to 100% cpu
<Saviq> mzanetti, mhm
<mzanetti> Saviq: so make sure to reinstall unity-mir from the repo before leaving the device unattended for a while
<mzanetti> or it'll get hooot
<Saviq> mzanetti, :)
<mzanetti> actually I should file a bug about it
<cwayne> Saviq: ping: are we eventually planning on having the unity automatically detect the screen resolution settings? or will we always need to drop a file in /etc/ubuntu-touch-session.d/?
<Saviq> cwayne, you mean DPR / GRID_UNIT_PX?
<cwayne> yeah, specifically GRID_UNIT_PX
<Saviq> cwayne, those are arbitrarily set, so AFAICT there will always be a per-device file there
<Saviq> cwayne, 'cause it's not really DPI
<cwayne> right, i was worried about that :)
<cwayne> Saviq: where are those files actually read?
<cwayne> i.e. is it just unity8 that actually reads the contents of those files?
<Saviq> cwayne, no, it's being exported in the session I think
<Saviq> mzanetti, can't launch apps, and run_on_device complains about pkilling processes that're not running?
<Saviq> mzanetti, ah wait, got dialer
<Saviq> mzanetti, what's the chopping at the top?
<Saviq> mzanetti, is the "I can swipe enough to go back to the app when reached the end of the stack?
<Saviq> +designed behaviour?
<mzanetti> Saviq: no. that's todo still
<mzanetti> Saviq: design is not exactly sure yet where the point of no return shall be
<Saviq> mzanetti, you mean todo to fix?
<Saviq> mzanetti, ok, how do we fix the cropping?
<mzanetti> Saviq: what cropping?
<Saviq> mzanetti, - yOffset is not needed any more
<mzanetti> ?
<Saviq> mzanetti, application.cpp in libunity-mir
<Saviq> mzanetti, the screenshots coming from mir are now the actual size of the surface
<mzanetti> Saviq: re launching of apps: currently you need to launch apps with the launcher as we didn't merge the fix to unity-scopes yet
<Saviq> mzanetti, 'stood
<mzanetti> Saviq: I don't see any cropping
<Saviq> mzanetti, merge trunk libunity-mir
<Saviq> mzanetti, you'll see it
<ricmm_> Saviq: hi
<Saviq> ricmm_, FUCK OFF
<mzanetti> again? I did that today already
<mzanetti> damn. conflicting again
<ricmm> so yea yOffset is not needed as app buffers are now the size of the render area requested
<ricmm> in accordance to the available geometry in the selected stgage
<Saviq> ricmm, in the selected what?\
<ricmm> Saviq: sthfgage
<Saviq> stg007Fage
<Saviq> mzanetti, you're being missed here
<mzanetti> am I? why is that?
<Saviq> mzanetti, just because ;D
<Saviq> mzanetti, it's late, I didn't sleep much, hungover, don't listen to me ;D
<mzanetti> is the beer any good down there?
<mzanetti> lol. do you have the drunken voice again?
<Saviq> mzanetti, it's *CHEAP* to start with
<Saviq> not any more ;) that was Monday :D
<mzanetti> :D
<Saviq> mzanetti, a pound a beer, 3-course dinner with a bottle a wine a head, 16 pounds
<ricmm> Saviq: hi
<Saviq> and they give you half a cow
<Saviq> ricmm, FUCK OFF
<Saviq> ââ he's sitting ââ
<ricmm> o/
<mzanetti> :D
 * mzanetti just realizes that the app suspend whitelist will mess with the screenshot stuff we're doing
<mzanetti> i.e. the screenshots are most likely always outdated
<ricmm> oh not at all
<ricmm> it still takes screenshots of suspended app's buffers
<ricmm> and technically the app wont have changed if its suspended
<mzanetti> yeah, but the app is not suspended so it will change after the screenshot has been taken
<mzanetti> that's what I mean... the whitelist
<ricmm> oh the whitelist
<ricmm> sorry
<mzanetti> np
<Saviq> mzanetti, the two last (bottom ones) screenshots get swapped sometimes
<Saviq> mzanetti, you know about that?
<ricmm> so the whitelisting is a hack
<mzanetti> Saviq: yep... that will implicitly be fixed with the point of no return
<ricmm> lets not write special code to support that outdate screenshot of music app
<ricmm> ultimately it wont use whitelisting
<Saviq> mzanetti, ok
<ricmm> but the media hub
<mzanetti> ricmm: ack
<Saviq> mzanetti, lookin' good!
<mzanetti> Saviq: nice :)
<Saviq> mzanetti, noticed that fullscreen apps might need to be handled differently
<Saviq> mzanetti, or are we not meant to put the toolbar on them?
<mzanetti> Saviq: yeah, that's one of the questions I had for design
<mzanetti> they don't know a solution yet
<mzanetti> the prototype and mocks only dealt with non-fullscreenones
<Saviq> mzanetti, no I mean that weren't we supposed to put the panel on the non-fullscreen ones?
<mzanetti> Saviq: hmm... dunno. I'd think that looks weird, but who knows. maybe that'll be designs answer
<Saviq> mzanetti, we will probably have to "composite" the OSK on the apps anyway
<mzanetti> well, it solve some more issues tho
<Saviq> mzanetti, yeah, and I thought videos were doing that (panel)
<mzanetti> yeah, martins videos did
<mzanetti> Saviq: vesar's prototype doesn't
<Saviq> mzanetti, I think the video is more of what we  should be looking at, but yeah a confirmation is needed
<mzanetti> hmm... no that was the mistake I did at first... I implemented the video while the prototype is the one where the changes from the reviews are in already
<mzanetti> but we'll see... I have another design feedback call either today or tomorrow - depending on how busy things are on the southern hemisphere
<Saviq> mzanetti, right, visual vs. behavioral
<Saviq> mzanetti, great
<mzanetti> but overall it's quite cool isn't it?
<mzanetti> makes the right edge so much more useful
<mzanetti> Saviq: I merged with trunk again, still nothing clipped off
<Saviq> mzanetti, there's been changes to platform api and qtubuntu that changed that
<mzanetti> ah...
<Saviq> mzanetti, so apt-get update/upgrade should show you that
 * mzanetti wishes he waited for another hour with the whole updating/merging thing :D
<Saviq> mzanetti, conflicts?
<mzanetti> yeah, lots of them
<Saviq> :/
<mzanetti> but merged already... just seems I'm not up to date again
<mzanetti> still good after an upgrade... /me tries dist-upgrade
<mzanetti> nope, nothing in there
<mzanetti> Saviq: did you manually install something on top? ^
<karni> Hey guys. Is the Y axis in Qt layouts pointed downwards from upper left corner, or upwards from lower left? I seem to be calculating correct values for vertical journal row spacing, but with the opposite sign. second.y - (first.y + first.height)
<mzanetti> karni: 0, 0 -> upper left
<karni> mzanetti: Thank you
<Saviq> mzanetti, no, I flashed latest trusty-proposed and installed your unity-mir, built unity8
<mzanetti> strange... looks fine here
<karni> Saviq / tsdgeos: https://code.launchpad.net/~unity-team/unity8/new-scopes-vj-integration/+merge/201932
<karni> tsdgeos: Thank you for your e-mail :)
<tsdgeos> karni: no worries
 * karni already notices copyright header wrong year heh
<tsdgeos> :D
<Saviq> karni, measuredTwoLinesHeight â out
<karni> Saviq: ow WOW sorry, that wasn't supposed to land there. yes, we talked about it
 * karni removes
<Saviq> karni, no worries
<Saviq> karni, I'd also s/columns/maxColumns/ probably
<karni> Saviq: The thing is, that's useful for ResponsiveGridView. In this case, we never make the number of columns less than "columns" set, because of large column spacing or other factors.
<karni> Saviq: That's why I thought naming it just columns would be more appropriate, as it always matches maxColumns. Thoughts?
<Saviq> karni, not sure I followed
<karni> Saviq: ResponsiveGridView - when you set maxColumns = 1000, it may happen number of columns will end up 23, because of delegate item with and column spacing
<Saviq> karni, yup, why is here different?
<karni> Saviq: in ResponsiveVerticalJournal - whatever you set the columns (i.e. maxColumns) value, that WILL always be the value of columns
<Saviq> karni, ah
<Saviq> karni, I don't think that should be the case
<karni> That's where my question came from if we shouldn't limit the number of columns from arbitrary values
<Saviq> karni, the number of columns should be dynamic
<karni> in which case I'd agree we should name it maxColumns instead
<Saviq> karni, we *know* the size of the cards (so column width)
<Saviq> karni, what we don't know is spacing or column number
<karni> hrm
<karni> I ended with conclusion we don't know delegate size, but what you're saying makes sense.
<Saviq> karni, we do
<karni> That'll need fixing, and with that, columns -> maxColumns makes sense
<Saviq> karni, it's small, medium or large
<karni> correct
<karni> my bad!
<Saviq> karni, no worries
<karni> Saviq: -> Needs fixing :)
<tsdgeos> karni: https://code.launchpad.net/~aacid/unity8/journal_misc_fixes ?
<Saviq> karni, done
 * karni looks
<tsdgeos> since daniel is back pained
<tsdgeos> i'll let you review it
<tsdgeos> who reviews https://code.launchpad.net/~aacid/qtubuntu-camera/no_priv_headers/+merge/201933 now that gusch is gone?
<tsdgeos> Mirv: âââ
<tsdgeos> sil2100: âââ ?
<tsdgeos> rsalveti: ââââ ?
<Saviq> tsdgeos, start with bfiller
<karni> tsdgeos: Jenkins failure is expected on that branch, right?
<Saviq> karni, one interesting thing to know would actually be whether cards should be resized or spaced out
<tsdgeos> karni: i retriggered the build
<tsdgeos> we have a pretty bumpy CI
<karni> tsdgeos: approved
<karni> Saviq: Correct, I came through that, gave it all much thought. Should I consult Katie?
<dednick> anyone know if it's possible to detect a click on a qml area, but not consume the events for it? ie. it gets passed still gets passed on.
<tsdgeos> dednick: MouseArea has a property for that afair
<karni> dednick: perhaps http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-mousearea.html#propagateComposedEvents-prop
<sil2100> tsdgeos: right, bfiller is the right person, but I guess I can take a look at this as well
<dednick> i've tried, but seems to get messed when there are mouse areas at a different/deeper parent level...
<mzanetti> Saviq: added the "point of no return" as I think it makes sense. fixes the weird flipping issue you had
<tsdgeos> dednick: standup?
<dandrader> tsdgeos, still no feedback from design regarding half-filled organic grids/
<dandrader> ?
<tsdgeos> dandrader: nope :_/
<tsdgeos> Saviq: can you get katie to answer the email we sent?
<tsdgeos> mzanetti: you're preview man? you doing https://code.launchpad.net/~diegosarmentero/unity8/purchase-service/+merge/201807 ?
<dandrader> tsdgeos, or I would exercise common sense and do what gallery does
<mzanetti> tsdgeos: ack
<tsdgeos> dandrader: ok, let me finish what i'm doing and i'll have a look at what the galllery does
<elopio> good morning everybody.
<elopio> I now need help with the cmake task to install the fake scopes and previews. Can somebody help me?
<mzanetti> mterry: hey, would you agree that an AP test makes sense here? https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/201817
<mterry> mzanetti, uh, sure.  The bug I fixed I don't think needs it (because the bug is in how we respond to events from upstart), but that code in general could use it (for testing integration boundary with upstart)
<mterry> I'll look at it
<mzanetti> yeah
<mzanetti> mterry: the functionality and the unit test look good to me. I'll approve once we have an AP test. Just drop it into the other app_lifecycle ap tests
<mterry> mzanetti, do the autopilot tests not have an example of locking the screen? ...  I'm not sure how to induce a fake power button press
<mzanetti> mterry: hmm... good question
<mzanetti> mterry: how does it actually work?
<mzanetti> mterry: I remember we were using Qt.KeyPower at some point, but that seems gone
<mterry> mzanetti, how does locking actually work?  we get a signal from powerd that the display setting is changing
<mzanetti> mterry: well, I guess in theory we'd need to change the display setting then
<mterry> mzanetti, seems like something we should mock
<mzanetti> mterry: not really in autopilot tests
<mzanetti> ideally autopilot would not use any mocks at all
<mterry> mzanetti, I get that they are integration tests, but I feel like actually changing hardware settings might be too much?
<mterry> mzanetti, cameras watching the devices and all might not like the screen going out.  Though I suppose it would only be for a moment
<mzanetti> and that's what we're striving for. the only reason we're using some mocks now is because we don't have an applicationmanager for the desktop yet
<mzanetti> mterry: the more I think about it, the more I think we should do that... its the proper thing to do
<mterry> mzanetti, actually change display brightness?
<mzanetti> mterry: yes.
<mzanetti> mterry: anyways, that's not really related to your tests here
<mzanetti> mterry: so why don't you just not unlock it after starting up unity and unlock it directly by starting some other app?
<mterry> mzanetti, well.  That's one test.  That test always worked though.
<mterry> mzanetti, the thing that broke was focusing an already open app while the greeter was up
<mzanetti> ah, I see
<mterry> mzanetti, but...
<mzanetti> hmm... so yes. my opinion is that we shouldn't mock in autopilot tests
<mterry> powerd-cli should be able to futz with screen for us
<mzanetti> yeah, that sounds like the proper thing to do
<elopio> not that anyone was asking, but /me agrees :)
<elopio> mzanetti: can you help me with the installation of the fake scopes ?
<mzanetti> elopio: hi
<mzanetti> elopio: what up? :)
<mzanetti> what exactly do you want to install?
<elopio> mzanetti: I need the scopes to be copied to builddir/install/lib/{arch}/unity8/qml/Unity/
<elopio> but I don't know anything about cmake.
<mzanetti> elopio: afaik they should already be packaged up into unity8-fake-env
<tsdgeos> need to reboot, something broke in here
<elopio> mzanetti: some of them, but not the ones I need.
<elopio> builddir/tests/mocks/Unity has more files than
<elopio> builddir/install/lib/{arch}/unity8/qml/mocks/Unity/
<elopio> so I suppose I'm missing the install function in tests/mocks/Unity/CMakeLists.txt
<elopio> but I don't know what to write in it
<mzanetti> elopio: oh boy... that's going to be tricky now :/
<mzanetti> elopio: so the thing is this:
<mterry> mzanetti, hm.  powerd-cli doesn't let you turn off display, only on.  Do you happen to know a better way?
<mzanetti> elopio: ideally we wouldn't use any mocks at all but we need to for now. that's why we install some of them
<mterry> mzanetti, sorry if you replied, I had connection issue
<mzanetti> elopio: the problem now is, if you just install your mock along with the others it will always be used for all tests
<mzanetti> elopio: so we'd need a way in autopilot to tell which mocks to use and which not
<mzanetti> mterry: no, I didn't reply yet. still thinking about something
<elopio> mzanetti: in this case, I think that's a must. Otherwise, all the tests will access the u1 production servers.
<elopio> mzanetti: we will cover the tests for the real scopes and servers in a different branch.
<mzanetti> Saviq: help me :)
<mterry> mzanetti, no rush, sorry
<elopio> mzanetti: oh, but btw, what you said is doable. We can tell the tests to use just some of the fakes, but for that we would need them to be in a separate folder.
<elopio> I suppose cmake can do that.
<mzanetti> elopio: yeah, cmake can do that
<mzanetti> mterry: really weird... powerd-cli help says <on|dc> and the descroption of that says "Off, On or Don't Care"
<mzanetti> mterry: does that seem like a bug to you too?
<mterry> mzanetti, maybe.  It has always been like that.  There is a documentation bug for certain.  Maybe also a missing functionality bug
<mzanetti> mterry: hmm... interesting... if I manually suspend the screen and then call powerd-cli display on it turns on
<mzanetti> mterry: but as soon as I kill powerd-cli again, it goes off again
<mzanetti> mterry: so off wouldn't work anyways as unity still holds the "on" state afaiu
<dandrader> mzanetti, a powerd-cli command is valid just as long as it's running
<mterry> mzanetti, yeah.  powerd-cli will install an 'on-hold' that goes away when it does
<dandrader> mzanetti, so you have to keep it running in a separate tab/ssh session
<mterry> mzanetti, fair...
<mzanetti> so I guess that architecture doesn't allow an off if someone else holds a on-lock
<mterry> mzanetti, and that's why it doesn't accept off as an argument, sure
<mzanetti> still a doc bug there I guess
<mterry> And yet, the user can press a button and the android drivers deliver a signal to powerd that a screen turn off should happen
<mterry> mzanetti, we could emulate/create that driver event?
<mzanetti> mterry: yeah... either that, or there is some admin mode to powerd where you can kill other locks
<mzanetti> mterry: I guess you need to ask someone from phonedations
<mzanetti> elopio: check out tests/mocks/Unity/Application/CMakeListsts.txt
<mzanetti> elopio: there are to install() statements at the end
<mzanetti> elopio: add the same to tests/mocks/Unity/CMakeLists.txt for the target FakeUnityQml and put some other directory in there
<elopio> mzanetti: let me give it a try.
<mzanetti> elopio: along with that, please group the add_subdirectory() from the top and the bottom of the file
<elopio> np
<elopio> mzanetti: it doesn't work.
<elopio> the libFakeUnityQml.so gets copied to the install lib, but I suppose we are still missing some files.
<mzanetti> elopio: yeah, the qmldir file
<elopio> ah, lets see
<elopio> mzanetti: thank you!
<mzanetti> np
<elopio> now, I think we need to discuss a little more about that never use fakes policy.
<elopio> we are actually aiming at closing external network access from the CI lab, at least for the tests run in merge proposals.
<karni> Saviq: tsdgeos: I sent Katie an e-mail. Without her opinion, I don't know whether I should spread the cards or resize them depending on available space in VerticalJournal. I'll shelve that untill I get a response, and will look into why Scott couldn't surface the summary field in the Card header.
<elopio> so many of the troubles we have now is because we didn't disallowed it when we started writing tests.
<tsdgeos> karni: i think that's on the spec
<karni> "Width of cards is determined by art width."
<karni> sorry, wrong row
<tsdgeos> or was
<karni> "Cards within a category have equal width. Card widths may be one of the 3 pre-defined sizes: S, L or M."
<tsdgeos> i had a question there with an answer
<karni> not much besides that
<karni> oh
<tsdgeos> and i think it was marked as resolved
<tsdgeos> so it's not shown anymore
<tsdgeos> don't know if you can get them back
<karni> Saviq: Do we have revision with old comments of the Future Dash spec? (if you're still around)
<mzanetti> karni: seems he isn't any more. they closed down the location
<karni> mzanetti: ack, np
<karni> tsdgeos: honestly, it it says card widths maybe on of of the 3 pre-defined sizes, I guess I shouldn't resize them, space them out instead
<karni> that would also match the behavior of ResponsiveGridView, I believe
<mzanetti> karni: I'd say yes
<karni> ack
<karni> I just re-read what I wrote. I clearly can't type heh, sorry ;)
<tsdgeos> dandrader|afk: but the gallery does exactly my thing does
<elopio> my branch is ready for review.
<elopio> https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
<elopio> mzanetti: can you?
<mzanetti> elopio: not today any more but I'll get it through the queue
<elopio> mzanetti: that's just fine, thank you.
 * karni is having serious problems finding the delegateWidth of VerticalJournal, since the card-size is defined within the delegate Component
<karni> mzanetti: You EODed yet? If not, maybe you could help me figure out one bit.
<elopio> karni: which one is your team now? unity?
<karni> elopio: Nope, I'm here temporarily, pushing a bit on pieces Phone Delivery needs
<karni> to build scopes for MWC
<karni> I'm enjoying it here :)
<elopio> karni: ah, nice.
<karni> ddd
<dobey> where's the right place to file UX bugs as relates to global menu bar?
<mhall119> Saviq: are all the packaged needed to build Unity 8 on Saucy built and published in the PPA now?
<karni> @all Unity8 won't start with packages installed from demo-stuff PPA: http://paste.ubuntu.com/6764850/
<karni> âââ
 * karni flashed ubuntu-system --channel trusty-proposed -b + demo-stuff setup
<karni>  /usr/lib/arm-linux-gnueabihf/unity8/qml/Unity/libUnity-qml.so: undefined symbol: _ZTIN5unity6scopes12ReceiverBaseE
#ubuntu-unity 2014-01-17
<RAOF> karni: That looks like library version skew.
<RAOF> What's the demo-stuff PPA? It's probably the thing that's broken.
<karni> RAOF: Yes, I'm sure that's the problem ;)
<karni> That's why I raised it, so maybe someone from Unity team will pick it up tomorrow/today morning.
<RAOF> Yeah, looks like something needs a rebuild.
<Saviq> mzanetti, cool, thanks
<Saviq> karni, she's off until Thursday I think
<Saviq> karni, so yeah, it's fine
<Saviq> karni, you can access old comments on gdrive - the comments button will take you to all comments
<Saviq> mhall119, they were, but I had to redo a few things, so they're coming
<Saviq> mhall119, I'm waiting for a new release of unity-scopes-api basically
 * mhall119 hopes Saviq is just starting work, not just ending it
<Saviq> mhall119, I'm in Cape Town, so yeah, just got in
<mhall119> ok, I'll look for the new stuff in ~8 hours then
<Saviq> ricmm, https://lists.launchpad.net/ubuntu-phone/msg04549.html
<didrocks> waow, but people are staring on emails!
<didrocks> ah no, I was thinking it was mine ;)
<didrocks> (see #ubuntu-eng-ci)
<didrocks> Saviq: btw, should we increase the timeout?
<Saviq> didrocks, why?
<Saviq> (you mean the kill timeout?)
<didrocks> Saviq: as you are still seeing corrupted stacktrace
<didrocks> yep
<Saviq> didrocks, it was only corrupted in the jobs before we installed u8-autopilot
<didrocks> Saviq: are you sure? I remember we saw some after this package being installed
<Saviq> didrocks, which were not smashed, but just didn't retrace
<Saviq> didrocks, so what I'm actually thinking is moving it to unity8 itself
<didrocks> Saviq: yeah, I think it's making sense
<Saviq> didrocks, as it only ever changes things when you go "initctl unity8 stop"
<didrocks> I was about to suggest the same :)
<Saviq> which normal users won't do, and if it crashes runtime, it will wait for apport to complete anyway
<didrocks> exactly
<Saviq> didrocks, https://code.launchpad.net/~saviq/unity8/move-upstart-timeout/+merge/202041
<ricmm> greyback: do you know enugh about the OSK controller thing?
<ricmm> need to fix that thing where keyb is the wrong orientation for sidestage apps
<greyback> ricmm: I do. Point me to the bug please
<ricmm> greyback: https://bugs.launchpad.net/ubuntu-keyboard/+bug/1257383
<ubot5> Ubuntu bug 1257383 in ubuntu-keyboard "On tablet; keyboard sideways" [Undecided,New]
<ricmm> old report, but its basically the bug
<ricmm> in sidestage, app thinks its portrait, rotation is set to -90
<greyback> ricmm: yeah. It's actually ubuntu-keyboard issue, shell/unity-mir is not responsible for how OSK draws itself
<greyback> ricmm: so ubuntu-keyboard needs to be made aware of the stage the app is running on. Eeek
<ricmm> greyback: why? cant the keyboard just follow gravity
<greyback> ricmm: it could
<ricmm> it already does for main stage I believe
<ricmm> its just getting confused with what portrait means for sidestage
<greyback> ricmm: now i am too. Did we add a hack to rotate the orientation reported to sidestage apps by 90 degrees at one stage?
 * tsdgeos complains about getting up too early to get an earlier EOD
<ricmm> greyback: none that I remember, but I do know that rotation is reported through the OSK controller
<ricmm> and no longer directly by maliit
 * tsdgeos starts to work
<tsdgeos> Saviq: i did try to test it and did not really succeed but i'll give it another go
<Saviq> tsdgeos, thanks
<tsdgeos> shouldn't be *that* hard since karni was hitting it :D
<greyback> ricmm: it's not. OSKController just waits for ubuntu-keyboard to create a surface, it makes it visible and sets up an InputArea for it. That's all
<ricmm> ok then not osk controller
<ricmm> but that socket based comms that we have
<ricmm> that reports geom
<tsdgeos> karni: there?
<Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity8/bad_loop_dash_test/+merge/201802 works doesn't it?
<tsdgeos> Saviq: sure
<tsdgeos> Saviq: but we don't seem to be hitting the thing it fixes atm
<Saviq> tsdgeos, ok, let's see
<tsdgeos> damn now i can't reproduce the crash in the journals in karni's branch
<tsdgeos> he seems to have changed something else that makes it not happen :/
<tsdgeos> ah good bzr
<tsdgeos> let me go back to the rev it fails
<mzanetti> Saviq: hey, can you check this one? https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
<mzanetti> Saviq: it contains code from me and I guided elopio through this. So I'd prefer having another pair of eyes on it
<mzanetti> anyone up for confirming this? https://bugs.launchpad.net/hud/+bug/1269788
<ubot5> Ubuntu bug 1269788 in Unity HUD "hud-service goes to 100% cpu if unity8 is not running" [Undecided,New]
<tsdgeos> Saviq: added the tests, took me more than expected
<tsdgeos> mzanetti: destkop or device?
<mzanetti> tsdgeos: device
<tsdgeos> mzanetti: so you do /sbin/stop unity8 ?
<mzanetti> tsdgeos: yeah
<mzanetti> tsdgeos: well... I do ./run_on_device
<tsdgeos> :D
<mzanetti> tsdgeos: which stops the service and runs another one. if that one crashes
<mzanetti> then hud-service is stuck at 100%
<tsdgeos> /sbin/stop unity8
<tsdgeos> worked here
<tsdgeos> hud is fine
<tsdgeos> and then starting a new one
<tsdgeos> hud went to 100% briefly
<tsdgeos> but is back at doing nothing
<mzanetti> tsdgeos: hmm... my device is constantly burning here
<tsdgeos> today's image?
<tsdgeos> i'm on yesterdays
<mzanetti> it's happening since weeks already
<mzanetti> at least since a week before xmas
<tsdgeos> 131
<tsdgeos> oh
<mzanetti> tsdgeos: so to be more precise, what I do is this:
<mzanetti> I install my patched libunity-mir
<mzanetti> then stop the installed unity8
<mzanetti> and start my patched unity8
<mzanetti> when I stop my patched unity8, the installed one doesn't start any more because it's not compatible with the installed unity-mir
<tsdgeos> maybe unity-mir patch breaks hud?
<tsdgeos> i mean
<tsdgeos> hud wants some stuff exported by unity-mir
<tsdgeos> and it may get unhappy if we're not providing that
<mzanetti> oh... interesting
<mzanetti> tsdgeos: well, I only added stuff
<tsdgeos> the dbus application stack model thing
<mzanetti> but sure... might cause woes
<tsdgeos> is consumed by hud afair
<mzanetti> mhm... interesting
<mzanetti> tsdgeos: but whenever I start my patched unity8, hud-service goes down to 0
<mzanetti> when I stop unity8 it freaks out again
<Saviq> mzanetti, I probably won't be able to look at it before Monday in over a week
<mzanetti> Saviq: ok, I'll ask someone else
<Saviq> thostr_, mhr3 lunch
<tsdgeos> Cimi: https://code.launchpad.net/~cimi/unity8/fix-1214423/+merge/192868 ?
<tsdgeos> Cimi: dandrader|bbl: https://code.launchpad.net/~cimi/unity8/searchIndicator-swipe/+merge/198258 ?
<tsdgeos> mzanetti: you doing https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718 right?
<mzanetti> tsdgeos: I'm trying to find someone else because it contains code from me and basically I told elopio to do this. So I'd like to have another pair of eyes on it
<mzanetti> tsdgeos: can you?
<tsdgeos> mzanetti: sure, i'll add me to it
<mzanetti> thanks
<dednick> mzanetti: want to see that solution i came up with for the MouseArea which doesn't consume events? :)
 * mzanetti senses a trap
<dednick> mzanetti: hehe.... it's a bit "interesting"
<mzanetti> sure I want to know :)
<mzanetti> I had this problem quite often already
<dednick> I'll just pastebin the cpp. And it only works for pressed, released, clicked, dblclick at the moment.
<dednick> http://pastebin.ubuntu.com/6767344/
<mzanetti> for example it would allow me to get rid of a workaround in the right edge thing
<mzanetti> ah ok...
<mzanetti> well sure... if there is a proper way to do it, I guess this is it
<mzanetti> dednick: so this first evaluates the qml code inside the PassthroughMouseArea. if there is accepted == true it behaves like a regular mousearea, right?
<mzanetti> dednick: if accepted == false, it still keeps on getting the following events, but they are additionally re-injected into QCoreApplication
<mzanetti> am I reading this correctly?
<dednick> mzanetti: if accepted==true (ie the PassthoughtMouseArea was pressed), then it re-sends the mouseevent through core application
<dednick> mzanetti: but it bypasses this mouseArea, because m_enabledEvents==false now.
<mzanetti> ah... 'cause if accepted == false, the MouseArea itself forwards it already... got it
<mzanetti> dednick: hmm... will this land in unity8 anytime soon?
<mzanetti> that would really solve the one dirty workaround I have in the rightedge stuff
<dednick> mzanetti: er. maybe. there's a few other branches it depends on.
<dednick> mzanetti: and it's not actually in MP yet.
<mzanetti> ok. no problem. the rightedge stuff is still a bit away too. just let me know when I can start using this please
<dednick> mzanetti: ok.
<dednick> mzanetti: um, what's currently the best way to get a click event through qmltests?
<mzanetti> dednick: huh? mouseClick() ?
<dednick> mzanetti: what about tap?
<mzanetti> dednick: I think everything is converted to a tap internally
<dednick> dont really understand why we have different ones for touch...
<mzanetti> so we shouldn't have different ones in unity
<mzanetti> dednick: dandrader knows all the details though
<mzanetti> dednick: but afaik, if there is a mouse click, the uqmlschene we use for testing should convert it to a tap
<dednick> i c
<dednick> doesnt seem to work.
<dednick> dandrader|bbl: ping when you're back
<mzanetti> dednick: pun intended? :P
<dednick> mzanetti: :)
<dednick> no!
<mzanetti> :D
<karni> tsdgeos: hi :)
<tsdgeos> karni: hi, was nothing, Saviq answered all your questions, right?
 * karni reads e-mail
<karni> tsdgeos: If I understand that correctly, for testing purposes, line 292 [1] is fine, because we're not on the CardVerticalJournal.qml level yet? [1] https://code.launchpad.net/~unity-team/unity8/new-scopes-vj-integration/+merge/201932
<karni> tsdgeos: It seemed strange to me I had to set ResponsiveVerticalJournal's columnWidth and delegate width separately
<karni> If it where in CardVerticalJournal.qml, setting CardVerticalJournal columnWidth would suffice.
<karni> By the way guys, I wrote this here last night, maybe someone can have a look at it:
<karni>  Unity8 won't start with packages installed from demo-stuff PPA: http://paste.ubuntu.com/6764850/
<karni> tsdgeos / Saviq: Would you guys have a moment today to review the merge [1] above? :)
<tsdgeos> karni: i can try having a look later
<karni> tsdgeos: thank you
<karni> tsdgeos: silly question - should this part of code ('category-layout': 'vertical-journal') already work in unity-scope-tool? It shows nothing when I switch to vertical-journal. If it should show stuff, I may have gotten something wrong.
<karni> the try and testResponsiveVerticalJournal work fine
<tsdgeos> karni: if you're not hooking category-layout vertical to the vJournal stuff
<tsdgeos> i'd say no
<tsdgeos> and i don't see you doing it, no?
 * mzanetti needs to leave for an hour and a half. bbl
<karni> tsdgeos: line 160 in qml/Dash/GenericScopeView.qml: case "vertical-journal": return "CardVerticalJournal.qml";
<tsdgeos> i hate it when ctrl+f fails on me :D
 * karni same here ^ ^
<tsdgeos> then i'd say it should workâ¢
<tsdgeos> but i'm not very uptodate in the new scopes architecture
<karni> tsdgeos: ok, I think that might be because CardVerticalJournal is missing: width: template['card-size'] (the GU value of it)
<karni> tsdgeos: I guess not many of us are :D
<karni> super fresh
<Saviq> mzanetti, you're famous now ;)
<Saviq> didrocks, I'm off next week, mzanetti would you like to be our first trained landing engineer in the team?
<didrocks> Saviq: ok, switching place sounds fine, mind forwarding that to mzanetti?
<didrocks> Saviq: he will have to do the paperwork, you win! :)
<mzanetti> Saviq: didrocks: ok...
<mzanetti> Saviq: yeah... didn't expect that much fame :D
<didrocks> mzanetti: did you get the email or should I forward it to you? ;)
<dandrader> dednick, ping
<mzanetti> didrocks: only got the invitation
<dednick> dandrader: howdy. was wondering what the diff is between mouseClick and sending press/release events in qml tests. Seems that click doesnt work with draghandle hinting.
<dandrader> dednick|lunch, dragHandle deals with touch events, not mouse events
<dandrader> dednick|lunch, so you should send a touch tap instead of a mouse click
<Saviq> karni, you haven't assigned the model to ResponsiveVerticalJournal in CardVerticalJournal, or bound CVJ's height to RVJ
 * karni looks
<Saviq> karni, basically because you're not doing DashVerticalJournal, you need to bind much more than you have - see DashFilterGrid
<karni> ack
<Saviq> karni, also, template and components are undefined on ResponsiveVerticalJournal
<Saviq> karni, so            template: cardVerticalJournal.template
<Saviq>             components: cardVerticalJournal.components
<Saviq> is wrong
<cwayne> heya guys, is there a timetable for scopes-as-click-packages
<Saviq> mhr3, do you know anything â?
<mhr3> thostr_, ^^
<karni> Saviq: thostr_: I know it's quite late notice, but would you guys like to hangout later and update us on progress made during the sprint?
<thostr_> cwayne: click packages are planned for 14.04 but not done by mid of Feb meaning won't be available for mwc
<thostr_> cwayne: do you need click package by mid Feb?
<karni> Saviq: I'm processing your comments
<thostr_> karni: I need to leave in couple of minutes for the airport
<karni> thostr_: maybe monday then?
<thostr_> karni: yes, sure
<cwayne> need might be a strong word, but it would certainly simplify things quite a bit for us thostr_
<karni> thostr_: anyway, we'll schedule the meeting
<karni> thostr_: safe flight!
<thostr_> karni: thanks
<Saviq> didrocks, greyback is on the spreadsheet for wave 1, too, and he's off next week as well
<Saviq> didrocks, I think it should be merged into team Unity TBH
<didrocks> Saviq: yeah, I agree, kgunn: are you happy to merge that in the Unity team and only have one lander?
<Saviq> didrocks, kgunn, or we get tsdgeos to be the second one (still, for a single Team Unity)
<elopio> tsdgeos: I updated my MP. Thanks for taking a look.
<tsdgeos> no worries
<karni> Saviq: re: no model in ResponsiveVJ - isn't it set by the user?
<Saviq> karni, the property is set on the top component - DashRenderer
<Saviq> karni, you need to bind it to RVJ
<karni> ack
<Saviq> karni, and probably a few others
<kgunn> didrocks: i'm always happy if Saviq is happy
<didrocks> ok, modifying then, thanks guys
<karni> Saviq: pushed bound properties of CardVerticalJournal top level component. Sadly, I don't know where the template and component values would come from.
<karni> Saviq: If it seems I'm slowing you down, you should tell me :)
<Saviq> karni, they're there on DashRenderer
<karni> oh. I should also create property aliases for 'em?
<karni> Saviq: Conceptually, when someone instantiates CardVerticalJournal -- will they introduce their own delegate? if so, the current delegate in CardVerticalJournal makes little sense
<karni> Or rather, that's just a good default value.
<Saviq> karni, that's the only value, yes
<Saviq> karni, so there should be no "delegate" property on CVJ
<karni> oh
 * karni removed
<karni> Saviq: Card (delegate) expects template and components on ResponsiveVerticalJournal (its parent), would this work then? http://paste.ubuntu.com/6768200/
<karni> Saviq: I don't want to flood you with MP updates..
<Saviq> karni, why do you say it expects it on its parent?
<Saviq> karni, it has those as its own properties
<karni> Saviq: you said it's undefined. should I point the card to the DashRenderer instead?
<karni> Saviq: I'm not sure if I have enough brevity for those final touches :(
<karni> brevity - wrong word heh
<karni> fluency
<Saviq> karni, that's where the values are
<Saviq> karni, so yes, you need: template: genericVerticalJournal.template instead
<Saviq> karni, cardVerticalJournal does not have a components or template properties
<tsdgeos> dednick: standtup
<tsdgeos> nic-doffay_: â
<nic-doffay_> tsdgeos, on my way
<tsdgeos> Saviq: wanna join just to tell us how you're on holiday next week?
<Saviq> tsdgeos, can't
<tsdgeos> Saviq: ok
<Saviq> tsdgeos, not sure I understand your question though ;)
<karni> Saviq: http://paste.ubuntu.com/6768235/ ? :)
<karni> Saviq: seems that's still not sufficient to make unity-scope-tool accept the vertical-journal integration. :S
<Saviq> karni, yes, model and height were not propagated (model down, height up) between DashRenderer and RVj in CVJ
<Saviq> karni, although that wasn't enough either
<Saviq> karni, I can't get much further though
<karni> Saviq: appreciated
<tsdgeos> dandrader: ping
<dandrader> tsdgeos, pong
<tsdgeos> dandrader: i had a look at the gallery
<tsdgeos> and does the same thing i do
<tsdgeos> i.e. the 4 element is put on the bottom row
<dandrader> tsdgeos, well I had a different impression
<tsdgeos> let me do a photo of the phone
<dandrader> tsdgeos, but we can merge it as it is
<dandrader> tsdgeos, and tweak this stuff later
<tsdgeos> now gallery doesn't want to start
 * tsdgeos reboots phone
<tsdgeos> dandrader: got the email?
<dandrader> tsdgeos, yes
<dandrader> tsdgeos, have you tried the situation I explained in my e-mail
<dandrader> tsdgeos, a module with only 2 items
<dandrader> tsdgeos, (e.g. a fully filled module and on its left a module with only 2 items
<dandrader> )
<tsdgeos> on the right?
<dandrader> s/left/right
<tsdgeos> dandrader: karni: can any of you top approve https://code.launchpad.net/~aacid/unity8/journal_misc_fixes ?
<tsdgeos> dandrader: so delete 2 items from the photo i sent you?
<dandrader> tsdgeos, yes
 * karni looks
<tsdgeos> dandrader: ahh
<tsdgeos> right that is different
<dandrader> tsdgeos, aha!
<tsdgeos> i thought you were always speaking of the 4 item configuration
<tsdgeos> not of the 2 item one
<karni> tsdgeos: looks good to me, shall I top approve? In previous teams the propose'er would do that.
<tsdgeos> karni: please
<karni> tsdgeos: done
<tsdgeos> we only top approve our own stuff if autolanding fails because one of the known "unstable" tests
<karni> I see. So the reviewer would top-approve? Also, do you usually seek more than one review?
<tsdgeos> depends
<tsdgeos> i'd say no
<karni> ok
<tsdgeos> it's hard enough to get one to review your stuff :D
<karni> haha
<karni> What's this aboug guys? Unity8 won't start with packages installed from demo-stuff PPA: http://paste.ubuntu.com/6764850/
<tsdgeos> i'd say rebuild needed somewhere
<karni> Is there anyone who could look into that? (/me doesn't know people on the team well, yet)
<tsdgeos> mhr3 or Saviq are the ones that rebuild that ppa afaik
<tsdgeos> saviq is out next week
<tsdgeos> let's hope mhr3 is at work and not touring south africa too
<karni> haha
<tsdgeos> pstolowski: do you know if mhr3 is back next week?
<pstolowski> tsdgeos, he should be, i think so
<tsdgeos> oki
<karni> phew
 * tsdgeos enjoys his early day start with an early eow
 * tsdgeos waves
<tsdgeos> nic-doffay_: see you man!
<karni> o/
<didrocks> mzanetti: if we move the bootcamp to 16 UTC instead of 15 UTC, would that work for you?
<didrocks> (to work a little bit better with the NZ guys)
<mzanetti> didrocks: ok, sure
<didrocks> thanks!
<karni> mzanetti: I learned from omgubuntu about the new app switcher. woot \o/ :) (though, I was bit surprized about the horizontal scroll control, seemed way to responsive/delicate)
<mzanetti> karni: yeah, it's a bit too fast still
<mzanetti> karni: need to tweak the values still
<mzanetti> karni: so, now you know what I'm talking about for days in the standup already :D
<karni> mzanetti: hahahah yeah, from omgubuntu ;D
<karni> mzanetti: looks great
<mzanetti> thanks
<karni> mzanetti: do you know which trusty-proposed revision can I flash to work with demo-stuff ppa? The most recent trusty-proposed just doesn't work with our new stuff.
<karni> mzanetti: you using trusty-proposed, right?
 * karni tries revno 132
<fginther> Saviq, the unity8 otto jobs are failing again with what looks like the same signature, but I've been able to identify a changed dependency that may be the culprit, libunity-scopes0
<karni> fginther: Hey Francis. He may have EOD'ed (haven't seen a while in here, he finished sprint today), he's on holiday next week.
<fginther> karni, thanks. I'll find someone else to ping Monday
#ubuntu-unity 2014-01-18
<Terces> hi there
<Terces> apparently unity interferes with XBMC, but I couldn't find any real information about this on the internet
<Terces> I also didn't find any solution (making it not fullscreen but windowed helped a lot though)
<Terces> apparently you could set in compiz the setting to "un-redirect fullscreen", which seems to have helped people
<Terces> hi everyone
<Terces> after a long night of looking, I found out that the window manager really is messing up with xbmc. I could not find a solution to this. I think the problems arise from Unity trying to "do its thing" on full-screen applications..
<Terces> any help to resolve this would be great appreciated
#ubuntu-unity 2015-01-12
<tsdgeos> an easy one https://code.launchpad.net/~aacid/unity8/removeMouseClick55/+merge/246094
<tsdgeos> any idea why
<tsdgeos> apt-get purge unity8
<tsdgeos> on a phone chroot wants to install what seem like lots of destkop stuff?
<tsdgeos> 0 upgraded, 225 newly installed, 3 to remove and 73 not upgraded.
<tsdgeos> there has to be some meta-package or something pulling them i guess
<tsdgeos> Saviq: sil2100: any idea? â
<Saviq> tsdgeos, ubuntu-touch
<tsdgeos> don't have it in the chroot
<sil2100> tsdgeos: is it really trying to install seemingly desktopish packages? Since on touch we also have a few of those, as they're pulled in by some of our touch components
<tsdgeos> yeah
<tsdgeos> it's trying to install some that aren't even in the repo
<tsdgeos> E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/u/unity-settings-daemon/libunity-settings-daemon1_15.04.1+15.04.20141128-0ubuntu1_armhf.deb  404  Not Found [IP: 91.189.88.140 80]
<tsdgeos> E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/u/unity-settings-daemon/unity-settings-daemon_15.04.1+15.04.20141128-0ubuntu1_armhf.deb  404  Not Found [IP: 91.189.88.140 80]
<tsdgeos> which is my problem basically
<tsdgeos> i wounldn't mind if it installed lots of crap in the chroot
<Saviq> tsdgeos, just remove ubuntu-touch
<tsdgeos> Saviq: it's not there
<tsdgeos> can't remove it :D
<Saviq> tsdgeos, it fails because rtm isn't a complete archive snapshot
<Saviq> tsdgeos, huh?
<tsdgeos> this is not rtm either
<tsdgeos> Saviq: http://paste.ubuntu.com/9717442/
<Saviq> even more huh
<tsdgeos> it's a vivid chroot
<tsdgeos> + landing 5 for qt54
<Saviq> tsdgeos, rdepends of unity8 there?
<tsdgeos> it's kind of long :D
<Saviq> tsdgeos, how did you create the chroot?
<tsdgeos> http://paste.ubuntu.com/9717453/
<tsdgeos> i don't remember tbh
<tsdgeos> i think debootstrap
<tsdgeos> but may be wrong
<Saviq> something you installed manually must've pulled unity8 in and now prevents its removal...
<Saviq> tsdgeos, you might wanna install aptitude and maybe it'll give you a different solution
<Saviq> when purging with it
<tsdgeos> let's see
<tsdgeos> that was better
<tsdgeos> 0 packages upgraded, 0 newly installed, 4 to remove and 73 not upgraded.
<tsdgeos> Saviq: congrats on the fosdem accepted talk btw
<Saviq> tsdgeos, is it difficult to get a talk accepted? :D
<tsdgeos> it depends on how much talks of "your desktop" are presented
<tsdgeos> the desktop room folks do lots of equality hoping so noone gets annoyed that there are too many kde, gnome, qt, glib, unity, whatever talks
<Saviq> hmm so bregma's talk did not get in
<tsdgeos> see it's hard to please everyone :D
<Saviq> will have to sneak some of his things in, then
<Saviq> 30mins starts looking crammed
<Saviq> well, let's see
<alim0x> anyone use docky 3 have shutdown/logout trouble?
<Cimi> mzanetti, on https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400 did you merge trunk?
<mzanetti> Cimi: nope. looking at that now
<mzanetti> Cimi: I've merged trunk and pushed now... lets see what jenkins says. I can't repro the test failure locally
<mzanetti> Saviq: btw, https://code.launchpad.net/~mzanetti/unity8/patched-control/+merge/246105
<mzanetti> oh... saw your comments now
<Saviq> ;)
<Saviq> dednick, the backported prompt suspend branch FTBFS, can you please have a look: https://launchpadlibrarian.net/194604798/buildlog_ubuntu-rtm-14.09-amd64.qtmir-gles_0.4.4%2B15.04.20150112.1~rtm-0ubuntu1_FAILEDTOBUILD.txt.gz
<dednick> Saviq: sure
<Saviq> dednick, that's the silo http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-018
<dednick> Saviq: it seems the prompt stuff didnt go in the backported mir
<Saviq> dednick, that's the backport https://code.launchpad.net/~mir-team/mir/backport-1355173.trust-prompt-suspend/+merge/246024
<Saviq> dednick, and it did build against 0.8.1 (I bumped the required mir version), so they must've b0rked the backport?
<dednick> hm.
<dednick> give me a sec
<dednick> oh right. it's the qtmir which hasnt been ported correctly.
<dednick> Saviq: ^
<dednick> Saviq: want me to fix?
<Saviq> dednick, oh, and it's only the -gles twin that failed...
<dednick> Saviq: hm odd. not sure why it would pass on the normal one. since the same issue exists where the new PromptSessionListener functions are not being defined.
<dednick> according to the diff anyway
<Saviq> dednick, ah no actually it all failed indeed https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-018/+packages
<Saviq> dednick, does the mir backport branch look sane ?
<dednick> Saviq: let me check it again
 * Cimi 's back is not bad today at all, I'm so happy :)
<Saviq> dednick, I've confirmed the backport patch actually *did* make it into the mir tarball (so they must've made it into the packages...)
 * Saviq lost a bit
<Cimi> mzanetti, cool, cause I noticed that on another branch https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/284/?
<Cimi> mzanetti, from https://code.launchpad.net/~aacid/unity8/bottomEdgeArrow1401869/+merge/245721/comments/606990
<Cimi> mzanetti, it might be that the test needs more stability
<Saviq> Cimi, mzanetti, that test should be fixed in the latest trunk, so merging trunk should help
<Saviq> biab
<dednick> Saviq: looks ok as far as i can tell
<tsdgeos> Saviq: sil2100: https://code.launchpad.net/~aacid/unity8/morefpic/+merge/246108
<Saviq> tsdgeos, tx
<tsdgeos> Saviq: i give up on reproducing the autopilot failures, i looped it again and can't get it to fail :/
<Saviq> tsdgeos, ok, thanks
<tsdgeos> Saviq: so what's next for me, want me to try to find out why everything dies when $HOME is full?
<Saviq> tsdgeos, bug #1402597 first I'd say
<ubot5> bug 1402597 in Canonical System Image "unity8 scope shell reboots on twitter trending" [Critical,Confirmed] https://launchpad.net/bugs/1402597
<tsdgeos> sure
<Cimi> my pkgconfig cannot find qtconnectivity1, which I think I installed, which package is that?
<Cimi> libconnectivity-qt1-dev  is missing in my repo
<Saviq> Cimi, looks like your repo is b0rked http://packages.ubuntu.com/vivid/libconnectivity-qt1-dev
<Cimi> Saviq, do you have it?
<Saviq> Cimi, http://archive.ubuntu.com/ubuntu/pool/universe/c/connectivity-api/
<Cimi> Saviq, yeah I downloaded it here, just wondering if your mirror was broken
<Saviq> Cimi, using archive. directly here (well, through a local apt-cacher-ng)
<Saviq> but even if I didn't http://pl.archive.ubuntu.com/ubuntu/pool/universe/c/connectivity-api/
<Cimi> using archive then
<Cimi> ok gb archive had issues...
<Cimi> Saviq, regarding https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1393008 that I am fixing now, what exactly needs to change?
<ubot5> Launchpad bug 1393008 in unity8 (Ubuntu) "Horizontal cards with summary don't get backgrounds" [High,In progress]
<Saviq> Cimi, we lost backgrounds for horizontal cards
<Cimi> Saviq, the only case to add background when is horizontal is ONLY when there is a summary?
<Saviq> Cimi, yes
<Saviq> tsdgeos, FWIW, the failures we get in AP https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/666/artifact/clientlogs/unity8/ seem to be aborts, there's a *lot* of what() messages in the unity8.log, at least one of them probably caused the failed test
<Saviq> I'm thinking this http://pastebin.ubuntu.com/9718242/
<Cimi> https://code.launchpad.net/~cimi/unity8/fix-1393008/+merge/246138
<Cimi> Saviq, that was added from sync notifications
<Cimi> ?
<Cimi> https://code.launchpad.net/~cimi/unity8/fix-1378920/+merge/238012
<Saviq> Cimi, what was added from sync notifications?
<Saviq> Cimi, ah media role, yeah I know
<Saviq> and yeah, that was a red herring :|, fixed in vivid already
<Saviq> argh
<Saviq> greyback, can I ask your assistance, dear sir?
<greyback> Saviq: sure
<Saviq> greyback, the tests in https://code.launchpad.net/~mir-team/qtmir/rtm-14.09-staging/+merge/244580 FTBFS: https://launchpadlibrarian.net/194613324/buildlog_ubuntu-rtm-14.09-amd64.qtmir_0.4.4%2B15.04.20150112.2~rtm-0ubuntu1_FAILEDTOBUILD.txt.gz
<Saviq> greyback, for some reason mirServer is not declared
<Saviq> I imagine something got refactored in trunk that causes the tests to not build in rtm, but can't pinpoint what
<greyback> Saviq: there was a transition mirConfig -> mirServer
<Saviq> greyback, right, I think I see what I've to do now
<greyback> Saviq: lemme know if you'd like a hand
<Saviq> greyback, tx
 * Saviq should've looked at the right source, too
<Saviq> dednick, if you could please have a look at https://code.launchpad.net/~mir-team/qtmir/rtm-14.09-staging/+merge/244580 - I believe this is now complete, it built fine locally, is building now in the PPA
<om26er> Saviq, Hi! I am having a hard time understanding the fix for bug 1384374
<ubot5> bug 1384374 in unity8 (Ubuntu RTM) "Dash pauses/stutters during scope switching left/right" [High,In progress] https://launchpad.net/bugs/1384374
<om26er> what exactly does it fix ?
<om26er> how long of a "pause" was originally seen ?
<greyback> Saviq: my Xcompile chroot is failing this morning with packaging errors: http://pastebin.ubuntu.com/9718446/ . It was working last week. I've updated the base chroot, but still get those errors. Any suggestions?
<greyback> oh feck, I didn't merge trunk
<greyback> same
<Saviq> greyback, the actual errors seem to be the qt packages being "not installable"
<Saviq> greyback, that's vivid amd64âarmhf?
<greyback> Saviq: yep
<Saviq> greyback, lemme try
<greyback> ta
<Saviq> greyback, what I do in a case like this is just manually apt-get install all the dependencies in order and hope that apt will tell me what the actual issue is
<greyback> Saviq: that old chestnut
<tsdgeos> damnit
<tsdgeos> we have some qmluitests faiulres back
 * tsdgeos checks
<tsdgeos> "No item given to waitForRendering"
<tsdgeos> our CI is slower and slower (or so is our code) and 15s is not enough to settle dashContent :S
<tsdgeos> Saviq: should i simply increase that a bit?
<Saviq> tsdgeos, there's also the question of why does the mock dash take so long to load
<Saviq> tsdgeos, I saw during AP tests it takes reaaaallly long
<tsdgeos> ls
<tsdgeos> wops :D
<Saviq> greyback, fwiw, a clean vivid chroot just installed all the deps fine here
<Saviq> just needed to add :native to the cpp dep
<Saviq> let's see if it actually builds
<tsdgeos> yeah even here in my pc it takes 8 seconds for dashcontent to settle
<tsdgeos> seems a bit on the high side
<Saviq> yeah
<greyback> Saviq: ok. thanks for trying
<Saviq> greyback, yeah, and it seems to have completed the build fine
<Cimi> mzanetti, new different fails https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400
<mterry> I don't suppose there is a ddeb server for ubuntu-rtm?
<mterry> oooh, looks like there is
<tsdgeos> yes there is
<mzanetti> Cimi: this isn't related
<Saviq> dednick, so, testing the packages, should I see the trusted prompt SIGSTOP'ed when I unfocus settings with online accounts on top or suspend the phone
<Saviq> ?
<Saviq> because that, to me, is "being part of lifecycle", and it's not happening?
<Saviq> greyback, having tested â, did you check?
<Saviq> (for vivid that is)
<greyback> Saviq: I didn't check that actually. But I had considering trusted prompts to be outside lifecycle control
<Saviq> well, that's what bug #1384950 is about
<ubot5> bug 1384950 in mir (Ubuntu RTM) "Trusted prompts need to be part of the lifecycle" [Undecided,In progress] https://launchpad.net/bugs/1384950
<Saviq> so either that bug is invalid/wontfix
<Saviq> or not fixed
<Saviq> we can say that it's the trusted helper's responsibility, but we need to say that :)
<greyback> Saviq: the patch doesn't address that bug. The patch prevents trust sessions being stopped when unfocused
<Saviq> greyback, not according to https://bugs.launchpad.net/ubuntu/+source/trust-store/+bug/1384950/comments/6
<ubot5> Launchpad bug 1384950 in mir (Ubuntu RTM) "Trusted prompts need to be part of the lifecycle" [Undecided,In progress]
<greyback> Saviq: well then I misunderstood the point of the work
<Saviq> greyback, well, no, the work was important for the other bug in any case, but might've been incorrectly linked to that bug is all
<greyback> Saviq: need dednick to clear it up then, as I'm not sure what the Mir prompt session internals actually do
<Saviq> greyback, not much, just notify the other side
<greyback> Saviq: then yeah, need to figure out how to do lifecycle of trusted prompts. AFAIK they're not managed by upstart, so are not in a cgroup. sigstop/cont a bit lame, especially as many use oxide
<Saviq> greyback, yeah, which is why I'm actually leaning to say that it's the helpers' responsibility
<Saviq> greyback, have asked for The Architect's opinion
<dednick> Saviq: we dont control the lifecycle directly
<dednick> sorry, engineer is here screwing with phone line
<dednick> Saviq: we just notify. other side decides what to do
<dednick> so each helper needs to be sorted out
<Saviq> dednick, ok, that makes sense probably
<dandrader> Saviq,  got this when trying to build unity8/shellRotation after merging with trunk:
<dandrader> """
<dandrader> The following packages have unmet dependencies:
<dandrader>  pbuilder-satisfydepends-dummy : Depends: g++-4.9:native which is a virtual package.
<dandrader> Unable to resolve dependencies!  Giving up...
<dandrader> """
<Saviq> dandrader, mzanetti has a branch for that
<Saviq> dandrader, https://code.launchpad.net/~mzanetti/unity8/patched-control/+merge/246105
<dandrader> Saviq, ok, thanks
<paulliu> got some trouble reflash my dead phone.. http://paste.ubuntu.com/9718940/
<paulliu> What does EOF means. No futher steps after that.
<Saviq> paulliu, if you go to https://system-image.ubuntu.com/gpg/image-signing.tar.xz.asc with your browser, does it work?
<paulliu> Saviq: yes. A PGP Signature.
<Saviq> paulliu, come to #ubuntu-touch please
<dandrader> mzanetti, seems lp:~mzanetti/unity8/patched-control doesn't fix this build problem I'm having :( https://launchpadlibrarian.net/194622493/buildlog.txt.gz
<mzanetti> looking
<mzanetti> dandrader: oh... yeah, that branch is only fixing ./build.sh
<mzanetti> didn't know about the ppa issue
<mzanetti> Saviq: hmm... I wonder why the ppa wouldn't eat the :native ^
<Saviq> mzanetti, that's weird
<Saviq> obviously that worked in the silo PPA
<mzanetti> yeah...
<Saviq> dandrader|lunch, where did the fail happen?
<mzanetti> Saviq: also, what exactly is the problem that I'm supposed to fix with -nt control?
<Saviq> mzanetti, just replace "unity8-build-deps*deb" with "control"
<mzanetti> yes, just wondering why
<Saviq> mzanetti, when you end up with two .deb files
<Saviq> mzanetti, the condition breaks
<Saviq> when there's a new version
<Saviq> and you don't --clean
<mzanetti> oh, because control will always be newer than one of those debs
<mzanetti> got it
<Saviq> well, at least as new as one of them, that is
<Saviq> a second apart
<Saviq> but the important bit is it will be older than the real debian/control if anything changed there
<mzanetti> yeah
<mzanetti> that's that I meant
<mzanetti> Saviq: pushed
<Saviq> mzanetti, acked
<om26er> unity-team can anyone help me confirm the fix for bug 1384374 ?
<ubot5> bug 1384374 in unity8 (Ubuntu RTM) "Dash pauses/stutters during scope switching left/right" [High,In progress] https://launchpad.net/bugs/1384374
<om26er> I am testing the silo 12 but the bug fix at hand is a bit difficult to understand.
<om26er> mzanetti, can you help with that ?
<dandrader> Saviq, here https://code.launchpad.net/~unity-team/+recipe/unity8-shellrotation (about where the fail happened)
<Saviq> aaah recipe
<Saviq> dandrader, you'll have to drop the :native in some of the branches in there, recipes don't deal with that yet :/
<Saviq> s/some/one/
<mzanetti> interesting
<mzanetti> om26er: which bug?
<om26er> mzanetti, 1384374
<om26er> #1384374
<mzanetti> om26er: afaiu, when you have an unpatched phone and swipe the dash left/right you should see some stuttering and if you watch .cache/upstart/unity8.log you'll see tons of warnings when doing that
<mzanetti> both should not happen any more with that silo
<Saviq> well, it will stutter *less* with the silo
<Saviq> not sure the warnings are actually gone
<Saviq> because were unrelated really
<mzanetti> ah. ok. now I can see how om26er has having troubles verifying it
<om26er> so the fix is subjective, hmm.
<om26er> I have verified other bugs to be fixed. The situation for this one doesn't look bad either.
<elopio> dandrader: have you used python fixtures before?
<dandrader> elopio, I don't know :) may I have
<dandrader> maybe
<elopio> dandrader: the unity suite doesn't use them a lot. It's pretty simple, but a powerful idea. It lets you write test set up by composition instead of inheritance.
<elopio> https://github.com/testing-cabal/fixtures
<elopio> dandrader: so what we want is a fixture to set a specific orientation, and revert it during the test cleanup. That way we could test any app rotated by just using the fixture.
<dandrader> elopio, ok
<om26er> Saviq, after thorough testing Dash is smoother without the silo
<om26er> I am taking left/right switching of scopes
<om26er> So I would hold-off on landing this silo
<Saviq> om26er, ugh, that sounds wrong :/
<Saviq> om26er, the more important fix there is the photos scope
<om26er> Saviq, yeah that I can confirm is fixed.
<om26er> Saviq, maybe revert the change for this particular bug
<Saviq> tsdgeos, fyi â, om26er's finding left/right switching less smooth with https://code.launchpad.net/~unity-team/unity8/rtm-20150108/+merge/245852
<Saviq> om26er, not possible, they're the same
<Saviq> om26er, we'll have to follow up tomorrow then
<om26er> Saviq, alright then.
<Saviq> om26er, if you could comment as much details on trello about how you found this, would be of hepl
<Saviq> help, even
<om26er> sure
<kgunn> mzanetti: so wakelock holding to allow suspends can only be repro'd on rtm ?
<kgunn> weird
<Saviq> om26er, worth noting, it seems the stuttering is reduced when loading the scopes for the first time, but indeed it seems to get worse with the silo when they're all loaded already
<Saviq> om26er, so basically the first traverse through them is slower on current, faster on vivid, at the cost of slightly slower swipes later
<mzanetti> kgunn: well, I can't repro the music stuttering which is described in the bug reports
<Saviq> om26er, we'll have a look tomorrow morning in any case
<mzanetti> kgunn: but apparently this is also device specific
<om26er> Saviq, yeah my case also involves the condition when all scopes are loaded.
<mzanetti> so I guess it varies between combinations of distro/device
<Saviq> om26er, ultimately this might be something we'll have to live with until we find a better fix, but will have a look with tsdgeos tomorrow morning
<om26er> it all depends on the priority I guess, if the picture loading issue is > scope switching.
<dandrader> mzanetti, so the ubuntu icon is not at the top of the launcher?
<dandrader> s/not/now
<mzanetti> dandrader: on the desktop, yes
<kgunn> fyi.... mterry locked himself out of his apartment, likely out for the afternoon
<dandrader> mzanetti, the tests "make try**" have them inverted :-/
<dandrader> inverted = ubuntu logo on top
<mzanetti> dandrader: yes, so?
<dandrader> mzanetti, that the tests should emulate what you get on the phone
<mzanetti> ?
<mzanetti> which test are you talking about?
<dandrader> mzanetti, Shell
<mzanetti> hmm... make tryShell has it on top indeed
<mzanetti> that's probably wrong
<dandrader> mzanetti, does the decision come from a gsetting or something?
<mzanetti> yes, com.canonical.Unity8 usage-mode
<mzanetti> again, the temporary thing until we have the magic that defines the usage mode
<dandrader> right
<dandrader> eod
<mzanetti> :D
<alesage> random question from QA: charles and I are writing automation for the indicators, specifically showing that the indicator-power icon changes according to charge level (using dbusmock)
<alesage> we're able to show the changed icon but I'm wondering what a fair assertion on this will be, i.e. we're able to verify the name, but can anyone think of anything closer to the presentation/UI layer?
<alesage> the name itself feels a little trivial
#ubuntu-unity 2015-01-13
<Saviq> tsdgeos, hey, so, Omer was testing our "more async dash" silo yesterday and found that switching left/right between scopes is actually worse than in current rtm when all the scopes are loaded already
<tsdgeos> what's the definition of "worse"?
<tsdgeos> more jumpy?
<Saviq> tsdgeos, it improves things for initial loading (and I imagine for refreshing then, too)
<Saviq> tsdgeos, and yeah, there's more stuttering after they're all loaded
<tsdgeos> it may be because of the bug i found yesterday
<Saviq> tsdgeos, do you think what you discovered yesterday would have impact? also, I started thinking maybe we should not do anything with the delegates when we change the current scope to avoid any operations blocking the animation
<Saviq> tsdgeos, right, that's what I was thinking
<tsdgeos> well it's creating more things than needed
<tsdgeos> we're not doign stuff when changing delegates
<tsdgeos> or at least that's what the code tries to do
<tsdgeos> there may be bugs of course, but i remember trying it
<Saviq> tsdgeos, are we not basing the size of the cache buffer on isCurrent?
<Saviq> tsdgeos, GSV.qml:412 seems to say so
<tsdgeos> yes, but cachebuffer is async "should not" affect performance and only do stuff in the background
<tsdgeos> but i see what you mean
<tsdgeos> can try not modifying stuff if the parent dashcontent is not settled
<Saviq> tsdgeos, yeah, please have a look at this today, anything I can take off your hands to not distract you?
<tsdgeos> i'm actually looking at another thing that makes the dash bad
<Saviq> the thing we talked about yesterday/
<tsdgeos> the carousel cachebuffer, displayMargins are badly set
<Saviq> ?
<Saviq> okies
<tsdgeos> since they assume a vertical growing pattern
<tsdgeos> not an horizontal one
<tsdgeos> so basically we're loading all the stuff on the carousel
<tsdgeos> for every single carousel out there
<tsdgeos> which is not bad in real life since we don't use them much
<Saviq> right, why do they stutter when scrolling then Â¿?
<tsdgeos> but it's what makes the dashcontent test slow to settle
<tsdgeos> carousels stutter?
<Saviq> yeah
<tsdgeos> well it must be something else being awful
<Saviq> at least the music one does for me
<tsdgeos> the delegates are all created
<Saviq> that might be the thumbnail image provider
<tsdgeos> if you put a
<tsdgeos> Component.onCompleted: console.log("CC Create", index, cardCarousel.objectName)
<tsdgeos>             Component.onDestruction: console.log("CC Destroy", index, cardCarousel.objectName)
<tsdgeos> on the Loader of CardCarousel.qml you'll see lots of stuff in the log
<tsdgeos> ah wait, no they're not all loaded
<tsdgeos> sorry, there's still a cachebuffer
<Saviq> yeah I understand, we're deferring the images are we not
<tsdgeos> it's just that those out of view still think they are in view and thus load themselves
<tsdgeos> when they should not
<tsdgeos> cacheBuffer is still set to 1404
<Saviq> I think it's the image loading itself (I can see them showing up late) that causes the stutter
<Saviq> tsdgeos, yeah, anyway, you know best what to do, let me know if I can help
<tsdgeos> we need to sit down and try to write unit tests for this stuff
<tsdgeos> but it's hard :/
<tsdgeos> Saviq: so there's 3 different bugs/issues, i'll report them so we have a paper trail of what's going on, ok?
<Saviq> tsdgeos, yeah, thanks
<mzanetti> Saviq: re drag-to-refresh minimum velocity
<Saviq> maximum, rather :)
<mzanetti> in my experience the best is if you require the finger release to happen while being dragged
<mzanetti> with min distance
<mzanetti> but no velocity
<Saviq> mzanetti, I trigger the refresh multiple times a day when just flicking up/down in the dash
<Saviq> +accidentally
<mzanetti> sure
<mzanetti> but the current code doesn't require you to press, drag a certain ditance and then release, does it?
<Saviq> it does
<mzanetti> hmm ok... true
<Saviq> just as long as you drag down a certain distance it will refresh, without it even being able to show you the "release to refresh" string
<mzanetti> ah ok... maximum velocity might help
<Saviq> yeah, just don't trigger unless the velocity at release time is < foo
<mzanetti> Saviq: what would also help is if the content would only disappear once the new content is here
<mzanetti> and not clear -> load -> show
<Saviq> yeah, there's a bug about that
<Saviq> but it would only help with the perception, not with the fact :)
<mzanetti> true
<mzanetti> but it's all about the perception :)
<Saviq> tsdgeos, I was thinking that instead of on isCurrentChanged, we could increase the cache buffer (if necessary, depending on memory and visual impact) on first scroll in a scope, otherwise we create and destroy delegates all the time without them being ever displayed
<Saviq> that's assuming we can't deal with a static cacheBuffer all along
<tsdgeos> that's right, when you switch scope we're creating delegates you may not need
<tsdgeos> but i'm pretty sure that if you do it on scroll
<tsdgeos> it is not going to work
<tsdgeos> in fact it's why we create them before hand
<tsdgeos> :D
<Saviq> yeah, that was /me just thinking, you know better :)
<tsdgeos> don't think i do much better, only a bit :D
<Saviq> paulliu, did you get help on flashing yesterday?
<Saviq> dandrader, can you please follow up on https://code.launchpad.net/~josharenson/unity8/physical_keys_filter/+merge/244244
<dandrader> Saviq, ok
<paulliu> Saviq: yes. Now it it solved. There are some lock file left in cache.
<Saviq> paulliu, glad
<paulliu> Saviq: I removed those files and it get worked.
<Saviq> Cimi, Wellark, can you please update the status of bug #1363400 and add appropriate tasks, comment on what's required to fix the bug
<ubot5> bug 1363400 in ubuntu-system-settings (Ubuntu RTM) "[wizard] allows to "Continue" without connecting to network" [High,Triaged] https://launchpad.net/bugs/1363400
<Saviq> dednick, can you please explain https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1378821.time-translation/+merge/246194 a bit? we don't care about that label overflow?
<dednick> Saviq: it's something funky with labels which are right aligned. changing the text doesn't seem to adjust it's size in a layout correctly iirc. So if the text changed from "" -> "Sat 10:30am" the text would start off the page on the right. Need to replicate and log with qt
<Saviq> dednick, ah, so a problem with layouts
<dednick> Saviq: yeah, or text areas. not sure which.
<dednick> only seems to happen with right aligned text areas...
<dednick> or only visible with them anyway
<Saviq> dednick, hmm, at least looking at the code it could never have gotten right-aligned because the Label was never wider than the text, so there was no right-alignment possible
<Saviq> dednick, what I mean is Layouts don't "stretch" items
<mzanetti> dandrader: hey, I just installed shellrotation on the nexus7
<mzanetti> dandrader: it breaks windowed mode
<Saviq> dednick, i.e. http://paste.ubuntu.com/9728215/ works fine
<dednick> Saviq: ok, but why was it screwing up?
<Saviq> dednick, that is a good question, I'll try and reproduce here
<dednick> actually, i think i remember why i put in the right align. because the text did not resize if the time changed. in which case, the text could get smaller than the label.
<dednick> Saviq: ^
<dednick> or seomthing
<Saviq> yeah in any case I can see the current code not doing the right thing
<dandrader> mzanetti, what did you do to switch to windowed mode on the N7?
<Saviq> but I'd say just growing the Label should do (not that anchoring to the right isn't better anyway in this case, assuming we're not afraid of overflow)
<Saviq> dandrader, there's a gsetting
<mzanetti> dandrader: gsettings set com.canonical.Unity8 usage-mode Windowed
<dandrader> mzanetti, so I guess it remained in tablet mode?
<mzanetti> yes
<Saviq> dednick, btw https://code.launchpad.net/~nick-dedekind/ubuntu-ui-toolkit/lp1378821.time-translation/+merge/246191/comments/608254
<dednick> Saviq: i think i removed the elide because of the non-growing promlem. or just the fact that eliding on the right is shite for time stamps
<dednick> Saviq: ta
<Saviq> dednick, that latter part makes sense :)
<Cimi> Saviq, aanti might be on holiday
<Cimi> Saviq, I tried pinging him since yesterday morning
<Saviq> dednick, btw, to update the .api file there's a script in tests/ that creates a .new file I think
<dednick> Saviq: yup. thanks
<Saviq> just diff the files and if correct, check in
<dednick> Saviq: hm. can't seem to get the api thingo working. keeps giving me "COmponent is not ready"
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/dash_ranges_on_move/+merge/246286 should make that no items are created/destroyed because of the scopes list being moved horizontally
<tsdgeos> it can still happen though that if you change scopes fast the cacheBuffer ones for the current one are in creation process
<tsdgeos> can't think of a way to make that not happen with our current infra
<greyback_> mzanetti: have done a little work on https://code.launchpad.net/~gerboland/qtmir/acquire-wakelock/+merge/245942 - but unable to repro your issue. Could you try again please?
<greyback_> and if you do repro your bug again, please ssh in and get the output of "sudo powerd-cli list"
<mzanetti> greyback_: well, sshing in is not that easy :)
<mzanetti> greyback_: as it only happens if unplugged
<greyback_> mzanetti: ssh over wifi works!
<mzanetti> doesn't that get cut off in the deep sleep phase?
<mzanetti> anyways, I'll try
<greyback_> mostly works
<Saviq> tsdgeos, FAIL!  : qmltestrunner::DashContent::test_noDelegateCreationDestructionOnMove() 'verify()' returned FALSE. ()
<greyback_> https://code.launchpad.net/~gerboland/unity8/async-dbus-dashcomm/+merge/244892 - could I get a review of this please? I'm unable to reproduce the CI test fails locally, are our tests stable in CI right now?
<Saviq> greyback_, they're not
<greyback_> Saviq: ok, good to know
<Saviq> greyback_, yeah, DashContent tests take too long there and fail, Albert's looking into improving that
<Saviq> dednick, mzanetti, who wants to review greyback_'s branch â?
<greyback_> Lorn already +1ed it
<greyback_> but happy to get more eyes on it
<dednick> Saviq: i can, but just about to start making lunch.
<dednick> once my eyes see food, i can't stop :)
<Saviq> dednick, enjoy, not too pressing
<mzanetti> well, as the dash doesn't get suspended any more... is this needed?
<Saviq> greyback_, â
<greyback_> mzanetti: yes, the main loop blocking is still a bad thing, which impacts code I want to propose after
<Saviq> tsdgeos, FYI: bug #1410260
<ubot5> bug 1410260 in thumbnailer (Ubuntu) "Image provider blocking the UI thread" [Undecided,New] https://launchpad.net/bugs/1410260
<tsdgeos> hmmm
<davidcalle> sil2100, ping
<tsdgeos> Saviq: hmmm, may be, they should probably want to use my code
<tsdgeos> Saviq: fails for you? or in CI?
<Saviq> tsdgeos, for me, some others failed in CI
<Saviq> tsdgeos, but what's worse, it fails IRL
<tsdgeos> ?
<tsdgeos> you mean when using it? or the test on your pc?
<Saviq> tsdgeos, commented on the MP
<tsdgeos> ok
<Saviq> tsdgeos, using
<tsdgeos> that's confusing
<tsdgeos> very confusing
 * tsdgeos tries to find out what's wrong
<Saviq> tsdgeos, let me know if can help
<tsdgeos> Saviq: did you try that on vivid or rtm?
<Saviq> tsdgeos, both, actually
<Saviq> tsdgeos, with debugging on rtm I think, but locally on desktop on vivid+trunk, too
<tsdgeos> i don't knwo what's rtm
<tsdgeos> has all the stuff for the dash been merged?
<tsdgeos> i don't see how it can fail in the test either
<tsdgeos> Saviq: can you add the debugs in the test?
<Saviq> tsdgeos, rtm + the silo, so all the stuff for dash in there
<tsdgeos> right
<Saviq> tsdgeos, I did, just let me know what and where
<Saviq> s/did/can/
<tsdgeos> ok, give me a sec, maybe i can reproduce too
<Saviq> I looked at the arrays and got ~1200 vs. ~600 items
<tsdgeos> 1275
<tsdgeos> that's how i get here in both
<Saviq> let me see
<Saviq> tsdgeos, btw, you say "Wait for the buttons to settle..." when in fact you just get them, don't wait for anything?
<tsdgeos> Saviq: i do
<tsdgeos> there's a 250 msec loop above
<Saviq> ah now I see
<Saviq> yeah ok
<sil2100> davidcalle: pong
<Saviq> tsdgeos, 1379 vs. 1395 now
<Saviq> tsdgeos, and that seems to be stable now
<tsdgeos> Saviq: can you try making that 250 msec 1000
<tsdgeos> just in case
<Saviq> tsdgeos, yeah, passed
<tsdgeos> really?
<tsdgeos> 1395 vs 1305 ?
<tsdgeos> i mean 1395 both?
<davidcalle> sil2100, hey :) I would need your input to update this dev doc page : https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels . In the "Ubuntu channels" section, is it useful to list the <release name> channel and the <release name>-proposed ? I would assume aliases are enough.
<Saviq> tsdgeos, yeah, test passed
<Saviq> tsdgeos, 500 not enough, 750 enough
<tsdgeos> meh
<tsdgeos> what takes 750ms to create
<Saviq> tsdgeos, in any case, should we really have that many items?
<tsdgeos> no
<Saviq> or is that the carousels?
<tsdgeos> but that's the carousel problem in part
<tsdgeos> a substantial part i'd say
<sil2100> davidcalle: looking
<tsdgeos> but anyway that's not the problem
<tsdgeos> the problem is that it doesn't seem to work as you say on the phone
<tsdgeos> well it worked for me on a quick test
<tsdgeos> let me try again
<Saviq> tsdgeos, not on my desktop either, just add http://paste.ubuntu.com/9729959/ and see what happens when you switch scopes
<sil2100> davidcalle: I would personally leave those there, but maybe change them to really something like "<series>" and "<series>-proposed", indicating that we have a channel for every series we support
<tsdgeos> Saviq: nothing
<Saviq> tsdgeos, make?
<tsdgeos> Saviq: note this is when switching scopes, not after the scope has switched
<tsdgeos> obviously after the scope has switched there will be items being created and destroyed
<Saviq> tsdgeos, well, ok, that's where I think the problem lies then
<tsdgeos> you are getting this while you drag the scope?
<tsdgeos> why?
<tsdgeos> there's no movement
<tsdgeos> at that point
<tsdgeos> so what's the problem?
<Saviq> tsdgeos, there is, because you're swiping to the next scope by that time
<tsdgeos> ah sure
<tsdgeos> this doesn't fix that
<davidcalle> sil2100, cool, that's what I have on my draft :) Also, if you see potentially outdated stuff, in the doc, please tell me, thanks!
<tsdgeos> Saviq: i already mentioned that, no? Or maybe i didn't
<Saviq> tsdgeos, and anyway, I see creates/destroys while I hold my mouse down
<tsdgeos> Saviq: from which scope to which?
<Saviq> tsdgeos, first to second
<Saviq> tsdgeos, *but*
<Saviq> tsdgeos, I mean that's happening for me in the real scopes
<sil2100> davidcalle: there's actually one thing I was thinking of changing since I already have you around ;)
<Saviq> that's probably the plugin
<sil2100> davidcalle: there's the "Channel selection guide" there
<tsdgeos> what do you mean it's the plugin?
<Saviq> tsdgeos, the plugin queries scopes onIsActiveChanged
<sil2100> davidcalle: I would actually recomment setting ubuntu-touch/ubuntu/devel as the preferred channel for Nexus 7 and 10
<davidcalle> sil2100, ok
<sil2100> davidcalle: in our current process we only do sanity testing for rtm for mako, emulator and krillin
<tsdgeos> Saviq: didn't we remove that code?
<sil2100> davidcalle: so we have no guarantee that the rtm images are working on those supported devices - on the other hand, the devel channel requires QA to do testing on all supported devices
<Saviq> tsdgeos, the shell plugin only queries the first two scopes on startup, then queries the "next" one as you change the active scope
<tsdgeos> ah, i see, that's something that is being done behind our backs
<Saviq> yes
<Saviq> tsdgeos, but my subjective feeling was that stuff got worse, let me try again
<tsdgeos> it can't turn worse
<Saviq> ;)
<Saviq> tsdgeos, it's better after scopes are loaded, but it felt worse while they were loading
<tsdgeos> well there's a few more connections
<tsdgeos> but that should be peanuts
<tsdgeos> the code is the same it was with the exception of the next scope doesn't get the new big cachebuffer that caused stuff to be created
<davidcalle> sil2100, when you have 5 more min, please tell me if it's ok to close this bug now : https://bugs.launchpad.net/developer-ubuntu-com/+bug/1403642 :)
<ubot5> Launchpad bug 1403642 in Ubuntu App Developer site "ubuntu-touch/stable description is no longer valid, other descriptions need updating as well" [Medium,Triaged]
<Saviq> tsdgeos, ok, to improve things a little, should we maybe delay us changing the margins for a split second so that you only trigger it if you've stayed on a scope a moment
<Saviq> ?
<Saviq> and maybe base isCurrent on that, too?
<Saviq> â isActive
<Saviq> tsdgeos, but I'm actually OK to delay, let me just confirm that this fixes what Omer reported
<Saviq> tsdgeos, and we can follow up later
<tsdgeos> i'm not sure i wouldn't go that way
<Saviq> tsdgeos, any idea about the test failures though?
<tsdgeos> what we need to make is just make the whole thing faster creating items
<tsdgeos> not find workarounds and workaroudns of worksrounds
<Saviq> tsdgeos, sure ;)
<sil2100> davidcalle: almost perfect, I was only wondering if maybe the /stable channel description could mention that currently it's pointing to /14.09? I know this would get outdated if we change rtm to a different series, but this way at least it will be clear that it's best using /stable
<sil2100> davidcalle: or maybe differently!
<sil2100> davidcalle: if you could add in 14.09 that it's best to use /stable instead, that would be awesome
<davidcalle> sil2100, agreed, doing that
<Saviq> tsdgeos, but, TBH we should not claim to have fixed bug #1384374 then...
<ubot5> bug 1384374 in unity8 (Ubuntu RTM) "Dash pauses/stutters during scope switching left/right" [High,In progress] https://launchpad.net/bugs/1384374
<tsdgeos> maybe no
<tsdgeos> it's just an unfixable bug
<Saviq> yeah, we just need to strike a balance and do our best to improve
<tsdgeos> unless you throw away all we have and go back to something sane like a alll the phones do and have a static dash
 * tsdgeos hides :D
<tsdgeos> Saviq: well there's one thing we can do at some point, not sure how hard it is
<tsdgeos> and is add our own incubator
<Saviq> tsdgeos, don't worry, we'll be rendering the bits out of process and compositing them soon enough, we'll be able to make the side-swiping perfectly smooth ;)
<tsdgeos> that doesn't incubate at all
<tsdgeos> when you're swiping
<greyback_> Saviq: "rendering the bits out of process" - yeah?
<greyback_> surface per scope?
<tsdgeos> what would solve your problem of swiping while the current cached items of the scope are being incubated
<tsdgeos> as far as i understand that should be possible
<sil2100> davidcalle: thanks! :)
<tsdgeos> Saviq: i can try looking into that if you want
<Saviq> greyback_, that's what we seem to be going towards, yes
<greyback_> Saviq: ok
<davidcalle> sil2100, np, thanks to you :)
<tsdgeos> Saviq: ok, so i work on the "not load all carousels at once", now, ye?
<Saviq> tsdgeos, are you fine with the tests on that MP though?
<tsdgeos> Saviq: i made the wait bigger
<Saviq> tsdgeos, ok
<tsdgeos> nasty and lam
<tsdgeos> e
<tsdgeos> as i can see it is either that or remove them
<tsdgeos> we can keep them and if they fail all the time
<tsdgeos> remove it and try to spend time to find a smarter way
<sterns>  good day.  I am doing some research for a software development project.  My question pertains to the use of the favorites/launcher bar.  When some programs are running, they do not create additional favorites entries, but instead stack on the existing icon.  How does one control that behavior?  The program currently has a separate (running) icon on the favorites bar, and I would like it to stack.
<Cimi> mterry, ping
<mterry> Cimi, heyo
<Cimi> mterry, morning :) any update on the first branch from design?
<mterry> Cimi, I believe they are going to go over it "this week"
<greyback_> oh yay, "g++4.9:native" works with my Xcompiling chroots
<Cimi> mterry, "okay"
<Saviq> greyback_, yeah, it's a nasty workaround, but there's nothing better yet
<mterry> Cimi, :)  I just meant I  don't know more specifics than a whole week
<kgunn> dandrader: hey, is the rotation ppa good to go ?
<kgunn> i've got richard pinging me
<dandrader> kgunn, it seemed to be yesterday, but today greyback_ told me it has visual glitches
<kgunn> dednick: on the laggy backend bug and doing a deeper dive, is that something we need design input on? or is it mainly a
<kgunn> technical frontend/backend rework
<kgunn> re-arch
<dednick> kgunn: not sure we need design input. unless we want to display something fancy while we wait for confirmation.
<dednick> *validation
<kgunn> dednick: ack...sounds like it can be an engineering solved prob then...
<tsdgeos> Cimi: the carousel thing is more a problem on how i set the cachebuffer from the outside than a carousel bug by itself
<tsdgeos> i can give you some insight if you want but i *think* i know how to fix it
<Cimi> tsdgeos, thought it was a carousel bug...
<Cimi> :P
<Cimi> tsdgeos, well I can test it then
<tsdgeos> nah, it's more a "how do we use the carousel in the big picture"
<tsdgeos> that'd be great
<Cimi> this one is easy https://code.launchpad.net/~cimi/unity8/fix-1393008/+merge/246138
<dandrader> Saviq, did the power button usage got worse recently (not blanking or turning the display on rapidly and consistently)?
<Saviq> dandrader|afk, not that I know of
<Saviq> Cimi, got one for you, should be somewhat simple, too
<Saviq> 1410337
<Saviq> bug #1410337
<ubot5> bug 1410337 in unity8 (Ubuntu) "Launching a scope once installed is broken" [High,Triaged] https://launchpad.net/bugs/1410337
<Cimi> Saviq, cool
<Saviq> tsdgeos, I was wondering, is there a chance non-current scopes still load its delegates synchronously? the amount of blocking on initial swipes is just crazy :/
<tsdgeos> Saviq: there is
<tsdgeos> i'm sure some of them are
<tsdgeos> but most of them shouldn't
<tsdgeos> thing is you need a patched Qt to debug that out
<greyback_> bregma: hey, this might be of interest to you: https://code.launchpad.net/~gerboland/qtmir/fix-GTK-rendering/+merge/246201
<tsdgeos> since there's really no way to know if somethign was done async or not otherwise
<greyback_> bregma: it's removing the hack you made to fix GL rendering. In my testing it works everywhere now without the hack - why, I've no real idea
<bregma> hmm, we shall see....
<greyback_> bregma: I checked it on my nvidia & amd machines, emulator and phone. But I'd really appreciate a sanity check
<bregma> did maybe some fix to Qt sneak in so it doesn;t use an enum any more?
<greyback_> bregma: Not a clue. I'd have to dig.
<Saviq> tsdgeos, well, I'm sure you can gdb it ;)
<tsdgeos> Saviq: kind of yeah
<tsdgeos> cimi: there?
<tsdgeos> Cimi: i'd like to know a way to know the width of the items on the viewport of a carousel
<tsdgeos> that is, if the carousel is 200 width
<tsdgeos> we're still cramming more items inside those 200 pixels because of the translations
<tsdgeos> so i'f need to know if it's 250 pixels or what were putting inside those 200
<tsdgeos> not sure if i'm making sense
<popey> greyback_: yo, i flashed my flo and updated as per https://wiki.ubuntu.com/Unity8/FullShellRotation but the dash is always landscape.
<popey> greyback_: known issue?
<greyback_> popey: intended
<popey> oh okay.
<greyback_> popey: was asked to make it landscape only anyway. Can be undone fairly easily
<Saviq> om26er_, as you might've seen, we've fixed the issue you reported on silo 12, and decided to not say we've fixed the stutter bug when we really need more time and work to investigate
<Cimi> tsdgeos, sorry I should not update kernel without checking compatibility :)
<Cimi> tsdgeos, mumble?
<tsdgeos> Cimi: i have to run now
<tsdgeos> tomorrow?
<Cimi> tsdgeos, ok, or ping me later
<om26er_> Saviq, good, i'll retest.
<popey> greyback_: is there a bit I can flip on my own device?
<greyback_> popey: edit /usr/share/applications/unity8-dash.desktop, and remove the "X-Ubuntu-Supported-Orientations=primary" line - then restart unity8
<greyback_> should work in theory, not tested
<Saviq> (restart uniity8-dash should be enough, no?)
<greyback_> Saviq: unity8 deas the desktop file of unity8-dash
<greyback_> s/deas/reads/
<Saviq> greyback_, well, yeah, but it will re-read it when the app restarts?
<greyback_> Saviq: true
<popey> greyback_: works, but yeah... â»
<greyback_> popey: that bad?? /me tries
<greyback_> guessing slow resize, so breaks animation
<greyback_> yep
<greyback_> dash resize is painfully slow for some reason
<Saviq> I know the reason ;)
<Saviq> it's a painfully complex UI
<greyback_> it's a freaking grid :D
<Saviq> greyback_, it is freaking, that's for sure
<Saviq> greyback_, prepping a unity8 silo, got qtmir? (like :native)
<Saviq> (for vivid)
<greyback_> Saviq: yes, but CI failed https://code.launchpad.net/~gerboland/qtmir/gcc4.9-crosscompile/+merge/246316
<greyback_> some udev package weirdness
<greyback_> I had to muck around in my chroots to fix it locally
<Saviq> greyback_, it's actually not a udev issue
<Saviq> greyback_, your CI job needs updating
<greyback_> Saviq: ah boo. Who can do that?
<Saviq> greyback_, you need H10strip_native_depends to be added to hooks
<Saviq> greyback_, my PoC is fginther
<greyback_> ok will poke him
<greyback_> t
<greyback_> aa
<Saviq> greyback_, basically, there's still a bunch of tools that don't understand :native - pbuilder is one of them
<Saviq> greyback_, any reason not to land the two remaining ACK-ed MPs for qtmir?
<greyback_> Saviq: none at all. I hoped you were just including them
<Saviq> greyback_, am, was just confirming
<Saviq> greyback_, should bug #1389189 make its way into rtm?
<ubot5> bug 1389189 in QtMir "event area not filled in by Mir" [Medium,In progress] https://launchpad.net/bugs/1389189
<Saviq> or the fix for, rather
<greyback_> Saviq: I don't really see it being RTM necessary really.
<greyback_> really
<Saviq> k
<om26er_> Saviq, the changelog for silo12 looks a bit scary, is there anything except for the TestPlan that I should be testing ?
<Saviq> om26er_, that changelog is a bug
<Saviq> om26er_, in the train
<Saviq> om26er_, ah wait
<om26er_> Saviq, sorry, I meant the diff
<Saviq> om26er_, no, it all impacts the dash, and only the "surface" of it, i.e. list of results
<Saviq> om26er_, it's been in vivid for two months now or so
<om26er_> yeah but not many are running vivid :)
<Saviq> om26er_, more than you think :)
<Saviq> om26er_, in any case, if you have not found anything wrong when just browsing through the dash, that's your confirmation
<Saviq> it should all behave slightly better, less stutter when swiping up/down
<om26er_> Saviq, I have confirmed the fixes and nothing looks wrong in the dash, I'll just go ahead with approving that
<Saviq> om26er_, we're confident with those changes, have tested them thoroughly, too
<om26er_> curious though why is the unity8 TestPlan on the wiki short.
<Saviq> om26er_, thanks
<Saviq> om26er_, we have a rather extensive set of qml tests
<om26er_> Great!
<Saviq> om26er_, so manual testing is basically just having a play with the phone and verifying the few journeys that we want to confirm are fine
<om26er_> Saviq, the loading of current view *3 shows blank pictures if quickly flicked from top to bottom in flicr
<om26er_> I guess that's a compromise we are gonna have to live
<Saviq> om26er_, yeah, it's either that
<Saviq> om26er_, or the view being stuck
<Saviq> om26er_, but the time it takes to load the images we still have ways to improve
<Saviq> om26er_, probably the biggest UX impact would be to actually show the empty shapes
<Saviq> but there's other issues, including in Qt, that we need to work on to speed this stuff up
<om26er_> Saviq, hmm, so perhaps a bug report will help us track of this, so that it doesn't get forgotten
<Saviq> om26er_, there are a few already, actually :)
<Saviq> om26er_, we can have a over-arching one "Improve image loading performance", but I think that does not require a bug for us to remember it ;)
<om26er_> Saviq, did you consider increasing the loaded area to view*4 ?
<om26er_> that might minimize this visual problem
<om26er_> Saviq, I am just trying to make sure we are not regressing something for little gains ?
<kgunn> greyback_: on this wakelock bug, i'm was gonna be a third set of eyes...trying to repro on vivid/mako before i test your fix
<kgunn> i only saw the camera app take a minute to render after my first boot/flash...
<kgunn> i've rebooted a couple of times, and every unlock i end up seeing the dash
<kgunn> is there some other symptom you're using/seeing reliably ?
<kgunn> ...the bug says happens after reboot, but is it really only after 1st boot/flash
<kgunn> ...ah nvmd, i see something listed in your first comment on the MP
<Saviq> om26er_, that's not going to improve things
<Saviq> om26er_, as loading just takes more time than scrolling
<Saviq> om26er_, we need to, at least: cache lower size images; improve Qt to parallelize (and cancel) image provider requests
<Saviq> om26er_, and then there's the adverse effect of memory consumption
<om26er_> I think that potential improvement have been identified for a long time, perhaps from the time when scrolling in the dash was jerky ?
<Saviq> yeah, this silo is fixing that adverse effect of too high memory consumption when we were loading too many items
<Saviq> and slaps on more asynchronicity, which is why you can swipe the my photos scope at all
<Saviq> instead of waiting multiple seconds for it to load (and kill multiple background apps in the process, wasting CPU etc.) of images that you might not even want to see
<Saviq> -of
<om26er_> I understand and somewhat convinced that we should land this ;)
#ubuntu-unity 2015-01-14
<Cimi> tsdgeos, hi, I am having some issues with my irc bouncer but I connected directly
<Cimi> tsdgeos, still need a hand?
<tsdgeos> Cimi: nope, figured it out what i needed, wasn't really what i thought i needed yesterevening
<Cimi> ok
<Cimi> cool
<Saviq> greyback_, there's no need for commit messages when there's a changelog entry (takes precedence anyway)
<greyback_> Saviq: ok
<tsdgeos> Saviq: Cimi: if you guys have time https://code.launchpad.net/~aacid/unity8/properRangesHorizontalCategories/+merge/246399
<Cimi> tsdgeos, I have
<tsdgeos> i'm not ultra happy about the growsVertically name, suggestions accepted
<Cimi> tsdgeos, what will be your definition of growsVertically first?
<tsdgeos> adding new cards makes the item grow vertically
<tsdgeos> :D
<Cimi> tsdgeos, or we can say those are "horizontal" oriented widgets?
<tsdgeos> so you want to call it growsHorizontally :D
<Cimi> tsdgeos, feels like more an orientation thing
<Cimi> tsdgeos, but we don't have enums...
<Cimi> Saviq, but isn't https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1410337 a scope bug?
<ubot5> Launchpad bug 1410337 in unity8 (Ubuntu) "Launching a scope once installed is broken" [High,Triaged]
<Cimi> Saviq, cannot find the actions being set
<Saviq> Cimi, we're not closing the preview
<Saviq> Cimi, the preview gets "transferred" to the temp scope
<Cimi> Saviq, we never close previews when we open an app
<Cimi> Saviq, we do when we switch back to dash
<Cimi> so the click scope runs an action, and we need to associate that action to the setCurrentScope function most likely
<Cimi> but let me dig more, might be dashcommunicator responsible for that
<Cimi> anyone experiencing issues building on the device with run_on_device?
<Cimi> I have this dpkg-gencontrol: warning: can't parse dependency g++-4.9:nativ
<tsdgeos> Cimi: yeah theres a branch
<tsdgeos> Cimi: comment it out or use the branch
<mterry> Saviq, is there an rtm silo for unity8 that will make it before the gates close?
<mterry> Ah nm, I see we just landed one
<tsdgeos> garg
<tsdgeos> QQuickItemView::setCacheBuffer immediately calls relayout instead of forceLayoutPolish like QQuickItemView::setDisplayMarginBeginning and QQuickItemView::setDisplayMarginEnd do :/
<tsdgeos> wonder if i can get a patch accepted to have the same behaviour
<tsdgeos> but anyway i need a workaround for that in current code
<mterry> kgunn, heyo!  How urgent is bug 1410830 (the split-off side of bug 1383277).  I ask because I think I have a band-aid fix that wouldn't address the root cause (which would still warrant investigation) but would likely stop the symptom.  I'm not sure how urgent stopping the symptom is, now that at least half of the problem is gone with the other bug's MP landing in RTM
<ubot5> bug 1410830 in unity8 (Ubuntu) "Shutdown dialog appears on resume, after a long delay in screen turning on" [Undecided,New] https://launchpad.net/bugs/1410830
<ubot5> bug 1383277 in Canonical System Image "Power dialog shown on resume with big backgrounds or high load" [Critical,Fix released] https://launchpad.net/bugs/1383277
 * mterry is loathe to apply a band-aid for a problem we don't quite understand unless there's urgency
<kgunn> mterry: it does have visibility
<kgunn> it's worth it...and i think tvoss was wanting a band aid in order to continue to dbug why the heck the bus goes nuts sometimes on resume
<mterry> kgunn, OK I can whip up an MP with appropriate caveats written all over it.  Especially since it's hard to reproduce and test.  But it *should* fix the symptom.  Meanwhile I can continue to try to reproduce reliably, which sounds like it would help tvoss too
<kgunn> yeah, rick seems to be able to repro fairly easy mterry....
<kgunn> well...at least it'll give him something to test against
<mterry> kgunn, in bug 1409003, Rick said he couldn't reproduce anymore (since r190)
<ubot5> bug 1409003 in Ubuntu system image "receiving an sms while roaming and suspended renders the phone difficult to use on resume" [Undecided,New] https://launchpad.net/bugs/1409003
<kgunn> ok, lemme check...i feel you  on the bandaid avoidance mterry
<mterry> kgunn, for sure the bug is still happening, just hard to reproduce
<kgunn> mterry: ok, conferred with rick & voss, they say land it
<kgunn> mterry: thanks for the work
<kgunn> mterry: how gnarly is the bandaid ?
<mterry> kgunn, not gnarly.  Not even a technically incorrect thing to do, but clearly a band-aid.  I plan to just not start the 2s timer for the shutdown dialog as long as the screen is off
<mterry> kgunn, it won't make the screen come on faster (remember, this version of the bug involves a delay on resume), but it will make the shutdown dialog not appear
<mterry> kgunn, https://code.launchpad.net/~mterry/unity8/no-shutdown-dialog-while-suspended/+merge/246445
<kgunn> thanks!
<Saviq> Cimi, it's not an app, it's a link to a scope
<Saviq> Cimi, so we need to make sure to close the preview when we open a temp scope is all
<Cimi> Saviq, yeah
<kgunn> mterry: so yeah, rick said he can still get it...got it a few times last night when out to dinner with wife
<Cimi> Saviq, I was saying that opening apps we keep the dash on hold
<kgunn> gonna load your mp in a silo to let rick test it
<Saviq> Cimi, yes, but the bug is about opening a scope, not an app
<mterry> kgunn, good!  sorta
<Saviq> mterry, no more into rtm this week, no
<kgunn> hehe...yeah...sad when you're happy about bugs actually existing....better than chasing a ghost
<Saviq> we just released one, and I've another ready to test for as soon as the gates open again
<mterry> Saviq, yeah I hadn't seen the one we released, and got nervous.  But I'm fine with the release we had
<Saviq> mterry, right, the power thing is there
<Saviq> mzanetti, any luck with the telephony service?
<mzanetti> Saviq: well, it was crashing, tiago fixed, was waiting for the new build. will try again sortly
<Saviq> mzanetti, ok, was just asking whether we got anywhere with the crash, really, glad
<Saviq> tsdgeos, Cimi, bug #1410794 looks interesting ;)
<ubot5> bug 1410794 in unity8 (Ubuntu) "massive chevron appears in nearby" [Critical,New] https://launchpad.net/bugs/1410794
<tsdgeos> lol
<Saviq> you can fight for who looks into it ;)
<Saviq> tsdgeos, lol indeed
<cwayne> i've seen that once, but could never reproduce it
<tsdgeos> wonder if it's because of the ...
<Saviq> couldbe
<Saviq> tsdgeos, kudos for CI!
<tsdgeos> well we're creating half of the items now
<tsdgeos> must be faster ^_^
<Cimi> tsdgeos, in case I spot it, I will tell you/assign myself
<tsdgeos> Cimi: Saviq: i need you guys to try https://code.launchpad.net/~aacid/unity8/properVRangesCurrentScope/+merge/246465 on the phone
<tsdgeos> it looks good to me
<Saviq> tsdgeos, will do
<tsdgeos> but since i've coded i think i may be slef convincing myself
<tsdgeos> it's always hard with those cache/lag things
<Cimi> we should have two phones to compare :/
<tsdgeos> still all this lag/cache things
<tsdgeos> they're different each time i reboot the phone
<Cimi> Saviq, does run_on_device log changes to dash into the same unity8-dash log file?
<Saviq> Cimi, run_on_device doesn't run the correct dash
<Saviq> Cimi, just go ./builddir/src/Dash/unity8-dash -mousetouch
<Cimi> I see why all my changes to dash seem uneffective
<Cimi> Saviq, from the device?
<Saviq> Cimi, ah on device
<Cimi> Saviq, I need to install click scopes
<Cimi> yeah
<Cimi> so I was running run_on_device with log for the functions called but nothing seems to be printed out
<Saviq> Cimi, yeah, it doesn't
<Saviq> Cimi, ~/.cache/upstart/unity8-dash.log
<Cimi> Saviq, I was looking at that
<Saviq> Cimi, but that might still not be it
<Saviq> Cimi, you can `restart unity8-dash BINARY=/path/to/your/unity8-dash`
 * Cimi tries
<Saviq> Cimi, run_on_device needs love, same as run, really...
<Cimi> oh yeah...
<Cimi> I was running system wide...
<Cimi> restart unity8-dash BINARY=shell/builddir/src/Dash/unity8-dash works on device...
<Cimi> I should add that to run_on_device...
#ubuntu-unity 2015-01-15
<Cimi> Saviq, tsdgeos what's the difference between openScope and gotoScope?
<Saviq> Cimi, fav vs. non-fav
<Cimi> ok
<Saviq> or the other way 'round
<Cimi> yeah other way
<tsdgeos> yeah
<tsdgeos> openscope is non fav
<tsdgeos> goto scope is
<Cimi> why don't we have a single call for them?
<Saviq> Cimi, legacy, really
<Saviq> Cimi, and the fact that the dash doesn't directly know whether it's fav or not, so the plugin gives us a hand
<Cimi> Saviq, to fix run/run_on_device, shall we restart also unity8-dash or we can pass a variable to unity8 upstart with the bin for unity8-dash?
<Saviq> Cimi, no, unity8-dash would need to be restarted, but it didn't work straight away when I tried it
<Saviq> tsdgeos, network trouble?
<tsdgeos> no, was playing with appmenu-qt5 in my irc client that just got upgraded to qt5
<tsdgeos> i have two menus now :D
<Saviq> :)
<Cimi> Saviq, it does not, because we specify in run.sh just the binary for unity8, not for unity8-dash
<Cimi> Saviq, so unity8 job then restarts the dash job which is the system-wide one
<Cimi> Saviq, we have two options: restart in run.sh the local dash job
<Saviq> Cimi, thanks for explaining, but guess what, I thought of that, and I did restart the dash with the right binary, but it didn't work locally IIRC
<Cimi> Saviq, or make the unity8 job look for the local dash build, maybe with a variable or so
<Cimi> Saviq, it worked here...
<Saviq> Cimi, the unity8 job knows nothing about the dash
<Saviq> Cimi, sure, if you solved this, MP it, we'll be sure to review
<Cimi> Saviq, yesterday when I tried with restart unity8-dash BINARY=/path/to/your/unity8-dash
<Saviq> Cimi, yes, I know that works
<Saviq> Cimi, but when I put that in run.sh, it did not work well (either on device or locally, don't remember)
<Cimi> Saviq, so my question is how can we tweak unity8 job to run that?
<Saviq> Cimi, we don't
<Saviq> Cimi, the unity8 job knows nothing about the dash
<Saviq> Cimi, we need to tweak the run scripts to restart unity8-dash with the correct binary
<Cimi> Saviq, well thje dash job restarts on unity8
<Cimi> Saviq, if we could set a variable pointing to the right binary...
<Saviq> Cimi, it doesn't restart, it starts and stops
<Saviq> Cimi, that's exactly what "restart unity8-dash BINARY=..." does
<Saviq> Cimi, but you can't do that in the unity8 job
<Saviq> Cimi, because it has no idea about the dash
<Saviq> Cimi, you need that in the run scripts, that will start the correct unity8 and then restart dash with the correct binary
<Cimi> Saviq, I meant adding something to the unity8 dash job, check if a variable is set ($UNITY8_DASH_BINARY), otherwise run system wide
<Saviq> Cimi, you'd have to set a global var like that, not sure we want that
<Cimi> Saviq, we set a variable in run.sh, and we unset the variable at stop of unity8
<Cimi> Saviq, so the variable is always unset, apart when we run run.sh
<Saviq> Cimi, sure, that could work, not much different than going "restart unity8-dash BINARY=..." in the same run.sh script
<Saviq> only thing is that the system-wide dash would be started first, but that's not really a problem IMO
<Saviq> Cimi, if we did that, we should make the unity8 job itself respect that env var
<Saviq> Cimi, but I'm worried it would easily get stale on Ctrl+C and such
<Saviq> and then you'd get stuck with the local build until you reset that var manually
<Cimi> Saviq, problem is that when we start unity8 in run.sh, this will start the dash
<Saviq> Cimi, yes, and then we can restart dash with the right binary
<Cimi> Saviq, with a sleep ?
<Saviq> Cimi, no, straight away
<Saviq> Cimi,
<Saviq> unity8-dash starts as soon as unity8 started
<Cimi> yeah
<Saviq> which initctl start unity8 exits even later than that
<Saviq> -which
<Cimi> ah ok, cool
<Cimi> thought was running in parallel
<Cimi> Saviq, doing ctrl-c will not run the stop script of unity8 job?
<Cimi> or post-stop
<Saviq> Cimi, it will, assuming you actually deliver the ctrl+c
<Saviq> Cimi, if you just unplug USB, nothing will happen
<Saviq> Cimi, but recovering from that is a simple "restart unity8" away
<Saviq> whereas with the global env you'd need to unset that env first
<Cimi> we could unset the variable in unity8-dash start
<Cimi> after the binary ran
<Saviq> Cimi, that's putting more and more test considerations in a real-life job, wouldn't like that
<Cimi> Saviq, ok, so let's just restart in run.sh
<Saviq> Cimi, I'd rather us put an .override in ~/.config/upstart and remove "itself" in post-stop
<Saviq> that could actually work and could mean we don't need to recommend installing unity8 on desktop, and make sure you always use the new job
<mzanetti> Saviq: wouldn't it make more sense to make the dash not start at all with ./run.sh ?
<mzanetti> you can just run ./builddir/src/Dash/unity8-dash to run the dash alone
<Saviq> mzanetti, that depends, it's used on device as well
<mzanetti> oh ok... I see the value for the device case
<Saviq> mzanetti, run_on_device calls run.sh
<mzanetti> but for local runs I think it's not useful
<Saviq> dunno, as long as it runs the right one, I'd be happy
<Saviq> especially since you have to remember -mousetouch to use the bottom edge etc.
<mzanetti> Saviq: I would rather rather have a run-dash.sh
<mzanetti> if you only need the shell, it's quite annoying that the dash is always popping up too
<Saviq> sure, we could refactor all that
<Saviq> and do away with .sh in the process ;P
<tsdgeos> Cimi: Saviq: can you reproduce https://launchpadlibrarian.net/194886158/bug.png ?
<Saviq> tsdgeos, no, I wonder if it's the Spanish version maybe
<tsdgeos> i'm on spanish krillin
<tsdgeos> can't either
<Saviq> tsdgeos, do you have the "Lugares emblemÃ¡tic..." category?
<tsdgeos> yeah
<tsdgeos> it fits just fine
<tsdgeos> http://i.imgur.com/QalsvMJ.png
<Saviq> oh that's interesting
<Saviq> so it got elided
<Saviq> so basically the chevron got huge, and the label is right-anchored to it
<Saviq> so it elided
<Saviq> now why would the chevron get huge?
<Saviq> if I had to guess, RowLayout is playing with us
<Cimi> sdk sdk sdk! :D
<tsdgeos> it's weird
<Saviq> Cimi, nope, it's all our components
<tsdgeos> because victor mentions it's fine and just wrong after scrolling
<tsdgeos> and the height of the icon is set to gu(2)
<MacSlow> tsdgeos, mzanetti, Saviq: is there any way to alter the qmltest-makefiles to run uqmlscene under gdb?
<mzanetti> MacSlow: make gdbtestFoo
<MacSlow> mzanetti, thx
<Saviq> MacSlow, you can always just copy-paste the qmltestrunner line, too
<MacSlow> ok
<tsdgeos> Saviq: how have you tried the new dash branches on rtm? i get errors if i try the branch directly
<tsdgeos> http://paste.ubuntu.com/9755298/
<tsdgeos> like i guess the sdk is too old or whatver
<Saviq> tsdgeos, I cherry-picked
<tsdgeos> i see
<Saviq> tsdgeos, and depends what you mean "new dash branches"?
<tsdgeos> i'll try that
<tsdgeos> properVRangesCurrentScope and properRangesHorizontalCategories
<Saviq> yeah, in general we can't run trunk on rtm any more, you need to cherry pick onto lp:unity8/rtm-14.09
<Saviq> yeah those I didn't try yet
<tsdgeos> ah ok
<tsdgeos> Saviq: i tried vivid, but rtm krillin has more interesting scopes
<Saviq> biab
<Saviq> tsdgeos, yeah, definitely worth to try there
<dandrader> mzanetti, did you enable the touch logging (TouchRegistry, DirectionalDragArea and TouchGate) in your dogfooding phone?
<mzanetti> dandrader: not yet. was quite busy yesterday. wanted to do that *now*
<mzanetti> dandrader: do you perhaps have some rtm packages with that enabled?
<dandrader> mzanetti, I don't
<mzanetti> I don't even know how to enable it...
<tsdgeos> what is this thing? https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/231726
<tsdgeos>  Proposed by Gerry Boland on 2014-08-21 ?
<tsdgeos> greyback: â Â¿
<greyback> tsdgeos: yeah, it's taken a while...
<greyback> tsdgeos: it's ready to review, that and it's children. Saviq did a review ages ago, but found an issue that AP tests would hang.
<greyback> Reason that it hung was because of the dash dbus blocking the mainloop thing
<greyback> so now that fix landed, can now try land this!
<Saviq> yeah, let's
<tsdgeos> Saviq: you taking care or want me to have a look?
<Saviq> tsdgeos, feel free, /me nursing silos still
<tsdgeos> ok
<kgunn> mterry: so rick said he never saw the poweroff dialog, but did experience the busy/slow resume
<Saviq> kgunn, looks like the same that mterry experienced then https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1410830/comments/2
<ubot5> Launchpad bug 1410830 in unity8 (Ubuntu) "Shutdown dialog appears on resume, after a long delay in screen turning on" [Undecided,In progress]
<Saviq> mterry, do we even want the band-aid then?
<mterry> Saviq, I missed kgunn's comment that you are responding to
<Saviq> <kgunn> mterry: so rick said he never saw the poweroff dialog, but did experience the busy/slow resume
<mterry> Saviq, I believe Rick was testing with the band-aid
<Saviq> mterry, right, my comment was more about your experiences then
<mterry> Saviq, Rick had previously reported being able to reproduce the shutdown dialog even with the MP that landed in rtm.
<mterry> Saviq, so the difference now between him not reproducing seems to be the band-aid...  So I'd vote +1 for band-aid since it isn't making anything *worse* and might be helping
<Saviq> that is true
<mterry> Saviq, I guess the result of my findings in comment2 you linked is that the band-aid should be attached to Rick's bug, not mine
 * mterry adjusts the LP connections
<kgunn> mterry: yep, +1, i saw we get that code reviewed (just a couple of lines) and landed
<Cimi> tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that?
<tsdgeos> Cimi: there's less mem usage, but wouldn't say it's noticeable
<Cimi> sorry I dropped
<Cimi> tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that?
<Saviq> <tsdgeos> Cimi: there's less mem usage, but wouldn't say it's noticeable
<Cimi> well. less is good no?
<Saviq> dednick, there's FTBFS with your rtm branch, could you have a look please?
<Cimi> tsdgeos, one thing I saw when playing with signals, is that we send signals to the whole list of scopes
<dednick> Saviq: sure
<Cimi> tsdgeos, like a openScope sends stuff to all of them
<Cimi> we need to take that into account when we connect to those
<Cimi> if we have like 20+ scopes all doing stuff when an event occurs
<sil2100> j ubuntu-meeting
<sil2100> Crap...
<dednick> Saviq: fixed.
<tsdgeos> Cimi: hmm openScope sends signals to what?
<Saviq> dednick, fast ;)
<dednick> just forgot to remove a include :)
<Cimi> tsdgeos, nevermind might be wrong on that
<Cimi> tsdgeos, seems like was some debugging leftover
<tsdgeos> greyback: do we still need the  QTimer::singleShot(0, this, SLOT(create())); in https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/231726 ?
<greyback> tsdgeos: no, that shouldn't be needed. Will remove
<greyback> tsdgeos: pushed
<tsdgeos> tx
<Saviq> dednick, "modelactionrootstate.cpp: multiple new lines at end of file"...
<dednick> Saviq: fixed
<Saviq> dednick, thanks
<Cimi> tsdgeos, Saviq I'd like to call openScope(scope) from tst_Dash.qml to open a non-fav scope, do you know easily how I could get the argument scope?
<tsdgeos> Cimi: the fake scopes have a get scope i think
<Cimi> mmm
<tsdgeos> yeaj
<Cimi> yeah get scope
 * Cimi tries
<tsdgeos> that may only return fav scopes though
<tsdgeos> Cimi: getScopeFromAll
<Saviq> greyback, testing wakelock here, krillin/vivid, anything special I should test? IIUC the camera and media issues were not visible outside of krillin/rtm?
<greyback> Saviq: I could repro the camera issue on stock vivid
<greyback> Saviq: the impact is pretty minor otherwise
<greyback> keep an eye on "sudo power-cli list" - it should list nothing 3 seconds after display off
<Saviq> greyback, 1.5s, got the lower timeout in that silo as well ;)
<greyback> Saviq: ah ok
<Saviq> ok, done
<Saviq> greyback, btw, noticed an interesting hack in unity-scope-click
<Saviq> greyback, they added a moot autopkgtest to just go through building the package, which runs the usual unit tests
<Saviq> greyback, sounds like qtmir would be a good candidate for that
<greyback> Saviq: I'll add it to my list ;)
<greyback> Saviq: em, where do I see it?
<Saviq> greyback, https://code.launchpad.net/~saviq/qtmir/add-autopkgtest/+merge/246625
<greyback> Saviq: oh thanks
<Saviq> greyback, to test: `adt-run .// --- schroot vivid-amd64-shm`
<Saviq> vivid-amd64-shm being an available schroot
<Saviq> note bug #1396955 if you use byobu
<ubot5> bug 1396955 in autopkgtest (Ubuntu) "adt-run fails if sourcing ~/.profile fails" [Medium,Triaged] https://launchpad.net/bugs/1396955
<dandrader> Saviq, when a process crashes a coredump is automatically generated, right? do you know where it is stored? will this whoopsie thing clean it up?
#ubuntu-unity 2015-01-16
<Tylershep> Hey guys, Im a long time user of Ubuntu and Jim have a suggestion for the design team. Why is the menu bar brown by default when the HUD, etc. are transparent?
<Tylershep> I, not jim*
<Wellark_> seems ALT+<num> combinations in gnome-terminal are broken in 15.04..
<Wellark> who are working on unity7 these days?
<Wellark> Saviq: do you know? --^
<Saviq> Wellark, Trevinho could be your first target
<Wellark> Saviq: thanks!
 * Wellark goes to calibrate the homing missile
<Wellark> oh, it seems new default shortcuts have been added to gnome-terminal to switch between it's tabs that conflict with irssi
<Wellark> got my irc navigation working again by removing the shortcuts
<Saviq> greyback, hey, I'm gonna need you to ACK https://code.launchpad.net/~unity-team/qtmir/rtm-20150116/+merge/246680, especially the .pro changes, as qtmir/rtm is still on qmake
<greyback> Saviq: am on it
<Saviq> greyback, no pressure, though, rtm is closed stil
<Saviq> just wanted to cut your work for next week
<greyback> because I don't have enough to be doing?
<Saviq> it was the collective "your"
<Saviq> the Royal, even
<Saviq> greyback, and I know you're slacking, really, sunbathing all the time
<greyback> in Ireland. Yeah totes
<seb128> speaking about slacking, how is fixing qtmir/gtk going? ;-)
<seb128> I see a branch up to review, who should be reviewing that? Saviq?
<Saviq> whooo?
<greyback> seb128: I asked bregma to give it a look, since it undoes a lot of what he did to enable unity8 on desktop
<greyback> not heard anything since
<seb128> ok
<seb128> I can ping him later ;-)
<greyback> seb128: you're welcome to test it. I tried it on my nvidia box, amd laptop, in emulator and on phone. But as the fix confuses me, I want a second opinion
<Saviq> I'll try it out anyway
<seb128> greyback, do you it in a ppa/silo?
<greyback> seb128: no
<seb128> would make testing easier... :-)
<greyback> sure, I just feel like that's abusing the silo system, just to test some code on all platforms
<Cimi> hey Saviq, you have few mins?
<mzanetti> Cimi: hey ho. where are we with this one? https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400
<mzanetti> the one test failure isn't related
<Saviq> Cimi, before standup enough?
<mhall119> are we going to fix the screenshot volume notification bug before Bq ships?
<Saviq> mhall119, hopefully yes
<mhall119> \o/
<Saviq> mhall119, we'll change the shortcut to be power, then volume
<Saviq> (while holding power)
<Saviq> this way we don't have to delay any events
<Cimi> Saviq, you know a bit on how we open scopes/close them in the dash or is a alber question?
<Cimi> Saviq, albert
<mhall119> Saviq: nice, that matches the normal Android shortcut too doesn't it?
<Saviq> mhall119, no idea :)
<Saviq> Cimi, I do, what up?
<Cimi> Saviq, so to me it looks like we should call closeScope on the temp scope that opened the new scope (we're not doing it now)
<Cimi> Saviq, so if we open the cinema scope from the store, then we should close the store in background, right?
<Saviq> Cimi, yes, we're kind-a doing this, the cinema scope replaces the store scope
<Saviq> Cimi, but you're right, if we're not closing it, we should
<Saviq> Cimi, and the preview
<Cimi> Saviq, I don't think we do, I made make testDash crash :D
<Cimi> with Scope::closeScope got wrong scope in closeScope
<Saviq> Cimi, there might be a race here indeed
<Cimi> I think
<Saviq> Cimi, because by the time you closeScope, you already got a new scope from openScope
<Cimi> I put code in lp:~cimi/unity8/fix-open-new-scope-from-tmp
<Cimi> yeah
<Cimi> I didnt add closeScope
<Saviq> Cimi, you should, in onOpenScope, check if you have a scope open and close it before doing anything else
<Cimi> I have this crash when I tap back from the last scope I opened
<Cimi> Saviq, question is: how do I know if this scope is favourited or not?
<Saviq> Cimi, you only get non-fav in openScope
<Saviq> fav you get in gotoScope
<Cimi> ok cool
<Cimi> Saviq, what should call activate for scope?
<Saviq> Cimi, activate?
<Cimi> Saviq, fake_scope complains that the argument of the scope to close is not m_openScope
<Cimi> Saviq, m_openScope looks like is set always to mockScope9
<Cimi> from a method called activate
<Saviq> Cimi, sounds like you'd need to read the code for the tests, I don't remember exactly what happens there
<Cimi> Saviq, nothing calls activate from tests...
<Cimi> Saviq, it was probably there for legacy or dunno
<Cimi> Saviq, I don't know why closeScope has this check for openScope, that;s why I asked
<Saviq> Cimi, can you point me at some code in particular?
<Cimi> Saviq, fake_scope.cpp
<Cimi> Saviq, line 211
<Guest4292> Saviq: enjoy o/
<Guest4292> why am i guest4292 bah
<Saviq> Cimi, I'd say that closeScope is expecting that you'll always open, close, open, close
<Saviq> Cimi, never open, open
<Saviq> which kinda makes sense
<Cimi> Saviq, but open does what?
<Cimi> Saviq, from Dash.qml seems like just scopeItem.scope = scope;
<Cimi> nothing else
<Saviq> Cimi, yeah, the fake scopes were probably not made to support multiple different scopes through openScope
<Saviq> Guest4292, you might wanna go '/nick kgunn' :)
<Saviq> and thanks :)
<Guest4292> Saviq:  :) ...had to go look up my password
<Guest4292> bah...
<Guest4292> did it again
<Saviq> ah NickServ, you old rat
 * Saviq back later today to see what died
<Saviq> \o/
<kgunn> lol
<kgunn> hopefully nothing
<Saviq> kgunn, mzanetti's on the rtm silos, so we're safe :)
<Saviq> o/
<kgunn> Saviq: my wife the old gymnast says "remember, you gotta _set_ the backflip"
<Saviq> kgunn, you're going to have to translate that into dumbese
<davmor2> Saviq: One Doesn't Simply Backflip......One has to _set_ it up ;)
<Saviq> what malareky
<Saviq> *malarkey, even
<Saviq> davmor2, context: https://owncloud.sawicz.net/public.php?service=files&t=b8143833369f9d5f0b450ef8c7e79e67&path=%2F&files=IMG_0392.MOV&download :P
<Saviq> /out
<davmor2> Saviq: ouch that's gotta hurt at somepoint :)
#ubuntu-unity 2015-01-17
<Bex> Hi! I'm trying to use the guide for setting up a unity8 dev environment, but the guide found here: http://unity.ubuntu.com/getinvolved/development/unity8/ seems out of date.
<Bex> Is it ok to ask questions about that here?
<Bex> Guess it is weekend for most ppl...
#ubuntu-unity 2016-01-18
<flux__> good morning all
<flux__> good morning
<flux__> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535058
<ubot5> Launchpad bug 1535058 in unity8 (Ubuntu) "applications close instantly when launched from the launcher or dash" [Undecided,New]
<faenil> Saviq: fresh Xenial setup, unity8-desktop-session-mir installed, log out, log in, black screen
<faenil> unity8 says "QXcbConnectio: cannot connect to display"
<faenil> or something along those lines
<faenil> I have the bt, journal, etc in the .crash file
<faenil> After reboot, it works
<faenil> let me know if you want a bug for that ;)
<pflux__> faenil, can you reproduce this bug? #1535058
<faenil> pflux__: I have that on phone already
<faenil> and there is a bug for it
<pflux__> faenil, oh :>
<pflux__> me trying on the phone
<faenil> https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1527737
<ubot5> Launchpad bug 1527737 in qtmir (Ubuntu) "Apps do not start if restarted quickly after closing" [High,In progress]
<faenil> pflux__: yes, they don't start at all when launched from apps scope, on this laptop
<pflux__> faenil, thanks :D confirmed then
<pflux__> same here on this desktop
<faenil> now I've just pressed Log Out, and I got a black screen...
<pflux__> but.. if i launch the app from a VT it does open
<pflux__> :/
<pflux__> black screen sucks
<pflux__> mzanetti, do you have any idea what it's going on? is unity8 or qtmir? ^^
<faenil> mzanetti: is the logout thing a known issue?
<faenil> oh no, the logout bug overwrote the .crash I had from the previous bug :/
<faenil> anyway, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535297
<ubot5> Launchpad bug 1535297 in unity8 (Ubuntu) "Unity8 crashes on session logout on desktop" [Undecided,New]
<tsdgeos> davmor2: ping
<davmor2> tsdgeos: hello
<tsdgeos> davmor2: what's the hardware you use for the video of https://bugs.launchpad.net/ubuntu/+source/unity-scope-mediascanner/+bug/1517830 ?
<ubot5> Launchpad bug 1517830 in unity8 (Ubuntu) "In landscape mode the music listing jumps when touched" [High,Triaged]
<tsdgeos> and can you reproduce it every time'
<tsdgeos> ?
<davmor2> has a look at the bug to remind himself
<oSoMoN> greyback_, hey man, are you around?
<greyback_> oSoMoN: yep, here
<oSoMoN> greyback_, Iâd very much welcome a review of https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515 , when you have a moment for it
<davmor2> tsdgeos: Flo but is happens on mako krillin and arale too just not to the same extent as flo
<tsdgeos> davmor2: ok, just reproduced on Flo, you get it on the phone too? even if it's on portrait'
<davmor2> tsdgeos: it's is more noticeable on Flo because of the landscape over protrait mode
<davmor2> tsdgeos: yeah if you open an album in the scope you can see the top one or two track if you tap on the top one it jumps up to display as many of the track as it can rather than just play that track
<tsdgeos> right
<davmor2> tsdgeos: you just don't notice it as much as on flo because of the mode and display or at least you don't think about it as much
<davmor2> tsdgeos: I think it is because on flo you already see a lot more of the track than you do on the other devices so you think it should just play where as it might make more sense when you can only see 1 or2 of the track list to move up to show all the tracks maybe :) Not sure anyway :)
<tsdgeos> yeah i need to check
<tsdgeos> i mean at least it should play and scroll
<tsdgeos> not just scroll
<davmor2> tsdgeos: yeap
<davmor2> that would be an improvement
<Daekdroom> Does Unity8 work with the proprietary nvidia drivers?
<dandrader> Daekdroom, the right question is: "does Mir work with proprietary nvidia drivers?" better ask that on #ubuntu-mir
<Daekdroom> dandrader, Oh, I see. I wasn't aware of that channel.
<Saviq> ltinkl, http://doc.qt.io/qt-5/qwindow.html#Visibility-enum
<tsdgeos> pstolowski: i was wondering, could you install libglib2.0-0-dbg on the phone where you have the trouble so that the backtrace of thread 1 gets a bit longer?
<pstolowski> tsdgeos, sure i can do that, no problem
<pstolowski> trying silo 36 now
<Saviq> Trevinho, have you tried pressing alt+tick on the desktop tile in alt-switcher recently? ;)
<Trevinho> Saviq: mh, I think I did... why?
<Trevinho> Saviq: getting crashes or what?
<Saviq> Trevinho, yeah :)
<Saviq> tsdgeos, I *think* it was GenericScopeView::test_searchQuery()
<Trevinho> Saviq: oh, if you get a backtrace let me know...
<Saviq> Trevinho, bug #1535460
<ubot5> Error: Launchpad bug 1535460 could not be found
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/tryCompareFunctionInsteadOfWhile/+merge/283012
<Saviq> camako, https://bugs.launchpad.net/avila/+bug/1535397
<ubot5> Launchpad bug 1535397 in unity8 (Ubuntu) "Implement support for QWindow::visibility set to Automatic" [High,Triaged]
#ubuntu-unity 2016-01-19
<lpotter> why are some windows full screen and others are just a slice on the right side on tablet? it's confusing and annoying
<lpotter> is that a bug or feature?
<davmor2> lpotter: it's sidestage it is phone sized apps open in it and then you can have for example webbrowser and notes open together on one screen
<lpotter> it seems random and confusing
<faenil> how do I change display resolution in unity8 on desktop? :/
<faenil> lpotter: I think at the moment it's the app that specify its sidestage behaviour using special tags in .desktop
<faenil> but the future is "all apps should be able to switch to fullscreen or sidestage"
<faenil> not sure about that though
<flux__> faenil, right X-Ubuntu-StageHint=SideStage
<flux__> yay libertine updates
<mterry> ltinkl, I just noticed that the silo finished building sometime yesterday  :)
<mterry> tedg, the debian/libubuntu-app-launch2.symbols file needs updating in your app-object branch to include all the c++ api
<tedg> mterry: Ah, yeah.
<tedg> mterry: Is there an easy way to get the c++ symbol list?
<tedg> mterry: Usually for C I just look at the diff that the deb packaging stuff prints out.
<mterry> tedg, fakeroot dh_makeshlibs | sed -e 's/^\+ \(.*\) \(.*\)/\+ \1 0replaceme/' -e 's/\([+-]\) \(_.*\) \(.*\)/\1 (c++)"\2" \3/' | c++filt > /tmp/diff_for_symbols
<mterry> tedg, from https://wiki.ubuntu.com/DailyRelease/FAQ
<tedg> mterry: Sweet, thanks!
<mterry> tedg, http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/desktopfilereader.h
<mterry> tedg, that's the list of info we pull from desktop files
<mterry> tedg, read http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/desktopfilereader.cpp for the actual keys read that correspond to that API
<tsdgeos> cimi: you can see in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+packages it's still being buit
<tsdgeos> built
<tedg> mterry: Really? What do you guys use exec() for?
<mterry> tedg, ... seemingly nothing I could find.
<mterry> tedg, skip that one for now.  maybe we used it in a hack in the past
<tedg> mterry: K
<flux__> X-( https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535058
<ubot5> Launchpad bug 1535058 in unity8 (Ubuntu) "applications close instantly when launched from the launcher or dash" [Undecided,Confirmed]
<mterry> tedg, we do have some code that supports legacy ways of launching apps in qtmir -- those do check the process's command line and try determining desktop file from desktop_file_hint and parse it
<mterry> and stage_hint
<mterry> tedg, how common is that these days?  Can we just drop it?
<mterry> tedg, we have two special checks for maliit-server and qt5/libexec/QtWebProcess
<tedg> mterry: I think we can just drop it, I don't know of any users of it today.
<tedg> mterry: We should probably ping someone like greyback or Saviq to see if they know.
<flux__> i use -- --desktop_file_hint=
<tedg> flux__: For what?
<flux__> to launch apps
<flux__> doh
<faenil> mzanetti: has anyone started looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535058 ?
<ubot5> Launchpad bug 1535058 in unity8 (Ubuntu) "applications close instantly when launched from the launcher or dash" [Undecided,Confirmed]
<faenil> we need to usertest core apps, but if unity8 doesn't cooperate... :|
<faenil> Saviq: ^
<oSoMoN> greyback, hey, have you had a chance to take a look at https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515 ? or will you have some time to look at it soon-ish ?
<greyback> oSoMoN: I'll get dandrader to have a look
<greyback> it looks reasonable
<oSoMoN> thanks!
<mzanetti> faenil, don't think so
<faenil> mzanetti: isn't it, like, super critical? XD
<faenil> no apps start, at all :D
<mzanetti> what?
<faenil> mzanetti: have you read the bug? :D
<mzanetti> oh, I thought it'd be the one where they stop when launched directly after closing
<flux__> mzanetti, no! they don't launch at all
<flux__> X-(
<faenil> mzanetti: no, they don't launch at all, this is another bug
<oSoMoN> dandrader, remember bug #1459362 ? IÂ could use your help in understanding why a bunch of touch events go to the item below a SwipeArea before a drag is detected
<ubot5> bug 1459362 in webbrowser-app (Ubuntu) "SwipeArea lets touch events through when a drag is detected" [High,New] https://launchpad.net/bugs/1459362
<dandrader> hmm
<dandrader> oSoMoN, oh, so you got a minimal test app. good progress
<oSoMoN> dandrader, yeah, itâs much easier (and more urgent too) now that SwipeArea is a public component :)
<Saviq> @unity: I either broke Unity8 CI, or I made it faster, we'll find out soon ;)
<dandrader> oSoMoN, commented on the bug
<oSoMoN> dandrader, thanks, IÂ commented back
<mterry> tedg, in you app-object branch, does IconPath ever be relative (i.e. a theme icon name)?
<tedg> mterry: Right now I'm just passing what the desktop file has.
<tedg> mterry: I've debated about that, but icon themes is kinda a pain.
<mterry> tedg, looks like you make a full path out of what the desktop file has..
<tedg> mterry: But I think we're gonna have to handle that, because you wouldn't know the data paths for the libertine icons.
<tedg> mterry: More meaning of resolving the icon themes than full/relative
<tedg> Paths are easy, icon themes are not :-)
<mterry> tedg, right...  But we presumably need icon theme support -- we don't know size we want ahead of time
<faenil> dandrader: oSoMoN since you're talking about letting events through
<faenil> dandrader: oSoMoN please take into account that you might have a scrollbar on any edge of the screen, and the scrollbar is draggable even on touch when the content is > 10 pages
<mterry> tedg, something like if (fullPath) { return iconPath; } else { return "image://theme/" + iconPath; } is what I would expect me to do in qtmir (or UAL to do itself)
<faenil> dandrader: oSoMoN so the shorter delay before scrollbars gets events, the better...at the moment I see a big delay between the moment I drag the scrollbar and the moment it actually moves, and I'm thinking it's because swipearea is blocking events at the beginning while it's deciding if it's a drag
<oSoMoN> faenil, in the case of the browser we should be safe, as oxideâs scrollbars are not draggable
<dandrader> faenil, because that app that has scrollbars doens't know how to handle touch cancelation events, thus unity8 has to withhold the touch events until it's sure it's not a drag
<dandrader> faenil, sending touch/gesture cancellation events to apps hasn't been done yet.
<faenil> dandrader: wait, I don't get it. Who should be sending touch cancel?
<dandrader> faenil, unity8
<dandrader> faenil, if the SwipeArea in question live in unity8, that is (the left, right and top edges)
<dandrader> s/live/lives
<tsdgeos> cimi: silo 54
<cimi> tsdgeos, yeeep
<faenil> dandrader: so, let's assume the usecase is the user is trying to grab the scrollbar
<faenil> what do you see as flow of events?
<faenil> swipearea will get the events first, right? because it's in unity
<faenil> i.e. on top of everything
<dandrader> faenil, yes
<faenil> so, how do you see that working good while the user is trying to grab the scrollbar?
<faenil> working well*
<dandrader> faenil, Then unity8 has a TouchGate in front of the app window which will withhold touch events from it until it's notified that the app has gained ownership over then (because the SwipeArea decided the touch is not performing a drag)
<faenil> exactly, so, swipearea has to decide that it's not a drag first. But that's what I see happening,
<faenil> the scrollbar gets events with a big delay at the beginning
<tedg> mterry: Sorry, got distracted. The problem is that you don't know the icon theme search path.
<tedg> mterry: And there could be a bunch of icon them roots.
<faenil> and I just wanted to let you guys know that and see if we can find a better solution, because the delay is suboptimal
<tedg> mterry: So you need to effectively adjust your XDG_DATA_DIRS to match those roots.
<dandrader> faenil, no way around it unless the app is able to touch cancellation events. but we don't have written support for it yet
<tedg> mterry: Which is kinda sucky.
<dandrader> faenil, no way around that delay near the edges, I mean
<faenil> dandrader: I still don't see why touch cancellation would improve that
<mterry> tedg, like a libertine app might have a whole icon theme inside it?
<mterry> tedg, so we need rooted icon themes?
<dandrader> faenil, but mouse events are not delayed. so dragging a scrollbar near the screen edge is immediate
<tedg> mterry: No, the libertine container would. And we'd have potentially multiple containers.
<mterry> tedg, oh one global container?
<tedg> mterry: So think that you could have a vivid and a trusty one.
<mterry> ah right
<tedg> mterry: Or three vivid ones, just for fun.
<faenil> dandrader: but mouseevents are only synthesized from touch if touch is not handled
<mterry> tedg, so we *could* modify our icon lookup code to look in those.  but we really only want to do that if the app is from that container
<faenil> dandrader: I'm talking about draggin scrollbar with a touch device, mind you
<faenil> we're talking about touchscreen
<mterry> tedg, you could give us something like image://libertine-theme/container-name/icon-name
<mterry> tedg, and adjust the icon lookup parser to understand that
<tedg> mterry: Yeah, so the issue I ran into there is that it seems that the Qt code for icon theme lookup is kinda singleton based. Which makes sense for /usr/share/icons â¦
<dandrader> faenil, let me rephrase: " but mouse events are not delayed. so dragging a scrollbar near the screen edge with a mouse is immediate"
<tedg> mterry: So we end up chasing down the rabbit hole
<faenil> dandrader: I got that...but the only way to get mouse events is to get events synthesized from touch events, and that won't happen until swipearea lets them through
<faenil> right?
<faenil> because whenever you use the touchscreen to grab the scrollbar, swiparea grabs touch
<mterry> tedg, well...  for Ubuntu SDK apps, we must end up pointing at a single icon right?
<mterry> tedg, maybe libertine apps can just give us a single icon too
<faenil> dandrader: oh I missed the point you edited. Yeah, it will be immediate with mosue
<mterry> tedg, but maybe still allow desktop files to use a icon theme name, since it's technically permissible
<faenil> mouse*
<dandrader> faenil, I'm not talking about synthesizing mouse events out of touch events. I was talking about mouse events coming from an actual mouse device
<tedg> mterry: Yeah, so perhaps we'll solve the icon theme situation just in the libertine case and give themes in the legacy root case.
<mterry> tedg, when they are on the system
<dandrader> faenil, yes
<faenil> dandrader: ok, we don't care about that ;)
<mterry> tedg, yeah
<tedg> How many apps do we have installed as debs? Just system-settings?
<faenil> dandrader: we care about improving the touch UX :D anything I or you can do
<faenil> ?
<dandrader> faenil, nothing you can do about that delay near the screen edges
<mterry> tedg, more but I don't remember list
<mterry> tedg, like 5 or less
<mterry> 5 or fewer  :)
<faenil> dandrader: alright..
<dandrader> faenil, to solve that we (unity8 team, maybe mir team as well)  have to implement detecting support for touch cancellation from apps and sending them if the do support it
<faenil> dandrader: again :D please explain how touch cancellation would improve that, because I Don't get how
<tedg> mterry: Looks like on my phone: dialer, mediaplayer, messaging, system settings and browser.
<dandrader> faenil, and then for apps to change their code to handle touch cancellation if they want to get rid of that delay
<mterry> tedg, 5!  bam
<tedg> mterry: Curious if we can just change those to not use icon themes :-)
<faenil> dandrader: why should unity send a touch cancellation if swipearea is still thinking what do with the events?
<mterry> tedg, stop trying to kill icon themes
<dandrader> faenil, no
<dandrader> faenil, unity8 would send touch events to app immediately, even though unity8's edge swipeArea is still doing gesture detection
<dandrader> faenil, then, if unity8's edge SwipeArea decided that this is an edge drag gesture, unity8 would send a touch cancellation event to the app
<faenil> dandrader: ah okay! yeah, then I get you of course
<dandrader> faenil, meaning that the app would no longer get evens from that touch point and that it should undo any changes caused by that touch so far
<faenil> sure, sure
<faenil> I misunderstood you before
<faenil> I didn't see how it could work with the current swipearea, and in fact it wouldn't. Once unity8 starts handling that, swipearea impl will have to be changed as well
<faenil> to let events through from the beginning
<faenil> and then unity8 will send touchCancel if needed
<dandrader> faenil, please file a bug requesting support for gesture cancellation to apps and stating why you need that (eg those touch-operated scrollbars)
<faenil> dandrader: right?
<dandrader> faenil, so we can properly prioritize that work
<dandrader> faenil, or actually, the bug should be simply about complaining that touch events near edges come with a delay
<faenil> I have to test that a bit better before filing it, once I'm pretty sure it's swipearea's fault I'll file it
<dandrader> faenil, sending gesture cancellation to apps is orthogonal to SwipeArea implementation
<dandrader> faenil, those are two separate things
<faenil> dandrader: yes, I get that
<faenil> dandrader: I'm talking about letting events through from the beginning
<dandrader> faenil, in unity8 code, TouchGate in SurfaceContainer.qml is the one withholding the touch events from the app
<faenil> once unity8 handles touchCancel, swipearea still needs to be modified to let events though from the beginning, right?
<faenil> ah ok
<faenil> I'll have a look at that then, thank you
<dandrader> faenil, read TouchGate's documentation
<faenil> yeah then TouchGate will have to be modified. I thought it was swipearea itself blocking them
<faenil> ok
<faenil> will do
<cimi> pstolowski, hey, can you send me/link me the scope with the filters? (click pkg)
<pstolowski> cimi, lp:~stolowski/+junk/scope-filters in click/ folder
<dandrader> faenil, no. what has to be done is that SurfaceContainer won't put a TouchGate in front of the app surface if the app surface tells us it support gesture cancellation
<dandrader> s/support/supports
<faenil> dandrader: yeah, clear now that I've read TouchGate's (short) doc
<faenil> :)
<faenil> and that explains what I was seeing as well
<faenil> all events are stored and replayed
<dandrader> faenil, only the ones for which ownership hasn't been solved yet, which are the ones that go through those SwipeAreas that unity8 have near screen edges
<faenil> dandrader: yes
<faenil> yes
<mterry> patriciadavila, can you point me to the spec for how the dash is supposed to look / behave in windowed mode?
<faenil> dandrader: so I guess SwipeArea doesn't get ownership until it's sure it's a drag
<dandrader> faenil, yes
<patriciadavila> mterry: this is the presentation that describes the journeys - https://docs.google.com/presentation/d/1uSTcU-My6VD94BEISs_Y30O-mJG26I_czuXCKI4BzFQ/edit
<patriciadavila> mterry, we'll have a session about this tomorrow, you are welcome to join if you have any questions
<mterry> patriciadavila, I have one question -- not about the content of the scopes window, but about the window itself -- like close / minimize / maximize buttons
<mterry> patriciadavila, which should it have / how should they behave?
<patriciadavila> mterry: maybe vesar can help you better with that? The dash window should have/behave like any other window afaik
<oSoMoN> dandrader, pardon my ignorance wrt touch even handling, what sort of event/notification do we get when a touch is grabbed by a SwipeArea?
<faenil> oSoMoN: I'm pestering him already :D
<mterry> patriciadavila, asked him, thanks
<oSoMoN> dandrader, faenil: shouldnât we be getting a TouchCancel event, or something like that?
<patriciadavila> mterry: yw
<faenil> oSoMoN: if I understood correctly, in the current state of things you won't get events until SwipeArea decides you shall
<faenil> and at that point, you'll get all of them at once, in the correct order
<faenil> that is because there's TouchGate in unity8 that prevents the touch events from getting to the app
<faenil> in the ideal future, the app will signal that it can handle touchCancel (I think this should always happen, not on demand), and unity8 will remove TouchGate
<dandrader> oSoMoN, http://doc.qt.io/qt-5/qquickitem.html#touchUngrabEvent
<faenil> at that point, both the app and SwipeArea will get the touch events, but if SwipeArea then decides that it has detected a drag, it will send touchCancel to the app
<faenil> and the app will behave accordingly
<dandrader> faenil, oSoMoN is talking about an in-app SwipeArea, not about a SwipeArea in unity8
<dandrader> faenil, those are two different scenarios
<faenil> sorry, didn't have context :)
<faenil> dandrader: well, it's the same except there's no touchgate already, right?
<faenil> because the app doesn't have it
<dandrader> oSoMoN, if can also listen to TouchOwnership events if you want to. but that's a ubuntu-ui-toolkit specific event type
<dandrader> s/if/you
<mterry> oSoMoN, what's the plan for remembering passwords in webbrowser-app?  Either internally or allowing some sort of plugin like lastpass to operate?
<oSoMoN> mterry, a while ago a lastpass extension was mentioned, but oxide doesnât have an extension mechanism, so that didnât go anywhere, Iâm not sure if thereâs a concrete plan at all
<mterry> oSoMoN, is an extension mechanism a no-go at all, or one of those "we haven't done it yet, but want to" things?
<oSoMoN> mterry, I think itâs pretty much a no-go, it would be a huge amount of work for which we simply donât have resources
<mterry> oSoMoN, and we don't plan remembering passwords internally?
<oSoMoN> mterry, Chris Coulson should be able to confirm, you can find him on #oxide
<mterry> oSoMoN, it's just another pain point for me on the desktop.  Everytime I want to log into my bank or whatever, I jump to Firefox to use lastpass
<oSoMoN> mterry, IÂ guess remembering passwords internally is the only way forward, but I donât think itâs even been planned/scheduled
<faenil> dandrader: so SwipeArea gets touch, it signals itself as candidateOwner, at that point touchgate will block those points, because it won't be able to get ownership on that, is that right?
<oSoMoN> mterry, I very much understand your frustration
<faenil> otherwise, if swipearea ignores, touchgate manages to get ownership, and that means it can send the events through
<mterry> oSoMoN, it's fine personally.  But just means I don't test as many websites   :)  Although I believe mint.com at least doesn't work in oxide anyway
<dandrader> faenil, pretty much it
<faenil> dandrader: had a quick look at both dda and touchgate, but didn't read thoroughly
<faenil> but that looks sensible
<faenil> dandrader: so all the touch events that have a candidate owner are stored and blocked. At one point SwipeArea either drops itself as candidate owner, or requests full ownership. If it drops itself as candidate owner, touchgate replays all the stored events, otherwise the events are removed from the queue
<dandrader> faenil, yes
<faenil> dandrader: ok, cool. Thanks for the help!
 * faenil leaves the office
<mterry> josharenson,  --no-tgz-check
#ubuntu-unity 2016-01-20
<oSoMoN> Saviq, should IÂ request a silo for https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515 , or do you prefer to add it to an existing/future silo along with other qtubuntu changes?
<Saviq> oSoMoN, I'll land it
<oSoMoN> Saviq, thanks
<dandrader> greyback, got a qtmir crash in MirBufferSGTexture::bind() while running uitk AP tests with *trunk*
<oSoMoN> Saviq, greyback:Â looking at bug #1534682, it seems that when connecting an external monitor to a phone via slimport the screen information is not updated, could you guys help me debug/fix that issue?
<ubot5> bug 1534682 in Canonical System Image "Not requesting desktop content when connected to monitor" [High,Confirmed] https://launchpad.net/bugs/1534682
<greyback> dandrader: eek
<greyback> are you investigating?
<dandrader> greyback, no yet....
<dandrader> *not
<greyback> oSoMoN: have you plugged USB power into the slimport cable?
<oSoMoN> greyback, I donât know as Iâm waiting for my slimport adapter to arrive, the issue was reported by bfiller, let me get him here to comment
<greyback> oSoMoN: how is UA string chosen?
<greyback> the Qt Screens info is not being updated currently
<greyback> if you're relying on that, then that's the problem
<greyback> I'm working on that code right now
<oSoMoN> greyback, based on screen diagonal size
<oSoMoN> greyback, well thatâs good news, do you have an ETA for a fix?
<greyback> oSoMoN: about 1-2 weeks
<oSoMoN> would that qualify for OTA-9.5 ?
<oSoMoN> or too late?
<greyback> that's what I'm trying for
<oSoMoN> excellent!
<oSoMoN> bfiller, greyback was asking earlier whether you had plugged USB power into the slimport cable?
<greyback> nah, ignore that. I misunderstood the issue
<bfiller> oSoMoN, greyback: no I didn't
<greyback> you're getting the external display working, so that's fine
<greyback> main issue is that qt isn't being told the screen changed
<bfiller> greyback: interesting though when launching the browser while the external display is connected it doesn not report the correct screen dimenions
<bfiller> dimensions
<greyback> bfiller: qt just giving you dimensions of one display, not necessarily the right one. Also, many displays fail to report their correct physical dimensions
<bfiller> greyback: ok
<mterry> tedg, when using your app-object branch, imports are a little weird
<mterry> tedg, #include <application.h> isn't very descriptive
<mterry> tedg, and I have to do that because it's not included from the main ubuntu-app-launch.h one
<tedg> mterry: Shouldn't it be "ubuntu-app-launch/application.h" ?
<mterry> tedg, it should be, but you don't have that extra directory.  You have libubuntu-app-launch-2... But that's not for import lines, that's just for the .pc file to set -I for ya
<tedg> mterry: Ah, okay, so it needs to install a layer deeper.
<mterry> tedg, yeah that could work
<mterry> tedg, what's this TypeTagger situation with AppID::package and such?  How do I treat those as strings?
<tedg> mterry: foo.value()
<mterry> tedg, ah thanks
<Saviq> mzanetti, bug #1521518
<ubot5> bug 1521518 in unity8 (Ubuntu) "OSK doesn't come up in login screen if mouse connected on nexus 7" [Undecided,Incomplete] https://launchpad.net/bugs/1521518
<cimi> tsdgeos, Saviq https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1536372
<ubot5> Launchpad bug 1536372 in unity-scope-click (Ubuntu) "Previews don't support two columns layout" [High,New]
<faenil> mzanetti: let me know if you need anything to fix the "no apps start" or if I have to setup usertesting laptop using vivid..
<mzanetti> faenil, I've saw it on cimi's laptop yesterday
<faenil> cool
<faenil> does that mean you'll fix it soon? :D
<cimi> faenil, va' a letto
<cimi> Ã¨ tardi
<cimi> :D
<faenil> cimi: eh c'hai ragione... :P
<mzanetti> isn't it just half past 10?
<faenil> yep
<cimi> that's when mzanetti usually starts hacking indeed :)
<faenil> fighting kernel issues on  nokia n950 :P
<mzanetti> 10... that's when I put the baby to bed
<faenil> just moved gcc to a new versions...and it doesn't boot anymore..(same kernel!)
<faenil> version*
<faenil> mzanetti: anyway, let me know...I don't care about black screen on logout, but not being able to start any app at all is a real blocker
<faenil> usertesting lead wanted the laptop ready tomorrow...
<faenil> of course that's not possible now, but the sooner the better
<mzanetti> faenil, you are usertesting the desktop?
<faenil> mzanetti: yeeeeeees :P
<mzanetti> ok, next time let us know like, say, a week beforehand at least :D
<faenil> mzanetti: I knew it like 3 days ago
<faenil> and I reported that bug, when, 2 days ago? :P
<faenil> the usertesting is next week
<faenil> but the lady has to play with the stuff to write the test plan I guess
<aaronraimist> I am on 16.04 and I am trying to build unity8 but when I do ./run.sh it says "Unity8 is already running, please stop it first"
<mzanetti> aaronraimist, hmm... the run.sh is probably broken... what are you trying to do? just playing around with it, or intending to fix some specific thing?
<aaronraimist> mzanetti: I am trying to fix a task as part of the Google Code-in program.
<mzanetti> aaronraimist, ah ok, what/where?
<aaronraimist> mzanetti: https://bugs.launchpad.net/ayatana-design/+bug/1066963, maybe I should actually be trying to build unity7?
<ubot5> Launchpad bug 1066963 in unity (Ubuntu) "Dash - Update the Dash to use the Ubuntu medium font weight" [Medium,Triaged]
<mzanetti> aaronraimist, right... that bug is about unity7
<aaronraimist> mzanetti: OK, thanks, I'll try to build unity7
#ubuntu-unity 2016-01-21
<faenil> mzanetti: I understand you don't want to commit or you're too busy sprinting...but please at least give me an alternative
<faenil> give me an ETA, or just tell me it's not going to happen and I should try with a tablet instead, or with vivid+ppa, I don't know
<faenil> peace :)
<rhuddie> mterry, hi, I noticed that the 'no sim inserted' page is no longer being displayed in the startup settings wizard
<rhuddie> mterry, do you know is this an intended change, or bug?
<mterry> rhuddie, sounds like a bug
<mterry> ltinkl, do you know anything about this? ^
<josharenson> greyback: what is the env variable? to make qtmir log input events?
<greyback> josharenson: QT_LOGGING_RULES="qQT_LOtmir.*.debug=true"
<greyback> eep
<greyback> josharenson: QT_LOGGING_RULES="qtmir.*.debug=true"
<josharenson> greyback: ah, thanks
<mzanetti> faenil, good morning. will try to get it running here now
<faenil> mzanetti: <3 thanks man
<mzanetti> (fwiw, I still struggle with starting the unity8 session at all)
<faenil> mzanetti: previous issues I had that caused those problems (on other laptops) were due to multiple kms packages installed
<faenil> check /usr/lib/blabla/mir/client-platforms
<faenil> ideally you should only have one, afaik
<faenil> if you have more , uninstall those packages
<mzanetti> I do have 2
<faenil> mzanetti: also check if you have mesa (or mesa2) mir platform installed
<faenil> I think that was causing issues as well
<mzanetti> faenil, that must be it, yes
<mzanetti> thanks a lot
<mzanetti> trying now (did an upgrade first)
<mzanetti> rather still doing... sloooow network
<cimi> Saviq, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1536372
<ubot5> Launchpad bug 1536372 in unity-scope-click (Ubuntu) "Previews don't support two columns layout" [High,New]
<faenil> mzanetti: np :)
<faenil> at least we save each other's time :D
<dandrader> dednick, https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701
<dandrader> dednick, appQuitsRightAfterBeingSuspended test
<mterry> mzanetti, engine->setObjectOwnership(as, QQmlEngine::CppOwnership);
<mterry> confirmed it works, even before passing the object back to qml
<Pursche01> Hello there, I have what could be a stupid question. I am looking for the correct IRC room to ask about Ubuntu's mouse handling, Unity was listed as the keyboard menu. Do you have any idea where I could ask questions about the mouse?
<mzanetti> mterry, really? I thought the registerSingletonType() wouldn't care about it
<mterry> mzanetti, well I haven't confirmed it's worked in *practice* -- I chased the code and confirmed that someone else on the internet said it works...
<mterry> mzanetti, that's like the same thing
<mzanetti> this usually works, but I think the singleton one is a bit special... you want to try tho
#ubuntu-unity 2016-01-22
<tsdgeos> mzanetti: so it lives here https://code.launchpad.net/~aacid/unity8/avila_apps_scope/+merge/282454
<tsdgeos> mzanetti: http://bazaar.launchpad.net/~aacid/unity8/avila_apps_scope/revision/2118 is the change
<sil2100> Saviq, dednick: hey guys! Anything known about but LP: #1536133 ? I don't see any updates in the bug itself
<ubot5> Launchpad bug 1536133 in qtmir (Ubuntu RTM) "Apps (gallery, camera) still visible in the spread when open from the content picker and cannot be reopen" [High,Triaged] https://launchpad.net/bugs/1536133
<dednick> sil2100: yes. working on it
<sil2100> dednick: any ETA? How serious is this issue in the end?
<dednick> sil2100: need to test the fix i have for it.
<dednick> sil2100: you can work around the issue easily enough by closing the second app from spread.
<mterry> josharenson, https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264
<ubot5> Launchpad bug 1427264 in schroot (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,In progress]
<josharenson> Was there a policy change so that when you lock the phone with the spread open and then unlock the phone, the last opened app shows instead of the spread?
<josharenson> Really in reference to https://bugs.launchpad.net/qtmir/+bug/1353593 as it would make it invalid
<ubot5> Launchpad bug 1353593 in QtMir "last focused app is resumed (active=true) while in spread, after lock & unlock" [Medium,In progress]
<dandrader> josharenson, yeah, I think we explicitly close the apps spread in unity8....
#ubuntu-unity 2017-01-16
<dmj_s76> Trevinho: Thanks for getting the fix committed.
<Trevinho> :-)
<Trevinho> thank you for that
<dmj_s76> Trevinho: Would be really good to get this backported for Xenial.
<Trevinho> dmj_s76: yeah, i've to backport quite some things there..
<Trevinho> let's leave it there for a while to check if there are regressions, then we go for that
#ubuntu-unity 2017-01-17
<dmj_s76> Trevinho: With 16.04.2 being held back, what are your thoughts on trying to get the hidpi fixes in?
#ubuntu-unity 2017-01-18
<kgunn> robert_ancell: hey, could you provide an update for acct svcs stuff wrt u8-session snap?
<robert_ancell> kgunn, I haven't even started on the accounts service stuff
<robert_ancell> kgunn, is that higher priority than the general lightdm work?
<robert_ancell> kgunn, hmm, I don't even have a trello item for that - is that a separate work item?
<kgunn> robert_ancell: oh, you know what, i don't think they meant acct svcs as in store stuff...i think it was like user acct, as in lightdm
<robert_ancell> kgunn, is this about AccountServices working with the current big unity8 snap or the split up snaps (i.e. ligthdm+AccountsService+...)?
<robert_ancell> I'm just looking at what I've got with the current lightdm snap, haven't picked it up since getting back from holiday last week.
<kgunn> i would assume acctsvcs working with big u8 snap....not quite at the point of expecting multiple snaps
<robert_ancell> kgunn, as far as I know I'm not assigned to work on that
<kgunn> robert_ancell: uh-oh, tedg_ and everyone else thot so :)
<robert_ancell> kgunn, do you know where the notes are from the sprint?
<kgunn> robert_ancell: if you know the session https://devices-sprint-2016.pathable.com/
<kgunn> otherwise bregma ^ ?
<kgunn> i think he was running those
 * robert_ancell is looking...
<robert_ancell> kgunn, I'm not finding anything
<kgunn> robert_ancell: i'll check with bregma and mterry tomorrow, i do recall the session
<duflu> tedg_: Would it be a good guess that bug 1654915 is some kind of snap-related change which doesn't work on legacy zesty without snaps?
<ubot5> bug 1654915 in ubuntu-app-launch (Ubuntu) "[regression] ubuntu-app-launch doesn't launch apps any more" [Critical,Confirmed] https://launchpad.net/bugs/1654915
<robert_ancell> kgunn, as I understood it I'm working on the lightdm snap, which became the unity-8-system snap because there were a number of other services that were needed by lightdm. It should be independent to the work to have a unity8 session snap that relies on the services being already installed
<kgunn> robert_ancell: ack, so we can clearly state, no one looking at usr session portion...i think this came up b/c of polkit discussion maybe...but we can cleear up tomorrow
<robert_ancell> kgunn, ok, thanks
<bregma> robert_ancell and kgunn I believe these are the session notes you're looking for https://docs.google.com/document/d/19SuiAye9BPwXA1Sk9QyYvY-y9DLTlmL0YWkrfTYMhv0/edit#heading=h.7xfmabehc9np
<robert_ancell> bregma, did you write those just then? ;)
<robert_ancell> bregma, so is that work now required for the unity8-session snap?
<bregma> I believe that is the work we identified in October, I have no idea what's changed since
<bregma> at least the session was earlier in the week so I was still keeping up with note taking
<bregma> I suppose I need to review some of that with mterry too to see if it's still relevant
#ubuntu-unity 2017-01-19
<blmvxer> Hello I have a few questions about Unity8 and Maliit keyboard
<duflu> blmvxer: Also, most of the team is in Europe so 6+ hours away from coming online :)
<blmvxer> Freaking of course lol
<blmvxer> Hello I have a few questions about Unity8 and maliit keyboard
<blmvxer> Hello I have a few questions about Unity8 and maliit keyboard
<sil2100> Hey guys!
<sil2100> For xenial, I reverted the dbus fix for https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1644323 since it was causing a regression with unity8
<ubot5> Ubuntu bug 1644323 in unity-gtk-module (Ubuntu Xenial) "Installing unity8-session-snap adversely effects unity7" [Undecided,Fix committed]
<sil2100> Now from what Laney mentioned, this was not really an issue with dbus itself but needed some changes elsewere
<sil2100> I would like to get this fixed once again for xenial, but I need someone to make sure it's not breaking unity8 once again
<sil2100> (as per https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1644323/comments/18 )
<ubot5> Ubuntu bug 1644323 in unity-gtk-module (Ubuntu Xenial) "Installing unity8-session-snap adversely effects unity7" [Undecided,Fix committed]
<Saviq> sil2100, I filed this: bug #1654365
<ubot5> bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365
<Saviq> this is *why* Laney's fix broke us
<Saviq> we should probably get robert_ancell to look at it, he might know best how lighdm + dbus works / should work
<rcspam> Hi, my system is Xenial... I have lost all icons (indicators,time,etc) in my unity-panel. This is happened after a stop a fullscreen video. Since, some compiz/unity reset + remove config files doesn't solve the problem. If i am logging to another user, same things. An idea to fix this !!!??? thanx
<sil2100> Saviq: thanks! Could you poke me once this one is resolved? I'd like to re-introduce his change then
<Saviq> sil2100, that said, Laney's change was broken a bit, because restarting dbus didn't work (not sure if that's important, actually)
<Saviq> I mean, it's probably not a real thing, but still it should kinda work
<sil2100> hm, yeah, I would expect that to be working, even if it's not actually used anywhere
<mterry> ltinkl: can I add a couple branches to silo 2272?
<tsdgeos> mterry: he's sick, but i guess yes
<mterry> oh no
<mterry> yeah I also would guess yes -- adding
<blmvxer> Hello, I have a few questions about unity8 and maliit keyboard
<tsdgeos> blmvxer: ask and if someone knows the answer they'll answer, it's better than asking to ask
<blmvxer> Okay, 1:Is there a manual command to force invoke Maliit keyboard?
<blmvxer> 2:Is there a manual way of forcing unity8 into landscape in Ubuntu 16.10(x86)
<tsdgeos> blmvxer: does the indicator rotation count as manual? what device are you running it that is not landscape by default?
<blmvxer> tsgedos: Sadly no. I'm running on a baytrail nextbook and for whatever reason it's stuck in portrait mode
<Saviq> blmvxer, you could modify https://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/DeviceConfiguration.qml
<Saviq> it sounds like whatever orientation value we're getting from the sensor is bogus
<Saviq> blmvxer, as for forcing the OSK up, there's this bug: #1521518 - we've not solved this completely yet
<ubot5> bug 1521518 in Ubuntu UX "No way to invoke OSK when a hardware keyboard is connected" [High,In progress] https://launchpad.net/bugs/1521518
<tsdgeos> blmvxer: Saviq: playing with /etc/ubuntu/devices.conf may work too afaics
<Saviq> right, I was looking for that thing!
<blmvxer> Tried  X-Ubuntu-Supported-Orientations=landscape on Unity8 and Unity8 shell and it rotates for a second then reverts back to portrait
<Saviq> blmvxer, check out what we mentioned aboveÂ â, if you can't get it to work, please file a bug with `ubuntu-bug unity8`
<blmvxer> Saviq: Sorry I switched to unity8 and missed what was posted before
<Saviq> <Saviq> blmvxer, you could modify https://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/DeviceConfiguration.qml
<Saviq>  it sounds like whatever orientation value we're getting from the sensor is bogus
<Saviq>  blmvxer, as for forcing the OSK up, there's this bug: #1521518 - we've not solved this completely yet
<Saviq> <ubot5> bug 1521518 in Ubuntu UX "No way to invoke OSK when a hardware keyboard is connected" [High,In progress] https://launchpad.net/bugs/1521518
<Saviq> <tsdgeos> blmvxer: Saviq: playing with /etc/ubuntu/devices.conf may work too afaics
<ubot5> bug 1521518 in Ubuntu UX "No way to invoke OSK when a hardware keyboard is connected" [High,In progress] https://launchpad.net/bugs/1521518
<mterry> josharenson: fyi I rebased greeter-guest onto your ported branch
<josharenson> mterry: ok, albert approved it yesterday so hopefully it lands soon
<mterry> josharenson: yeah both branches are in same silo, that's what motivated my rebase
<josharenson> mterry: ack
<blmvxer> Okay, I'm using unity8 right now, I modified the QML file to make desktop InvertedLandscape. now it's figuring out the OSK when I undock my device
<blmvxer> Hell I didn't know there was so much I can manualy edit with QML 0_0
<Saviq> blmvxer, patches welcome :)
<Saviq> blmvxer, as for the OSK, the plan was to listen to lid sensor data (iio)
<blmvxer> Saviq: best I can probably do is write a script that reorients and restarts mir. My tablet was hell to even get Ubuntu on lol.
<blmvxer> Saviq: I'm looking at forceOSKEnabled = autopilotDevicePresent() to force OSK in desktop mode as a temp fix for my issue
<Saviq> blmvxer, yeah that's a temporary workaround for sure
<blmvxer> If I was more knowledgable of how Ubuntu was detecting my orientation then I would try to work on it more in depth.  Maybe a new project to work on since I have landscape mode up
<Saviq> blmvxer, we're relying on Qt's sensors API
<Saviq> http://doc.qt.io/qt-5/sensors-backend-topics.html
<blmvxer> Still working on forcing OSK in the desktop shell of unity 8. I came across this line. oskEnabled: (keyboardsModel.count === 0 && screens.count === 1) || forceOSKEnabled
<mterry> mzanetti: I can spend a little time looking at bug 1654306, I need to get back to our snap bugs -- been futzing in pure u8 land too long  :)
<ubot5> bug 1654306 in unity8 (Ubuntu) "Unity8 is not in desktop mode inside the snap session" [High,Triaged] https://launchpad.net/bugs/1654306
<blmvxer> I believe I found some more info on why my OSK doesn't appear
<blmvxer> file:///usr/share/maliit/plugins/com/ubuntu/Keyboard.qml:179 Type KeyboardContainer unavailable file:///usr/share/maliit/plugins/com/ubuntu/KeyboardContainer.qml:22 module "UbuntuKeyboard" is not installed
<blmvxer> Though I have ubuntu-keyboard installed via apt
<blmvxer> Okay so I got maliit keyboard setup in desktop unity 8
<blmvxer> I called maliit-server when docked, removed the physical keyboard
<blmvxer> Then it worked
<mterry> josharenson: what is the end-user-experience that test_changingSessionSticksToUser is testing?
<josharenson> mterry: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1631365
<ubot5> Ubuntu bug 1631365 in unity8 (Ubuntu) "unity8 greeter does not save the last used session" [Undecided,Fix released]
<mterry> josharenson: so it's testing that the session we show when we switch to a user is the same as the session that liblightdm has stored for that user?
<josharenson> mterry: and that the icon matches
<mzanetti> mterry, hey, this seems to be some gsettings issue. I cannot repro, must be racyness
<mterry> mzanetti: I couldn't reproduce either
<mzanetti> seems to happen in like 50% of the cases for Pat, Saviq said it happens more often for him
#ubuntu-unity 2017-01-20
<Blu2> Ever took in consideration to make the top bar transparent and only fill it only when in fullscreen mode in Unity 8?
<Saviq> Blu2, by "top bar" you mean the panel with menus and indicators? depending on the wallpaper, it could be really difficult to make out the details of the icons
<Saviq> and when you expand a menu, would you fill the panel, too? or leave the menu "hanging" in void?
<Blu2> Yeah it obvious has some problems, but if app windows had different colors and the top bar adapting it would be nice, like on andorid and ios
<Blu2> I'm suggesting this for the visual appearance, it's "in" that the DE is as much in the background as possible
<Blu2> like in chromeOS
<Saviq> Blu2, we have a plan for that in the new unity8 interface, but that requires cooperation from the app, so that it doesn't draw when we're drawing indicators next
<Saviq> so it will be opt-in
<Blu2> another idea I had was putting everything (clock, networking, langeugae select notification center etc) as an icon in the launcher
<Saviq> Mirv, hey, did we get the fix for https://bugreports.qt.io/browse/QTBUG-54822 into xenial/overlay's Qt?
<Saviq> mzanetti, is what's written in https://code.launchpad.net/~mzanetti/unity8/appdrawer-improvements/+merge/313139 as commit message all that this branch changes? seems bigger :)
<Mirv> Saviq: no, it's not even in 5.6.2 but in 5.6.3 to be released in a few months. and when I tried backporting the fix to 5.6.1, stuff started exploding in colorful ways. so we are stuck with the slightly config modified arm64 kernels that are installed on builders. however 5.7.1 seems fine so hopefully that means 5.6.3 will be too.
<Saviq> Mirv, right, that just makes us unable to run arm64 CI on xenial :/
<Saviq> ohwell
<Blu2> Will icons be interactive eventually? like calendar showing the actual date
#ubuntu-unity 2017-01-21
<linuxaholic> you guys brokama-heart
