#ubuntu-unity 2012-11-12
<JanC> eh, what happened to the wallpaper plugin in compiz?
<JanC> showing the login screen as "wallpaper" is a bit silly...
<didrocks> hey Mirv
<didrocks> Mirv: the branches that you gave me are building on arm*, right? The FTBFS I'm seeing in the SRU ppa is newer?
<Mirv> didrocks: they build, the FTBFS you're seeing in SRU ppa is precise!
<Mirv> the quantal SRU packages were basic smoketested on arm hardware
<didrocks> Mirv: perfect, all I wanted to confirm, thanks! :)
<Mirv> np
<didrocks> duflu: https://code.launchpad.net/~didrocks/nux/build-nux4.0/+merge/133864 (as you approved the first one)
<duflu> didrocks: Argh. I had no idea nux had a debian/ already
<didrocks> duflu: no worry ;)
<didrocks> duflu: but even without it, we still needed to update the packaging, even if it was in a separate dir
<didrocks> branch*
<ricotz> didrocks, good morning
<didrocks> hey ricotz :)
<ricotz> didrocks, could you reapprove those proposals? https://code.launchpad.net/~ricotz/bamf/replace-user-visible/+merge/131723 https://code.launchpad.net/~ricotz/bamf/g-type-init/+merge/131722
<didrocks> ricotz: sure, done and done :)
<ricotz> thank you!
<didrocks> yw ;)
<didrocks> thanks duflu
<didrocks> Mirv: hum, I'm taking your dee branch
<didrocks> Mirv: take lp:ubuntu/dee but the latest commit
<didrocks> Mirv: and it's telling me that it diverged
<didrocks> Mirv: can you give it a quick look? I'm building the rest of the stack meanwhile
<Mirv> didrocks: hmm
<Mirv> didrocks: in raring it's already in, so I based the dee branch which is aimed for quantal only from lp:ubuntu/quantal/dee
<didrocks> Mirv: waow, that's weird the branch is at the same revision than the -r -2 lp:ubuntu/dee, but it seems the base are different
<didrocks> Mirv: not sure what they did when reboostrapping the raring distro
<didrocks> Mirv: but yeah, using the quantal one works, thanks!
<Mirv> interesting...
<Pandu> hi is there any body to tell me how to install telugu on 12.04 Unity
<Pandu> any body?
<Pandu> exit
<tsdgeos> mhr3: hi, could you go by https://code.launchpad.net/~aacid/dee-qt/support_arrays_and_tuples/+merge/133677 and confirm the fix i did for the memory leak is correct?
<tsdgeos> mhr3: http://bazaar.launchpad.net/~aacid/dee-qt/support_arrays_and_tuples/revision/69 to be exact
<mhr3> tsdgeos, yep, look good
<mhr3> looks*
<tsdgeos> thx
<didrocks> Mirv: can you look at why unity is FTBFS on the ppa, please?
<popey> didrocks, I know Mirv was looking at the arm build failures earlier, not sure on progress yet.
<didrocks> popey: even i386 is failing now FYI
<didrocks> popey: thanks, Mirv, keep us updated please!
<popey> yeah
<popey> i note we're doing make -j2 now.. has that always been the case? I thought we always did -j1.
<didrocks> popey: the packaging supported it for a while, I force -j4 here
<didrocks> popey: where do you see -j2 in the ppa?
<didrocks> we clearly do as we have some deprecation warning
<didrocks> (and they are not at the end)
<didrocks> but not sure where you see this -j2
<popey> https://launchpadlibrarian.net/122837679/buildlog_ubuntu-quantal-armhf.unity_6.10.0bzr2888pkg0quantal75_FAILEDTOBUILD.txt.gz
<popey> dh_auto_build: make -j2 returned exit code 2
<didrocks> popey: ah, it's -j8 on i386 :)
<didrocks> popey: it's detecting the number of available cores
<popey> vroom
<popey> cunning
<didrocks> heh ;)
<didrocks> so the issue is due to deprecated symbols in bamf
<didrocks> should be quite easy to fix once Trevinho is around
<popey> ahhh, thanks
<sisa> hi help install ubuntu12 win8
<popey> sisa, you probably want #ubuntu for support questions.
<Trevinho> didrocks: I'll check it after lunch..
<Mirv> ah I was looking at the precise build problems
<Mirv> it's the CI working almost as intended, I think :)
<Mirv> the last functional unity build was the same as the now failing, and a bamf change now causes a warning in unity build and all warnings are treated as errors
<Mirv> Trevinho: you approved the deprecation of bamf_view_user_visible in bamf, would fixing unity to not use it be trivial or should the deprecation be reconsidered?
<Mirv> filed bug #1077937 as the first measure
<ubot5> Launchpad bug 1077937 in Unity "Unity FTBFS since bamf_view_user_visible was deprecated" [Undecided,New] https://launchpad.net/bugs/1077937
<Squarism> Hey. Im on ubuntu 12.04 and in System Settings->Keyboard->Shortcuts i cannot find a settings for "Semi-maximises current window". Anyone know how this can be changes wo installind compiz config?
<Squarism> ...a remapping of the Ctrl+Super+left/right shortcut that is
<Squarism> ...or where are the raw config files for unity(non 2d) in ubuntu 12.04?
<jaaso> Does anyone else still  have problem with building ubuntu unity one 12.10
<Squarism> There must be tons of people knowing where config files for unity are located in 12.04
<Squarism> ?
<didrocks> hey bregma!
<didrocks> how are you?
<bregma> uh oh, now what?
<didrocks> bregma: don't be scared (well, just a little) :)
<mhr3> i see didrocks pinging is a general sign of trouble :)
<didrocks> bregma: your friday upload of geis broke evince: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1077376
<ubot5> Ubuntu bug 1077376 in geis (Ubuntu) "Evince crashes when using the latest version of libgeis1" [High,Confirmed]
<didrocks> bregma: can you get someone from the oif stack looking at it?
<bregma> yeah, on my list
<didrocks> thanks :)
<didrocks> bregma: do you know if it will be fixed today? otherwise, we'll revert geis in the distro (with the paradigm on not breaking things)
<bregma> unfortunately, the "someone from the oif stack" only include two people who are working on other things, so....
<bregma> I will take a look today, since my name is on the upload
<didrocks> bregma: thanks a lot :)
<didrocks> Mirv: popey: any news on unity/bamf FTBFS?
<bregma> Squarism, config for unity uses gsettings instead of config files
<Mirv> didrocks: I haven't been able to look at fixing it myself, so would need to ping more people if Trevinho is not here right now. but filed the bug describing the bamf change causing the problem https://bugs.launchpad.net/unity/+bug/1077937
<ubot5> Ubuntu bug 1077937 in Unity "Unity FTBFS since bamf_view_user_visible was deprecated" [Undecided,New]
<Mirv> marked critical now as well
<didrocks> thanks Mirv :)
<Squarism> bregma, would u know how i could change the shortcuts for Ctrl+Super+(Left/Right) that isnt visible in System Settings->keyboard->Shortcuts ?
<Squarism> or a good hint on what to try
<mhr3> Mirv, afaik that was a simple rename to bamf_view_is_user_visible
<Squarism> is CCSM a big no for 12.04 unity (even if u just wanna change 2 keyboard shortcuts?)
<didrocks> fginther: around?
<bregma> Squarism, you are free to use CCSM in 12.04, but if you break something you get to keep both halves
<Squarism> "big no no"
<Squarism> oh ok
<Squarism> just bugs me that i can reassign these settings. =/
<fginther> didrocks, on the phone
<fginther> didrocks, bon jour!
<fginther> didrocks, what's up?
<didrocks> fginther: my turn to be in a hangout :)
<didrocks> fginther: just wanted to know if you need help
<didrocks> for the u-l-a script refactoring
<didrocks> fginther: just fallback to the "inline packaging" case I would say
<fginther> didrocks, Thanks for the offer, I'm testing my fix now and should have the MP re-approved for merging shortly
<didrocks> great :)
<Squarism> is there no discussion beetween OS developers and App developers? Half the shortcuts in intellij conflicts with Unity
<fginther> didrocks, should the auto-merger jobs continue settin DPKG_GENSYMBOLS_CHECK_LEVEL=0? This is a carry over from having a separate packaging branch, do we still need it?
<didrocks> fginther: good point, please set it to 4!
<didrocks> fginther: this forces the symbols to be updated
<didrocks> which is what we want :)
<fginther> Trevinho, ping
<bregma> anyone wanna review https://code.launchpad.net/~bregma/unity/lp-1077937/+merge/133959 to get unity builds back up and running?
<didrocks> bregma: thanks for the patch btw :)
<popey> fginther, sil2100 Mirv ^^
<Trevinho> fginther: pong
<fginther> Trevinho, nevermind, bregma submitted an merge proposal
<bregma> does the jenkins builder not pick up the latest dependencies, or do I need to explicitly bump dependencies (for #1077937)?
<fginther> bregma, it should have picked up the latest bamf.  I'm looking into the failure
<bregma> mkay, some of this stuff appears a little murky from outside
<bregma> or maybe even turgid
<bregma> I like the word "turgid" I think I will use it more often in every day conversation
<fginther> bregma, I re-approved 1077937 after addressing a jenkins/build issue
#ubuntu-unity 2012-11-13
<Mirv> didrocks: wasn't it so that you rejected http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.7/revision/3111 from precise SRU in the summer, and thus it should be reverted in the 0.9.7 branch as well?
<Mirv> I'm not sure if I remember right
<Mirv> it's not very useful patch anyway for SRU
<didrocks> Mirv: yeah, it's not really useful, if it's not in precise, you should revert it
<Mirv> didrocks: thanks, doing that, and yes it's not yet in precise and now won't be
<didrocks> thanks Mirv ;)
<Squarism> i have this issue with unity on ubuntu 12.04 that i cant reassign "semi-maximize". Should i give up or IS there a solution, yet hard to find?
<Squarism> please people.. gimme a hint atleast
<philipballew> Squarism, hey
<philipballew> If noone helps you here, askubuntu is good, or #ubuntu
<Squarism> philipballew, thanx man
<philipballew> Squarism, not a problem,
<mpt> conscioususer, hi, what's up?
<conscioususer> mpt: hi, I needed some guidelines on the sensitivity of menuitems, when the menubar is shared between different windows
<conscioususer> https://wiki.ubuntu.com/MenuBar gives me some cases, but not all
<mpt> conscioususer, I suggest you set up a parent model that makes sensitive the items that make sense regardless of which window is focused
<mpt> Choosing some of those items might involve focusing, or even opening, a window that isn't focused right now
<conscioususer> mpt: oh, that part is actually already coded, it's the "make sense" part I need to understand
<mpt> conscioususer, what's the easiest way for me to see your current/intended menu structure?
<mpt> daily PPA, branching trunk, or something else? (I'm running 12.10)
<conscioususer> mpt: some cases are obvious.. quit is always sensitive, about too... preferences shouldn't be sensitive when you're on the preferences window
<conscioususer> mpt: I have a branch suitable for 12.10, but the menus are actually incomplete... I thought I could start with some general guidelines
<mpt> conscioususer, so Preferences would be sensitive normally, and the Preferences window would make it insensitive
<conscioususer> mpt: it's cases like "refresh" that I'm not sure about... the effects are only visible on the main window, but I don't see why the user should be forbidden to do it from the settings window
<mpt> conscioususer, yes, that's an example of an item that would focus the main window, and open it if it isn't open currently
<conscioususer> mpt: and focus if it's open but not focused?
<conscioususer> mpt: oh, sorry, that's what you saids
<conscioususer> *said
<conscioususer> mpt: what about "add account"? the whole process happens in a new window (wizard), but visually the effects will only be seen on the main one
<conscioususer> mpt: "remove current account" depends on the account menubutton, which is on the main window, so I guess it must be insensitive on the prefs window
<larsu> conscioususer, sorry if I'm ignorant, but shouldn't menu item sensitivity be correct automagically when you're using app. and win. actions properly?
<conscioususer> mpt: yeah, and this is working, my questions to mpt are to decide which will be app and which will be win
<conscioususer> larsu: ^
<larsu> conscioususer, ah, go ahead then :)
<mpt> conscioususer, correct. You might focus the main window after the Add Account process finishes. Not because the command is tied to the window, but just because that's the easiest way to show that the command succeeded.
<conscioususer> mpt: hmm, ok, I think I can follow this to deduce the other ones
<mpt> conscioususer, ok, let me know if you'd like me to review anything later on. :-)
<conscioususer> mpt: sure will :)
<conscioususer> mpt: thanks a lot :)
<mpt> np
<conscioususer> mpt: GMenu is really making my life easier on this one.
<mpt> cool. :-) You can thank desrt
<conscioususer> mpt: I thank him for that and also for some bugs he and larsu helped me with recently :)
<conscioususer> mpt: btw, if you eventually have some time I'm interested on your opinion on this: https://lists.launchpad.net/unity-design/msg10086.html
<larsu> conscioususer, ha, I asked the same thing on irc a while ago. It's a tricky situation unfortunately :/
<mpt> conscioususer, an easy way to fix that is to stop showing the application name in the menu bar :-)
<conscioususer> true, but then the whole name-becomes-window-buttons would have to be rethought
<didrocks> mterry: hey, how are you?
<mterry> didrocks, hello!
<mterry> good
<didrocks> mterry: I saw that in fact, for merging inline the packaging branch back to upstream, you did merge the branch itself, not just copy debian:c
<didrocks> debian/ ?
<conscioususer> mpt, larsu: I wonder if this might be the last drop that will make the design team give up on the titlebar-panel fusion? ;)
<mterry> didrocks, yeah
<didrocks> (this was not clear on the merge request with the diff)
<didrocks> mterry: ok, this gives me some interesting challenge :)
<didrocks> for the daily upload bits
<mterry> didrocks, oh sorry  :-/  I thought keeping some history was valuable
<didrocks> as it's walking up the tree since last release
<didrocks> mterry: yeah, I got why it was important
<mpt> conscioususer, the design team? ;-)
<didrocks> mpt: but basically the first release of every component is closing "all the bugs" :p
<larsu> conscioususer, I'd certainly welcome that... (even though I do like the general idea)
<didrocks> mterry:
<conscioususer> mpt: you know what I meant :P
<didrocks> sorry mpt ;)
<mterry> didrocks, all the bugs in the packaging branch?  :)  hmm
<mterry> didrocks, blacklist those merges?
<didrocks> mterry: yeah, and as with the debcommit, you get the upstream ones listed
<mpt> didrocks, I think I'm missing some context
<didrocks> mterry: well, not that easy
<didrocks> mpt: I was talking to mterry, so m<tab> and you spoke last, sorry ;)
<mpt> ah
<didrocks> mterry: I would say, to avoid cripping all the upload, we can bootstrap by hand
<conscioususer> mpt: larsu: I'm not worried about polly, as I won't use an appmenu, but we're about to see 90% of gnome apps present this issue :-/
<mterry> didrocks, meaning what?
<didrocks> mterry: listing the bug and make a MR with the magic stenza (which is needed anyway)
<didrocks> mterry: will discuss about it when we can enable the project for daily upload
<didrocks> mterry: not related, but I think you saw https://code.launchpad.net/~mterry/unity-lens-applications/sync-packaging/+merge/133401 ?
<didrocks> (didn't have the time to look at it)
<mterry> didrocks, yeah I saw, will go back to it
<didrocks> thanks! :)
<conscioususer> desrt: the GMenu XML parsing functions were dropped in Gio, but the docs on those were the only source I knew for the DTD... where I can find the DTD now?
<desrt> conscioususer: i don't know.
<desrt> i guess the gtkbuilder one didn't get updated?
<desrt> ....i guess gtkbuilder doesn't even _have_ one?
<desrt> hrmph.
<conscioususer> desrt: I noticed some things changed... for example, I can't seem to use the less verbose mode anymore
<mterry> didrocks, what things are using /usr/lib/nux/unity_support_test nowadays?
<desrt> less-verbose mode of what?
<conscioususer> desrt: according to http://developer.gnome.org/gio/2.31/gio-GMenu-Markup.html, I can set menuitem attributes using XML attributes instead of full-fledged <attribute> tags.. but in 12.10 (Gio 2.32) trying to do this gives me an error
<desrt> ya.  we dropped that
<desrt> it was leading to problems
<desrt> two problems, specifically:
<desrt> 1) it was unclear how we would support that for non-strings
<desrt> <item target='5' target:type='i'/> ?
<desrt> ugly...
<desrt> 2) it was unclear how we would support translation for that
<desrt> <item label='File' label-is-translatable='yes'> ?
<desrt> ugly...
<desrt> so we had a system that only really worked for string-typed values that were not translatable
<desrt> which was approximately nothing at all
<desrt> so it got nixed
<conscioususer> ah, makes sense
<didrocks> mterry: compiz itself is using it
<conscioususer> desrt: ok, so I guess the XML string example in http://developer.gnome.org/gtk3/unstable/GtkApplication.html tells me pretty much everything I need to know?
<desrt> i admit that some things would be nice as direct attributes... like 'action'
<desrt> since it's always a non-translatable string
<didrocks> mterry: it needs to be unfortunately in a separate process
<didrocks> otherwise you can't reinitialize opengl forcing llvmpipe
<desrt> conscioususer: crikey....
<desrt> conscioususer: it kinda scares me that blotpad gets included wholesale into the docs
<conscioususer> desrt: well, that kinda helped me :)
<desrt> conscioususer: well,it should
<desrt> bloatpad is supposed to be a demo of all of the major features of GtkApplication
<desrt> it's just kinda.... big :)
<desrt> for a code sniplet
<mterry> didrocks, yar.  Only compiz?  (Branch to move to dh9 will bring multiarch to nux, so I'm thinking of adding a toolsdir variable to the .pc file, but I need to know who else needs to look for that var)
<didrocks> mterry: yeah, only compiz + the source_xorg.py package hook
<didrocks> mterry: it seems that it's been added to other hooks as well
<didrocks> like graphic driver ones
<conscioususer> desrt: agree, sometimes it's hard to find something specific... well, GtkApp *does* have a ton of different features
<mterry> didrocks, do you have a way to find out which by any chance?
<desrt> conscioususer: it will have more soon :)
<conscioususer> desrt: cool, I look forward to that... as long as they work on GC-languages :P
<didrocks> mterry: I don't really know, I only did the xorg one :) I found the nvidia ones by grepping in  /usr/share/apport/package-hooks/ evn if I don't use it. Maybe some are installed by default?
<mterry> k
<didrocks> fginther: can you have a look at https://code.launchpad.net/~didrocks/bamf/rev/+merge/134052 please?
<fginther> didrocks, lookinv
<fginther> looking
<ricotz> didrocks, hi, i doubt this compiles
<didrocks> ricotz: ?
<ricotz> 1878	- if (!bamf_view_user_visible (BAMF_VIEW (window)))
<ricotz> 1879	+ if (!bamf_view_is_user_visible (BAMF_VIEW (window)))
<ricotz> this isnt part of 0.3 irc
<didrocks> ricotz: I don't care about the content, this was a test, see the comment on other merge request
<ricotz> ah sorry
<ricotz> i thought this transition is going to 0.3 too
<didrocks> no worry :)
<fginther> didrocks, I may be missing some context, are you really trying to merge that MP into lp:bamf/0.3?
<fginther> lp:bamf/0.3 is still merging with unity-merger
<didrocks> fginther: I don't
<didrocks> fginther: just look at the comment
<didrocks> fginther: it's for the next daily workflow
<didrocks> fginther: so basically, there is changelog change only
<fginther> didrocks, ok, so you want to push a release instead of an automatic build to staging ppa
<didrocks> fginther: not a real push
<didrocks> fginther: this can go to the traditional merge circuit
<didrocks> fginther: so doing bzr lp-propose <branch> --approved
<didrocks> fginther: but if I do that, there is no "approved revision"
<didrocks> like, you see the approval, but not the rev
<didrocks> is that an issue for you?
<fginther> didrocks, thanks you, it's starting to make sense now.
<fginther> didrocks,  I think I understand better now. I'll need to investigate the launchpad API a bit to make sure we can correctly identify the merge proposal
<didrocks> fginther: thanks :)
<didrocks> mterry: kenvandine: cyphermox: hey, soâ¦ looking at this autolanding thing, it seems that some package (not mine, you ken! :p) doesn't have source package name == upstream project name
<didrocks> this gives a bunch of configuration nightmare that I want to avoid
<didrocks> do you think you can review each stack and ensure it's fine?
<kenvandine> yeah
<seb128> didrocks, #ubuntu-desktop dude :p
<kenvandine> which package is that?
<mterry> didrocks, sure
<didrocks> kenvandine: unity-lens-video! :-)
<mterry> didrocks, I assume you prefer to rename the package in Ubuntu?
<didrocks> mterry: also, on the lens land, most of them finishes with a s
<kenvandine> ugh
<didrocks> mterry: I don't really mind, as long as it's consistent :)
<didrocks> like all lenses finishing with a s
<mterry> didrocks, hmmm.  renaming LP projects is way easier.  :)
<didrocks> but of course, no shoppings
<didrocks> mterry: does it work?
<didrocks> mterry: I looked at it
<didrocks> and it doesn't seem to be possible?
<didrocks> kenvandine: I want videos! :-)
<mterry> didrocks, I think you have to ask LP admin to do it
<didrocks> mterry: oh oh
<didrocks> mterry: that can be interesting
<didrocks> kenvandine: what do you think? ^
<didrocks> if LP renaming is an option, let's go for it
<kenvandine> i'd prefer that
<kenvandine> davidcalle, ^^
<mterry> didrocks, for some of them anyway.  Like, the unity-lens-gdocs is upstream unity-scope-gdocs, so obviously we want to fix the scope mistake, and that's going to be in LP
<didrocks> mterry: kenvandine: cyphermox: each one taking care of their stack? :)
<didrocks> mterry: agreed
<mterry> didrocks, that will still cause you configuration pain, I suppose, as all your scripts have to change to point
<davidcalle> kenvandine, I can't see what you are pointing to :)
<cyphermox> didrocks: ack
<didrocks> mterry: well, it's still better to just have one parameter than two, so I'll take care of that ;-)
<kenvandine> davidcalle, we are talking about making the source package name and lp project match for the videos lens
<fginther> kenvandine, mterry, cyphermox: if the LP branch names change, please let me know so that I can update the automerger jobs
<davidcalle> kenvandine, ok.
<cyphermox> fginther: ok
<davidcalle> kenvandine, do you want me to poke a lp admin or will it be faster if it comes from your side?
<kenvandine> i doubt it matters
<kenvandine> it's your project though
<kenvandine> so i would feel better if you did
<davidcalle> kenvandine, ok
<kenvandine> davidcalle,
<kenvandine> davidcalle, thanks!
<davidcalle> kenvandine, np!
<didrocks> kenvandine: mterry: so cyphermox came with setting -c4 by default
<didrocks> kenvandine: mterry: I think it's a nice idea (I have it for years on my desktop), next time we touch the packaging of any lib, what do you think about setting DPKG_GENSYMBOLS_CHECK_LEVEL=4 in the rules?
<didrocks> that avoid the dh_makeshlibs override
<didrocks> and force the value
<cyphermox> didrocks: really, if it's done for the merges, it's more like belt + suspenders
<didrocks> cyphermox: I'm all for suspenders :)
<mterry> didrocks, OK
<didrocks> mterry: I think though that we shouldn't activate that on the C++ projects, pitti and I spent a lot of time of trying to have symbols tracking on them and we never succeeded as we discussed at Copenhaguen
<mterry> didrocks, oh god no.  I hate symbols & c++
<cyphermox> bah, then maybe just forget about it and have everything pretty much the same
<didrocks> mterry: we all do! :-) everytime I'm reading http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ and forget about those sneaky detailsâ¦
<didrocks> cyphermox: we just can't have symbols file in c++ project, but I guess that's fine
<didrocks> thanks mterry, cyphermox, kenvandine :)
<cyphermox> didrocks: it doesn't fail the build though :(
<didrocks> cyphermox: hum, are you sure? you have a diff and it doesn't?
<didrocks> cyphermox: it did a lot for me
<didrocks> with the env var?
<cyphermox> yeah, I commented one out and bzr bd didn't fail
<didrocks> cyphermox: do you have an url handy? I can try it
<kenvandine> i think that is intended to not fail the build
<didrocks> kenvandine: with 4, it should and it does here ;)
<kenvandine> ok
<didrocks> (it's in my system env and not stripped by debuild)
<kenvandine> what level shouldn't fail it?
<didrocks> 0
<kenvandine> i seem to recall folks setting that to 4 to short circuit the check
<didrocks> kenvandine: man dpkg-gensymbols
<didrocks> -c[0-4]
<kenvandine> i guess i might have had the order backwards :)
<didrocks> yeah ;)
<didrocks> kenvandine: the merger always did export 0
<didrocks> because I didn't wanted it to fail
<didrocks> as the packaging was separated
<didrocks> (it sedded beautifully the debian/rules file)
<didrocks> cyphermox: do you have a link of what you are trying so that I can give it a shot?
<cyphermox> didrocks: lp:~mathieu-tl/indicator-messages/inline
<didrocks> thanks :)
<cyphermox> comment out one symbol from libmessaging-menu0.symbols and run bzr bd
<didrocks> doing :)
<didrocks> cyphermox: oh
<didrocks> you need to export it
<didrocks> export DPKG_GENSYMBOLS_CHECK_LEVEL=4
<didrocks> because it's a subprocess
<didrocks> (dpkg-gensymbols)
<cyphermox> of course
<cyphermox> I suck
<cyphermox> :)
 * cyphermox facepalm
<didrocks> no, you just got trapped :p
<cyphermox> no, that's just being dumb, I know about this ;)
<didrocks> well, no worry anyway, I was just surprised that it didn't work :)
<didrocks> I confirm that bzr bd isn't happy after that!
<cyphermox> well, I also was suprised ;)
<cyphermox> of course that works now
<cyphermox> well, the MR is updated
<didrocks> cyphermox: looking!
<didrocks> cyphermox: even my pbuilder is happy. Good work! :)
<didrocks> fginther: https://code.launchpad.net/~mathieu-tl/indicator-messages/inline/+merge/134100 is ready for inline packaging landing
<fginther> alesage, I may need your help with ^^ indicator-messages MP
<alesage> didrocks, fginther I confess that I'm surprised by this proposal, thought we resolved to leave indicators-stack packaging "out of line"; tedg and kenvandine wishing to review?
<tedg> Also confused why you'd drop all the history of the other bazaar branch.
<tedg> cyphermox, ^
<cyphermox> tedg: I'm not sure how I could keep it. It's not hugely relevant for the packaging branch though, because the history is in debian/changelog
<cyphermox> or what branch history do you mean, actually?
<tedg> cyphermox, It is, because debian/changelog doesn't really have information for things like bzr blame.  It's really an incomplete history for user consumption.
<cyphermox> no
<cyphermox> debian/changelog contains the history of who changed what
<tedg> cyphermox, I mean start with "bzr merge lp:~ubuntu-desktop/indicator-messages/ubuntu" instead of "cp"
<tedg> cyphermox, not really, I edit that file all the time :-)
<cyphermox> right, but when you edit it, you should have your name on top or on the trailer line
<cyphermox> e.g. using dch
<cyphermox> tedg: those branches don't have ancestry
<tedg> cyphermox, And when I delete a revsion in the middle because it isn't relevant?
<tedg> cyphermox, Yes, they do.  They're properly build bzr build-deb branches.
<cyphermox> what do you mean delete a revision?
<tedg> Not some importer stuff.
<tedg> cyphermox, Edit the file, select those lines.  Hit delete.
<cyphermox> you should never have to remove stuff from debian/changelog
<cyphermox> oh wait
<tedg> You do though in reality.  Distro doesn't care about all the PPA trial version or anything else.
<cyphermox> ubuntu-desktop/indicator-messages/ubuntu was a full branch, not a merge-mode branch, it possibly did have ancestry, but when I initially tried to merge it basically blew up in my face
<cyphermox> tedg: but you could just as well include it
<tedg> If you only look at it from the "one archive" perspective you don't, but that's a limited perspective.
<cyphermox> anyway, whatever, I don't feel strongly for one way or the other. I don't think the history for that was very relevant
<cyphermox> (because what we care about was already in changelog)
<tedg> I would say all history is important, it's what defines us :-)
<tedg> And, at a practical level.  It makes your branch conflict with any other.
<tedg> Because now you've created new file IDs
<tedg> For the same files.
<cyphermox> tedg: there are no same files
<cyphermox> it's adding debian/
<cyphermox> that's really it
<tedg> cyphermox, We have many packaging branches.  Now all of those (which have a debian dir) conflict with yours.
<cyphermox> just retesting, merging lp:~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages reverts a bunch of changes done upstream
<cyphermox> tedg: what do you mean many packaging branches?
<cyphermox> the goal is to take the packaging and fold it upstream, I'm not sure what else needs to be done. all the other branches should IMO just go
<tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu
<tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.4
<tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.3
<tedg> https://code.launchpad.net/~ken-vandine/indicator-messages/lucid
<tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.1
<tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.2
<tedg> All of those are comparable, because they use the same file IDs.
<cyphermox> that's fine, but those should just go. they are still useful historically prior to a possible merge of my work, but past that the "upstream" packaging is what we want to use
<cyphermox> anyway, let's bring that up to didrocks to decide
 * cyphermox will head back to NM for the time being
<cyphermox> also, if you know how to cleanly just merge the *right* packaging branch, which should be ~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages (for example), then please teach me :)
<cyphermox> (by cleanly I mean without messing around with all the non-debian/ changes we clearly don't want)
<tedg> cyphermox, They're probably there because of distro patching.  You can just bzr revert all of those.
<tedg> cyphermox, Then you keep with the upstream branch.
<tedg> Well, I guess I'm not allowed to use the term "upstream" anymore.
<cyphermox> well, yes you are :)
<tedg> "The version with the changelog that no one edits and is out of date"
<cyphermox> tedg: that's what we want to change
<tedg> bzr log > debian/changelog
<cyphermox> tedg: or actually, that's what *will* change, because that will be the canonical changelog for the projet
<cyphermox> oh god no
<tedg> No, it won't be.  The Bazaar history always will be.
<tedg> It's a nice try, but a failure waiting to happen :-)
<cyphermox> there's a disconnect here
<cyphermox> changelog is meant for the packaging changes, not upstream changes
<tedg> Exactly, which is why they shouldn't be in the same branch.
<cyphermox> (with the possible exception of key new features)
<cyphermox> tedg: talk to didrocks, there were more than one discussions about this stuff at UDS, and the net result was to fold in debian/ to upstream packages to get easier daily uploads to the archive and help you guys with feedback
<tedg> Not something we asked for or felt we needed.  But yes, didrocks decided to do that.
<cyphermox> well, maybe not for indicators so much, but quick feedback on changes was something that unity would win on
<cyphermox> I'm saying this, but I wasn't in *all* of the sessions about this :/
<tedg> No, not really.  Because what will happen is the devs will stop committing to trunk.  They don't want quick feedback from users, they want to be able to discuss things amongst themselves first.
<tedg> So "trunk" is the new packaging branch.  And "not trunk" is where work gets done.
<cyphermox> not quite
<cyphermox> trunk should be where stable stuff lands, and not trunk for unstable, possibly broken crack :)
<cyphermox> e.g. trunk always builds and has as few regressions as possible
<tedg> Sure, kinda like "releases" were before.
<cyphermox> yeah
<tedg> So anytime where a release would be made before, that's now a merge to "trunk"
<cyphermox> with the difference of releasing just about every day to the archive
<tedg> No, it'll only release when something is added, it won't get commits everyday.
<tedg> There's no reason for devs to want to commit to it.  You just get yelled at by users.
<cyphermox> tedg: basically, it will be the same CI as usual, except when this pass unit tests and some extra testing it will get automatically in archive
<tedg> Kinda like "releases" in the past.
<cyphermox> tedg: trunk it's meant for new crack until it's stabilized though, that's what was happening because (maybe) and why people were complaining
<cyphermox> tedg: let's punt this to didrocks. I'm just the muscles for this one ;)
<cyphermox> can't believe we're in such apparent disagreement right now though, I would have thought it would have been already discussed with you and more or less agreed to already, I'll ask him what's up
<cyphermox> fginther: so you're holding off on that merge for now, right? :)
<cyphermox> one more day won't hurt
<fginther> cyphermox, yes, holding off for now
<charon__> hi all!
<charon__> I just tried to compile unity according to the manual on unity.ubuntu.com, however, cmake produces an error even before compilation starts. Maybe this manual needs fixing? I'm using ubuntu 12.04.
<charon__> cmake complains "package 'unity-protocol-private' not found"
<bschaefer> charles, you need to compile/install libunity or grab the stagging ppa
<bschaefer> charles, opps! wrong person
<bschaefer> charon__, ^
<charles> :)
<charon__> libunity-dev is installed. does this mean, the version is not compatible with the unity trunk?
<bschaefer> charon__, yes, the unity-protocol-private was added later...(im not sure when), but it is in trunk libunity
<charon__> what exactly is considered to be a package btw? is it some form of a c++ class?
<bschaefer> umm im not sure what you are asking
<charon__> the cmake script also complained that package zeitgeist was not available, so I installed libzeitgeist-dev and that error went away
 * bschaefer also doesn't know much about packaging
<charon__> I mean, obviously the package is part of libunity. Is this an API or what?
<charon__> sorry for these questions, but i'm _really_ new to unity.
<charon__> before also compiling libunity, maybe I should try to build unity 5.x, which is part of ubuntu 12.04.
<bschaefer> hmm I would think it is just part of it
<bschaefer> that should work for you
<bschaefer> bzr branch lp:unity/5.0
<charon__> thanks for that!
<bschaefer> np! let me know if you run into any other compiling problems
<charon__> still, the website (unity.ubuntu.com) needs fixing as it just doesn't work anymore. The manual states that it is meant for precise, which I'm using.
<bschaefer> hmm I would think the current state of building unity would be with the current version...
 * bschaefer goes to look at the site
<charon__> compiling unity 5.0 seems to work
<bschaefer> well you wont get trunk unity, you'll just get unity 5.0
<charon__> that's fine. I need to fix a bug in unity 5.x ;)
<bschaefer> perfect then :)
<charon___> Hmm, not a good idea to run the freshly compiled unity with unity --replace. My display just got crazy with many graphics errors.
<charon___> what is a good workflow for testing a freshly compiled unity?
<bschaefer> 'unity' should work or using the standalone files
<bschaefer> unity/build/dash/dash
<charon___> (without crashing the running unity from the repository)
<bschaefer> well running 'unity' kills compiz, then restarts compiz
<bschaefer> what errors does it give you when you run unity?
<charon___> Is it a good idea to use another user? For this user, a second instance of lightdm is started on alt-f8?
<charon___> I then wouldn't care if something crashes.
<bschaefer> hmm no, you should be fine just running 'unity'
<charon___> the display becomes _very_ colored with a lot of pixel garbage.
<charon___> so i can't say what it says ;)
<bschaefer> try running 'unity' in a tty
<bschaefer> alt-f1
<charon___> ok.
<bschaefer> then going back to f7
<bschaefer> ctrl+alt...
<charon___> I'm not a linux newbie ;)
<bschaefer> :), the ... are for me forgetting the ctrl part haha
<charon___> hmm, could be that it is working now. I used "unity-env" to get my staging branch, then "unity --replace"
<bschaefer> because what should happen. Compiz is killed, then restarted with the unity you built...which then it should go and actually restart the unitshell plugin
<bschaefer> hmm
<bschaefer> and if it fails it would say Error to load unityshell...but im not sure what you are seeing, or if there are any errors
<charon___> it now started without errors
<charon___> I just have to check that it is the compiled binary from me and not the one from the repository.
<charon___> (any idea how to do that?)
<bschaefer> hmm a print statement :)
 * bschaefer should know how though...
<charon___> I could change the version in the source code
<bschaefer> you could also check ~/.compiz-1/plugin
<bschaefer> plugins*
<bschaefer> if that is there, that is what compiz reads first
<bschaefer> it is a good indicator you are running a compiled version.
<charon___> yes, the directory exists and there are a couple of shared libraries in it.
<charon___> i just compiled a new version, setting the version to 5.17.0 (in build/config.h). But typing unity --version still gives 5.16.0.
<bschaefer> unity is just a python scrip in your /usr/bin
<bschaefer> if you wen to build/bin/unity --version
<bschaefer> it will give you the correct one
<charon___> hmm, maybe I changed at the wrong position.
<bschaefer> usually to be 100%, just add a printf in unity/dash/DashController.cpp under Show
<bschaefer> then everytime you show the dash you get that print state ment haha
<charon___> of found it
<charon___> of=oh
<bschaefer> cool
<charon___> :)
<charon___> UNITY_MINOR in CMakeLists.txt
#ubuntu-unity 2012-11-14
<davidcalle> didrocks, lp:unity-lens-videos is now lp:unity-lens-video, the change has just been applied on the whole project
<Mirv> davidcalle: cool, finally no mismatch between the names! :)
<didrocks> davidcalle: \o/ thanks a lot :)
<mhr3> didrocks, why wasn't the pkg renamed instead? it's not like the lens searched for a single video :P
<didrocks> mhr3: I agree, but renaming a source package is way more complex
<conscioususer> mpt: hi, you around
<conscioususer> mpt: I'd like your advice wrt to my "add acount" wizard
<mpt> conscioususer, always
<conscioususer> mpt: :)
<conscioususer> mpt: the first time the user starts an app and receives the wizard, I was wondering what to do when he cancels the wizard
<conscioususer> whether to quit the app or proceed to the main window anyway
<conscioususer> mpt: I considered not popping the wizard directly, but showing a welcome message on the main window with a button to open it
<mpt> conscioususer, I would exit it.
<mpt> conscioususer, I briefly wrote up a first-run assistant for Empathy, though it was never implemented. <https://live.gnome.org/Empathy/WelcomeToEmpathy>
<conscioususer> mpt: that makes sense for me too, but iirc I never found an app that does that
<mpt> conscioususer, Adium and Apple Mail both do that iirc
<conscioususer> mpt: would I close it directly or show a confirmation dialog?
<conscioususer> mpt: (a dialog that obviously wouldn't be shown in subsequent usage of the wizard)
<mpt> conscioususer, it depends how much state would be lost. And that doesn't change regardless of whether it's the first time you're using it or a subsequent time.
<mpt> i.e. how much stuff you've entered that would be discarded
<mpt> For a Twitter account at least, there's very little state, so probably not
<conscioususer> mpt: no important loss at all, actually, I was worried if it would be clear enough that the app exited, as other popular apps wouldn't
<mpt> conscioususer, other popular apps such as?
<conscioususer> mpt: empathy now, iirc
<mpt> pfft
<conscioususer> mpt: also, thunderbird
<mpt> conscioususer, I think that's only because there's a non-assistant way of adding a Thunderbird account
<mpt> which some people prefer
<conscioususer> mpt: hmm
<conscioususer> mpt: so in my case, cancel would simply close the window and that's it?
<mpt> I think so
<conscioususer> mpt: ok, since you are advising what my opinion was leaning towards to already, it's an easy call :)
<conscioususer> mpt: sounds easy enough to implement too
<mpt> :)
<conscioususer> mpt: thanks
<didrocks> Mirv: sil2100: can you please have a look at https://code.launchpad.net/~didrocks/bamf/dailybootstrap/+merge/134297?
<didrocks> shouldn't be long to approve/review :p
<popey> didrocks, blimey, even _I_ could approve that ;)
<didrocks> popey: be my guest! :)
<popey> odd, i couldn't type a + sign in the comment field!
<popey> i had to copy and paste one in.
<Laney> should I make packaging and code changes in the same commit?
<Laney> (unity-lens-music)
<didrocks> Laney: well, can be two commits, but one merge request
<didrocks> it's a matter of taste I guess
<Laney> it will be one MP, yes
<Laney> I don't really get the convention about what's documented in d/changelog either
<didrocks> Laney: all things that have a bug attached + packaging change
<Laney> like there's an unreleased ubuntu2 there now
<Laney> but I'm making upstream changes so surely they would only go in a new upstream release
<didrocks> Laney: what do you try to do exactly?
<Laney> gstreamer 1 port
<didrocks> Laney: do you need to upload it right away? can it wait like a few days?
<didrocks> Laney: if so, you can just merge that upstream
<Laney> yeah I expect it to wait
<didrocks> Laney: ok, so don't update debian/changelog if you don't have packaging change
<didrocks> Laney: just make the upstream change
<didrocks> if you link to a bug report, the changelog will be populated automatically
<Laney> I need to change the build-deps though
<didrocks> with your name :)
<Laney> not sure if there is a bug
<didrocks> ah, yeah, list the build-dep change then :)
<Laney> ok, cool
<Laney> thanks
<didrocks> yw :)
<Laney> is there a PPA I can depend on to test build?
<Laney> the requirements have been bumped to beyond what's in raring apparently
<didrocks> Laney: oh yes, it's in unity-team/staging
<didrocks> for nux 4 :)
<Laney> check
<didrocks> popey: to exercise your "+" key: https://code.launchpad.net/~didrocks/dee/dailybootstrap/+merge/134299 :)
<popey> hah
<popey> pfft, works now!
<mterry> didrocks, hello!
<popey> maybe i should use a french keyboard layout :)
<didrocks> hey mterry!
<didrocks> popey: heh, I'm sure it's the cause
<mterry> didrocks, so for -c4, I have a bamf branch, but I had wanted to talk to you first about it.
<didrocks> mterry: ah?
<mterry> didrocks, so when you do need to add a new symbol to the .symbol file (as bamf needs to), you need to provide a version
<didrocks> yep
<mterry> didrocks, for my branch, I just bumped the version in debian/changelog to what I imagine the next upstream version will be and used that in the .symbols file
<mterry> didrocks, how will that work for autolanding?  How does a person know what the next version will be?
<didrocks> mterry: basically, I propose that we do:
<didrocks> <currentupstreamversion>dailyyy.mm.(dd+1)
<didrocks> as it will be released at the earliest the day after
<didrocks> mterry: does it make sense?
<mterry> It's tough though because it may be incorrect (may take longer to land).  But I suppose that will just mean it will be slightly unnecessarily tight.  Which isn't a problem per se
<mterry> Or wait.  No, it will mean it thinks a version that doesn't have the symbol will satisfy
<mterry> Which isn't true
<didrocks> mterry: right, it may be incorrect, but in this case, there will be no release between <currentupstreamversion>dailyyy.mm.dd and <currentupstreamversion>dailyyy.mm.(dd+correct_day)
<mterry> It will be loose
<didrocks> counting on the fact it's merged the day you propose it
<mterry> didrocks, you don't think I could propose merge A, then someone else lands merge B, then it takes several days to land my A?
<didrocks> mterry: yeah, that's a valid point
<didrocks> mterry: TBH, as we ship only one version on the distro, it's not a real issue, people upgrade
<didrocks> but we can write guidance for this case
<didrocks> like when reviewing a symbol change, ensuring dd is the correct day
<mterry> didrocks, we could do something like adding a version like 0.4.3-0ubuntu0replacemeplease and have the autolander fix it up?
<didrocks> mterry: that's another solution, totally possible
<didrocks> fginther: thoughts? ^
<didrocks> mterry: like the autolander making a diff
<didrocks> and if there is a + in symbol files
<didrocks> replacing with the current day + 1
<mterry> yar sure
<didrocks> mmrazik: can you invite my @gmail to the hangout? I need to use my android device for it
<didrocks> as it's broken on raring right now
<mmrazik> didrocks: ok
<didrocks> thanks :)
<mmrazik> didrocks: can you private msg your private gmail address?
<didrocks> done ;)
<didrocks> mterry: oh, on bootstrapping, did you see my bamf/dee/libunity branches?
<mterry> didrocks, yeah.  You want me to approve them?  They seem pretty innocuous.  That's part of getting the autolanding changelog writing to work?
<mterry> didrocks, just filed bamf c4 merge
<didrocks> mterry: be back after the hangout and will explain it in great length
<Squarism> Isnt there a setting in 12.04 where ALT+TAB -> Desktop doenst minimize all windows on all screens?
<Trevinho> didrocks, mterry I think these could clash lp:~mterry/bamf/c4 lp:~didrocks/bamf/dailybootstrap
<mterry> Oh, probably.  I can rebase mine on top of didrocks's
<Trevinho> mterry: yes, thanks... so I'll do with mine too
<Trevinho> (I'm bumping the whoule bamf to 0.4 for r)
<Trevinho> mterry: ping me once you've done please
<mterry> Trevinho, done.  I guess you can change my 0.3.5 changes to 0.4, since 0.3.5 was never released
<didrocks> mterry: soâ¦
<didrocks> mterry: that would be good if you can approve them. yeah, it's about bootstrapping with the "rev" after which looking for bugs to collect
<didrocks> mterry: so, I set it just after your "inline packaging merge" and have to manually list those before there are not in raring (like in libunity)
<mterry> didrocks, ah so from now on, no more manual changelog entries?
<didrocks> mterry: apart for packaging change
<didrocks> well, it can be automated if you have a bug linked :)
<mterry> didrocks, it's only automatic if a bug is linked?  OK.  Otherwise a branch without a bug should add a changelog entry?
<mterry> (isn't there a commit message we could use in such cases?)
<didrocks> mterry: should or not, I don't think we want to get all commit messages in
<didrocks> we can in the future, it's not a big change to what we have today ;)
<mterry> sure
<Trevinho> didrocks: as I told you some time ago, I'd like to get rid of the libbamf-0/libbamf-3 thing... The only project depending on libbamf0 (ginn) is already using libbamf3 in trunk, so I'm in the process of removing the gtk2 dependencies in the bamf code.
<didrocks> mterry: do you want me to help doing some others? I think the bootstrapping is quite quick to do, maybe for all but compiz and unity which will take some time
<didrocks> Trevinho: ok, please update the packaging or ask us if you need help for it :)
<didrocks> like mterry or I
<Trevinho> didrocks: however the strange thing is that both libbamf3 and libbamf0 never have been different on dependency.. I mean, both have always been gtk-free from dependency point of view...
<Trevinho> so I never saw the point of having this difference
<Trevinho> (only the daemon can be built using gtk2 or gtk3, but in the archives we only have the gtk3 daemon)
<didrocks> Trevinho: hum, I don't remember per say, maybe there had been a gtk dep and it's been removed
<Trevinho> didrocks: yes, sure.. but I've some packaging background I hope it's still enough :)
<Trevinho> didrocks: mh, I don't know... I never saw them, but probably there was...
<didrocks> Trevinho: we'll review anyway :)
<Trevinho> didrocks: however... It would be also nice to change the packaging name, even if I think that this could lead to a lot more troubles
<didrocks> Trevinho: it does, why do you want to rename it?
<Trevinho> well... I don't see the point of having a library called libbamf3 when the "3" is really irrelevant as it is not related to the gtk version
<Trevinho> but... I know it's just a thing it's better to keep
<mterry> didrocks, (got back from afk) OK, you want me to go through and bootstrap the non-compiz/unity ones?
<didrocks> mterry: do you have time for it? (I didn't ask to not do the compiz/unity, just saying it's the longer one, the others should be quick)
<didrocks> I can take some if needed
<mterry> didrocks, I can add them to the list, sure
<didrocks> mterry: ok, thanks :)
<didrocks> mterry: so the rev to list is the rev where you merged the packages in, to be clear
<didrocks> and then, we need to look for bugs that were not fixed in distro already until the previous release
<mterry> didrocks, the inline branches?  OK
<mterry> didrocks, just things with bugs attached, eh?
<didrocks> yep :)
<didrocks> mterry: my plan was first to list just the rev of the previous release
<didrocks> mterry: but as you merged the packaging branch in the trunk, it was listing every bugs since the beginning :)
<fginther> didrocks, mterry, regarding having the autolander fix up the symbol revisions...  It should work
<fginther> would it just add the current package version as the replacement: 0.4.3-0ubuntu0replacemeplease -> 0.4.3bzr498pkg0quantal18?
<didrocks> fginther: mterry: I'm wondering if finally, it shouldn't just be the "daily release" doing it?
<didrocks> like my script, as we know the day of the release, it will make more sense
<mterry> didrocks, that could work too
<didrocks> fginther: don't bother, I'm adding that
<didrocks> mterry: now, let's see if we can just add "replaceme" :)
<mterry> didrocks, you forgot the 'please'  ;)
<mterry> so rude
<didrocks> mterry: heh, ok, adding in the spec :p
<mterry> hah
<mterry> Reminds me of how the Debian bts uses 'thanks' as a stop-marker for commands to the bot
<didrocks> it likes the please! :)
<didrocks> so I can definitively do that
<didrocks> fginther: so merge proposal with only changelog and symbols should get the pass-through I guess :p
<fginther> didrocks, wouldn't you want a new package built if the symbols were updated?
<didrocks> fginther: it's only for listing the dep. They won't be exact *in the ppa*, but I think people are using dist-upgrade
<Trevinho> didrocks: https://code.launchpad.net/~3v1n0/bamf/bump-to-0.4/+merge/134322
<fginther> didrocks, ok
<Trevinho> mterry: thanks for review, fixed...
<cariveri> hey there. Im new to the unity src code and could use a little help.
<cariveri> anesm
<cariveri> Trevinho: excuse me, who should I ask about the Launcher's code?  - the data model is not quit clear ot me.
<bregma> cariveri, just go ahead and ask questions, there's a few folks who can probably answer
<didrocks> alesage: hey, any progress on merging https://code.launchpad.net/~mathieu-tl/indicator-messages/inline/+merge/134100?
<alesage> didrocks, I think you're suggesting that I run a red light :)
<didrocks> alesage: red light?
<didrocks> which one?
<alesage> didrocks, I don't wish to stir up controversy but have we decided, after all, for inline packaging for indicators?
<didrocks> alesage: no, the stackholders of the indicators stack (larsu and charles) agrees with inline packaging
<didrocks> we decided from the meeting that the stackholders decide, the other won't have automated daily push to ubuntu and will deal with that themselves
<larsu> alesage, I can vouch for the correctness of what didrocks says ;)
<alesage> didrocks in that case, is it possible to clean up this MP, e.g. to make a graceful merge of the existing packaging-branch history?
<alesage> or is that not technically possible, in your opinion?
<cyphermox> it's done
<cyphermox> alesage: I updated the branch, the MR should be listing "new" commits in grey
<didrocks> alesage: same request for indicator-sound: https://code.launchpad.net/~mathieu-tl/indicator-sound/inline/+merge/134163
<alesage> cyphermox, didrocks, larsu ok--I suppose I'm the gatekeeper as the Jenkins representative
<cariveri> alright. where in the code is the loop over desktopfiles to load them in the launcherBar?
<didrocks> alesage: exactly ;)
<alesage> and I for one welcome our new robotic-butler overlords
<alesage> didrocks, see a mail from mmrazik this A.M.--our Jenkins is being migrated, should be up RSN
<larsu> alesage, yup. I can merge it into trunk, but we need to sync so that the jenkins stuff is ready
<didrocks> alesage: sure, please keep us in touch
<alesage> actually I do have to make a configuration change if we're going to move to inline (removing our former packaging branches from config)
<didrocks> alesage: I'm just approving in the comment, don't approve the whole status so that you can do the necessary work and approve it
<alesage> yes didrocks larsu, I'll update you
<didrocks> alesage: right, fginther is an expert at that now if you need more help I guess :)
<didrocks> (he did for a bunch of projects ;))
<alesage> ok thx didrocks
<larsu> thanks alesage
<didrocks> thanks alesage ;)
<cariveri> hey. can anyone explain me the data model of the desktopfiles in the unityshell/src ? I expected Launcher to hold all info from the desktopfile and one LauncherIcon.
<Trevinho> cariveri: hi, I was out sorry...
<Trevinho> cariveri: I wrote the model, yes...
<Trevinho> what's up?
<Trevinho> cariveri: the launcher loads the icons through BAMF (see LauncherController), each icon takes most of data from bamf, that is the component that examine the .desktop files and exposes the informations to all its clients
<MCR1> Hi :)
<MCR1> Trevinho: If you have a minute: https://code.launchpad.net/~mc-return/unity/unity.merge-minor-possible-speed-improvement/+merge/133435 and https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520 need approval :)
#ubuntu-unity 2012-11-15
<riX2000> Hi everyone. (Sorry for big chunk of text:) I've got a problem with (I believe) unity. Some windows I minimized (terminals in particular) are behaving strangely. If I have another window active and press alt-tab to a terminal, it does not become active. (However alt-tabbing to the terminal window group, waiting for the group to expand and then choosing one works).
<riX2000> I've tried unity --replace, unity --reset, compiz --replace, it does not help.
<riX2000> A lot of windows from before the first time I did unity --replace are now completely invisible. I have come up with a method to get some of them back (see screenshots), but this does not work for programs nt having an "internal" window list.
<riX2000> I've posted more info + screenshots here: http://inky.ws/g/2cr
<riX2000> Somewhat related: http://askubuntu.com/questions/177139/gnome-terminal-not-showing-up-in-unity-why
<didrocks> mmrazik: hey, seems autolanding has some issues: https://code.launchpad.net/~didrocks/dee/dailybootstrap/+merge/134299
<mmrazik> didrocks: I'm working on it
<mmrazik> didrocks: in particular on this specific MP
<didrocks> thanks :)
<mmrazik> didrocks: the issue is that the IPs change and there are some issues in connecting to local archive
<mmrazik> but there is one more problem now which I don't understand...
<mmrazik> (yet)
<didrocks> mmrazik: hum, I can just say "good luck" ;)
<mmrazik> didrocks: ack :)
<mmrazik> didrocks: sorry for spamming your MP
<mmrazik> but I'm getting closer :)
<didrocks> no worry ;)
<tsdgeos> Trevinho: Mirv: what about https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background_6.0/+merge/132297 think it makes sense?
<mmrazik> didrocks: FYI https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-trunk/348/testReport/
<mmrazik> that is the last "successful" autopilot run
<mmrazik> then we hit a cobbler bug :-/
<mmrazik> which Max fixed yesterday night but now we are running into something new
<mmrazik> didrocks: its ~27% fail rate
<didrocks> mmrazik: ok, I think you guys have a plan to work on it? :)
<mmrazik> sure
<Mirv> tsdgeos: I'd think that since Unity can be considered part of infrastructure, and the fix isn't clearly fixing a high impact bug, it doesn't fall under SRUable commits
<didrocks> mmrazik: thanks for the link :)
<tsdgeos> Mirv: ok, the poor sods that get randomly a false assigned to that var would probably disagree but that's going to be 1 in a million
<tsdgeos> Mirv: could you please comment so in the merge request?
<Mirv> tsdgeos: did so
<tsdgeos> ah :D
<tsdgeos> tx :-)
<Mirv> :)
<mmrazik> didrocks:  could you please have a look:
<mmrazik> https://jenkins.qa.ubuntu.com/job/bamf-mbs-autolanding/21/build=pbuilder,distribution=quantal,flavor=amd64/console
<mmrazik> is that a packaging issue?
<didrocks> mmrazik: make[5]: *** [test-headless] Error 1
<didrocks> mmrazik: seems more make test-headless returned 1â¦
<didrocks> (despite having OK everywhere)
<mmrazik> oh... missed that... only saw the "dh_auto_test: make -j1 check returned exit code 2"
<mmrazik> didrocks: mhm.. I'll try to re-approve. The next bamf MP passed the tests (but failed at dh_makeshlibs)
<didrocks> mmrazik: ok, keep me in touch, not having this bootstrapping makes us using other branches to test
<mmrazik> didrocks: are there more branches like that?
<didrocks> mmrazik: dee, bamf, libunity for now
<mmrazik> didrocks: ack.. just found the libunity one...
<didrocks> thanks
<mmrazik> didrocks: beside the random make test failure we have one problem in bamf.
<mmrazik> https://code.launchpad.net/~mterry/bamf/c4/+merge/134313 is fixing some gensymbols issue
<mmrazik> didrocks: but it lists the debootstrap branch as prerequisite
<didrocks> mmrazik: in a hangout, I can inverse them if needed
<mmrazik> didrocks: and the debootstrap branch fails with the gensymbol (if the make test randomly passes)
<mmrazik> didrocks: ok
<cariveri> hello there. Id like to introduce a new LauncherIcon type, but cant find the code which parses the desktopfile's fields. please help me on this.
<cariveri> Hi larsu can you help me?
<larsu> cariveri, sure, what's up?
<cariveri> larsu Id like to introduce a new LauncherIcon type, but cant find the code which parses the desktopfile's fields. please help me on this.
<larsu> cariveri, what project are you talking about? Unity?
<didrocks> mmrazik: hey, why do you have gensymbol issues?
<didrocks> mmrazik: did fghinter runs -c4 now?
<cariveri> larsu: yes unity. unityshell/src ?
<larsu> cariveri, I don't know, I'm not a unity developer :) a quick grep for g_desktop_app_info_new points to launcher/ApplicationLauncherIcon.cpp and UnityCore/DesktopUtilities.cpp
<larsu> but I'm sure that other people in this channel can be of more help
<mmrazik> didrocks: I don't know
<didrocks> mmrazik: if not, we don't need mterry's branch in mine
<mmrazik> didrocks: btw. I was thinking of pushing the bamf dailybootstrap thing via autolanding with no tests
<didrocks> mmrazik: that can do it, but we need to know at some point why the tests are failing, maybe check with Trevinho
<mmrazik> I think the bamf stuff is broken and needs to be fixed. Have seen the same random failures in libunity
<mmrazik> we need to fix libunity too
<mmrazik> or actually... the branch that enables the tests didn't land yet
<mmrazik> bamf was probably just lucky during the enablement
<didrocks> maybe
<cariveri> larsu: I expected a loop where the files are parsed and evaluate, for that the Icons on the launcher can be created. There is are types like TYPE_APPLICATION defined in AbstractLauncherIcon, but cant find the place where it is set from the files. Maybe you'r a smarter grep-er then I am.
<mmrazik> didrocks: I believe all the bootstrap branches now landed
<didrocks> mmrazik: ok, there will probably be a lot more once mterry is around
<didrocks> thanks
<larsu> cariveri, there's no TYPE_APPLICATION anywhere in AbstractLauncherItem. Unity probably uses GDesktopAppInfo instead of parsing the desktop files manually: http://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html
<larsu> what are you trying to achieve?
<mmrazik> didrocks: right now I'm aware of the bamf issue and the unity can not land (due to various errors the nux4 stuff didn't get it into the local archive)
<mmrazik> the rest should be landing fine
<mmrazik> or rather I didn't see it failing yet ;)
<cariveri> larsu: AbstrcatLauncherIcon.h not item :)
<cariveri> larsu: and I know how to parse thos efiles my self, but the question is how unity does it and where so I can integrate porperly my new feature.
<mmrazik> didrocks: FYI autopilot/unity is currently stuck on UTAH. Trying to figure out if there is somebody in europe who can help me. Otherwise I need to wait for Max
<larsu> cariveri, sorry, that was a typo. The only TYPE_APPLICATION in there is BAMF_TYPE_APPLICATION...
<larsu> cariveri, I can't tell you for sure how unity parses those files, but like I said, it looks like it's using GDesktopAppInfo
<cariveri> hmm I took the unity src from by apt-get source. and there is a lot of TYPES defined. TYPE_EXPO, TYPE_TRASH and so on.
<cariveri> larsu: but thanks for trying to help me.
<mmrazik> didrocks: its weird but https://code.launchpad.net/~mterry/bamf/c4/+merge/134313 landed with no issues
<didrocks> mmrazik: right, I think you need to snapshot the worspace where the tests failed and ask something in the unity team to look at it
<mmrazik> ack. Will have a look on it.
<mmrazik> didrocks: FYI -- I need to wait for max on the autopilot/unity thing :-/ Just a small demonstration that there is much more instability than just unity/autopilot...
<mmrazik> but the good news is that I think I fixed autolanding for unity
<mmrazik> I'll be going through the rejected MPs in a while and will be re-approving
<didrocks> mmrazik: ok, thanks
<bregma> three cheers
<didrocks> hey bregma! :)
<bregma> hey, how's it going?
<didrocks> good good, and you? :)
<bregma> not too bad
<bregma> I'm hoping the current nux-4/unity fandango has been resolved
<bregma> but all the outstanding failed MPs will have to go through first
<mmrazik> bregma: brandon's branch is compiling right now (~80%)
<mmrazik> bregma: I'll go through the other ones once this is through
<bregma> it's pretty much the key, that brancjh
<mmrazik> bregma: it has just landed
<mmrazik> or not?
<mmrazik> mhm...
<mmrazik> oh.. the job finished.. the merge didn't yet
 * bregma holds his breath
<mmrazik> bregma: its there now. really.
 * bregma breathes again
<mmrazik> bregma: the remaining failures seems to be genuine problems (like conflicts). If there is still something the I probably missed. Feel free to re-approve or ping me.
<bregma> mkay
<didrocks> alesage: hey, good morning!
<didrocks> alesage: any news on landing the indicator inline packaging branchs?
<alesage> didrocks, why hello
<alesage> didrocks, I'll review during coffee, a few min pls :)
<didrocks> alesage: thanks :)
<bobweaver> I want to make libnux render a better back cover how to do this ?
<bobweaver> for RenderCoverFlow
<bobweaver> Like when uri is active
<bobweaver> I will take screenshot of wxample
<bobweaver> example *
<bobweaver> http://imagebin.org/235990
<bobweaver> 2d Concept work ^^
<alesage> didrocks, I'll test the new build style for i-sound, i-session, i-messages and will report; should take an hour
<didrocks> alesage: thanks a lot :)
<bobweaver> that is what I want to do with NUX though like the "orange" that is on selected item. Or should I just change something to do with the card ?
<didrocks> alesage: don't merge i-session right now, see my needs fixing first :)
<didrocks> I think cyphermox will fix it once he's around
<cyphermox> I'm around and ifixing it
<alesage> didrocks, ok--we'll merge when someone clicks 'approve' in the mp
<didrocks> cyphermox: thanks!
<didrocks> alesage: the 2 others are green, feel free to needs review -> approve once you made the changes to the job
<bobweaver> Sorry file is called CoverflowResultView.cpp
<alesage> ok didrocks willdo
<didrocks> thanks ;)
<bobweaver> CoverflowResultView.cpp  << can not tell by shadowing what card is chosen so I thought that having background would be good thing. why is this code so dam hard !!!!!!!!
<bobweaver> change the camara view and you can tell but still I do not want to make 20 ft interface only 10
<bobweaver> ;)
<bobweaver> so like this   layout_->AddView(coverflow_, 1, nux::MINOR_POSITION_CENTER, nux::MINOR_SIZE_FULL);          ow to add color ?  to backing of that ?
<bobweaver> s|ow|how|
<bobweaver> http://www.youtube.com/watch?v=8Tup9pD0Fps
<bobweaver> I would like to say that I do not think that people are ignoring me. It is just that I want to make awesome sauce that is all :) I will get it
<cyphermox> didrocks: if you want to try the tests now, not sure how much better it will work, here they just keep hanging
<didrocks> larsu: do you know about it? ^
<cyphermox> http://paste.ubuntu.com/1360585/
<larsu> didrocks, which tests are these?
<cyphermox> indicator-session
<didrocks> larsu: ah, missing schema :)
<larsu> what didrocks said :)
<didrocks> larsu: normal when you build it
<cyphermox> but in that case, it should crash, not hang around doing nothing
<didrocks> you should do something similar to what I've done for the lens
<didrocks> larsu: http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/data/Makefile.am
<didrocks> it compiles the schema on build
<didrocks> larsu: and then using http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/test/vala/test-vala.vala#L35 to set it to the path
<didrocks> (XDG_DATA_HOME)
<didrocks> and compile ;)
<larsu> didrocks, right. I'm going to pass this on to charles_ :)
<didrocks> charles_: seems you are the victim in that story :)
<didrocks> hey mterry, do you think you will have time for working on the bootstrapping of the unity stack? (other than the 3 I've made. I'm sorry, didn't have the time today to do the others, finishing the automated upload process)
<mterry> didrocks, sure I'll work on them today
<didrocks> mterry: this sounds like spam for me tomorrow morning! Thanks a lot :)
<mterry> yup  :)
<Trevinho> didrocks: when you're back: https://code.launchpad.net/~3v1n0/bamf/remove-gtk2/+merge/134537 (or mterry...)
<mterry> Trevinho, neat
<mterry> will be nice to lose that build
<ricotz> Trevinho, hi, i would introduce LIBBAMF_VER and just use "3" at those places
<ricotz> wouldnt*
<MCR1> bschaefer: Hi :) Video of Dash overlay-scrollbars looks great - Top Job ! :-D When will it land ?
<bschaefer> MCR1, :), thanks. It should land in trunk in the coming weeks
<MCR1> bschaefer: So far away from merge ?
<bschaefer> MCR1, no, I just want to polish it up and it is hard to say
<MCR1> ah, ok
<bschaefer> MCR1, hopefully next week (hopefully!)
<Trevinho> ricotz: I wanted to factorize that value... any better idea?
<ricotz> Trevinho, i think there is no need for that, or are you planning for GTK+4.0 ;)
<MCR1> ricotz: Hi :) Do you already have an ETA for plank-docky ?
<ricotz> MCR1, no ;)
<MCR1> ricotz: Still using the best dock no money can buy here... ;)
<ricotz> MCR1, quiet, do you where you are ;P
<MCR1> but unfortunately with a new bug introduced with latest fglrx ATI driver :(
<ricotz> sorry g2g
<MCR1> Yes, but I will voice my opinion anyway :P :-X
<Trevinho> ricotz: no plan for gtk4, just don't want to keep magic numbers around :)
<MCR1> Trevinho, andyrock, bschaefer: Could you please take a look @ https://code.launchpad.net/~mc-return/unity/unity.merge-minor-possible-speed-improvement/+merge/133435 and https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520 ?
<bschaefer> MCR1, Ill look into it
<bschaefer> MCR1, https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520
<bschaefer> the init list should look like:
<bschaefer> ctor()
<bschaefer> : var(false)
<bschaefer> not ctor() :
 * bschaefer thinks it looks cleaner
<andyrock> MCR1, also no space between variable and (
<MCR1> ok, I am always confused with different styles used for Compiz/Unity
<MCR1> :)
<bschaefer> MCR1, yeeah compiz uses a crazy style
<MCR1> C++11, mixed spaces and tabs
<bschaefer> well compiz doesn't use C++11 yet
<bschaefer> and yes...they mix spaces and tabs :(
<MCR1> but no problem, I'll change it
<MCR1> to Unity style :)
<bschaefer> thanks :)
<MCR1> ~20 min (girlfriend calls ;))
<andyrock> MCR1, also keep in mind that .size() in c++11 is O(1)
<andyrock> so it's not so slow :)
<andyrock> but I prefer to use ::empty
<andyrock> so thank you
<bschaefer> plus empty usually checks the size
<bschaefer> but it is more readable
<andyrock> bschaefer, MCR1 talking about C++03 ::empty is faster using std::list and std::string
 * bschaefer would think size is a stored variable
<bschaefer> which empty should just return size;
<bschaefer> if it == 0 ... its false
<bschaefer> o well
<andyrock> bschaefer, gcc implementation did not store the size
<bschaefer> oo i see
<bschaefer> that makes sense
<andyrock> but now it does
<andyrock> it's a minor change but a big ABI break
<bschaefer> I could imagine...
<bregma> andyrock, that change was backed out of GCC 4.7 because it caused the ABI-incompatibility bug
<bregma> 4.7.2 does not confirm, but at least it's not broken
<andyrock> bregma, so std::list::size on gcc 4.7 is still O(n) ?
<MCR1> bschaefer: Should be fixed now :)
<bschaefer> MCR1, awesome
 * bschaefer looks again
<MCR1> andyrock, bschaefer: Thanks for the reviews :)
<andyrock> ;)
<bschaefer> MCR1, you missed andyrocks comment :(
<bschaefer> + : icon_size (0)
<bschaefer> no space between
<bschaefer> e and (
<bschaefer> e (
<bschaefer> e(
 * bschaefer feels extra picky for some reason
<MCR1> bschaefer: ups, will fix that also :)
<bschaefer> MCR1, thanks :)
<MCR1> I've initialized the bool with false btw, not sure if this is ideal...
<bschaefer> MCR1, what does it normally get set to?
<bschaefer> MCR1, looking at that, it should be fine
<MCR1> bschaefer: Some initialize bools with true...
<bschaefer> MCR1, hmm, let me look some more at the code
<bschaefer> it might need to be true
<mterry> fginther, I wanted to look at the jenkins failures in https://code.launchpad.net/~mterry/unity-scope-gdrive/dailybootstrap/+merge/134521 but the links are for a local jenkins install
<popey> mterry, bodge s-jenkins IP 10.97.0.6 into your hosts file for a quick/dirty fix?
<popey> mterry, or manually s/s-jenkins/10.97.0.6/ in those urls
<popey> http://10.97.0.6:8080/job/unity-scope-gdrive-ci/build=pbuilder,distribution=raring,flavor=amd64/5/console works for me
<mterry> popey, fair enough
<fginther> mterry, did popey's suggestion work for you?  I'll ping the owner of this job to have it published to the external server
<mterry> fginther, uh, let me see
<mterry> fginther, nope.  I get "could not connect to 10.97.0.6:8080"
<popey> you have vpn setup?
<popey> via batuan?
<mterry> nope
<mterry> I should have guessed with a 10. address
<bschaefer> mterry, do you have a link of what you are trying to access?
 * bschaefer has VPN
<mterry> bschaefer, fginther is grabbing me a log I think
<mterry> thanks though!
<bschaefer> mterry, awesome, I was about to :)
<bschaefer> mterry, (here it is anyway: http://paste.ubuntu.com/1361226/)
<fginther> mterry, http://paste.ubuntu.com/1361227/
<fginther> wow, consecutive numbers
<bschaefer> nice
<mterry> fginther, bschaefer: Thanks!
<mterry> fginther, this build error is dumb.  Couldn't resolve bazaar.launchpad.net
<mterry> fginther, is that build job broken?
<bregma> must be the internets that's broken
<fginther> mterry, there have been some infrastructure/networking changes regarding the build host. However, these should have cleared up before #5 ran
<mterry> fginther, a separate gdrive branch just passed jenkins, so maybe it's fine now
<mterry> fginther, though I notice that I'm not a member of ~online-accounts
<fginther> mterry, you're membership should not matter, the branch is accessed via a special account
<mterry> fginther, yeah, but it prevents me from toggling branch status
<fginther> grumble...
<mterry> fginther, it's odd that we use online-accounts for that one branch anyway
<fginther> mterry, let me see if I can kick it
<mterry> fginther, thanks.  I have to run an errand right now anyway, but we can catch up later
<MCR1> bschaefer, andyrock, Trevinho: We have quite a bit of multimonitor bugs, which need to be fixed - One of them is that the Place Plugin's settings being ignored, because Unity is loaded after Place and got it's own window-place function. How can we best ensure in this function that the Place plug-in's Place function is called also ?
<bschaefer> MCR1, make a bug about it
 * bschaefer isnt 100% sure off the top of my head
<MCR1> bug 874146
<ubot5> Launchpad bug 874146 in Compiz "Multimonitor: New windows open on the wrong monitor, Place Plugin settings silently ignored" [Undecided,In progress] https://launchpad.net/bugs/874146
<MCR1> bschaefer: Do you run a multimonitor config ?
<bschaefer> nope
<MCR1> :(
<andyrock> MCR1, are you talking about UnityWindow::place() ?
<MCR1> bschaefer: The problem is we have 2 place functions, which do not work together correctly - yes
<MCR1> andyrock: yes
<MCR1> exactly
<andyrock> and PlaceWindow is not called right?
<andyrock> PlaceWindow::place
<MCR1> and the combination with the place plug-in
<andyrock> or something like that
<MCR1> yes, the whole place plug-in gets ignored
<MCR1> so windows do not open correctly on the right monitor as specified
<andyrock> MCR1, did you talk with duflu?
<MCR1> but if you load the place plugin after unityshell it works correctly
<MCR1> no, but I talked with smspillaz
<MCR1> https://bugs.launchpad.net/compiz-core/+bug/874146/comments/30
<ubot5> Ubuntu bug 874146 in Compiz "Multimonitor: New windows open on the wrong monitor, Place Plugin settings silently ignored" [Undecided,In progress]
<MCR1> here you can see how it *should* work
<andyrock> MCR1, I'm not too much in the problem but have you tried to call window->place(...) in UnityWindow::place
<MCR1> Sam told me  we need to look at UnityWindow::place to see if you can prevent unity from overriding the place plugin
<MCR1> So can I just call  CompWindow::place () inside of unityshell.cpp, yes ?
<andyrock> hmmm let me check the code
<MCR1> andyrock: It would be great if you can help here, because it is a really nasty bug - I've fixed it here (but with the wrong solution - by just ensuring that place gets started after uniutyshell...)
<MCR1> Here my discussion with Sam: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix874146-place-plugin-broken/+merge/130672
<andyrock> MCR1, ::place returns a bool, do you know why?
<MCR1> To be honest: no ;)
<MCR1> you mean the place from place.cpp ?
<andyrock> no all the place functions :)
<MCR1> yeah, just noticed...
<andyrock> btw you just need to call window->place inside UnityWindow::place
<MCR1> I simply could not believe that the solution for this nasty long-time bug could be so simple...
<andyrock> MCR1, one moment
<MCR1> andyrock: It is the same Sam suggested...
<andyrock> MCR1, calling it ensures that place window is called too
<MCR1> moving bool result = window->place(pos); to the top of the function ?
<andyrock> MCR1 can you tell me a fast way to reproduce the bug?
<MCR1> sure, but you need multimonitor ofc
<MCR1> best see the description here: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix874146-place-plugin-broken/+merge/130672
<MCR1> see [Test Case]
<MCR1> andyrock: Thx 4 your help here :)
<andyrock> MCR1, yeah i've a multimonitor
<MCR1> ;)
<andyrock> brb
<andyrock> MCR1, i can reproduce the bug in the MP description
<andyrock> it works just fine with the terminal
<andyrock> the windows open in the correct monitor
<andyrock> at the correct position
<MCR1> So you mean the Place plug-in settings are working correctly in current trunk ?
<MCR1> Or with the fix applied ?
<andyrock> with quantal vanilla
<andyrock> MCR1,
<andyrock> and with unity-trunk too
<MCR1> so can you reproduce the bug or you cannot reproduce it ?
<MCR1> sry - it is already late here ;)
<andyrock> MCR1, I cannot reproduce it :)
<andyrock> it's late for me too (23:54)
<MCR1> strange, but good news... I wonder when this changed - but perfect if it is fixed already...
<MCR1> so you can set the terminal window to open where the mousepointer is, yes ?
<MCR1> andyrock: Thx a lot 4 your help @ late hours...
<andyrock> MCR1, yeah my terminal follolow my mouse
<andyrock> *follows
<MCR1> great, fix released without any code then :)
<andyrock> MCR1, don't change the status for the moment
<MCR1> ok
<andyrock> MCR1, maybe it happens only for some monitor configurations
<MCR1> I could reproduce it 100%, but I am too tired to remove my fix here and retest...
<andyrock> MCR1, your monitor resolution?
<MCR1> 1920x1200 and 1280x1024
<MCR1> and 1920 x1080
<MCR1> which does not work as triple config with fglrx @ the moment...
<andyrock> so 3 monitors?
<MCR1> but worked as 3-screen with gallium
<MCR1> yes
<MCR1> well, 2 monitors and a TV :)
<Klap-in> i have here also a maximizing problem with two different screens, don't know if it is also this place issue..
<MCR1> but with fglrx just the 2 monitors are active
<Klap-in> hmm, sorry on precise
<MCR1> Klap-in: No, that is probably bug 751605
<ubot5> Launchpad bug 751605 in Compiz "Multi-monitor - Windows maximize on the wrong monitor" [Critical,In progress] https://launchpad.net/bugs/751605
<MCR1> Klap-in: duflu is already working on it :)
<Klap-in> MCR1: you're right!
<Klap-in> nice
<MCR1> Hope it will backported to Precise once it's fixed, but guess it will be - but do not hold your breath while waiting for it ;)
<Klap-in> improvement of the multimonitor behavior would be great, of course ;)
<MCR1> Klap-in: I agree 123%
<mterry> fginther, hey, I was noticing that the jenkins jobs for unity seem to be based on quantal still.  Seems wrong, no?
#ubuntu-unity 2012-11-16
<didrocks> hey mmrazik
<didrocks> what was the bzr misconfiguration you are talking about?
<didrocks> thanks for the report btw :)
<didrocks> larsu: on this not so sunny Friday, do you want some really free karma? https://code.launchpad.net/~didrocks/indicator-power/bootstrap/+merge/134623
<larsu> didrocks, sure! done ;)
 * larsu love lp karma
<didrocks> larsu: thanks! I knew you live for karma!
 * apw has recently updated on Quantal and the messaging indicator is gone, i assume this is not expected
<larsu> apw, yes it is: the messaging menu is only shown when you have applications that integrate with it. And you need to start them manually once
<apw> larsu, oh, hmmm, is that new behaviour or am i just unobservant
<apw> larsu, i thought i used to start the applications from that menu ...
<ppisati> i've same problem as apw
<ppisati> and i always had the envelope icon
<larsu> apw, you'll be able to, you just need to start them once and they'll show up again
<ppisati> first thing i did in the morning was to start irc, msn, skype, ectec
<larsu> beware: not all applications have been ported to the new API yet
<ppisati> and i did it going to the messaging menu, and mrking myself as avilable there
<apw> larsu, indeed starting gwibber did make the menu appear
<ppisati> now, how am i supposed to login in msn if all the dialogues went through it? (and the icon/menu is not there anymore)
<larsu> apw, and it will stay there now :) (until you uninstall gwibber or disable messaging menu integration in its preferences)
<apw> larsu, so did that happen when i updated P->Q and i just didn't notice?
<larsu> apw, yep
<apw> an pidgin which i use most isn't apparently connected to it hense its not appeared again before
<larsu> apw, yeah pidgin is one of the apps that aren't ported yet. But there's already a patch attached to https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259
<ubot5> Ubuntu bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress]
<larsu> apw, fyi: http://design.canonical.com/2012/04/status-menus/
<apw> larsu, thanks for the explanations; i am not sure the user supprise this clearly engenders was the best user experience possible, not that any of that is your fault
<ppisati> larsu: so, if i start an application that uses that menu, it appears, right?
<ppisati> larsu: but wasn't empathy supposed to start automatically at boot?
<larsu> ppisati, no, empathy doesn't start automatically afaik
<ppisati> larsu: well, then it did when you select "available" in the envelope men
<ppisati> u
<larsu> ppisati, you only have to start the application once to make it appear in the menu forever from that point on (even after you close the app or reboot)
<ppisati> larsu: ack, done
<ppisati> larsu: thanks
<apw> larsu, is there a way to get rid of things you never use from it which you used in the past and no longer do ?
<ppisati> larsu: but i don't get why it shouldn't be there after a P->Q transition
<larsu> ppisati, apw, I agree it's not a perfect experience for users upgrading from P -> Q, but due to the new API it was practically impossible to write migrations
<larsu> it was a tradeoff, we chose the minor annoyance of starting the app once
<ppisati> larsu: ok
<larsu> apw, a well-behaved application will offer a preference. Otherwise you can remove it from dconf-editor (com.canonical.indicator.messages.applications)
<larsu> of course, uninstalling an application will also remove it
<ppisati> larsu: another question, i was used to have the skype icon show up in the iconbar
<ppisati> larsu: but is not there anymore, you know why?
<ppisati> of course, skype is running now
<larsu> ppisati, it shows up for me, right next to the messaging menu
<ppisati> :(
<ppisati> nt for me...
<ppisati> i've it in the unity bar
<ppisati> but not up there
<larsu> ppisati, no idea, sorry. There doesn't seem to be a preference, either
<ppisati> larsu: do you know if there's a place (directory, gconf entry, etcetc) where all the icons that show up in the bar are listed?
<larsu> no, there isn't
<mhr3> ppisati, try adding "skype" to com.canonical.unity.panel.systray-whitelist
<mhr3> (in dconf)
<ppisati> mhr3: so we still need to whitelist it, ok
<ppisati> mhr3: question: since it's such a common app (and it's integrated with the messaging menu), why don't we whitelist by default?
<mhr3> it's weird, i remember it using indicator previously, now it isn't :/
<mhr3> larsu, i guess because of the api changes?
<ppisati> s/it's integrated/it's not integrated/
<larsu> mhr3, yep, but somebody seems to be working on it: https://bugs.launchpad.net/skype-wrapper/+bug/1040259
<ubot5> Ubuntu bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress]
<larsu> mhr3, I don't have skype on the whitelist. I think its an appindicator already
<mhr3> larsu, that's what i said, but it disappeared for me after moving to 12.10
<larsu> mhr3, oh, you mean skype in the messaging menu or skype on the panel?
<mhr3> larsu, panel
<mhr3> or maybe it's just a qt lib that's no longer installed with skype
<larsu> mhr3, might be. Does the sykpe binary export the /org/kde/statusnotifieritem objects for you?
<larsu> and do you have indicator-application installed
<mhr3> larsu, it doesn't export that
<larsu> that's the problem, then :)
<larsu> which skype version are you running?
<mhr3> the question is why :)
<mhr3> 4.0.0.8
<larsu> okay, same for me
<larsu> mhr3, do you have sni-qt installed?
 * larsu found agateaus blog post about it: http://agateau.com/2011/07/19/statusnotifieritem-for-qt-applications/
<larsu> skype seems to use QSystemTrayIcon still, and sni-qt is a plugin that turns systray icons into app indicators
<mhr3> larsu, i do :/
<larsu> :(
<mhr3> and that's what happens when aurelien leaves
<conscioususer> larsu: do you know where I can find some UOA docs for third party app devs? just reading the api is being insufficient for me
<conscioususer> mhr3: I heard some people solved this issue by installing the correct arch of sni-qt
<mhr3> conscioususer, bingo, installing the i386 variant fixed it
<mhr3> larsu, ^^
<conscioususer> :)
<mhr3> now if only the skype menu didn't flicker everytime i click on it
<larsu> conscioususer, awesome, thanks!
<larsu> conscioususer, I'm not sure about docs for uoa, let me find out
<conscioususer> larsu: thanks :)
<didrocks> larsu: hey, I have an other simple and dummy merge for your karma :) https://code.launchpad.net/~didrocks/indicator-power/changes_from_trunk.12.10/+merge/134643
<larsu> didrocks, sure - but I'll wait to see the diff. Not that I don't trust you.......
<didrocks> larsu: sure sure :)
<larsu> conscioususer, meet amigadave :)
<amigadave> conscioususer: hi!
<amigadave> conscioususer: mardy wrote https://docs.google.com/a/canonical.com/document/d/1MVsDdwzff6LqQ6i3z-cSgg8dHjb5DaHMXFeWtIa6Cvo/edit which is some general developer documentation for UOA
<amigadave> conscioususer: is that more what you were looking for?
<conscioususer> amigadave: probably, as I'm specifically looking for info for 3rd party clients
<conscioususer> amigadev: at a first glance this seems enough, thanks :)
<amigadave> conscioususer: we are working to get all of that documentation into the API references too
<amigadave> let us know if you have any feedback :)
<conscioususer> amigadave: will do, thanks :)
<larsu> didrocks, approved
<larsu> didrocks, I'm really looking forward to seeing how daily landing will turn out in practice
<didrocks> larsu: same here, we are >< <- that close
<larsu> \o/
<didrocks> larsu: just need a commit after the bootstrapping so that it can detect there are some changes
<didrocks> larsu: let's find something useful for each project :)
<larsu> didrocks, yep :)  btw, did you decide on a rule on when to mark bugs as "fix released"?
<didrocks> larsu: right now, I only open the downstream bug and it will be marked as fix released, I don't touch the upstream one until you decide to do your own release
<didrocks> larsu: it's really as you prefer, if you think it should close it, we can discuss it :)
 * larsu is unsure
<larsu> still :)
<didrocks> let's see how it goes that way :)
<conscioususer> amigadave: er, why does uoa store user passwords for oauth-based accounts?
<amigadave> conscioususer: so that it can reauthenticate without the user having to enter the credentials again
<conscioususer> amigadave: isn't this what the access token is for?
<amigadave> conscioususer: if the token expires, then the user would otherwise have to re-enter the username and password
<amigadave> i think that refresh tokens were tried (with Google, specifically) but they did not work reliably
<amigadave> and Google has very short token validity :/
<conscioususer> amigadave: but what about oauth1.0 services like twitter?
<conscioususer> amigadave: btw, what do you mean by "not work reliably"? I'm curious on that one because I use google refresh tokens on an app of mine
<amigadave> conscioususer: mardy knows the full details
<amigadave> conscioususer: and #accounts-sso might be a better place for these questions :)
<conscioususer> oh, of course
<conscioususer> sorry, will move there :)
<davidcalle> mhr3, does this kind of bug fall under your new jurisdicition? (frequency of recommendations and sources calls to *search.ubuntu.com) https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1079699
<ubot5> Ubuntu bug 1079699 in unity-lens-video (Ubuntu) "Empty queries being sent to videosearch" [Undecided,New]
<mhr3> pawel is looking at it
<mhr3> i mean, pstolowski
<davidcalle> Ok
<pstolowski> davidcalle, mhr3: hey, yep. it's basically "by design", I'll check with server side guys if we can query it less often for recommendations.
<mhr3> pstolowski, are the sources checked that way too?
<pstolowski> mhr3: yes, same interval
<pstolowski> mhr3: this is definately too often for sources
<mhr3> i can imagine that sources should be checked just once
<mhr3> + on location change
<mhr3> which i'm not sure can be detected easily
<davidcalle> mhr3, I think that tedg has made some work on Ubuntu geoclue last cycle, maybe he could give a hint?
<mhr3> yea, i'm pretty sure the time indicator or whatever behind it knows, just don't think it exposes changes to location as some signal
<tedg> mhr3, We poll occasionally, it's GeoIP though so it really only changes on reboot.  But it's all just GeoClue.
<tedg> mhr3, So if you cache an address then you can get the new one.
<tedg> mhr3, If you grab indicator-location you can see what you've got easily.  Also, some simple sample code.
<pstolowski> mhr3, davidcalle: we could consider location for R, but for P or Q we should only fix the frequency
<mhr3> tedg, i'm not a fan of polling, i want to be notified :)
<mhr3> pstolowski, sure
<davidcalle> pstolowski, +1
<tedg> mhr3, Well, you'll be notified on changes.  For GeoIP we can't get notified.
<Squarism> java is the most popular programming language, intellij is the most popular IDE... tons of hotkeys in intellij conflict with Unity. Please solve this to make ubuntu alot more user friendly for a big number of programmers
<larsu> [citation needed]
<bregma> Squarism, is there a bug in Launchpad you can reference?
<MCR1> smspillaz: Hi :) Thanx 4 the ultra-fast approval...
<mterry> didrocks, what does the jenkins error in https://code.launchpad.net/~mterry/unity-scope-gdrive/rename/+merge/134567 mean?
<didrocks> mterry: I don't really know, it seems something similar to my check I did with tarmac, like "check that the approved rev id is the latest rev on the branch"
<didrocks> I think they do the same on jenkins
<didrocks> mmrazik? ^
<didrocks> hum, not hereâ¦
<didrocks> mterry: so, I approved agian
<didrocks> now see:
<didrocks> Approved revision: 30
<didrocks> sometimes, it can be "unknown"
<didrocks> due to launchpad timeout I guess
<didrocks> maybe that was the case
<didrocks> let's bet on this
<MCR1> didrocks: Hi :) Could we change the way expo is patched for Ubuntu ? It seems to create quite some problems...
<didrocks> (it seems they have the same check, see "Unapproved changes made after approval.")
<didrocks> MCR1: how do you want to change it?
<MCR1> Hmm, maybe with some ifdefs or so...
<MCR1> COMPILE_FOR_UBUNTU_UNITY or something like that
<MCR1> the problem is that for example this patch fails all the time: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1009592-and-1074487-expo-xml-tooltip-fixes/+merge/132754
<didrocks> MCR1: what do you mean? it's still a patch applied
<didrocks> MCR1: with inline packaging, you can now try and apply it yourself :)
<didrocks> and fix it
<didrocks> or convince upstream who did the patch to take it by default
<MCR1> yeah, that is what I mean
<didrocks> I would love that it's upstream
<MCR1> it should be in upstream, otherwise things are really hard to fix
<didrocks> if you can push for that, please try :)
<didrocks> (I already tried)
<didrocks> having patches to maitain is a burden
<MCR1> and expo is currently very broken in various ways (the ubuntu patch is breaking it...)
<didrocks> well, the ubuntu patch was done by upstream, you know ;)
<MCR1> for example brightness and saturation settings are ignored...
<MCR1> *of inactive viewports
<MCR1> and other issues
<didrocks> if you feel fixing them, that would be awesome!
<MCR1> so I got to convince smspillaz and duflu ?
<didrocks> exactly!
<MCR1> ok
<MCR1> thx
<MCR1> 4 the info
<didrocks> yw
<Munchor> Hello guys
<Munchor> When an appindicator does not remove itself properly, what is actually done
#ubuntu-unity 2012-11-17
<MCR1> smspillaz: Hi :) Did you already talk to someone to make you a member of ~compiz-team again ?
<MCR1> Trevinho: Hi. Are you here ?
<FlowRiser> hello :)
<FlowRiser> I want to develop a qt/cpp desklet for the default ubuntu desktop. Is it possible to have a qt application take-over the whole desktop space ?
#ubuntu-unity 2012-11-18
<mhouse> hello
<mhouse> anyone on
<EXORCIST> HI LAL
<EXORCIST> ALL
<Daekdroom> Stop screaming.
<Daekdroom> My left ear is aching.
<EXORCIST> My unity runs quite slow
<EXORCIST> !ops
<ubot5> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici,  jpds,  gnomefreak, bazhang, jussi, Flannel, ikonia, maco, h00k, IdleOne, bkerensa, nhandler or Jordan_U!
<EXORCIST> !ops
#ubuntu-unity 2013-11-11
<Saviq> tsdgeos, fyi: I've a surprise National Holiday today ;)
<tsdgeos> Saviq: cool!
<tsdgeos> surprsise holidays ftw!
<tsdgeos> enjoy :-)
<tsdgeos> mzanetti: you back today or tomorrow?
<Saviq> mzanetti, tomorrow
<Saviq> tsdgeos, rather â
<tsdgeos> oka
<tsdgeos> tx
<nic-doffay> tsdgeos, commented back https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
<tsdgeos> nic-doffay: null doing what/whenÂ¿
<nic-doffay> tsdgeos, if you remove that alias searchHistory doesn't get passed through properly to the page header.
<tsdgeos> nic-doffay: hwo do i test it?
<nic-doffay> tsdgeos, if you remove that ill alias you'll see in the output...
<nic-doffay> It will complain about the "count" variable in the PageHeader
<dednick> Is jenkins down?
<tsdgeos> may be
<tsdgeos> read somewhere about "friday issues"
<tsdgeos> or something
<tsdgeos> nic-doffay: i din't see any count warning when searching and that line removed
<tsdgeos> nic-doffay: can you be a bit more precise on what you do exactly and what exactly you get as warning?
<nic-doffay> tsdgeos, I get this when I remove that line and attempt a search from the Apps http://pastebin.ubuntu.com/6398871/
<tsdgeos> right
<tsdgeos> silly me
<tsdgeos> need to try in the apps scope if want to test dashapps code :D
<nic-doffay> tsdgeos, at first I assumed the same as you about this. What would be the need for the alias?
<tsdgeos> nic-doffay: looks like a Qt bug to me, maybe related to https://bugreports.qt-project.org/browse/QTBUG-30493
<tsdgeos> nic-doffay: can you add acomment saying "FIXME this shouldn't be neeed but without it the property is not correctly propagated to the PageHeader, check with newer Qt if it can be removed"
<tsdgeos> or something like that?
<nic-doffay> tsdgeos, sure
<mzanetti> Saviq: tsdgeos: tomorrow
<tsdgeos> mzanetti: oka, enjoy!
<mzanetti> tsdgeos: meh... have to drive from italy to germany today :/ not too much fun
<tsdgeos> dednick: yeah according to #ubuntu-ci-eng "All services are down" :D
<dednick> tsdgeos: ah :)
<tsdgeos> dednick: about https://code.launchpad.net/~nick-dedekind/unity8/lp1249369/+merge/194540
<tsdgeos> can the if (searchContainer.popoverShouldOpen) { searchContainer.openPopover(); } checks move to inside openPopoever itself?
<dednick> tsdgeos: no, because we want calls to openPopover to always open it.
<dednick> tsdgeos: the check is only for the delay caused by the animation.
<tsdgeos> i see
<dednick> tsdgeos: otherwise if we call something that causes the open animation to run, then explicitly call closePopover, it will close and the open again once the animation is coplete
<tsdgeos> looks a bit prone to breaking, like we may forget the check when it's needed somewhen
<tsdgeos> but we have the unittests to catch that hopefully :D
<dednick> tsdgeos: hm. let me check if i can make it better. Maybe explicitly stop the open animation when calling close
<tsdgeos> dednick: nah it's ok
<tsdgeos> dednick: though this is a bit confusing though
<tsdgeos> if (!searchContainer.popoverShouldOpen) { searchContainer.closePopover(); }
<dednick> tsdgeos: yeah, i know.
<tsdgeos> in my mind a variable named "popoverShouldOpen" shouldn't control the closing :D
<tsdgeos> dednick: maybe a simple comment may help on why those are needed there?
<tsdgeos> or?
<dednick> tsdgeos: would you prefer to flags? popoverShouldOpen/popoverShouldClose ?
<dednick> s/to/two
<tsdgeos> dednick: probably nto since they would have the same value all the time, no?
<dednick> it's somewhat more accutate
<dednick> tsdgeos: opposite values
<tsdgeos> hmmm
<tsdgeos> don't know tbh
<dednick> tsdgeos: ok. i'll sort it out. actually i dont think they will always be opposite, so may be best to have both.
<tsdgeos> oki ;.)
<tsdgeos> tx
<tsdgeos> sorry for being a bit obnoxious
<dednick> tsdgeos: :) np
<dednick> tsdgeos: you're LVWPH bug man right? :)
<tsdgeos> that's what they say
<dednick> tsdgeos: https://bugs.launchpad.net/unity8/+bug/1237942
<ubot5> Ubuntu bug 1237942 in Unity 8 "Unity8 crash while doing search in home scope" [High,Confirmed]
<tsdgeos> let me see if i can repro
<tsdgeos> meanwhile i'm waiting on 6 reviews
<tsdgeos> if anyone could take one...
<tsdgeos> https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 should be easy
<tsdgeos> same for https://code.launchpad.net/~aacid/unity8/noModelInSignal/+merge/194672
<nic-doffay> Can anyone confirm if jenkins is having issues?
<dednick> it's actually fairly easy to see the bug in the code, but it's a bit complicated just for me to jump into without most likely breaking it ;)
<tsdgeos> nic-doffay: it's down yes
<tsdgeos> dednick: well m_firstVisibleIndex should never be 0 if m_visibleItems is empty
<tsdgeos> seems like that is the case in your backtrace
<dednick> tsdgeos: yep
<tsdgeos> dednick: and of course i can't reproduce
<dednick> tsdgeos: http://pastebin.ubuntu.com/6399365/
<dednick> growDown=true, so m_firstVisibleIndex does not get set to -1
<tsdgeos> meh
<tsdgeos> ok let's read the code if i can't repro
<tsdgeos> dednick: does this help? http://paste.ubuntu.com/6399373/
<tsdgeos> probably not
<dednick> tsdgeos: nope
<tsdgeos> dednick: http://paste.ubuntu.com/6399392/ ?
<tsdgeos> that one oughta be better
<dednick> tsdgeos: yeah, that worked
<dednick> tsdgeos: can remove the check above to set -1.
<tsdgeos> ok now we need a test case :D
<tsdgeos> dednick: which check? the one in the other function?
<dednick> oh right you did.. nvm
<tsdgeos> ah the one a few lines above
<tsdgeos> yeah i did
<tsdgeos> dednick: ?
<dednick> eh?
<tsdgeos> what you mean with single line commit message
<dednick> i'm sure we were asked to only use a single line for commit?
<tsdgeos> nope
<tsdgeos> we were asked to use a "git-like" commit message
<tsdgeos> i.e.
<tsdgeos> single line
<tsdgeos> empty line
<tsdgeos> longer stuff if we need it
<dednick> Oh. right
<tsdgeos> dednick: can you do a quick test? can you uncomment the //     qDebug() << "ListViewWithPageHeader::onModelUpdated" << changeSet << reset;
<tsdgeos> in ListViewWithPageHeader::onModelUpdated to make sure you are getting the removes and the insert at the same time?
<tsdgeos> dednick: you may need to comment changeset since it is silly and doesn't know how to print it even if the header says it knows
<dednick> tsdgeos: nope. different
<dednick> tsdgeos: not sure i enjoy your cavalier usage of first() without checks ;)
<dednick> it makes me sweat
<tsdgeos> dednick: well, there *is* a check ;-)
<tsdgeos> that is the m_firstVisibleIndex :D
<tsdgeos> dednick: i need you to add a few more debugs
<tsdgeos> dednick: can you help me?
<tsdgeos> dednick: i need to know why growDown is true, is it that item is null or that item is culled?
<tsdgeos> dednick: standtup?
<MacSlow> nic-doffay, your mumble working
<tsdgeos> Cimi: ok, while dednick doesn't come back with the info let's have a look at that inversemousearea thing
<tsdgeos> Cimi: what's the problem exactly
<tsdgeos> Cimi: i.e. what do i do to repro?
<Cimi> tsdgeos, apply that pastebin
<Cimi> tsdgeos, run an app
<Cimi> tsdgeos, ener termination mode
<Cimi> *enter
<Cimi> tsdgeos, tap anywhere inside the running applications grid and you see "pressed" on console
<Cimi> tsdgeos, tap outide - nothing
<tsdgeos> Cimi: do you have something that can be tested on the desktop?
<MacSlow> Cimi, tsdgeos, dandrader: did the IP of s-jenkins change again?
<Cimi> tsdgeos, you can test that
<tsdgeos> MacSlow: it's dead jum
<MacSlow> tsdgeos, *sigh* thx
<tsdgeos> s/jum/jim
<Cimi> tsdgeos, you need xdv dirs
<tsdgeos> MacSlow: well not dead, they're moving the metal it seems
<MacSlow> tsdgeos, ok
<tsdgeos> Cimi: Â¿?
<Cimi> tsdgeos, hodl on
<Cimi> tsdgeos, XDG_DATA_DIRS=tests/mocks/data/:$XDG_DATA_DIRS ./run
<Cimi> tsdgeos, then click on the camera app
<tsdgeos> ok tx
<dednick> tsdgeos: sorry, got caught in some traffic during lunch. I'll take a look
<tsdgeos> Cimi: do you know where's the IMA documentation?
<tsdgeos> in the sourcecode...
<dednick> tsdgeos: item has been culled
<tsdgeos> dednick: that's weird on its own
<tsdgeos> being just one item on the list
<dednick> tsdgeos: if you say so. don't know what culled it
<dednick> *is
<tsdgeos> it should be visible
<tsdgeos> culled = non visible
<dednick> clipped ;)
<tsdgeos> i don't know what it really means either
<tsdgeos> it's just the term qt uses here
<Cimi> tsdgeos, sorry I'm in a call
<dednick> ok
<Cimi> tsdgeos, yeah ask zsombi
<mhall119> thostr_: mhr3: in http://developer.ubuntu.com/scopes/tutorial/ if you scroll down to "The scope file" there is a field: RemoteContent=false
<mhall119> it's not documented in the tutorial what that does, and I don't think it's documented anywhere else either
<mhall119> can you tell me what it's for?
<mhall119> and what uses it
<dednick> tsdgeos: i'm getting shed loads of glib-critical log messages when clearing the search field for the second search.
<dednick> from dee
<mhr3> mhall119, it's the "this scopes does internet"
<tsdgeos> dednick: mhr3's your man for that :D
<mhall119> mhr3: what uses that?
<mhr3> mhall119, so if internet searches are disabled, the scope is disabled
<mhall119> I thought if internet searches were disabled, only default scopes were used
<tsdgeos> dednick: tbh at this stage i'm not sure i can easily create a testcase that reproduces what you're doing :-/
<mhr3> mhall119, you thought wrong :)
<tsdgeos> basically you have a list that has just one item and that item is created but somehow not visible
<tsdgeos> that's a bug by itself
<tsdgeos> and then when you remove that item
<mhall119> so in the given example, it should be true not false
<tsdgeos> it crashes
<tsdgeos> that's also a bug
<tsdgeos> i can easily fix that second one but it is technically a workaound for the first one
<dednick> tsdgeos: hm. ok. maybe i'll do some more debugging and try figure out where the culled item is comming from
<tsdgeos> not sure if i make sense
<tsdgeos> dednick: appreciated :)
<mhr3> mhall119, right, it talks to the internet, doesn't it?
<mhall119> yeah
<mhall119> mhr3: so if online search is disabled, the smart scopes service won't be used, right?
<mhr3> right
<mhall119> so then nothing is making scope recommendations to the dash, how does it select which scopes to use?
<mhr3> it just queries the ones it always queries
<mhr3> apps, files
<mhall119> so the default ones
<mhr3> music?
<mhall119> that's what I thought
<mhall119> so then what does this field do?  Not allow the user to set a remote scope as a default scope when they have online search disabled?
<mhr3> it disallows communication to that scope if searching internet is disabled
<mhall119> communication that isn't likely to happen in the first place, since it won't be recommended to use the scope
<mhall119> not to be argumentative, just making sure I understand this so I can explain it to community folks
<mhr3> it could still be queried if it was a subscope of the always-search scopes
<mhall119> do we have any that are like that?
<mhr3> gdrive
<mhall119> that's a default scope?
<mhr3> yes
<mhall119> ah, ok
<mhr3> and it's files subscope
<mhall119> thanks mhr3, that puts it all together for me
<mdeslaur> ah, thanks mhall119, mhr3: that clears up some mystery :)
<mhr3> np
 * mhr3 waves hand @dednick there are no bugs in dee
 * mhr3 waves hand @tsdgeos there are no bugs in dee
<dednick> mhr3: if you wave your hands like that you might attract some attention... you want to be hiding.
<mhr3> my jedi powers fail me
 * mhr3 hides
<dednick> tsdgeos: the first visible item's position is somewhat out of page...
<dednick> when it does layout() it's setting to culled even though there is only 1 item.
<tsdgeos> that is weird :S
<tsdgeos> let me re-read the code
<tsdgeos> right layout just assumes the first item will be correctly positioned
<tsdgeos> doesn't try to fix it if it isn't
<tsdgeos> i wonder why i can't reproduce it
<tsdgeos> dednick: so you searrch "test", wait for search to finish, clear and search "test" again?
<tsdgeos> and it crashes?
<dednick> tsdgeos: search "test", expand "files and folders", clear search, enter "test" search again
<tsdgeos> dednick: you wait for the search to finish or not?
<dednick> tsdgeos: it's the cat expansion that does it
<dednick> tsdgeos: yeah
<dednick> i do wait
<tsdgeos> so search, wait, expand, clear, search again
<tsdgeos> dednick: â ?
<dednick> tsdgeos: yep
<mhall119> mhr3: follow up question, if a .scope has no RemoteContent field, what does it default to?
<tsdgeos> dednick: on the phone? or in the pc?
<dednick> tsdgeos: desktop
<mhr3> mhall119, unfortunately false :/
<mdeslaur> mhr3, mhall119: hrm, can we file a bug on that and change the default?
<mhall119> thanks again
<tsdgeos> dednick: defenitely not happening here :(
<mdeslaur> mhr3, mhall119: or would that break backwards compatibility or something?
<mhall119> mdeslaur: or make it a mandatory field
<dednick> tsdgeos: what categories do you have in default home?
<mdeslaur> mhall119: even better, yeah
<mhr3> mdeslaur, btw i wouldn't mind breaking stuff, this default sucks
<tsdgeos> dednick: apps and files and folders
<mdeslaur> mhr3: what package should we file the bug against for that?
<mhr3> mdeslaur, libunity
<mdeslaur> mhall119: I'll file the bug
<mhall119> defaulting to remote doesn't make sense either, there isn't a "sensible" default thinking about it from a non-privacy point of view
<mdeslaur> yeah, making it mandatory is better
<mhall119> can we do that mhr3
<mhall119> ??
<mhr3> well, that would break even more scopes
<mhall119> yes, but it would break them in expected ways early on
<dednick> tsdgeos: it's because when the category is expanded, there is only one listitem, and you clear the seach, the other categories are inserted, with the application category above it, but it's culled because it's position is above. Maybe it's not updating it's position when an item above it is removed.
<tsdgeos> dednick: i just can't see the difference between the first time you search test and the second
<dednick> tsdgeos: i mean when an item lower
<tsdgeos> i mean the LVPWH is just the same, no?
<mdeslaur> mhall119, mhr3: bug 1250134
<mhall119> IMO, having scopes break early and often is better than wondering why your local Virtual Machine scope doesn't return results when you have online search disabled, because the developer didn't provide an explicit value
<dednick> tsdgeos: the category expand
<ubot5> bug 1250134 in libunity (Ubuntu) "RemoteContent field should be mandatory in .scope file" [Undecided,New] https://launchpad.net/bugs/1250134
<tsdgeos> but the category exapnd gets reseted after you reset search
<tsdgeos> ah wait
<tsdgeos> it doesn't
<tsdgeos> maybe you just have more files & folders than me
<tsdgeos> i have 7
<tsdgeos> you have enough so that they fill the home when no search is there?
<mhr3> mhall119, that's the problem, from end user pov it'll be the same - the scope won't work
<mhall119> mhr3: but the scope developer will see it and fix it
<mhall119> and either way I think we'll need to go through all of the scopes we ship by default and check/fix them
<mhr3> even for the developer it's hard to see, it's the loader that will complain and you don't usually see its output
<mhall119> mhr3: we can compromise and just throw a nasy warning at the developer when it's run from the terminal?
<dednick> tsdgeos: i dont know. when i expand the category when i havent got a search present, I get multiple list items, but only one when i do have a search.
<dednick> tsdgeos: multiple "visible items" i mean
<mhall119> or will running it from the terminal while testing it by-pass the part that would check the .scope file?
<tsdgeos> i'm lost
<tsdgeos> dednick: your default home files and folders, how many items are there if you expand it?
<mhr3> mhall119, running a scope yourself won't show anything, the scope file is not necessary for that
<mhall119> ok..
<mhall119> well then, I'm +1 for just changing the default to true and checking the scopes we ship to make sure they are explicit
<dednick> you mean scope results? if under search, about 100, if not about 30
<mhr3> dednick, you're fixing the issues when reordering is enabled?
<mhr3> or this is unrelated to that?
<tsdgeos> dednick: so your default home "files and folders" fills the height when expanded and no search is there
<dednick> mhr3: no
<dednick> tsdgeos: yeah.
<tsdgeos> ok, mine doesn't
<tsdgeos> that probably makes a difference
<tsdgeos> i need to get more stuff in there
<tsdgeos> any ieda how to?
<dednick> tsdgeos: you need more files ;)
<dednick> i dont know actually
<dednick> mhr3: ?
<mhr3> files are coming from recently used
<mhr3> which is coming from zg
<mhr3> so just open stuff in gedit
<mhr3> tsdgeos, i imagine you're using too many qt-ish apps that don't integrate with zg, right?
<tsdgeos> most probably
<tsdgeos> dednick: ok, got it now
<dednick> tsdgeos: woo
<tsdgeos> dednick: much better
<mhr3> tsdgeos, so what is it that you're using the most and doesn't appear in zg?
<tsdgeos> mhr3: not sure i get you
<mhr3> tsdgeos, everytime you open a file it should be logged to zg, we have patches in gtk, kde libs... clearly something is missing
<dednick> nobody does
<mhr3> tsdgeos, or you're just on irc the whole day
<mhr3> :)
<tsdgeos> mhr3: yeah clearly the patch to kdelibs doesn't work
<tsdgeos> mhr3: i'm using kate for my file editing
<mhr3> hm, someone should check the patch
<mhr3> volunteers? :)
<tsdgeos> oyu mean like someone that knows how kdelibs works?
<dednick> you were  waving earlier
<dednick> pretty sure that means you!
 * tsdgeos points at mzanetti Â¬.~
<tsdgeos> mhr3: i guess the patch is at the ubuntu level, right? don't remember any "proper" kdelibs code with zg
<mhr3> dednick, my waving is very complex, is has implied pre and post conditions etc...
<mhr3> tsdgeos, right
<dednick> mhr3: yeah, well nobody understands the syntax, so they just assume you're good to go :)
<mhr3> dednick, one of the precondition is "if (mhr3.has_to_do_extra_work()) throw NoWayError("No way!");
<dednick> heh
<dednick> i should get one of those plugins
<tsdgeos> mhr3: you sure there's a patch for that? can't see anything that mentionszeitgeist in  kde4libs-4.11.2/debian/patches
<tsdgeos> Cimi: i think i may have found why the IMA doesn't work
<tsdgeos> Cimi: the topmostItem thing doesn't seem to "understand" touch events
<mhr3> tsdgeos, well it was implemented for precise iirc
<tsdgeos> may have been dropped
<mhr3> maybe
<Cimi> tsdgeos, talk to zombi if you can
<Cimi> tsdgeos, unless it's a bug in my patch
<tsdgeos> he's gone eating brains
<tsdgeos> will do tomorrow
<tsdgeos> mhr3: talked to the kubuntu packagers, noone seems to remember or be able to find a zeitgeist patch for kdelibs, maybe it was in the plan but just never happened?
<mhr3> hmm
<mhr3> let me dig up old emails
<Cimi> tsdgeos, thanks for helping
<tsdgeos> Cimi: that's team work!
<Cimi> tsdgeos, I can bring beers!
<tsdgeos> he he :D
<mhr3> tsdgeos, ok, checked it was never implemented in the kde libs, there's a dataprovider that is trying to read KRecentDocument by going over ~/.kde/share/apps/RecentDocuments
<mhr3> but it doesn't use any k-APIs so maybe the reader part got out-of-sync from the writer in kde libs?
<mhr3> or maybe the thing you're using doesn't use KRecentDocuments
<tsdgeos> yeah
<tsdgeos> that only gets filed if i open stuff with the open dialog
<tsdgeos> but not if i do
<tsdgeos> kate moo.cpp
<tsdgeos> which may be a bug in kate if you think about it
<mhr3> well, logging that is practically impossible
<tsdgeos> well not really, goes through kio::open you could easily log that if you have a kdelibs patch
<tsdgeos> anyway
<tsdgeos> back to real work ;-)
<mhr3> tsdgeos, you mean together with all the tmp files, dynamic modules and whatnot
<mhr3> zg wants user actions
<tsdgeos> sure
<tsdgeos> dednick: still there?
<dednick> tsdgeos: yo
<tsdgeos> dednick: can you check if the fix in lp:~aacid/unity8/lvwph_bad_header_position_1240118 also fixes this bug for you?
<tsdgeos> seems to fix it here
<tsdgeos> but a second confirmation is better
<dednick> tsdgeos: sure
<dednick> tsdgeos: yeah, seems to do it
<tsdgeos> dednick: ok, i'll link it there to that bug too
<tsdgeos> dednick: though probably we still have a testcase about it
<tsdgeos> dednick: thoughts?
<dednick> tsdgeos: would be nice to have a testcase, but it's a bit of an edge...
<dednick> tsdgeos: although the miraculous fix from that other branch seems a bit dubious...
<dednick> It's all a bit "random events
<tsdgeos> dednick: it's not dubious at al
<tsdgeos> l
<tsdgeos> it's just what needs to happen
<tsdgeos> i've two people say "it's dubious"
<dednick> trusting that this variable wont be the value because this other variable is this value when this happens... the problem is not the logic, but that we've caught all cases.
<tsdgeos> when tbh, you guys know close to nothing on how the LVWPH works
<tsdgeos> sure
<tsdgeos> i agree to catch all the cases, that's why we unit test stuff
<tsdgeos> to make sure we do not regress
<dednick> :) ok, then we need a unit test
<tsdgeos> yep
<tsdgeos> will do tomrrow though, eod now! tomorrow more!
#ubuntu-unity 2013-11-12
<pero> where can i get the actual extension for chromium's unity web apps? i've lost it and get it back it no matter what (reinstalling chromium-browser, unity-webapps-common, etc)
<tvoss> Saviq, ping
<tvoss> Saviq, for when you wake up: https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp/+merge/194797
<tvoss> and https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp/+merge/194804
<Saviq> tvoss, I like all the red
<tvoss> Saviq, :)
<Saviq> tvoss, missing debian/control entry, though
<tvoss> Saviq, yup, fixing
<tvoss> Saviq, please don't top-approve, yet
<Saviq> tvoss, k
<tvoss> Saviq, updated
<Saviq> tvoss, cheers
<tvoss> Saviq, now if only jenkins was with us again
<Saviq> tvoss, ;)
<cooljckd> hi guys
<cooljckd> anybody on the keyboard ?
<cooljckd> i just wanted to ask you guys in there is any repo for ubuntu in mauritius
<cooljckd> if*
<cooljckd> i mean a server locally in mauritius
<cooljckd> because the moment we have to download everything from the uk
<cooljckd> and it sucks
<cooljckd> to have to download updates on a daily basis from here with this type of bandwidth
<cooljckd> i mean what would cost you make a git server on the island and commit resent security updates to it automatically from anywhere
<greyback> cooljckd: you should be able to choose a repo closer geographically. Did you look in "Software & updates" ?
<cooljckd> nop
<cooljckd> it doesnt work that way
<cooljckd> let me explain why
<greyback> cooljckd: open that app, there's a dropdown for "Download from" where you can choose other servers
<cooljckd> the local telecom company is a jerk all outgoing connection is being reroute to the uk
<cooljckd> which make every bandwidth wise
<cooljckd> suck
<greyback> *all* outgoing connections? That's ridiculous
<cooljckd> so even if you choose another repo it stills sucks
<cooljckd> l know its crazy
<greyback> well then you need to talk to your local telecom company
<cooljckd> but seems they dont trust the local operators
<greyback> routing all traffic half way around the world is crazy sounding
<cooljckd> well all can be proven
<cooljckd> of course
<cooljckd> if you dought my info
<cooljckd> just check for yourself
<greyback> no I don't doubt you
<cooljckd> so i've to the uk recently
<cooljckd> i bandwidth there is 33 mb for the average jo
<cooljckd> its cool to work there
<cooljckd> dont get me wrong i love to travel but i still like my country
<cooljckd> and im trying to find a way to make think ok for me and everybody using linux
<cooljckd> in mauritius
<cooljckd> have a better experience
<cooljckd> using there fav os
<greyback> sure. But unfortunately there's no mirror on Mauritius right now :(
<cooljckd> was there any
<greyback> not that I know of
<cooljckd> i vpn and ssh to germany everyday
<cooljckd> and i dont have any problem
<cooljckd> working from out here
<greyback> cooljckd: maybe there'd be interest in establishing a mirror. Have you talked with these guys: http://lugm.org/
<cooljckd> well i guess i just keep looking for a distro that can suit my needs
<cooljckd> thanks for answering anyway
<greyback> good luck
<cooljckd> hehe
<cooljckd> luck has nothing to do with this
<cooljckd> its a teritorial thing
<cooljckd> i mean you cant expect some windows lovers to let linux traffic out now can you
<greyback> Well I'd hope your ISPs are linux users
<cooljckd> well maybe someday maybe
<cooljckd> in 30 years
<cooljckd> perhaps
<cooljckd> when worlds ends and the zombies invades
<cooljckd> anyway i hope im still there then
<cooljckd> bye
<cooljckd> cheers
<greyback> bye! Hope you find a solution somehow :)
<nic-doffay> tsdgeos, can we land this today? https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
<tsdgeos> nic-doffay: the landers are dead
<nic-doffay> tsdgeos, ah still.
<tsdgeos> nic-doffay: any reason you need it today?
<tvoss> tsdgeos, the landers sounds a bit like the elders :)
<tsdgeos> :D
<nic-doffay> tsdgeos, not particularly.
<tsdgeos> oka
<tsdgeos> dandrader: i added you to https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1250412
<ubot5> Ubuntu bug 1250412 in Ubuntu UI Toolkit "InverseMouseArea does not work with TouchEvents" [Undecided,New]
<tsdgeos> if you can share some thoughts on it
<tsdgeos> it'd be cool
<tsdgeos> dednick: man, i can't repro the crash anymore :(
<dednick> tsdgeos: hm.
<dandrader> tsdgeos, well, it's an InverseMouseArea, not an InverseTouchArea. :P
<tsdgeos> dandrader: i know
<tsdgeos> dandrader: so i guess you're suggesting we strip the code that makes MouseArea work with TouchEvents?
<dandrader> tsdgeos, added a comment
<dandrader> tsdgeos, I don't think MouseArea has any code about touch events
<dandrader> tsdgeos, it's all in QQuickWindow
<tsdgeos> QQuickWindow has
<tsdgeos> let's kill it
<tsdgeos> by your suggestion
<tsdgeos> doesn't make any sense
<tsdgeos> ok, you were joking
<tsdgeos> i'll stop continuing your joke as it's obvious it's not working
<dandrader> tsdgeos, I wonder why they did it like that. If it's an optimization or something...
<dandrader> tsdgeos, I stumbled upon it while doing the "touch ownership" work. I had to use a Qt private API in order to dispatch a touch event to an item
<dandrader> there's a QQuickItemPrivate::dispatchTouchEvent() "public" method that QQuickWindow calls
<dandrader> intenally it just call QQuickItem::touchEvent()
<dednick> tsdgeos: mine isn't either
<dandrader> tsdgeos, It  might be worth proposing a Qt patch to make touch events go through the regular QObject::event
<tsdgeos> dednick: maybe something changed at the model level that sends stuff in a different order
<dandrader> tsdgeos, in the worst case, if they reject it, we will at least know why they did it like that
<tsdgeos> dandrader: good luck with that (yeah i've had a bad day with our Qt friends today)
<tsdgeos> dednick: hopefully i'll be able to fake the test with the info you got yesterday, let's cross fingers :D
<dandrader> tsdgeos,  well,  I will hunt down the author of that dispatch code and ask why it's like that...
<dandrader> (easier than proposing a patch)
<tsdgeos> good luck :-)
<tsdgeos> obviously they are ont sure it's right
<tsdgeos> since the code has stuff like
<tsdgeos>         // XXX todo - should sendEvent be doing this?  how does it relate to forwarded events?
<dandrader> tsdgeos, hmm, that's pretty old code, from the beginnings of QML. I bet it was just an overlooked...
<dandrader> s/an//
<tsdgeos> one can hope :-)
<dandrader> :)
<dandrader> ok, I'm motivated enough to come up with a patch now
<Cimi> where is Unity.Application?
<Cimi> in which package?
<greyback> Cimi: libunity-mir1
<Cimi> greyback, it's already the newest version
<Cimi> greyback, that means I have wrong includes maybe
<greyback> Cimi: probably yeah
<tsdgeos> unity-mir ?
<tsdgeos> Cimi: âââ
<greyback> Mirv: ping
<Saviq> om26er, re: https://code.launchpad.net/~om26er/unity8/helper_dont_try_unlock_if_already_unlocked/+merge/194839
<Saviq> om26er, IIUC the RuntimeWarning should be raised if it's already unlocked
<Saviq> om26er, does that not happen for you?
<Saviq> om26er, please make sure veebers has a look at that MP
<om26er> Saviq, it seems to be not working here. with the screen unlocked it tried the swipe() and failed
<om26er> Saviq, yes, I was going to email him that
<Cimi> I added http://paste.ubuntu.com/6404934/
<Cimi> but it still doesn't find unity.application
<Cimi> how do you do this in cake?
<Mirv> greyback: pong
<greyback> Mirv: heya, I think I know the answer to this before I ask, but worth a try: I'm working with Qt5.2 from the beta2 PPA. There wouldn't be debug symbols available for it, would there?
<Mirv> greyback: those are compiled with -debug & CONFIG+=debug, so qtbase5-dbg, qtdeclarative5-dbg etc should in theory be what the doctor ordered?
<greyback> Mirv: ah really?! Yay!
 * greyback was searching for *-dbgsym, duhh
<greyback> Mirv: magic, thank you
<Mirv> greyback: yeah, I kept those local changes from the trusty 5.1.1 builds. you're welcome.
<dandrader> tsdgeos, About Qt work: I should work on the "stable" branch, right?
<tsdgeos> dandrader: stable is for 5.2.1, release is for 5.2.0, devel is for 5.3.0
<tsdgeos> at this point i thikn stable == rlease
<dandrader> tsdgeos, so I suppose things on stable are fed to devel?
<tsdgeos> kind of
<tsdgeos> i think so yes
<Cimi> cmake ^^
<tsdgeos> dednick: meh i can't find a way to create a test that causes the crash
<tsdgeos> mhr3: there was any release to any scope package yesterday?
<tsdgeos> doesnt' seem like there was
<dandrader> tsdgeos, found a bug about the qquickitem::event issue https://bugreports.qt-project.org/browse/QTBUG-32004
<tsdgeos> :D
<tsdgeos> now we just need them to fix it ;-)
<dandrader> tsdgeos, will try to get that bug from Frederik
<tsdgeos> oka
<mzanetti> mhr3: everything should be fixed now: https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803
<greyback> Wellark: ping
<mzanetti> Saviq: o/
<Saviq> mzanetti, welcome back
<mzanetti> Saviq: thanks. from what I see jenkins is currently off
<Saviq> mzanetti, yeah, in transit
<mzanetti> Saviq: should I re-top-approve approved branches?
<Saviq> mzanetti, if there are some that should be re-top-approved, sure
<mzanetti> Saviq: e.g.: https://code.launchpad.net/~mzanetti/unity8/launcher-small-tweaks/+merge/191380
<Saviq> mzanetti, we're in auto mode now (well, when jenkins is back, that is)
<mzanetti> Saviq: ah ok... yeah. wasn't sure if you still want to trigger one by one
<Saviq> mzanetti, that one was never top-approved was it :)
<mzanetti> Saviq: I think it was
<Saviq> mzanetti, why would it be un-top-approved then?
<Saviq> mzanetti, jenkins didn't report anything on it
<Saviq> re: autolanding at least
<mzanetti> Saviq: I assumed you un-approved them in order not to flood jenkins when it starts picking up stuff again
<Saviq> mzanetti, ass-you-me
<Saviq> mzanetti, I didn't un-approve anything, let me see my mail history
<mzanetti> not sure I follow the whole pun
<Saviq> mzanetti, "when you assume, you make an ass of u and me"
<mzanetti> ah
<greyback> sounded like an invitation to me ;)
<Saviq> greyback, not for you
<Saviq> mzanetti, on that note, I'm still able to break the view behind switching previews quite easily
 * mzanetti checks
<greyback> Saviq: I can live with that
<Saviq> mzanetti, just swipe between two previews at row boundary, or at category end
<Saviq> mzanetti, seems to be easiest to reproduce with the last results in a scope
<mzanetti> Saviq: ok. but this was working.
<Saviq> mzanetti, it is working, but sometimes it isn't ;D
<mzanetti> Saviq: with latest trunk it's 100% broken here
<Saviq> mzanetti, maybe something else affected it
<mhr3> tsdgeosnot really, why?
<mzanetti> I'll try to fix
<mhr3> tsdgeos, not really, why?
<Saviq> tsdgeosnot
<mzanetti> Saviq: shouldn't the Audio element use the media player service implicitly?
<Saviq> mzanetti, that's a good question
<Saviq> mzanetti, it could indeed
<mzanetti> Saviq: I'd say yes. on meego it does for example
<mzanetti> because we want *all* Audio {} elements to shut up when there is a phone call incoming for example
<Saviq> mzanetti, yeah
<Saviq> mzanetti, right, so once we provide a QtMultimedia backend for our media service, that would still work fine
<Saviq> mzanetti, ok then, +1
<mzanetti> I'd say so
<mhr3> mzanetti, wrt the music preview, could you make the whole track row clickable?
<mzanetti> mhr3: technically sure. design-wise I personally wouldn't like that. let me ask rosie
<dandrader> tsdgeos, have you compiled qtdeclarative recently?
<Saviq> dednick, "[nick-dedekind] Search label should hide when dash isn't focused: INPROGRESS" I think that was fixed
<Saviq> dednick, and re: "[nick-dedekind] Replace the SEARCH label with current lens name or the search query (in double quotes) when page header goes out of view - proportionally to header's visible portion: INPROGRESS" please ask design folk that's still the desired solution
<dednick> Saviq: partially. still available when previewing which screws it up becuse it tries to show keyboard.
<Saviq> dednick, ok
<dednick> ok, will ask about other one
<Saviq> dednick, [...] as they've been iterating the search behaviour recently
<dandrader> tsdgeos, nevermind. I had an outdated qtbase
<hashken> I was trying out the GMail Unity Webapp
<hashken> Whenever I open the GMail webapp from dash, GMail is just opened as a tab in the current Firefox Window and also there is no GMail icon in the launcher.
<hashken> Searching online shows a lot of people facing such problems.
<hashken> My impression was that when an webapp is opened it will open in it's own window with it's own icon and behave separately from firefox
<hashken> What is the actual behavior that is to be expected?
<mhr3> Saviq, is there a way to take screenshots with mir now?
<mhr3> Saviq, designers miss that a lot :)
<Saviq> mhr3, there's a script
<mhr3> Saviq, oh?
<Saviq> mhr3, http://lmgtfy.com/?q=ubuntu+phone+mir+screenshot ;)
<mhr3> lmgtfy... :P
<dednick> Saviq: so apparently the whole dash is being redesigned. so...
<kgunn> dednick: !?
<dednick> kgunn: well, i don't really know the extent of redesign, but the doc "Dash Visual Design 14.04" is no longer "entirely" valid. Some new dash toolkit coming in.
<kgunn> dednick: ah..yeah
<kgunn> dednick: less freaked out...that's the template stuff
<dednick> kgunn: ok, just saw the doc. was just a bit of sensationalisation.
<kgunn> dednick: well...where designers are involved...that's totally possible "let's start over!" :)
<nic-doffay> Cimi, are you busy with this? https://bugs.launchpad.net/unity8/+bug/1152150
<ubot5> Ubuntu bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,Confirmed]
<Cimi> nic-doffay, we have to dig this probably outside shell
<Saviq> nic-doffay, Cimi, yeah, it's a lower-level (Qt-level) thing
<nic-doffay> Saviq, does your comment on this still stand currently? https://bugs.launchpad.net/unity8/+bug/1224552
<ubot5> Ubuntu bug 1224552 in Unity 8 "[Dash] Category expansion transition has varaible speeds" [High,Triaged]
<nic-doffay> About measuring by the category height.
<Saviq> nic-doffay, yes
<nic-doffay> Saviq, what do you mean by a two-step animation?
<Saviq> nic-doffay, only the visible part of the category should be resized / animated - the rest should be expanded / collapsed in one frame
<Saviq> nic-doffay, so, when expanding â animate to shell height within a duration, then just change the height to the target value
<Saviq> nic-doffay, when collapsing â change the height to shell height, then animate to target value
<Saviq> nic-doffay, makes sense?
<nic-doffay> Saviq,  yep gotcha.
<mhr3> Saviq, need to pick your brainz - re the scopes plugin, your idea was to keep providing the current functionality and register new types different higher version, so we'd have qmlRegisterType<Scope>("Scope", 0, 1, ...) and qmlRegisterType<NewScope>("Scope", 0, 2, ...), is that right?
<mhr3> Saviq, and then when everything is "ready" we'd remove the 0.1 stuff?
<Saviq> mhr3, yeah, sounds about right
<Saviq> mhr3, and then the dash app would import 0.2 already
<Saviq> mhr3, you could also have a completely separate plugin
<Saviq> mhr3, if you went for a major version bump
<Saviq> mhr3, then you'd install it in Unity.1, for example
<mhr3> Saviq, yea, i was just thinking which one makes more sense
<Saviq> mhr3, depends on how similar the APIs will be
<mhr3> it's unlikely you'd use both at the same time...
<mhr3> well... ultimately the api is just exposing a bunch of models
<Saviq> mhr3, also, for minor versions
<mhr3> so it could be kept fairly consistent
<Saviq> mhr3, you can in theory use the same object, but mark certain methods as per-revision
<mhr3> don't think we'd need that atm
<Saviq> yeah I know
<Saviq> mhr3, I think it's fine to keep in a single plugin - this way you won't need to copy stuff around
<mhr3> Saviq, my current dilemma is whether to branch the repo and start removing stuff, or branch the repo and just start adding stuff :)
<Saviq> mhr3, the versioning system is more about backwards compatibility, which we don't care about for the moment
<Saviq> mhr3, the unity8 repo?
<mhr3> Saviq, no, the scopes plugin repo
<Saviq> mhr3, for the new version, you mean?
<Saviq> mhr3, what would you remove?
<mhr3> Saviq, yes, i'd basically remove everything old api related
<mhr3> so really just the headers would stay
<mhr3> not even all of them :)
<Saviq> mhr3, well, we want both version to work for the time being, no?
<Saviq> mhr3, from the same source?
<mhr3> do we? :)
<mhr3> that's my ultimate question i guess
<Saviq> mhr3, I think so, yes, to support the current unity dash and the new dash app
<Saviq> mhr3, well, plan is to transition to new scopes by 14.04 anyway, isn't it
<mhr3> in that case it's clear what needs to be done
<Saviq> mhr3, so we'd remove the old plugin before then anyway
<mhr3> sil2100, that reminds me, zmqpp in universe yet? :)
<vesar> Saviq, hi dude. Would you have any quick solution to my problem? I'm trying to run mzanetti's branch on device and when ./run_on_device -s it gives me following: http://paste.ubuntu.com/6405829/
<vesar> Saviq, I did also touch /userdata/.writable_image && reboot before that already
<Cimi> mterry, hey
<mterry> Cimi, hello!
<Cimi> mterry, I tried running your latest revision on the desktop, it fails with unity.applciation
<mhall119> seb128: thostr_ is gone, but https://blueprints.launchpad.net/ubuntu/+spec/client-1311-mediascanner-roadmap still need to be accepted for the uds-1311 sprint
<mterry> Cimi, yeah, because we use OSKController or some such
<Cimi> mterry, yes, but why doesn't work on the desktop?
<Cimi> mterry, missing include?
<seb128> mhall119, can you do that? I've some launchpad issues from that box (need to remember it when I'm back to my desktop a bit later otherwise)
<mterry> Cimi, no.  Because the desktop doesn't provide a Unity.Application plugin, like Touch does.  It will work on Touch, or you can point it at a mock Unity.Application on your desktop.  unity8 builds a mock version for running on a desktop and I pointed the wizard at that when testing
<seb128> mhall119, or is there somebody else around who can accept it?
<mterry> Cimi, let me see if I can find my command line
<mterry> Cimi, nope, it's left my bash history.  But basically I'd build unity8 trunk, then set QML2_IMPORT_PATH to unity8's builddir/tests/mocks/ or some such
<mterry> Cimi, or just comment out the OSKController bit
<mterry> Cimi, and the Unity.Application import
<mhr3> vesar, was that about the music-preview branch?
<mhr3> vesar, if so i should have that on my device in a sec
<sil2100> mhr3: yes! Actually it's in universe - 3.2.4 is enough?
<mhr3> where sec == ~10minutes :)
<mhr3> sil2100, are you sure about that? aren't you talking about zmq itself? we need the c++ bindings for it -> zmqpp
<Cimi> mterry, ok
<Cimi> mterry, I cannot test the wifi page, I don't have wifi on my virtual machine
<mhall119> seb128: I can, I just don't want to accept BPs for tracks that aren't mine, unless the track lead asks me to of course :)
<Cimi> mterry, can you see what's working there until I get the phone working? (my ubuntu phone does not boot)
<mhall119> seb128: accepted, it'll be imported into summit in the next hour or so
<mterry> Cimi, you are running saucy still?  :)
<seb128> mhall119, thanks
<mhall119> np
<Cimi> mterry, trusty
<mterry> Cimi, OK, I can test
<mterry> Cimi, which branch?
<Cimi> mterry, yours
<mterry> Cimi, k
<tsdgeos> dednick: did my answer solve your concern about the test?
<dednick> tsdgeos: yep. thanks
<vesar> mhr3, no it's one launcher related branch
<vesar> mhr3, thanks anyway
<mhr3> vesar, yea, sorry, don't have that one
<mhall119> davidcalle: ping me when you're around
<davidcalle> mhall119, pong
<mhall119> davidcalle: hey, so I'm working on these scopes API docs
<mhall119> I started parting the python html docs, but then remembered that we should be promoting C, is that still correct?
<mterry> Cimi, I don't see anything on the WiFi page in my branch
<davidcalle> mhall119, it is, but server-side scopes can still be in Python
<mterry> Cimi, I see the page, just no content.  No stderr output either
<Cimi> mterry, does the wifi plugin on the system settings work at least?
<mterry> Cimi, fair question...
<mhall119> davidcalle: do you think we should make docs for both?
<mterry> Cimi, yeah
<Cimi> mterry, it's a good start
<Cimi> mterry, I just need to get this bloody thing working
<davidcalle> mhall119, I think so. Even if there is still no formal process to submit them for inclusion, the server is open to new scopes.
<Cimi> thing = phone
<mterry> Cimi, in case I didn't mention, I proposed the team branch for merging.  So don't commit back to that same one if you land a wifi fix.  I'd like to land the team branch and then propose further fixes directly to system-settings trunk
<mhall119> davidcalle: ok, one more thing, is there anything in the docs that indicates that a class is for a specific "section"?
<mhall119> like, there classes are for previews, these classes are for filtering, these classes are for the search scopes, etc
<Cimi> mterry, ok
<davidcalle> mhall119, I'm not sure about C scopes, but for Python ones, it's not that straightforward. Python scopes must have a set of methods with specific names which return specific objects. They are ran by the scope-runner app, which call these methods.
<Cimi> mterry, ok phone works, how do I test the app on the phone?
<mterry> Cimi, I haven't done it in a while....  if things still work the same, you should be able to actually install it
<mterry> like the .deb
<mterry> and reboot
<Cimi> ok
<Cimi> mterry, but the wizard?
<davidcalle> mhall119, so, I can help you finding what is what in the doc, but I don't think it will be useful (for Python) if these "specific methods" are not documented as well.
<mhall119> davidcalle: are the docs at http://developer.ubuntu.com/api/devel/ubuntu-13.10/python/Unity-7.0.html sufficient for writing a python scope?
<mhall119> that's what I'm using
<davidcalle> mhall119, not without a tuto.
<mhall119> ok, well we have a tutorial for C, so I'll concentrate on those docs first
<mhall119> davidcalle: these giraffe docs are pretty sparse though, is there anywhere I can get a short description of what each class is used for, and perhaps what each method does?
<davidcalle> mhall119, not that I know of. A lot of them are used by the scope-runner, not by scopes themselves, that's probably why they are not very explicit.
<davidcalle> mhall119, I could get you some info about those that are actually used in scopes
<tsdgeos> Saviq: http://pastebin.kde.org/pcfzadvzl :-)
<tsdgeos> Saviq: looks "good enough" to me
<tsdgeos> gonna run the tests now to see if it regresses something and will add my test too
<tsdgeos> and submit
<Saviq> tsdgeos, "QV8Engine" :?
<tsdgeos> Saviq: yeah the naming is amazing :D
<Saviq> too many Vs
<tsdgeos> their "semi-public" class is still called QV8Engine
<tsdgeos> so they now have a QV8Engine::getV4()
<tsdgeos> :D
<tsdgeos> wonder why
<Saviq> tsdgeos, cool, thanks for pushing
<Saviq> tsdgeos, it did feel it's an omission as opposed to a conscious decision...
<tsdgeos> it does
<Saviq> tsdgeos, so that fixes the original 5.0 bug, too, I expect?
<tsdgeos> Saviq: sure
<tsdgeos> you you don't need the "variable" anymore
<Saviq> cool beanz
<tsdgeos> just pass it around and that's it
<Saviq> tsdgeos, awesome
<nic-doffay> Saviq, are you aware of any property in FilterGrid which is bound to the shell height?
<Saviq> nic-doffay, there isn't one, but it shouldn't be there
<Saviq> nic-doffay, it's the LVWPH that should control that animation, so that it's consistent regardless of whether FilterGrid is used or anything else
<nic-doffay> Saviq, I'm not sure I follow. Must the FilterGrid animation be removed then?
<Saviq> nic-doffay, there's two separate animations there - we should think of fixing that
<Saviq> nic-doffay, tsdgeos will know more, please make sure to talk to him about this tomorrow
<tsdgeos> that's going to be a bit of a pain
<tsdgeos> but yeah let's talk tomorrow
 * tsdgeos eods
<Saviq> nic-doffay, but yeah, it feels like there should be no animation on height in FilterGrid itself, but there's probably a reason why it'st here
<Wellark> greyback: pong
<Wellark> greyback: sorry, didn't notice your ping on "this side" before
<greyback> Wellark: no problem, I found what I needed anyway.
<nic-doffay> Saviq, sure.
<didrocks> mhall119: the french loco would want to discuss about their DPI (Dash Privacy Interface) at vUDS. Do you have a slot for it? https://blueprints.launchpad.net/dash-privacy-interface/+spec/community-1311-loco-projects-introducing-dash-privacy-interface
<didrocks> mhall119: preferably in the last day slots
#ubuntu-unity 2013-11-13
<tvoss> mzanetti, you fine if I answer to your latest reply publicly. Seems like you only sent it to me instead of the list
<tsdgeos> Saviq: damn, my 5 lines patch fixes https://bugreports.qt-project.org/browse/QTBUG-30730 and https://bugreports.qt-project.org/browse/QTBUG-34617 but not https://bugreports.qt-project.org/browse/QTBUG-34651
<tsdgeos> i'll have a look at that one too
<mzanetti> tvoss: oh... yeah, that wasn't intentionally
<tvoss> mzanetti, ack, can you resend publicly, will answer then
<mzanetti> tvoss: done
<Saviq> tsdgeos, oh interesting...
<tsdgeos> yeah
<tsdgeos> similar but not same thing
<Saviq> tsdgeos, 1 != 1?...
<tsdgeos> yep
<tsdgeos> kind of
<Saviq> it probably tries to compare the wrapper against the object or something?
<tsdgeos> yeah
<tsdgeos> need to find out a comparison that works and then fix this one to go there too :D
<Saviq> ;)
<dednick> Cimi: ping
<tsdgeos> woa, adding a debug in qv4runtime_p.h wasn't a good idea :D its recompiling almost everything :S
<dednick> Cimi: https://bugs.launchpad.net/unity8/+bug/1250815
<ubot5> Ubuntu bug 1250815 in Unity 8 "Carousel click/pressAndHold not working" [Critical,New]
<Saviq> mhr3, any reason why lp:unity-scopes-shell source package is unity8-plugin-scopes? why can't it be the same name?
<Saviq> mhr3, also, qtdeclarative5-foo-plugin is the preferred name for QML plugins
<Saviq> mhr3, OTOH we might want a different naming, 'cause it's meant to be installed in a different import path...
<Saviq> didrocks, thoughts â? where should we install plugins directed at the shell?
<Saviq> and whether to change the package naming scheme?
<Saviq> Mirv, I'd like your opinion, too â
<didrocks> the source package needs to match the project name
<didrocks> for non confusing reason :)
<didrocks> are those only unity8 plugins?
<didrocks> it's not in the standard QML import path?
<Mirv> Saviq: the preferred naming is actually qtdeclarative5-foo0.1, as decided by kenvandine & co, so that also the install path contains the API version specific path - see for example qtdeclarative5-friends0.2
<Mirv> Saviq: the idea is that one can co-install older API package as well, for example than that was released with 13.10
<didrocks> (I decided that one actually :p)
<Saviq> didrocks, yeah, we want to put them on a unity8- (well, shell-) specific path
<Saviq> didrocks, so that apps don't have access there
<didrocks> maybe it shouldn't follow that naming scheme then
<Mirv> didrocks: oh, I never figured out how the decision process went, I only heard the end result :)
<didrocks> Saviq: will it follow your virtual unity-apis versions?
<Saviq> didrocks, yes
<didrocks> so I would say unity8.<APIversion>-<plugin-name>-plugin
<didrocks> hoping that one day we can make 8 and API version matching :)
<Saviq> didrocks, there's no one global API version, though...
<Saviq> didrocks, or what is that APIversion meant to be?
<Saviq> didrocks, I mean scopes have different API version than notifications, for examlpe
<Saviq> as we didn't want people to have to bump if changes were unrelated
<didrocks> Saviq: well, as long as you are backward compatible
<didrocks> we should really use semantic versionning
<didrocks> and "integrating with the shell" is just one version
<didrocks> being scope or integration with the launcher or indicators
<Saviq> didrocks, yeah, we're not backwards compatible, remember? ;P
<didrocks> Saviq: I knowâ¦ ;)
<Saviq> didrocks, what would APIversion be, then? unity-api version number?
<didrocks> when do you think you will ensure backward compatibility?
<didrocks> that can maybe help shaping the versioning
<Saviq> didrocks, backwards compatibility of Unity8 with older API versions?
<Saviq> didrocks, not until 16.04 :P
<Saviq> didrocks, those are not APIs public enough that it warrants backwards compat for quite some time
<mhr3> Saviq, i knew the naming will be the primary thing of discussions :)
<mhr3> anyway, i don't care, just tell me what to change it to
<mhr3> didrocks, but we'll need to push the scopes plugin as a separate pkg to the distro
<mhr3> ideally asap :)
<mhr3> Saviq, though i guess we should bump unity8 minor/micro version
<mhr3> and then make the scopes plugin break unity8 << that_version
<Saviq> mhr3, yeah probably
<didrocks> Saviq: so I would say, let's version it to 0 and handle the breakage manually
<didrocks> everytime you break the API, you Breaks: all components << version
<Saviq> didrocks, so, unity.0-scopes-plugin in that instance?
<Saviq> (I wouldn't want to put the 8 in there)
<didrocks> Saviq: unity0 then
<didrocks> no .
<Saviq> didrocks, Mirv how about the path where we install shell-facing plugins?
<didrocks> Saviq: same concept to me?
<didrocks> all unity0- something
<didrocks> then, the patch itself
<didrocks> path*
<mhr3> "unity0-scopes-plugin"
<didrocks> should be libexec I guess
<mhr3> looks wrong :P
<Saviq> yeah, /me no likes either :/
<didrocks> mhr3: yeah, we need to prepend
<didrocks> something
<didrocks> -scopes- is the name of the extension, right?
<mhr3> also the plugin seems pretty redundant
<mhr3> qtdeclarative-unity0-scopes
<didrocks> mhr3: no
<Saviq> didrocks, we need a common /usr/lib/*/unity/qml, or similar, path where those will get installed
<didrocks> mhr3: that sounds like it's an official qt things
<mhr3> didrocks, we already have dozens of qml plugins like that that aren't official
<didrocks> Saviq: yeah, sounds good to me (unversionned or unity0 until we have something)
<didrocks> mhr3: yeah, but it's a plugin of a shell
<didrocks> not a qt plugin for using without the shell
<mhr3> well you wanted a prefix :)
<didrocks> not that one :p
<didrocks> or unityplugin0-scope ?
<mhr3> fine with me
<didrocks> unity-plugin0-scope? (putting the API version next to plugin)
<Saviq> +1
<mhr3> what if the plugin supports multiple versions of the api?
<didrocks> mhr3: it's unrelated from a packaging perspective
<mhr3> ok
<didrocks> unity-plugin21-scope can provides unity-plugin20-scope
<didrocks> mhr3: ^
<mhr3> ok, renaming to unity-plugin0-scopes
<didrocks> hum, in fact, we're wrong
<didrocks> mhr3: you are not providing the plugin
<didrocks> unity8 is
<didrocks> so unity8 needs to provides unity-plugin0
<didrocks> and you plugin is just unity-plugin-scopes
<didrocks> your*
<didrocks> you won't have plugin of your plugin, right? :)
<mhr3> hm?
<mhr3> ah, i see what you mean
<didrocks> will the scopes plugin won't have backward compatibility for the scopes?
<didrocks> so, basically, do you provide an API in it?
<mhr3> no
<didrocks> or is it just an extension like "show battery level"
<didrocks> ok, so you don't need to version in
<didrocks> you just need to dep on unity-plugin0
<didrocks> which will be provided by unity8
<Saviq> huhuh?
<mhr3> this last part is huh indeed
<Saviq> didrocks, that package will provide the binary plugin
<didrocks> ok, I think there is an inception effect :)
<didrocks> ah ok
<didrocks> so yeah, versioning is needed
<didrocks> it will provide an API to scopes?
<Saviq> didrocks, no
<Saviq> didrocks, it's the shell side of it
<mhr3> it will implement interface defined in lp:unity-api, used by unity8
 * didrocks is lost by what you with "will provide the binary plugin"
<Saviq> didrocks, will provide the plugin unity8 will use to talk to scopes
<Saviq> didrocks, not the APIs scopes will use
 * didrocks is probably dumb, but not seeing the difference in those 2 statements
<didrocks> if the plugin implements the code for unity8 to talke to scopes
<didrocks> it's exposing/creating the API for scopes, right?
<Saviq> no
<Saviq> it's the shell side of that transaction
<Saviq> the scope side of that transaction will come from lp:unity-scopes-api
<mhr3> and it will actually dep on libunity-scopes-api... soon
<didrocks> ah, so basically, this plugin will only decide "this is how I render/handle the signals I'm getting through unity-scopes-api"
<Saviq> didrocks, scope â unity-scopes-api â unity-scopes-shell â unity8
<didrocks> yeah, so that's what I told
<Saviq> didrocks, yeah, you can think of this as a shell-facing QML wrapper of unity-scopes-api
<didrocks> unity8 as a private API for its plugins
<didrocks> which isn't unity-scopes-api
<didrocks> has*
<didrocks> so unity8 should provides a unity-plugins0 package
<didrocks> that the unity-scopes-shell will depend on
<Saviq> didrocks, there is nothing like that ;(
<mhr3> not really private, it's defined in unity-api
<Saviq> or well, in that sense
<mhr3> or... will be :)
<Saviq> unity-api defines the APIs unity8 consumes
<didrocks> ok, so all will be exposed in unity-api?
<mhr3> the problem is that there's no compile/link dependency there
<Saviq> didrocks, unity-api just provides headers
<Saviq> didrocks, interfaces
<Saviq> we will probably make a .so of them soon-ish
<didrocks> right, and that's the interface that the unity-scopes-shell will use?
<Saviq> didrocks, will expose
<Saviq> didrocks, unity8 will use
<didrocks> so there is no need for yet-another-versioning? We have through unity-api what unity8 version the unity-scopes will be compatible with
<Saviq> didrocks, yes
<didrocks> and so unity-plugin-scopes is enough
<Saviq> yay
<didrocks> (and we can name all those plugins unity-plugin-*)
<Saviq> didrocks, +1
<mhr3> damn it, if i didn't put the 8 there i'd have it already right :P
<didrocks> ok, nice :)
<Saviq> lol
<didrocks> heh mhr3 :)
<Saviq> mhr3, rename the source, please, too
<mhr3> Saviq, pushed
<Saviq> mhr3, and make it Provides: unity-scopes-impl, unity-scopes-impl-0
<mhr3> k
<Saviq> mhr3, and then in the lp:unity8 part, Depends: unity-plugin-scopes | unity-scopes-impl, unity-scopes-impl-0
<Saviq> mhr3, and the version bump and Breaks: you mentioned
<mhr3> eh
<mhr3> dpkg-source: error: source package has two conflicting values - unity-scopes-shell and unity-plugin-scopes
<mhr3> are you sure src pkg can be different to the binary pkg name?
<didrocks> mhr3: it means you changed in either debian/control or debian/changelog but not in both place
<tsdgeos> Saviq: this one is a bit more complicated https://codereview.qt-project.org/#patch,all,71155,3 let's see how it goes
<mhr3> didrocks, i have to use the src pkg name in changelog?
<Saviq> tsdgeos, lol, so the original code was isEqual() { return false; }? :D
<mhr3> yea.. ok
<Saviq> mhr3, just the last entry
<mhr3> there's just one :)
<tsdgeos> Saviq: well, there's lots of classes that reimplement the isEqual
<tsdgeos> it just doesn't hit them if you're comparing singletons
<Saviq> tsdgeos, mhm
<tsdgeos> that's why i'm not sure it's the best place to do it
<tsdgeos> but here it works
<tsdgeos> let them comment :D
<didrocks> mhr3: in the top one, yeah
<mhr3> didrocks, since both unity-plugin-scopes and unity8-private provide the same file, do i add Breaks to unity-scopes-shell, or Conflicts/Replaces needed too?
<didrocks> mhr3: the files are getting removed from unity8-private, right?
<didrocks> so we need to uninstall it?
<mhr3> didrocks, yea, latest version of unity8-private won't have them
<didrocks> mhr3: Breaks/Replaces in that case
<didrocks> on the version << unity8-private without that file
<mhr3> thx
<didrocks> yw!
 * didrocks goes for a run
<Cimi> seb128, if I run system settings on the desktop, I don't have wifi... do you?
<mhr3> didrocks, if you could check once you're back http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/debian/control
<mhr3> Saviq, ^ you too
<Saviq> Cimi, network uses different indicator backends
<Saviq> Cimi, on desktop it's nm-applet, not indicator-network
<seb128> Cimi, I have it just fine
<seb128> Saviq, the package depends on indicator-network so it should be there
<Cimi> mmm
<Saviq> seb128, right, if you have two network indicators, yeah
<Cimi> no wifi here on system settings
<Cimi> trusty
<seb128> is indicator-network running?
<seb128> did you restart your session since you installed it?
<Saviq> mhr3, I don't think you need -dev-tools build-dep, though
<Cimi> no
<seb128> so restart the session
<Saviq> seb128, so 1980's solution! ;D
<Saviq> Cimi, seb128 restarting unity-panel-service should be enough, no?
<seb128> restart unity-panel-service
<seb128> Saviq, snap :p
<Saviq> :)
<mhr3> Saviq, qmlplugindump
<Saviq> mhr3, ah
<Cimi> seb128, ok works now, but I have two
<Saviq> Cimi, yes, expected
<Cimi> on unity
<Cimi> how can I remove one?
<Cimi> blacklist in unity?
<mhr3> Saviq, but i wouldn't be surprised if something was missing/extra, didn't try to build it on clean chroot
<Saviq> Cimi, you'll lose functionality
<seb128> can you stop complaining? :p
<Saviq> mhr3, let me
<mhr3> Saviq, thx
<Saviq> seb128, me? :D
<seb128> you can edit /usr/share/unity/indicators/com.canonical.indicator.network and delete the desktop profile
<seb128> Saviq, no, Cimi
<mhr3> Saviq, as there's no ci for it yet, you can push fixes directly to trunk ;)
<Saviq> seb128, ah yeah, no, he can't ;)
<seb128> Saviq, seems so ;-)
<Cimi> Saviq, I'm half polish :)
<Saviq> Cimi, indeed, that would explain things
<seb128> Cimi, btw can you spend some time to fix the GTK themes before the LTS? they have some issues/stuff not looking right on new widgets
<Cimi> seb128, saw that
<Cimi> seb128, was actually thinking of doing an ubuntu touch theme
<seb128> Cimi, LTS is not about doing new stuff, it's about polishing what we have and shipping a solid product...
<seb128> Cimi, thanks for looking at those bugs/fixing the issues
<Cimi> seb128, depends when polishing is more work
<seb128> I doubt fixing a few bugs is that much work
<mhr3> seb128, then you didn't do gtk theming :)
<seb128> mhr3, don't get me started ... can we have a working dash for the LTS? ;-)
<mhr3> seb128, we don't?
<seb128> mhr3, for some value of "working" I guess
<seb128> mhr3, I still get the "no result found" empty dash issue several time a week
<mhr3> hmm, i still don't know what's causing that
<seb128> still no idea of what info I could provide to help debugging it?
<mhr3> seb128, steps to reproduce
<seb128> "use the dash"
<mhr3> works fine... not a bug :P
<seb128> mhr3, http://ubuntuone.com/0RPwctnL0nRftR9hWFTMuS
<seb128> mhr3, I clear the text by pressing "esc"
<Saviq> dednick, any steps to repro bug #1243146 ?
<ubot5> bug 1243146 in Unity 8 "SIGSEGV when clearing message indicators" [Medium,In progress] https://launchpad.net/bugs/1243146
<Saviq> mhr3, you need qt5-default
<seb128> mhr3, also my homescreen only lists apps, not files atm ... is that normal?
<Saviq> mhr3, let me add
<mhr3> seb128, do you have online sources on?
<seb128> mhr3, yes
<mhr3> wonder if that would make difference
<mhr3> hm, so do i
<dednick> Saviq: it's pretty random
<mhr3> seb128, as for files, check if the category is enabled
<seb128> mhr3, oh, fun
<seb128> mhr3, only "help" is enabled in the filters, that's why my dash is empty
<dednick> Saviq: have a message in the indicator expanded and clear them all.
<seb128> mhr3, if I enable applications it works
<mhr3> solved, yey! :)
<seb128> mhr3, is the smart server trying to be too smart and telling my dash to disable apps?
<seb128> mhr3, well, it's not happening on session start/by my doing, I didn't even know we had filter in the homescreen
<mhr3> no, empty search filters are remembered
<mhr3> and i think there's a bug somewhere where it saves incorrect state of those
<mhr3> pstolowski, ^
<Saviq> dednick, thanks
<mhr3> pstolowski, maybe, search for "foo" (which takes a while), change filters while it's in progress and quickly press esc can make it confused?
<pstolowski> seb128, as mhr3 said, the only way it can disable apps is when user manually de-selects apps in the filter while the search string is empty. if it happens on any other interactions, then this is a bug
<pstolowski> seb128, if you find any way to reproduce it, then please include the output of 'gsettings get com.canonical.Unity.Lenses home-lens-default-view' in the bug report
<seb128> pstolowski, hey, there is a bug then...
<seb128> pstolowski, ok, the issue is that I've not been able to find obvious steps to reproduce, but I run into that several time a week
<seb128> the dash is not empty all the time, and not on session start, so I doubt it's a buggy config
<seb128> it happens a some point during the day
<seb128> pstolowski, in that case the filter had "help" only selected
<pstolowski> seb128, but when it's gone, it's gone for good, until you enable it back via filters?
<seb128> pstolowski,  http://ubuntuone.com/0RPwctnL0nRftR9hWFTMuS is what happens from an user view
<seb128> pstolowski, I just noticed, thanks to mhr3, that the homescreen has filters and that only "help" was selected
<pstolowski> seb128, and you're hitting esc on that screencast?
<seb128> pstolowski, yes
<seb128> easiest way to clean the text entry
<pstolowski> seb128, can you report it?
<seb128> pstolowski, sure, is there enough info in that description to make an useful bug?
<seb128> pstolowski, I never reported it because I don't know how I land in the buggy state and mhr3 always said he didn't have enough info/a clue how to debug
<mhr3> i think there are two bugs actually
<mhr3> one that makes the home scope save an odd state of the filters for empty searches (not requested by the user)
<mhr3> and another where you're getting results you shouldn't be
<mhr3> so for example you should have never seen app results if they're disabled
<mhr3> yet you somehow do from time to time
<mhr3> (with empty search string)
<seb128> right
<seb128> seems like doing "one" -> esc was giving me a view ignoring the filters
<mhr3> yet i can't reproduce that here
<Saviq> mzanetti, reject https://code.launchpad.net/~unity-team/unity8/fix-1238232/+merge/191424 ?
<mzanetti> Saviq: imo yes
<Saviq> mzanetti, please do
<mzanetti> ajmitch: done
<mzanetti> Saviq: ^
<mzanetti> sorry ajmitch
<Saviq> mhr3, pushed tweaks to debian/control - builds in chroot now
<mhr3> Saviq, great, thx a lot
<mhr3> didrocks, now we just need to push it in t :)
<mhr3> well... once the unity branch is merged
<Saviq> tsdgeos, yay, we got +1 on the bugs :D
<tsdgeos> yeah
<tsdgeos> i've been wondering were tronical was
<tsdgeos> been trying to reach him on irc to no avail
<tsdgeos> i randomly remember someone telling me he is/was on paternal leave
<tsdgeos> but may be a different guy it was about
<tsdgeos> mzanetti: what's the units.gu(5) in  lp:~mzanetti/unity8/fix-switching-previews-positioning  ?
<mzanetti> tsdgeos: yeah. that sucks. it's the height of the section header. Is there a way to get to it?
<tsdgeos> mzanetti: category header?
<tsdgeos> should be possible
<tsdgeos> let me see
<tsdgeos> mzanetti: can't you just use sectionDelegate.height?
<tsdgeos> ah no it's a qqmlcomonent
<tsdgeos> damnit
<Saviq> tsdgeos, yeah, you can't get to the delegate
<Saviq> tsdgeos, mzanetti, only thing I can think of: use a prop on the *view
<Saviq> dednick, we need https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 so that we support non-qt time format strings?
<tsdgeos> mzanetti: are you trying to do with that, is it something regarding the clipping of the top section header?
<pstolowski> seb128, sorry, I was itm. yes, I think whatever you described so far is enough for a bug report, it's important we don't forget about it and try to repro
<mzanetti> tsdgeos: with what exactly? the header height?
<seb128> pstolowski, ok, I'm going to file it in a bit
<tsdgeos> mzanetti: yep, i see you have that max in there
<mzanetti> tsdgeos: I make sure the split for the openEffect doesn't happen at the top where the content could be hidden by the header
<tsdgeos> right
<tsdgeos> ok
<mzanetti> tsdgeos: let me add a comment in all places where I use the 5 grid units
<tsdgeos> we either need a context property that chaneges all the time (to not actually change)
<tsdgeos> or introduce the idea of "i promise i'll be well behaved" and just have one value
<tsdgeos> or not sure :D
<tsdgeos> but that units.gu(5) looks to fragile tbh
<tsdgeos> too
<mzanetti> yes. I agree
<dednick> Saviq: yeah, i think it's the alarm indicator that gives time format in gdatetime (strftime)
<mzanetti> tsdgeos: such a context property would be per delegate, right?
<Saviq> dednick, any idea why it wouldn't give up a preformatted string?
<Saviq> dednick, same as we expect translated strings and such...
<tsdgeos> mzanetti: we can see how to expose it
<tsdgeos> one per delegate
<tsdgeos> or one just for the top section delegate
<tsdgeos> but yeah one per delegate makes sense
<dednick> Saviq: tz changes
<dednick> possibly
<mzanetti> tsdgeos: just like the other section.* properties probably
<mzanetti> section.headerHeight
<Saviq> dednick, well, wouldn't the indicator service know?
<tsdgeos> mzanetti: we don't really have secion. properties but yes
<tsdgeos> we have "section" and "delegateIndex"
<tsdgeos> mzanetti: do oyu want to have a look at it?
<mzanetti> tsdgeos: on it
<didrocks> mhr3: what's going to dep on unity-scopes-impl-0? (priority should be optional btw and I prefer libs just after just after priority)
<dednick> Saviq: it would then have to repoll all the calendar events from the source when a change occurs. Plus I think it's better that the view decides how to display the data. I don't even think the dackend supplying the format is right...
<Saviq> dednick, top-approve https://code.launchpad.net/~aacid/unity8/noModelInSignal/+merge/194672 ?
<Saviq> dednick, right, it feels weird to get the format string from the backend
<dednick> Saviq: yeah.. i know, we will probably override it anyway at some point.
<dednick> Saviq: Do you know when CI is going to be back?
<Saviq> dednick, like... last Tuesday...
<Saviq> dednick, there were issues, guys are working day/night to get everything back
<dednick> Saviq: but there's no jenkins approve right? because services are down...
<dednick> ?
<Saviq> dednick, yes
<dednick> So how does CI work with no jenkins?
<Saviq> dednick, does it?
<dednick> <dednick> Saviq: Do you know when CI is going to be back?
<Saviq> dednick, I meant it was supposed to be back Tuesday
<Saviq> dednick, but it's not :)
<dednick> oh.. right :)
<tsdgeos> guys i need someone to review/topApprove this too https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200
<tsdgeos> Saviq: standip?
<tsdgeos> kgunn: ââ
<Saviq> crap
<Saviq> greyback, got that cron script yet? ;P
<greyback> :)
<dednick> tsdgeos: Just testing your branch now
<greyback> mterry: how usable is nested mir right now? Can it be used inside xmir?
<mterry> greyback, yeah I think so.  There are some u-s-c branches that need to land for Touch, but I don't think they'd affect desktop+xmir
<mhr3> didrocks, unity8 deps on the impl-0
<didrocks> mhr3: but the scope plugin deps on unity-api-impl-0
<didrocks> which is implemented by unity8
<didrocks> seems like a circular dep to me
<greyback> mterry: hmm, there instructions anywhere on how to do it?
<mhr3> didrocks, no it doesn't, it provides it
<mterry> greyback, with xmir, I don't know.  I believe in current trusty, it'd be as simple as installing unity-system-compositor?
<greyback> mterry: ok. Might play around with it this evening
<mhr3> didrocks, well, it provides unity-scopes-impl, it will build-dep on unity-api-dev at some point in the future
<didrocks> mhr3: and what will dep on the unity-scopes-impl?
<mhr3> didrocks, unity8 does :)
<mhr3> it's not the deps that are circular, this discussion is :P
<didrocks> mhr3: but both are going to depend on libunity-api0, right?
<mhr3> didrocks, probably, yes
<mhr3> if we find some actual code to put in there
<didrocks> I think there is something fuzzy in the way you handle the deps TBH
<mhr3> it might end up header-only pkg
<mhr3> didrocks, fuzzy in what way?
<mhr3> didrocks, it's simple, unity8 deps on scopes-impl, scopes-plugin provides it
<mhr3> that's all that matters right now
<didrocks> mhr3: you expect to have other packages providing scopes-impl?
<mhr3> hm
<mhr3> i don't think so, but one binary pkg could provide different versions
<mhr3> s/different/multiple/
<didrocks> and you expect different unity8 which can be installed in parallel?
<didrocks> and supporting different versions?
<Saviq> didrocks, no
<didrocks> so I don't think this -impl is needed
<mhr3> well ultimately Saviq wanted it this way, he'll know why :)
<Saviq> didrocks, if you applied that logic we wouldn't need it anywhere
<Saviq> didrocks, until someone else did another implementation
<didrocks> Saviq: well, maybe that was a mistake, but on the other pieces, you told me that you would see other implementations
<didrocks> being compatible with unity8
<didrocks> here, it doesn't seem to be the case from my question ^
<Saviq> didrocks, sure, that's the idea - doesn't mean *we* would provide them
<Saviq> didrocks, there could be a mock -impl
<Saviq> didrocks, used for ap tests
<dednick> tsdgeos: you getting that crash in test?
<tsdgeos> yep
<didrocks> ok, so we will have multiple implementations
<didrocks> and so, it makes sense in that way :)
<dednick> tsdgeos: ok. cool. thought i might be going crazy
<didrocks> (even a mock is just an implementation)
<Saviq> didrocks, good :)
<tsdgeos> dednick: i'm pretty sure i wasn't
<tsdgeos> but now i am
<tsdgeos> so that's eough :D
<dednick> hehe
<dednick> Cimi:
<dednick> Cimi: ping
<Cimi> dednick, pong
<dednick> Cimi: you got my bug I see. have you checked it out?
<didrocks> mhr3: did you change on my other (small) requests?
<Cimi> not yet back
<dednick> back wherE?
<dandrader> tsdgeos, wjat
<dandrader> tsdgeos, in qt, what's dev branch as opposed to stable branch?
<tsdgeos> 5.3
<dandrader> hmm
<mhr3> didrocks, oh the priority? fixing
<mhr3> didrocks, not sure what you meant with the other thing... Build-Deps should be directly after Prio?
<didrocks> mhr3: Prio, Section, Build-Deps
<mhr3> didrocks, pushed
<didrocks> mhr3: <3 thanks!
<mhr3> sil2100, how are looking on the capnp and zmqpp front?
<dednick> yikes. app scope is scary
<dednick> the view i mean
<sil2100> mhr3: capnp is in universe already, zmqpp is ready in my PPA - Ken was to make a review of it and *maybe* sponsor ;)
<sil2100> mhr3: while zmq3 is in the archive already
<mhr3> sil2100, awesome, do we bother you to setup ci and autolanding and stuff for the new scopes lib then?
<sil2100> mhr3: which one it will be?
<mhr3> sil2100, lp:unity-scopes-api
<sil2100> mhr3: once all the infra is back, I'll take care of doing that stuff ;)
<mhr3> sil2100, great
<mhr3> so now i'll just bother kenvandine to sponsor zmqpp :)
<kenvandine> hey mhr3
<kenvandine> sil2100, oh... sorry forgot to sponsor that :)
<mhr3> that was quick :)
<mhr3> thx kenvandine :)
<sil2100> kenvandine: I updated it a bit, fixing some stuff :)
<sil2100> kenvandine: now the debian/watch file is more correct and the build-deps are better
<sil2100> kenvandine: there is a package built out of it in ppa:sil2100/ppa if you want to check
<sil2100> kenvandine: thanks! :)
<sil2100> kenvandine: (I'll create lp:zmqpp/ubuntu once you give a green light)
<mhr3> didrocks, unity8 is now seeded in default trusty images? it seems to bring lots of the phone-only stuff
<mhr3> or well.. stuff that was meant phone-only
<didrocks> mhr3: hum, it shouldn't, where do you see it seeded?
<mhr3> didrocks, i'm assuming cause thomas mentioned that there's mediascanner and related stuff in T
<didrocks> mhr3: they are in T, but universe, I think they are not seeded
<didrocks> unity8 as well is in universe
<didrocks> so very very very veryâ¦ (very?) few chance it's in the iso
<didrocks> or there is a big bug
<mhr3> didrocks, hmm, i'll follow up with thomas then
<dednick> graaa. my phone wont start after a flash :(
<kenvandine> sil2100, mhr3: sponsored, it's in NEW now
<sil2100> kenvandine: waaaa!
<sil2100> kenvandine: thank you!
<kenvandine> n[
<kenvandine> np
<mhr3> yey, thx kenvandine
<mhr3> Saviq, didrocks, could we do the transition to the separate scopes plugin tomorrow or... since it won't be possible to do that automatically?
<didrocks> mhr3: better to transition once CI is back
<didrocks> mhr3: can you file that in the landing ask? so that we don't loose it from sight
<mhr3> didrocks, but CI won't be able to test nor merge that
<didrocks> why?
<didrocks> we'll need to land your packages
<didrocks> which is cu2d/daily release
<mhr3> didrocks, cause it's a new pkg that replaces part of old pkg?
<didrocks> which is down as well due to ci
<didrocks> yeah, we need to land unity8 + scope
<mhr3> exactly
<mhr3> so it needs to be done manually, no?
<didrocks> well, it will be done with cu2d
<Cimi> dednick, what shall it do?
<Cimi> dednick, the carousel?
<mhr3> didrocks, hm, ok, i guess i underestimated it :)
<didrocks> :)
<Cimi> on click and hold
<didrocks> mhr3: just write in the landing ask please ;)
<didrocks> otherwise, I'll forget for sure
<mhr3> didrocks, i don't think i have perms for that
<didrocks> mhr3: ask thostr_ then, he's a specialist
<mhr3> heh, k
<mhr3> thostr_, could you? landing ask to land updated unity8 + unity-scopes-shell
<mhr3> needs to be done in sync, cause the latter replaces part of the former
<didrocks> unity-scopes-hell :)
<mhr3> didrocks, you should be glad we still manage to provide you with some challenges! :)
<didrocks> hehe!
<Saviq> mzanetti, for you https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803/comments/450347
<Saviq> mhr3, so it doesn't have to be done in sync
<Saviq> mhr3, because until you upgrade unity8, nothing will pull the new package in
<mzanetti> Saviq: thanks
<mhr3> Saviq, right, that actually makes sense :)
<dednick> Cimi: when i click on a result on the carousel, nothing happens....
<dednick> so should probably either open a preview, or activate the result presumably
<tsdgeos> dednick: that crash is nasty :-S
<tsdgeos> dednick: the listview seems it's not getting deleted  when the parent goes away
<tsdgeos> and then all kind of funky stuff happens
<dednick_> tsdgeos: did you get the reply?
<mhr3> according to my irc he didn't :)
<dednick> tsdgeos: hm. sounds like  problem i've seen before. Is the listview deleted during a glib callback? eg. dee ?
<tsdgeos> dednick: hmm
<tsdgeos> does look like
<tsdgeos> why?
<dednick> anything that is deleted by calling deleteLater from an interal glib callback will not be deleted.
<tsdgeos> hmmmm
<tsdgeos> lil check
<mhr3> ehm, that sound like it would introduce lots of problems
<dednick> tsdgeos: i found it with delegates being deleted from a listview
<dednick> mhr3: yeah...
<mhr3> dednick, but i mean random crashing all the time, and we do not see that... fortunately
<mhr3> cause afterall any external event is reported via a glib callback
<mhr3> well... lots of them anyway
<dednick> well it was in the indicators, but i fixed it. Dont know how dee-qt works
<mhr3> dee-qt will emit q-signals from within callbacks
<dednick> mhr3: not problem with external events. It's only if we pick up through a callback directly
<mhr3> dednick, so how does the call stack have to look like for it to be an issue?
<dednick> mhr3: https://bugreports.qt-project.org/browse/QTBUG-32859
<dednick> mhr3: tbh, i'm supprised we don't see problems with dee
<mhr3> well, dee is not using timeout nor idle sources
<mhr3> but i still don't fully get why that is a problem
<dednick> mhr3: using g_signal
<dednick> mhr3: it's to do with the qt event loop
<mhr3> yea, but i don't understand the interaction that causes the issue
<mhr3> dednick, hm, so if glib dispatches a source directly without qt knowing about it, deleteLater() doesn't work?
<mhr3> ...if you call it from inside that dispatch
<mhr3> is that right?
<seb128> mhr3, pstolowski: oh, I had open a bug about that back then: https://bugs.launchpad.net/ubuntu/+source/unity-scope-home/+bug/1223933
<ubot5> Ubuntu bug 1223933 in libunity "sometimes the dash home list "no result matching your query" string" [Undecided,Triaged]
<dednick> mhr3: not only a source. any async callback that goes through the gmainloop.
<mhr3> async callback is an idle source ;)
<mhr3> but that is... really bad
<dednick> mhr3: a gaction callback is a idle source ?
<mhr3> i'm not into gactions really, but they sound like dbus signals and dbus signals are delivered via idle sources
<dednick> mhr3: ok. then yes :)
<dednick> mhr3: and yeah, it's bad. I've looked at the dee code, and it looks like it just goes directly from glib to qt.
<mhr3> indeed, it responds to dbus signals :)
<mhr3> so again idle sources
<dednick> yup
<mhr3> maybe someone who likes compiling qt should add some debug code in deleteLater and figure out how bad are we talking about
<mhr3> but tsdgeos ran off :P
<dednick> mhr3: what's really bad is when it happens during an infinite animation. It never ends. So cpu stays at 100%.
<dednick> which is what was happening in indicators
<pstolowski> seb128, ack, thanks, will try to repro
<mhr3> dednick, well sounds like we should come up with a real patch
<seb128> pstolowski, thanks, same here
<mhr3> dednick, not just workarounds like you did with indicators
<mhr3> and upstream qt apparently doesn't care
<dednick> mhr3: yeah, i was meaning to look into it, but never got there...
<dednick> then forgot...
<mhr3> dednick, wondering now what was it that you were complaining about yesterday :P
<dednick> heh
<mhr3> dednick, but yea, talk to tsdgeos about it tomorrow, he likes patching qt :)
<dednick> mhr3: aiight
<mhr3> seb128, thanks for updating it
<seb128> mhr3, yw ;-)
<mhr3> dednick, https://bugreports.qt-project.org/browse/QTBUG-18434?focusedCommentId=173857&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173857
<mhr3> scary
<dednick> mhr3: heh, nice find
<mhr3> dednick, it's actually linked from your bug :)
<dednick> dednick: i'm not even sure it's possible to patch. It's a pretty fundimental issue
<dednick> talking to myself again
<mhr3> well, their stance is - anything like this should be posted to qt event loop
<dednick> yeah
<mhr3> but that'd be massively expensive for things like dee
<mhr3> so i think we should just write a downstream patch
<dednick> which is probably their way of saying its really diffucult to fix...
<mhr3> while trying to not break too much stuff :)
<dednick> mhr3: no need to post, can just send.
<mhr3> dednick, is there a difference?
<dednick> post is async
<mhr3> ah
<mhr3> yea, send would work
<mhr3> still, quite a lot of patching though
<dednick> yeah.. it was a pain just for the unitymenumodel.
<mhr3> indeed, that's why i'd rather go the nasty downstream patch route
<mhr3> anyway.. eod, cyas
<dednick> i dont think it can be fixed. the only way i could think is pushing the g_main_loop and using another context, but it doesnt work for g_idle.
<dednick> mhr3: ^ thats for qt patch i mean
<dednick> mhr3: using pushing the g_main_context_push_thread_default i mean.
<mhr3> everything's hackable
<dednick> mhr3: heh.
<dednick> mhr3: ok, i'm off too
<dednick> mhr3: you in office tomorrow?
<mhr3> dednick, yea, for the afternoon ;)
<dednick> mhr3: :) ok
<mhr3> got meeting at 8, no way i'd get to the office so early :)
<veebers> robru: ping
<Saviq> veebers, hey, just a ping about https://code.launchpad.net/~veebers/unity8/ap_make_use_of_helpers_in_tests/+merge/191575 so you don't forget ;)
<veebers> Hi Saviq
 * veebers looks
<veebers> Saviq: ugh, that one slipped through my fingers somehow :-\ I'll get that updated and sorted today. Thanks for that
<Saviq> veebers, cheers
<veebers> Saviq: also fyi, it looks like I was too slow getting another of my MRs reviewed: https://code.launchpad.net/~veebers/unity8/update_ap_tests_ready_for_py3/+merge/194655 vs https://code.launchpad.net/~robru/unity8/autopilot-py3k/+merge/195128
<Saviq> veebers, yeah, just saw that
<Saviq> veebers, that's 'cause it's marked WiP ;)
<veebers> Saviq: ugh, d'oh. My bad again :-|
<Saviq> veebers, robru, lp:~veebers/unity8/update_ap_tests_ready_for_py3 seems to work fine, lp:~robru/unity8/autopilot-py3k complains:
<Saviq> Traceback (most recent call last):
<Saviq>   File "/home/michal/dev/canonical/unity8/repo/tests/autopilot/unity8/shell/tests/__init__.py", line 111, in setUpClass
<Saviq>     if "start/" in output:
<Saviq> TypeError: Type str doesn't support the buffer API
<Saviq> for each test
<Saviq> so please guys fight amongst each other which one should be merged ;)
<veebers> Saviq: :-)
<veebers> robru: that would be due to the subprocess call needing: universal_newlines=True
#ubuntu-unity 2013-11-14
<veebers> Saviq: if you're still around; I can't build unity8 package due to 2 failing tests. Are you seeing this too?
<robru> Saviq, oh, sorry, didn't notice that there was already a branch for that. feel free to disregard mine, it's incomplete anyway
<robru> veebers, ^^
<veebers> robru: cool, sounds good to me.
<veebers> robru: I was going to mention that my branch includes the tox stuff which eases running the tests with py27 and py3
<Mirv> copied some newer Qt 5.2 beta1 builds over to qt5-beta2 from my other PPA, should not affect anything but tell me if it does
<tsdgeos> Saviq: so the pass objects to c++ one has been merged \o/
<tsdgeos> haven't had any comment in the compare singletons against themselves one yet
<Saviq> tsdgeos, nice
<nic-doffay> Saviq, tsdgeos mind if we pick up about that FilterGrid animation?
<nic-doffay> From where we left off on Tuesday.
<Saviq> tsdgeos, can you have a look at the height animation in LVWPH with nic-doffay?
<tsdgeos> sure
<tsdgeos> nic-doffay: Saviq: what's the issue?
<Saviq> tsdgeos, bug #1224552
<ubot5> bug 1224552 in Unity 8 "[Dash] Category expansion transition has varaible speeds" [High,In progress] https://launchpad.net/bugs/1224552
<Saviq> tsdgeos, and comment #3 in particular https://bugs.launchpad.net/unity8/+bug/1224552/comments/3
<ubot5> Ubuntu bug 1224552 in Unity 8 "[Dash] Category expansion transition has varaible speeds" [High,In progress]
<nic-doffay> tsdgeos, the animation currently happens in FilterGrid.qml
<nic-doffay> I was planning to keep it there.
<Saviq> nic-doffay, not only there
<tsdgeos> so you want it to expand at a continuous speed?
<Saviq> nic-doffay, it's there in listviewwithpageheader, too
<Saviq> tsdgeos, no, we need to expand it to $visible_height in a duration, then to $target_height in one frame
<tsdgeos> Saviq: hmmm, yes and no, the only thing the LVWPH does is move the Y
<tsdgeos> nothing to do with the height
<Saviq> tsdgeos, and the opposite for collapsing - to $visible_height in one frame and then animate to $target_height
<Saviq> tsdgeos, yeah, but still you put the comment in that they need to happen in sync ;)
<Saviq> tsdgeos, would it be possible to apply a height behavior on LVWPH's delegates?
<Saviq> tsdgeos, from LVWPH, I mean?
<Saviq> tsdgeos, well, maybe I'm overcomplicating things... the only expandable thing we have is the grid...
<Saviq> so maybe it's fine if we just leave it there
<Saviq> tsdgeos, the height animation was never in sync with the y animation then anyway - only important thing is that y happens slower than height, doesn't it
<nic-doffay> Saviq, is there a variable in FilterGrid which holds the shell height already btw?
<Saviq> nic-doffay, dunno, doubt it
<tsdgeos> nic-doffay: knowing the height of the shell is not going to help you anyway, lots of stuff to substract in there
<nic-doffay> tsdgeos, what do you mean?
<tsdgeos> nic-doffay: i mean we have the panel and stuff
<tsdgeos> you don't want to know the shell height
<tsdgeos> you want to know the genericscopeheight
<nic-doffay> tsdgeos, is that just the height of the GenericScopeView
<tsdgeos> is that a question?
<tsdgeos> or?
<nic-doffay> tsdgeos, yeah it is.
<tsdgeos> then i don't understand the question :D
<nic-doffay> tsdgeos, how can I calculate the genericscopeheight, is it stored somewhere?
<tsdgeos> nic-doffay: well the genericscopeview knows about it
<tsdgeos> and it's what triggering the filtering
<tsdgeos> so passing it around should not be that hard
<nic-doffay> tsdgeos, is the genericscopeheight the genericscopeview height property?
<nic-doffay> That's the question basically.
<tsdgeos> ah no
<tsdgeos> that's just some crap i wrote
<tsdgeos> but it's an item
<tsdgeos> so it has a .height property
<nic-doffay> tsdgeos, you mean the GenericScopeView has a .height property, right? Just double checking because I intend to pass that through...
<nic-doffay> If I'm understanding you correctly? You mean it's best to use the GenericScopeView height to work out the animation?
<tsdgeos> nic-doffay: well it's what contains the filter grid
<tsdgeos> so yes
<nic-doffay> tsdgeos, cool
<tsdgeos> that is what i'm saying
<tsdgeos> btw my leg is paining me a bit, sorry if i'm slower or grumpier than usual today
<mzanetti> Saviq: about QtMultimedia in the test environment. Should I wait for jenkin's opinion or should I mock it straight away no prevent it from breaking at some point?
<mzanetti> s/no/to/
<Saviq> mzanetti, just mock it, shouldn't be too difficult - not sure we need the mp3s at all, either
<mzanetti> ack
<Saviq> mzanetti, if you can control the Audio component from the test, shouldn't be needed
<Saviq> or well, you need to be able to control it, and once you mock the component, you won't need the mp3 ;)
<mzanetti> yep
<Saviq> tsdgeos, so, rejecting the 5.2 regression workarounds?
<Saviq> i.e. https://code.launchpad.net/~aacid/unity8/singleton_52/+merge/194123
<Saviq> https://code.launchpad.net/~aacid/unity-api/52regressions/+merge/194303
<tsdgeos> Saviq: the unity-api needs the comparison one to land
<tsdgeos> ours is fine if we wait for the release
<Saviq> tsdgeos, yeah, I know, I'd rather distro-patch than to disable the tests, TBH
<Saviq> if we need it earlier
<tsdgeos> ok
<tsdgeos> i'm really confused about this
<tsdgeos> my GenericScopeView is getting the "onDestruction" call
<tsdgeos> but the ListViewWithPageHeader inside doesn't get the destructor called
<tsdgeos> any idea why that could happen?
<Saviq> tsdgeos, only reason I can think of... ownership somehow b0rked? and QML doesn't destroy the LVWPH?
<Saviq> tsdgeos, no idea why it would be b0rked, since it's a QML type like any other
<tsdgeos> right
<tsdgeos> thing is
<tsdgeos> kind of works sometimes
<tsdgeos> but if the test is adding removing them a lot
<tsdgeos> gets confused and breaks
<Cimi> dednick, ping
<dednick> Cimi: pong
<Cimi> dednick, hey mate
<Cimi> dednick, I was reading carousel code
<Cimi> dednick, and I see pressandhold signal
<Cimi> dednick, however it's triggered only if you stay within 1px
<Cimi> dednick, can you pls try to see if you can click and hold the selected element without moving?
<Cimi> dednick, we might just decide to enlarge the area
<tsdgeos> what do i do manually to test lp:~mzanetti/unity8/fix-switching-previews-positioning ?
<dednick> Cimi: is it working for you at all?
<Cimi> dednick, I'm compiling
<mzanetti> tsdgeos: go to a scope where contentHeight > height
<Cimi> dednick, but I see there's code
<mzanetti> tsdgeos: move it so that a row of items is mostly covered by the header
<Cimi> dednick, it's though only fwd when the click is steady in position
<mzanetti> tsdgeos: open the preview => the items at the bottom should *not* be covered any more
<Cimi> dednick, which might be logically wrong
<dednick> Cimi: i dont think you understand. It's not working for me at all, no matter pressAndHold/click. The click signal is not getting from the Carousel to GenericScopeView because we've put the GenericCaroselLoader in between, which is not forwarding the click.
<Cimi> dednick, AAAAAAAAHN
<Cimi> dednick, ok
<Cimi> dednick, will fix that
<dednick> there's also other parameters which are expected to be bound when we're using the grid view, like expanded/filter.
<dednick> Cimi: i think it's probably better not to use the CarouselLoader at all and just decide when to display either carousel / grid in the GenericScopeView.
<Cimi> dednick, I see all now
<Cimi> dednick, indeed it will get complicated unless carousel and filter grid will share common interface
<tsdgeos> well
<tsdgeos> i'm working on that
<dednick> Cimi: yeah.
<tsdgeos> kind of
<tsdgeos> but stuck on other things
<tsdgeos> so yeah fix it :D
<Cimi> tsdgeos, who are you talking to?
<tsdgeos> you guys
<Cimi> ok :)
<Cimi> tsdgeos, what's your ideal solution?
<tsdgeos> that = common interface
<Cimi> ok
<dednick> Cimi: you should be able to check the count in the GenericScopeView instead, by making the getRenderer function depend on the count.
<Cimi> dednick, unfortunately I think it depends on the model
<Cimi> dednick, let me dig into
<nic-doffay> Are we able to land branches again guys?
<Saviq> nic-doffay, not yet
<dandrader> Cimi, how far did you go with https://bugs.launchpad.net/unity8/+bug/1152150
<ubot5> Ubuntu bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,Confirmed]
<nic-doffay> Saviq, this is ready if you'd like to take it for a test drive: https://code.launchpad.net/~nicolas-doffay/unity8/category-transition-speed-fix/+merge/195203
<Saviq> nic-doffay, k
<Cimi> dandrader, I did not go far: I had a discussion with Saviq and tsdgeos on how we should approach this
<Cimi> dandrader, we decided we should work on low level qt
<Cimi> dandrader, so we stopped going ahead
<Cimi> dandrader, I might unassign myself
<dandrader> Cimi, mind if I take that bug? I have nothing better to do at the moment
<Saviq> nic-doffay, one nitpick: wrap "root.height = genericScopeHeight;" in { }
<Cimi> dandrader, it's qt bug though
<dandrader> Cimi, I know. I like digging into qt
<Cimi> dandrader, have fun then! :)
<Cimi> dandrader, I addigned you
<Cimi> *Assigned
<nic-doffay> Saviq, sure thing
<Saviq> nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/category-transition-speed-fix/+merge/195203/comments/450635
<nic-doffay> Saviq, reading
<tsdgeos> mzanetti: the test is failing for me
<tsdgeos> FAIL!  : qmltestrunner::GenericScopeView::test_hiddenPreviewOpen() 'verify()' returned FALSE. ()
<tsdgeos>    Loc: [/home/tsdgeos_work/phablet/unity8/fix-switching-previews-positioning/tests/qmltests/Dash/tst_GenericScopeView.qml(149)]
<mzanetti> interesting
<tsdgeos> mzanetti: can you test?
 * mzanetti wonders how he broke that one
<mzanetti> tsdgeos: sorry. forgot to update that one. it was still reading the context prop
<mzanetti> tsdgeos: fixed now
<dandrader> Saviq, mzanetti what does it mean when a bug has a "affect Ubuntu UX" with a "fix commited" status? Does it mean that there's some design doc specifying it or something?
<dandrader> e.g. https://bugs.launchpad.net/unity8/+bug/1152150
<ubot5> Ubuntu bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,In progress]
<dandrader> I would ask the reporter, but he's gone
<mzanetti> dandrader: it menas that design has come to a conclusion on this
<mzanetti> dandrader: but it might be a design spec or a comment on the bug
<mzanetti> dandrader: in this case as Oren reported the bug I think the bug itself is the solution for the UX
<dandrader> mzanetti, hmm, ok. thanks
<nic-doffay> Saviq, it needs to take the y of the filter grid itself into account right?
<tvoss> Saviq, test ping
<Saviq> tvoss, test pong ;)
<Saviq> nic-doffay, yes, the y in relation to ScopeListView
<nic-doffay> Saviq,  out of interest did you see this issue on the desktop? I'm not noticing it yet.
<Saviq> nic-doffay, yes
<nic-doffay> Saviq, so the best way to see it is to scroll up one row then collapse/expand right?
<Saviq> nic-doffay, yes, but it's not even about seeing it - just think about it
<Saviq> nic-doffay, nevertheless it is visible - but it's happening very quickly
<nic-doffay> Saviq, yeah just wanted to ensure I could see the fix well though.
<Saviq> nic-doffay, here's one: http://ubuntuone.com/4AuII1GwHnbNI9C9yearMZ
<Saviq> nic-doffay, you can see "Files & Folders" disappearing both when expanding and collapsing
<Saviq> nic-doffay, that's the "you didn't take uncollapsedHeight into account" issue
<Saviq> nic-doffay, and here's the other one http://ubuntuone.com/5wVUF7Jo3YD8X9Kcs6qHL6
<Saviq> nic-doffay, you can see it blinking when collapsing
<Saviq> but also when expanding it sometimes doesn't show all the items
<mzanetti> mhr3: hi
<mhr3> mzanetti, hey
<mzanetti> mhr3: looking at the preview spec there are some previews which are not fullscreen
<mzanetti> mhr3: is there already a plan on how to make that possible?
<mhr3> mzanetti, yea... let's not go there yet :)
<mzanetti> mhm
<mhr3> tbh i think the design should be changed
<mhr3> it was under the assumption that those results can't have an image
<mhr3> but they can
<mzanetti> mhr3: wait. the smaller previews should have an image too?
<mhr3> design assumed they don't so they created small previews
<mhr3> that's how i think it went
<mzanetti> mhr3: probably, yes. but so far the dash plugins don't have images except very few ones
<mhr3> which is a bug
<mhr3> majority of them do have images
<mhr3> but there's some issue on the server
<mzanetti> ah ok. but maybe design doesn't even want those
<mzanetti> i for one think the amazon preview would be better off without the screenshot of the amazon website
<mhr3> maybe
<mhr3> but those small previews don't consider other-than-phone form factors
<mzanetti> ok. I'll clarify this with design
<mhr3> therefore they suck :)
<mhr3> Saviq, i noticed that with my scopes split, unity goes for the mock scopes plugin when you ./run it
<mhr3> Saviq, ok to just do http://paste.ubuntu.com/6415955/ or would you want something more elaborate?
<Saviq> mhr3, what's "unity-scopes-qml"? :D
<Saviq> mhr3, and why would plugindir come from there - shouldn't unity8 (or unity-api, for that matter) define that path?
<mhr3> Saviq, it's me being consistent with naming :)
<mhr3> Saviq, otherwise, pc installed by unity-plugin-scopes
<mhr3> Saviq, sounds a bit odd that unity8 itself would define it
<mhr3> although only because you're running it
<mhr3> otherwise it kinda makes sense
<Saviq> mhr3, yeah, that's why I said unity-api
<Saviq> mhr3, it would define the interfaces and the place where to install them
<Saviq> mhr3, both the implementations and unity8 would find out where to look for those build-time
<Saviq> from the unity-api .pc
<mhr3> Saviq, yea, that sounds good
<Saviq> biab
<mhr3> so i'll just remove the unity-plugin-scopes' .pc file completely and move this var into unity-api's .pc, k?
<mhr3> hmm, and maybe i'll keep it
<mhr3> though not sure who'd need to know its libdir
<nic-doffay> Saviq, I've sorted out the one issue, but where must the y be taken into account? I've tried testing as much as I can to check for faults.
<nic-doffay> I'm not seeing anything after fixing the issue you mentioned in your comment.
<tsdgeos> Cimi: ping
<tsdgeos> dednick: ping
<dednick> tsdgeos: yo
<tsdgeos> dednick: i've updated https://code.launchpad.net/~aacid/unity8/noScopeView/+merge/194486 with a wait and the crash is gone, it is my current understanding that for reason even if the element has been removed it if it had a pending paint it gets painted again and then it crashes. I think this is something we should investigate but given the amount of changes in the renderloop in 5.1 and 5.2 i've opted for adding a TODO about it
<tsdgeos> what's your opinion?
<tsdgeos> Saviq: âââ
<Cimi> tsdgeos, pong
<Cimi> Saviq, was reading of that http://www.tomshardware.com/news/NAND-Flash-Flash-Friendly-File-System-F2FS-Jaegeuk-Kim,18229.html - do we have plans for ubuntu?
<tsdgeos> Cimi: so you're trying to find do a "base item" for the generic scope view items?
<Cimi> yep albert
<dednick> tsdgeos: what is the change in plugins/ListViewWithPageHeader/listviewwithpageheader.cpp for?
<dednick> or just a change in logic pattern?
<tsdgeos> Cimi: ok, i may have been not clear this morning, but i was also doing it before i got sidetracked, this is what i had in Dash/DashBaseRenderer.qml http://paste.ubuntu.com/6416258/
<tsdgeos> dednick: there's no change?
<tsdgeos> or you mean the change in the last commit?
<dednick> last commit. you removed check for parentContext
<tsdgeos> dednick: that was the reversal of the previous attempt to not make it crash
<dednick> tsdgeos: oh right, so you were seeing it earlier? ok
<tsdgeos> yeah
<tsdgeos> on the same test
<dednick> hm. wonder why this has suddenly caused issues
<tsdgeos> dednick: it's not sudden
<tsdgeos> dednick: the test was using a fake genericscopeview
<tsdgeos> not the real one
<tsdgeos> which now i use
<dednick> tsdgeos: ah. ok
<tsdgeos> i can "fix" it
<tsdgeos> adding gets here and there
<tsdgeos> but tbh i'd like to wait for 5.2 and then see if it is still happening
<tsdgeos> and if it is
<tsdgeos> investigate it more
<tsdgeos> because it doesn't make sense that just adding the wait there it stops crashing
<dednick> tsdgeos: ok, well if it's not a new thing and just now the test failing, then i think it's ok to just make the test pass for now and add a TODO
<tsdgeos> the todo is there already :-)
<dednick> yup, i know, which is why i've approved :)
<mhr3> tsdgeos, there was a talk some time ago that we shouldn't be putting QObjects into a model?
<tsdgeos> hmmm
<tsdgeos> don't remeber about it
<tsdgeos> and can't think of an immediate reason why not to tbh
<tsdgeos> mhr3: c++ wise you mean, right?
<mhr3> tsdgeos, yep
<mhr3> tsdgeos, hm, i do remember a discussion about model and objects, although maybe the conclusion wasn't that there shouldn't be objects
<mhr3> or maybe it was about not using QFoo* in there?
<mhr3> instead to have QFoo instead
<tsdgeos> well, it depends on what you're trying to do :D
<tsdgeos> do you have an example we can talk over?
<mhr3> i'm writing a new model and don't want to make mistakes from the beginning :)
<tsdgeos> mhr3: i guess you just need to make sure you keep the ownership of the * clear if you use *
<tsdgeos> that's the only thing i can really think of atm
<mhr3> yea, that makes sense
<Saviq> nic-doffay, say you're expanding the second category
<Saviq> nic-doffay, you don't want to animate from $currentHeight to $scopeViewHeight
<Saviq> nic-doffay, but from $currentHeight to $scopeViewHeight - $currentY
<mhr3> dednick, btw any development on the glib source in qt issue?
<Saviq> tsdgeos, does it crash in 5.2, too?
<tsdgeos> Saviq: haven't tried, compiling and running the whole thing against 5.2 is not that easy (unless you run the ppa which i'm not sure i want to do and risk messing up my system)
<Saviq> tsdgeos, I'm good with workaround + TODO, but if it's something that needs to be fixed in 5.2 anyway...
<Saviq> tsdgeos, the ppa should be safe, + ppa-purge to go back
<tsdgeos> i've never used ppa-purge
<tsdgeos> but ok, i'll check it tomorrow
<tsdgeos> changing the other Qt patch now
<tsdgeos> i pinged lars and he did a quick comment to make me fix something so i need to fix it so he has no excuse not to continue looking at it :D
<Saviq> tsdgeos, do do do :F
<Saviq> tsdgeos, ppa-purge is very handy - it will downgrade all the packages, that you have installed from that ppa, to distro versions
<Saviq> or at least to latest non-that-ppa versions
<Saviq> and comment out the ppa
<Saviq> Cimi, well, it's not in the kernel yet, even, is it ;)
<Saviq> Cimi, our kernel folk would have to look into it and see the advantages
<nic-doffay> Saviq, yeah so the individual category y. I was thinking of the scopeView y for some reason...
<nic-doffay>  Got it though, ta
<Cimi> Saviq, I read that motorola is using it on moto x and g
<Cimi> moto g seems like a great phone where I would like to see ubuntu on it
<Cimi> it's cheap
<Cimi> and does good stuff
<dednick> mhr3: em, not really. have a better solution, but it's still just sending events
<Cimi> dednick, so I've been digging on the carousel filter grid
<Cimi> dednick, in general I think those two are too different to be shared :\
<Cimi> there's so much more custom code between scope view and filter grid than it's required for the carousel
<Cimi> Saviq, ^
<Cimi> as albert started http://paste.ubuntu.com/6416258/
<pete-woods> mterry: hi, did you ping me earlier about the MIR stuff? I can't find any trace of it, but my brain suddenly said, "hey you forgot something!"
<mterry> pete-woods, yar, you said there were bug subscribers, but I don't see them
<Cimi> there's also highlightIndex
<pete-woods> mterry: where do I look to verify?
<pete-woods> I thought I added them
<pete-woods> I put them on the launchpad project, not the source package, was that wrong?
<mterry> pete-woods, https://launchpad.net/ubuntu/+source/libqtdbusmock
<mterry> pete-woods, yeah.  I mean, both are good
<mterry> pete-woods, but MIR specifically cares about Ubuntu maintainership
<pete-woods> mterry: okay, I will do that then
<veebers> Can anyone here tell me the status of Optimus graphics on Ubuntu? Should I stay away and opt for Intel graphics? Is bumblebee a solution that just works?
<Saviq> veebers, http://www.webupd8.org/2013/08/using-nvidia-graphics-drivers-with.html
<veebers> awesome, thanks Saviq I'll take a look
<Saviq> veebers, at least in my Dell I can switch between nVidia (by disabling optimus) and Intel (by enabling, but not using optimus)
<Saviq> veebers, with  nvidia-prime Xorg crashes here, though :/
<veebers> Saviq: sweet, sucks about the crash though :-\ Looks like I have a couple of other laptop options available to me now
<Saviq> veebers, I've been happily using either nVidia or Intel on this laptop for two years now, just never really both at the same time
<Saviq> I did experiment with bumblebee, but it's just never proven useful (I'm no gamer, though)
<Saviq> veebers, truth is, if you don't need the umph from nVidia for gaming or such, probably better to steer away from it for all kinds of reasons
<veebers> Saviq: right, that was my original thinking. But I've got a couple of laptops that I'm considering, one has nVidia Optimus so thought I would do some reasearch
<veebers> Saviq: actually, if you have a moment, could I ask you a qml question?
<Saviq> veebers, hit me, but latency might be high ;)
<veebers> Saviq: ack, thanks. Is there a better way for me to pass an argument to this purely qml app so that it can be used as a property: https://code.launchpad.net/~veebers/stock-ticker-mobile-app/mock-server-for-testing/+merge/194971
<veebers> I'm wanting to pass in the server url to use, but on startup it seems that the argument value isn't ready yet and thus initially uses the default
<Saviq> veebers, yeah, so: QML objects are always instantiated with defaults
<Saviq> veebers, and then the property values are evaluated and set
<Saviq> veebers, so you always need to react to onPropertyChanged
<Saviq> veebers, "get_data_server() ? get_data_server() : ..." you can use bracket-enclosed JS that you return a value from in a binding, so:
<Saviq> { var foo = get_data_server(); if (foo) return foo; else return "bar"; }
<Saviq> saves you one call to get_data_server()
<veebers> Saviq: ah right, nice. But your saying that for instance this isn't doing what I expect it to (i.e. I expect that the dataserver arg (used in get_data_server() ) is available and would be used) : property string dataServer: get_data_server() ? get_data_server() : "http://finance.yahoo.com/"
<Saviq> veebers, from what I can see things should be working, 'cause other props are bound to dataServer
<Saviq> veebers, only potential missing thing is listening for args.values.dataserver changes
<Saviq> veebers, but IIUC that comes as a command-line argument, so it should be safe
<veebers> Saviq: odd, if I add debugging logging to get_data_server stating if args.values.dataserver is set or not, thre are some initial calls where it is not set
<Saviq> veebers, yeah, I expect there may be
<veebers> Saviq: yes it's an Argument that's set via command line, so it shouldn't change during operation
<Saviq> veebers, well, but then it depends how the whole Arguments / Argument machinery behaves
<veebers> Saviq: ah, good point
<Saviq> veebers, there might be some cycles where it didn't yet pick up the args
<Saviq> veebers, it's the first I've seen the Arguments component, do you know where it comes from?
<Saviq> ah, SDK ;)
<veebers> Saviq: it's a uut component: http://developer.ubuntu.com/api/devel/ubuntu-13.10/qml/ui-toolkit/qml-ubuntu-components0-arguments.html
<Saviq> veebers, so yeah, I'm not sure on its internals, but I expect there might be some racing involved, especially if you see the value being empty at first
<veebers> Saviq: ack ok. I'll explore further. Is there any other methods available to me for a pure qml app to pass an argument either via command line args or env var that you know of?
<Saviq> veebers, nope, there's nothing like that - those kind of things are meant to be done in c++ before starting the QML engine
<veebers> Saviq: aye, that's the conclusion that I had come too as well. Thanks for clarifying :-)
<veebers> Saviq: on that note, what sort of boiler plate would be needed to add that to the app (the c++ side)?
<Saviq> veebers, very little
<veebers> Saviq: hmm, I might explore that then
<Saviq> veebers, create a QML app in QtCreator, it will give you a C++/QML template
<veebers> Saviq: nice, thanks.
<Saviq> veebers, file a bug against SDK, though, if you find that's indeed the case that the values are not ready straight away
<veebers> Saviq: will do
<veebers> Saviq: also (change of topic :-) ) fyi: https://code.launchpad.net/~veebers/unity8/ap_make_use_of_helpers_in_tests/+merge/191575
<Saviq> veebers, yeah I tested it today and it was fine, wanted to have a look again
<veebers> Saviq: cool thanks.
<Saviq> veebers, one thing, though - there's some logging output from the helpers we should probably quiet down
 * veebers looks
<veebers> Saviq: this is the "Restarting unity . . ." logs?
<Saviq> veebers, yeah, and then the output from upstart
<veebers> Saviq: cool, I'll take care of it
<Saviq> veebers, cheers
 * veebers takes extra logging out into the woods to "take care of it"
<Saviq> veebers, while you're at it, maybe it'd make sense to log the output from upstart, so that it shows up in -v
<veebers> Saviq: good point, will do
<veebers> hmm, my qtcreator doesn't have the ubuntu branding etc. which leads me to believe that perhaps I need some more things installed. Anyone have an idea?
<Saviq> veebers, ubuntu-sdk
<veebers> Saviq: ack thanks. I'm installing as we speak :-)
<Saviq> /away
#ubuntu-unity 2013-11-15
<pero> i've lost my the Unity Webapps extension in Chromium - yet everything seems installed ok - any way to get it back?
<tsdgeos> my clock indicator is gone again
 * tsdgeos manually starts it
<Cimi> tsdgeos, hey :)
<tsdgeos> Cimi: ho
<Cimi> tsdgeos, I had a look yesterday
<Cimi> tsdgeos, and basically it's like your work plus something else
<Cimi> for example highlghtIndex
<Cimi> tsdgeos, I'm wondering if it really makes sense to share a common interface... filter grid is lot more complex
<tsdgeos> Cimi: well, if you don't have a common interface how am i supposed to implement a new renderer (let's say one that displays stuff in a circle)?
<tsdgeos> just by magicly going over all the code and random guessing stuff?
<Cimi> tsdgeos, but the common interface is raised in complexity because of the filtegrid
<Cimi> tsdgeos, I will have to add dummy stuff to the carousel just to match the interface
<tsdgeos> no
<tsdgeos> you have dummy stuff in your interface
<Cimi> whatever
<Cimi> I meant, it's not used
<tsdgeos> yes
<Cimi> you have APIs that do nothing
<tsdgeos> it's not used now either
<tsdgeos> Cimi: what's the other solution?
<tsdgeos> have lots of if (FilterGrid) ?
<Cimi> :\
<Cimi> I dunno
<Cimi> that's why I am asking your opinion
<tsdgeos> or just end up with warnings like now because we access stuff that doesn't exist
<tsdgeos> my opinion is that the common interface makes sense
<tsdgeos> we need to properly define it
<tsdgeos> i.e. if property moo only makes sense if you support filtering or something
<tsdgeos> then we need to make it clear in the doc of that common interface
<tsdgeos> Cimi: afaiu that was also Saviq's position, but you may want to check with him
<Cimi> ok
<Saviq> Cimi, tsdgeos, yes, even if not used, we should have a common interface, just to avoid changing it in one place and forgetting about other places, like we had already
<Saviq> after all, noop on part of an API is just a special case
<tsdgeos> +1
<Saviq> Mirv, hey, we got a fix in upstream Qt that would fix unity8's FTBFS with 5.2
<Saviq> Mirv, we could distro-patch if you think it worth it https://codereview.qt-project.org/#change,71208
<Saviq> Mirv, or wait until a second beta or something
<Saviq> Mirv, there's one more related in review: https://codereview.qt-project.org/#change,71327
<Cimi> i'll do that then
<tsdgeos> man https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews is starting to look scary again
<Mirv> Saviq: oh cool. the RC should on Tuesday
<Mirv> Saviq: I can put it in as a patch
<Mirv> Saviq: btw webkit, sensors, location, multimedia also in qt5-beta2 PPA. had to disable the device pixel ratio patch of qtwebkit again as it didn't apply.
<tsdgeos> hmmm
<tsdgeos> are we using VideoInfo.qml?
<tsdgeos> or AppInfo.qml?
<Saviq> tsdgeos, probably not
<Saviq> tsdgeos, VInfo was reading .nfo files - so no
<Saviq> tsdgeos, AppInfo, yes - it's part of the app preview
<Saviq> or hmm
<Saviq> tsdgeos, it *was* part of the app preview, looks like it's moved to Header, since, I think
<tsdgeos> :D
<tsdgeos> so kill both?
<tsdgeos> or?
<Saviq> yeah, if you can confirm they're not used
<Saviq> kill with fire
<Saviq> Mirv, right, the second patch should be merged by Tuesday, too
<Saviq> tsdgeos, they're going into 5.2, right â? (/me doesn't know the stable vs. release targets in Qt's gerrit)
<tsdgeos> Saviq: the one that is merged will be in 5.2.0
<tsdgeos> the one that is still being discussed seems like it'll be in 5.2.0 too
<tsdgeos> or at least it's the branch i'm targetting
<Saviq> tsdgeos, yup, cool beanz
<tsdgeos> Saviq: at this moment release -> 5.2.0 stable -> 5.2.1 dev -> 5.3.0
<Saviq> tsdgeos, ah, got it
<nic-doffay> Saviq, any bugs you can recommend for me to take a look at?
<tsdgeos> nic-doffay: how's the filter expansion one going? needs review or still wip?
<nic-doffay> tsdgeos, I just need to do a small change to keep it in line with the sdk
<nic-doffay> but it's basically ready to land ages ago.
<tsdgeos> nic-doffay: no no, i mean the dash animation expansion, no the filtering in the header
<tsdgeos> sorry :D
<Saviq> nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145/comments/450251 that says it isn't ready ;)
<Saviq> tsdgeos, Cimi what's the deal with the InverseMouseArea? did you find a workaround until Daniel's "deliver touch through sendEvent" gets in?
<Cimi> I did not wrk on it
<Saviq> tsdgeos, ah, you only did a "don't filter if disabled"
<tsdgeos> Saviq: Â¿?
<Saviq> Cimi, mhm, k - we'll probably distro-patch Daniel's patch when it gets in
<Saviq> tsdgeos, https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/ima_do_not_filter_disabled/+merge/194830
<nic-doffay> Saviq, I've addressed those.
<tsdgeos> ah yes
<tsdgeos> Saviq: that was a different fix altogether
<nic-doffay> Saviq, oh wait..
<nic-doffay> :P
<tsdgeos> Saviq: if you had two InverseMouseArea they would fight eachother
<Saviq> nic-doffay, yeah :P
<tsdgeos> which was awful :D
<Saviq> tsdgeos, oh the blood
<tsdgeos> Saviq: now they only fight eachother if they are both enabled, which is "understandable" as you have two mouseareas where both say they are the topmostitem
<tsdgeos> so well, fix your software :D
<Saviq> yeah, of course
<Saviq> nic-doffay, please make sure to reply to review comments so that people don't have to find what's fixed by themselves
<nic-doffay> Saviq, sure
<nic-doffay> Saviq, either way it looks like I'll be busy with those changes.
<Saviq> nic-doffay, I'm ok with not having the expansion fixed completely, but getting stuck in the filters is bad
<Saviq> nic-doffay, so we need to make the best we can to improve the situation while we don't have the whole expansion thing sorted out
<nic-doffay> Saviq, there's no reason why those changes can't be done today.
<nic-doffay> Aside from the icon depending on design.
<Saviq> nic-doffay, k
<nic-doffay> Saviq, for the filter selection I just plan on using inverse mouse areas to dismiss/block selection of the other drop downs.
<Saviq> nic-doffay, yeah, we need to have IMA fixed for that, too
<nic-doffay> Saviq, that's what I was concerned about.
<nic-doffay> Hopefully it will function ok.
<tsdgeos> no mirco today?
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/remove_unused_info_files/+merge/195365
<Saviq> tsdgeos, thanks
<mzanetti> Saviq: the click package upgrading feels a bit like BAMF :)
<mzanetti> as we have a different appId, different .desktop file and need to guess if its just an upgrade or in fact a different app :)
<Saviq> mzanetti, you shouldn't care about that
<Saviq> mzanetti, just store appid://..../current-user-version
<mzanetti> Saviq: but when an app gets started I get the full appid
<mzanetti> and still need to figure what it is
<Saviq> mzanetti, well, just strip the version number, no?
<mzanetti> Saviq: yeah... but then I need to open the .desktop file to read the icon etc
<mzanetti> and for that I need the full version again
<Saviq> mzanetti, right, that should be the desktop file parser's job, shouldn't it...
<Saviq> mzanetti, but yeah, while we don't have it
<Saviq> mzanetti, shouldn't be too difficult to just find the matching .desktop file?
<Saviq> as there can (well, should...) only be one
<Saviq> fail-safe - find the latest one alphabetically
 * Saviq wonders if QStandardPaths::locate supports wildcards
<Saviq> nope :/
<tsdgeos> mzanetti: https://bugreports.qt-project.org/browse/QTBUG-32251 should we discard this one?
<tsdgeos> Saviq: like?
<Saviq> tsdgeos, like *
<tsdgeos> it does i've been told it could do * stuff
<tsdgeos> i actually even wrote code i think :D
<Saviq> tsdgeos, hmm maybe locateAll does not?
<tsdgeos> hmm
<tsdgeos> ok, actually not
<tsdgeos> waht i did was
<tsdgeos> const QStringList localeDirs = QStandardPaths::locateAll(QStandardPaths::GenericDataLocation, QString("locale"), QStandardPaths::LocateDirectory);
<tsdgeos> taht is kind of a *
<tsdgeos> but not really
<tsdgeos> i.e. it returns all subdirs of QStandardPaths::GenericDataLocation containing a subdir named "locale"
<Saviq> tsdgeos, http://pastebin.ubuntu.com/6420982/ is what I tried
<Saviq> tsdgeos, hrm subdirs?
<Saviq> tsdgeos, so ~/.local/share/*/locale?
<tsdgeos> yep
<tsdgeos> or not
<tsdgeos> wait
<tsdgeos> i'm speaking shit here :D
<Saviq> yeah you are ;D
<tsdgeos> what it does is return the subirs of /usr/share/locale/
<Saviq> that'd be wrong ;)
<Saviq> then it doesn't do what the docs say it does :D
<tsdgeos> true
<Saviq> ("/home/michal/.local/share/locale", "/usr/share//locale")
<Saviq> tsdgeos, that's what it does ;D
<tsdgeos> because i'm speaking shit again
<tsdgeos> sorry
<Saviq> so no, not what you said :D
<tsdgeos> don't listen to me again :D
<Saviq> tsdgeos, don't worry, it's Friday ;)
<tsdgeos> it's weird it doesn't support * though
<tsdgeos> since it's written by the KDE guy that wrote KStandardDirs
<tsdgeos> and that supports *
<tsdgeos> i do
<tsdgeos> list = KGlobal::dirs() -> findAllResources("appdata", "*.kgm");
<tsdgeos> in one of my kde apps
<tsdgeos> Saviq: maybe QStandardPaths::ApplicationsLocation is /usr/bin and that's why it doesn't return stuff?
<Saviq> tsdgeos, no, that's $GenericDataLocation/applications
<Saviq> tsdgeos, so ~/.local/share/applications, /usr/share/applications
<Saviq> tsdgeos, if I use the full file name, it works
<tsdgeos> let me ask david
<tsdgeos> oh, he's not online
<Saviq> mzanetti, on that note... (how) do we remove pinned items for apps that are removed?
<mzanetti> Saviq: we don't right now
<Saviq> mzanetti, yeah I'm not sure what we should do TBH
<Saviq> mzanetti, whether we should do anything, for that matter (other than ignoring invalid entries - and pick them back up when installed again)
 * greyback thinks version string in appId is more trouble than it's worth
<mzanetti> +1
<mzanetti> Saviq: do we actually use the version field somewhere or do we just work around it everywhere?
<greyback> and it break the existing ability to watch for app installs/updates/removals by inotify on the desktop file directories
<mzanetti> it kinda defeats the purpose of the appId, because it doesn't identify an app
<Saviq> greyback, mzanetti, the reason for having them in is being able to install multiple versions at the same time
<Saviq> in a multi-user environment
<Saviq> you don't want other users to upgrade your apps
<mzanetti> mhm
<greyback> doesn't each user have their own .local directory
<Saviq> greyback, only for the .desktop files
<mzanetti> for the rest too actually
<Saviq> greyback, the apps are installed in /opt
<mzanetti> in /opt/.click/user/...
<Saviq> s/installed/unpacked/
<mzanetti> at least the icon file is located there, not where the main thing is unpacked
<Saviq> # ls /opt/click.ubuntu.com/
<Saviq> com.ubuntu.developer.mzanetti.ubuntu-authenticator
<Saviq> com.ubuntu.developer.mzanetti.xbmcremote
<Saviq> com.ubuntu.developer.rick-rickspencer3.franglish
<mzanetti> ls /opt/click.ubuntu.com/.click/users/phablet/
<mzanetti> com.ubuntu.developer.alecu.qr-code         com.ubuntu.developer.mzanetti.ubuntu-authenticator  com.ubuntu.developer.ogra.fruity-pops
<mzanetti> com.ubuntu.developer.elopio.xbmcwebremote  com.ubuntu.developer.mzanetti.xbmcremote
<mzanetti> so it's linked (without version information) to a user specific dir
<Saviq> right
<Saviq> that looks internal to the click system, though
<Saviq> another reason is having per-version data directories, so that app upgrades don't b0rk your data
<mzanetti> Saviq: what you mean with data directories?
<mzanetti> .cache ?
<Saviq> mzanetti, .local/share/ rather
<Saviq> .cache is not for data ;P
<greyback> so should we should agree in shell to drop version string from appId everywhere? Since per user session, only one version of an app can be installed
<mzanetti> I think it would be better to drop it everywhere in unity than just having regexps on ever interface the launcher has to the outside
<Saviq> greyback, mzanetti, sure, I don't think it helps us anywhere shell-side
<Saviq> and it hurts us where we store/match it
<mzanetti> yeah
<greyback> +1
<Saviq> we should talk to cjwatson / barry about this
<Saviq> maybe even upstart shouldn't care about them
<mzanetti> yeah... I do see the reason why we install it in different directories. but the fact that the version is inserted in the appId seems to cause only issues
<Saviq> that I agree with
<greyback> would be handy of upstart adopted it too. I think it makes sense, as the session upstart is only able to launch 1 version anyway. Would make my life nicer too :)
<greyback> that still leaves us with the problem: how can shell know if a click app was updated? Watching the desktop file directories isn't quite enough really.
<greyback> similarly when app removed
<mzanetti> greyback: the update issue would go away, no?
<greyback> mzanetti: are we proposing drop the version string from the desktop file name in the .local ?
<greyback> if yes, then we're golden
<greyback> but then what about system apps. Ahh
<mzanetti> greyback: the .desktop filename is "appId".desktop
<mzanetti> greyback: what's the problem with system apps?
<greyback> mzanetti: let me recap: we're using "$appId.desktop" files. appId includes version string. On update, the desktop file is removed and a new one with different file name created
<mzanetti> yes
<mzanetti> because appId changes
<greyback> we plan to watch via inotify the desktop file directories for the deletion and creation?
<mzanetti> greyback: not really, no
<greyback> mzanetti: oh, how does shell know if app updated or removed?
<mzanetti> greyback: yeah, well, we could do that to determine if an app is removed. but it still wouldn't help us in the upgrade case as it would go away and a *different* one appears
<greyback> mzanetti: exactly. That's my concern.
<mzanetti> so yes. once the upgrade leaves the file alone, watching it might be an option to determine removal of an app
<mzanetti> assuming an upgrade wouldn't remove it and then recreate it a few seconds later
<greyback> I think easier solution is just to have the desktop file name use the app Id minus the version string. Since desktop file is placed in a user specific directory, the versioning is irrelevant data in that context. The app install directory can keep the version string though.
<mzanetti> greyback: yes, that would happen too if we decide to ditch the version field completely (except click system internal)
<greyback> mzanetti: yep. Must see what click people would think of the idea
<mzanetti> yes
 * greyback hates when texlive needs an update
<mzanetti> haha
<mzanetti> Saviq: can you drive this version number discussion with the click guys?
<Saviq> mzanetti, yeah, I will
<Saviq> mzanetti, actually, let's just file a bug
<Saviq> mzanetti, greyback, bug #1251635
<ubot5> bug 1251635 in click (Ubuntu) "drop version numbers from users' .desktop file names" [Undecided,New] https://launchpad.net/bugs/1251635
<Saviq> please add your comments if you have something to add
<nic-doffay> Saviq, I think there's an issue with the inverse mouse area. I've included it as a child of the filter delegate as you can see in this pastebin: http://pastebin.ubuntu.com/6421305/
<nic-doffay> The problem is the last InverseMouseArea swallows everything.
<nic-doffay> So the first filter in the list cannot be clicked.
<nic-doffay> Am I making sense?
<Saviq> nic-doffay, you need to only enable the InverseMouseArea when the filter is expanded
<Saviq> nic-doffay, although there's https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/ima_do_not_filter_disabled/+merge/194830
<Saviq> nic-doffay, which you're probably hitting if you have multiple IMAs
<nic-doffay> Saviq, that's probably it then.
<mterry> Saviq, who's upstart savvy that we can poke for my set-mir-socket branch?
<Saviq> mterry, I poked ogra yesterday, at least to point at someone else if he does not want to, but seems I didn't get his attention
<mterry> Saviq, poking him in #ubuntu-touch
<Saviq> nic-doffay, standup
 * kgunn wonders if this is why people resist updating...rebooting
<Cimi> tsdgeos, so both FilterGrid and Carousel are inside Components. I wanted to write a DashRenderer so instead inheriting from Item they were subclassing DashRenderer
<tsdgeos> right
<tsdgeos> so we talked with Saviq about this the other day
<tsdgeos> damn i half broke my s key when cleaning the shit under it
<tsdgeos> left me try to reassemble it
<tsdgeos> better
<tsdgeos> Cimi: the conclusion we reached is that from a separation point of view
<tsdgeos> what made more sense is having the DashBaseRender in Dash/
<tsdgeos> and then you do a DashFilterGrid that is a DashBaseRender and contains a FilterGrid and forward the neccessary signals/properties
<tsdgeos> Saviq: am i right that is that on what we agreed?
<tsdgeos> Saviq: am i right that is that on what we agreed?
<tsdgeos> sorry :D
<Saviq> tsdgeos, unfortunately, yes
<Saviq> tsdgeos, Cimi, but that's the only way for us to separate the FilterGrid and Carousel from the Dash indeed
<Saviq> those two should remain agnostic, since we might push them to the SDK at some point
<Cimi> Carousel in sdk :'(
<Cimi> I fear terrible abuse of it
<dednick> mhr3: hm.. through a very lucky random set of events, I think the dash is getting away with dee updates coming through directly from glib. not that it shouldn't be fixed though.
<Saviq> Cimi, might
<Saviq> Cimi, not will
<mhr3> dednick, how come?
<mhr3> also, not liking being lucky
<dednick> mhr3: erm, dunno, looks like it's only reset which issues immediate deleteLater calls on a model items remove seems seems to go through some other chain. Not sure when reset gets called on dee model. think it's only if underlying model changes.
<dednick> mhr3: that's a qt model reset i'm talkin about
<mhr3> right
<mhr3> it can happen though
<mhr3> and actually first synchronization should trigger a reset
<mhr3> although at that point the model is empty
<mhr3> so perhaps there's nothing to deleteLater
<dednick> mhr3: yah.
<dednick> mhr3: can sync change?
<mhr3> a simple call to DeeListModel::setModel() to change the model would trigger a reset
<dednick> mhr3: indeed. but we presumably aren't using that.
<dednick> when it's not empy i mean
<mhr3> at least not in the common paths
<mhr3> i just hate knowing about races...
<mhr3> why did you tell me about it? :P
<dednick> anyway. it's still wrong, and we're just lucky
<mhr3> yea
<dednick> mhr3: hehe. i didnt. you waved your hand
<mhr3> heh, see, and i was right, there's no bug in dee
<mhr3> it's qt that's buggy :P
<dednick> mhr3: hehe, yeah
<dednick> anyway, i've pimped the even sending mech so you only really need 1 extra line to send the event. slicker'than'snot.
<dednick> still sucks though..
<mhr3> dednick, i'd rather see a patch to qt's deleteLater tbh
<dednick> mhr3: hm. it still doesn't get away from the fact that qt does not support what they call "alien context". That linked bug showed another issue seemingly not realted to deleteLater.
<dednick> mhr3: however, i dont really agree with that assessment, seeing as it is actually the same context...
<mhr3> dednick, the other bug mentions use cases with moving qobjects between threads... i don't think we care about that
<mhr3> dednick, so right now i'd see deleteLater as the *only* problem
<dednick> mhr3: oh right. well i think you're supposed to call moveToThread or something in that case...
<mhr3> yea, whatev, we don't care
<mhr3> tsdgeos, question - all of our QAbstractItemModel implementations don't implement parent(), columnCount() nor index(), how the hell is it possible that it compiles seeing that all of those are pure virtual?
<tsdgeos> mhr3: because we are implemnting QAbstractListModel ?
<mhr3> aaaaaah
<mhr3> stupid four letters inside a long word
<mhr3> my brain optimizes that out :)
<Cimi> Saviq, in many files I'm noticing the lack of import Ubuntu.Components but still using for example units.gu()
<axisys> I wanted to enable 3d widows with ccsm and that's when I lost the alt+ctlr+arrow functionality.. removed ccsm and compiz-plugin-extras since then..
<axisys> even the workspace switch does not work when pick a running application from different workspace
<axisys> keyboard shortcut shows the right setting.. but no worky
<axisys> something needs reset/restore .. lets hope I dont need to re-install ubuntu
<bschaefer> axisys, hello, so are you having problems with Ctrl+Super+RIght/Left?
<bschaefer> axisys, take a look in ccsm -> Desktop Wall -> Keybindings
<axisys> Ctrl+Alt+Right/Left
<axisys> bschaefer: so reinstall ccsm ?
<axisys> Ctrl+Super+RIght/Left works
<bschaefer> axisys, yeah opps, Alt+Ctrl :)
<bschaefer> Take a look in Desktop Wall plugin
<axisys> i was hoping to restore back to initial unity without re-installing ccsm
<bschaefer> axisys, its all stored in a binary :(, so you'll have to go through ccsm or possibly gconf?
<bschaefer> ccsm isn't that bad
<axisys> if I hit Alt+Ctrl+right/left I get C or D in the terminal :-(
<bschaefer> Yeah sounds like Compiz doesn't have a grab on those keys
<axisys> ok re-installing ccsm
<bschaefer> axisys, im guessing what happened, when you enabled 3d windows, it had some hotkeys that Desktop Wall shared, and removed them
<bschaefer> so you'll just have to go back and poke Desktop Walls keybindings back to default
<axisys> ccsm installed.. I see Desktop Wall is disabled.. like you hinted
<axisys> ok.. its back!!
<axisys> bschaefer: thanks a lot
<bschaefer> axisys, np!
<axisys> I guess need to install compiz-plugins-extras for wobbly window?
<axisys> I am asucker for wobbliness :-)
<axisys> a sucker
<bschaefer> axisys, yeah I believe its in there :)
<bschaefer> axisys, just pay attention when you see a keybinding conflict
<axisys> wobbly window is back too
<bschaefer> yay!
<axisys> one last thing I need is rotate workspace instead of slide.. that's what broke the workspace switch keybinding last time
<bschaefer> hmm rotate workspace?
<axisys> I don't need 3d windows
<bschaefer> you mean the cube?
<axisys> bschaefer: right
 * bschaefer doesn't recal if that plays nicely with other plugins
<bschaefer> axisys, what you'll want to look at doing is going into the cube and changing the hot keys
<bschaefer> so it doesn't conflict with the Desktop Wall plugin
<axisys> bschaefer: cube or right swithcer
<bschaefer> but...I think the cube might disable the Desktop Wall
<axisys> so no cube then.. np
<bschaefer> let me take a look to see if its a hard depend
<axisys> I am looking for a animated way to switch workspace
<bschaefer> but thats what im thinking
<bschaefer> axisys, well you'll have to replace the desktop wall with that, there should be some more but i've not really used them :(
<axisys> bschaefer: that's fine.. I maily needed wobbly window.. I can live without the rest
<axisys> bschaefer: thanks for your help
<bschaefer> axisys, cool, and np! You can always attempt to reset everything back to default in CCSM
<bschaefer> if things go wrong again
<bschaefer> in ccsm -> Preferences -> Reset To Default
<axisys> bschaefer: can you do it from cli
<bschaefer> cli?
<bschaefer> command line?
<axisys> bschaefer: command line / terminal
<bschaefer> axisys, not that  I know of
<axisys> bschaefer: thanks
<bschaefer> as all the settings are stuff into a binary :(
<axisys> :-)
 * greyback__ eow
<crass> I just upgraded from 13.04 to 13.10, and now keepassx is always goes to fullscreen
<crass> I think this is due to a change in unity, can anyone confirm this?
#ubuntu-unity 2013-11-16
<shiznix> not sure i'm in the right channel for this, but i started digging today into why KDE applications don't show up in the dash 'Recently used' sections
<shiznix> it seems zeitgeist-fts doesn't index any KDE applications when launched from the dash
<shiznix> this is for Saucy btw
<shiznix> ok it's because zeitgeist will only operate on *.desktop files if they reside as /usr/share/applications/*.desktop
<shiznix> not (using konsole as an example) /usr/share/applications/kde4/konsole.desktop
#ubuntu-unity 2014-11-10
<tsdgeos> Saviq: what do you think of https://code.launchpad.net/~aacid/unity8/dierfv ?
<Saviq> tsdgeos, surprise, did we not use it in the end?
<tsdgeos> Saviq: we were using this only for the screenshots thing
<tsdgeos> in the old apps scope
<MacSlow> tsdgeos, hm... that is odd... the "if"-issue
<tsdgeos> MacSlow: it's what jenkins says :D
<Saviq> tsdgeos, ah, Flow...
<tsdgeos> Saviq: yep
<MacSlow> tsdgeos, jenkins is my personal enemy ;)
<Saviq> tsdgeos, now I remember, I even got to that conclusion when I first saw your MP, still confusing this with Journals ;)
<Saviq> tsdgeos, yeah, +1 of course
<tsdgeos> Saviq: he he
<tsdgeos> Saviq: ok :)
<tsdgeos> MacSlow: you can not reproduce locally?
<MacSlow> tsdgeos, just trying... but thunderbird is messing up my system, thus everytihng is dog-slow
<MacSlow> and exiting thunderbird takes its time too :)
 * MacSlow just can't get the hang of mutt
<Saviq> seb128, do you have plans to land ubuntu-system-settings into rtm? or should I talk to someone else?
<seb128> Saviq, ken has been handling the rtm landing, I can do one but better to sync up with him first
<Saviq> seb128, ok, will do
<seb128> Saviq, plans we have yes, there are a stack of fixes that should go to rtm or ota1
<Saviq> yup
 * Saviq preps unity8 alone then
<seb128> what fixes do you lan?
<seb128> d
<MacSlow> tsdgeos, I've fixed the if-issue... but still have to iron out a part of the dismiss-test (sync/confirmation notifications were not available when I initially worked on the swipe-to-dismiss branch)
<tsdgeos> ok
<MacSlow> tsdgeos, I'll mark my branch as "wip" for the time being.
<Saviq> seb128, the accepted ones from the recent unity8 release https://launchpad.net/ubuntu/+source/unity8/8.01+15.04.20141107.2-0ubuntu1
<seb128> Saviq, hey, could you look at the current comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1390643 and comment on what you think is the best approach between those suggested?
<ubot5> Ubuntu bug 1390643 in ubuntu-system-settings (Ubuntu) "Orientation lock switch doesn't notice gsettings changes" [High,Confirmed]
<Saviq> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1390643/comments/3
<ubot5> Ubuntu bug 1390643 in ubuntu-system-settings (Ubuntu) "Orientation lock switch doesn't notice gsettings changes" [High,Confirmed]
<seb128> Saviq, thanks
<mzanetti> Saviq: hey, what happened to the fact that we only lock the screen when waking up, as opposed to locking it before going to sleep?
<mzanetti> iirc you once said there's a branch fixing it
<Saviq> mzanetti, there were some approaches, but none that we implemented yet
<Saviq> mzanetti, not a problem on krillin, so lower prio
<mzanetti> ah ok
<mzanetti> interesting... why isn't it a problem on krillin? display waking up slower?
<Saviq> mzanetti, yup
<mzanetti> Saviq: may I assign the RTM ones to you? given you do the cherry-picks... https://bugs.launchpad.net/ubuntu-rtm/+source/qtmir/+bug/1351559
<ubot5> Ubuntu bug 1351559 in unity8 (Ubuntu RTM) "Apps in spread are not anti-aliased" [High,In progress]
<Saviq> mzanetti, yeah, I should've done that
<mzanetti> no prob
<seb128> Saviq, if you use a Binding{} in the other way around too, don't you create a binding loop?
<Saviq> seb128, kinda, but it's quickly interrupted by if (old != new) in all the setters
<seb128> Saviq, well, it makes a warning be printed on stdout
<Saviq> seb128, so even if you get a warning, it's benign
<seb128> or stderr
<seb128> I don't like getting warnings ;-)
<Saviq> seb128, yes, that's why we need a BidirectionalBinding { } ;)
<seb128> when is that coming? ;-)
<mzanetti> Saviq: is there something like that in the works yet?
<Saviq> mzanetti, not really, we were considering it with dednick at some point
<Saviq> seb128, patches welcome ;)
<mzanetti> well, so far I have decent results with Binding {} from backend to ui, and using ui's onClicked handler to change the backend value
<mzanetti> that's what I usually do in my apps
<mzanetti> but I agree QML should make it somewhat easier
<dednick> Saviq, seb128, mzanetti: there was something for that in the ubuntu-settings-components check sync branch, but seb didnt want a special component.
<seb128> dednick, I didn't say I don't want a special component, but rather than it should be in the uitk
<mzanetti> -1
<dednick> https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1336715.check.sync
<mzanetti> should be upstream Qt
<seb128> mzanetti, that's "toolkit" for me
<seb128> so +1 for qt directly
<mzanetti> seb128: you said uitk :D
<seb128> I didn't know if it makes sense for qt
<seb128> but the more upstream/mainstream it can be, the better
<dednick> hm. not sure if it makes sense for qt
<mzanetti> I'd say yes... some sort of UiBinding {} component
<dednick> http://bazaar.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1336715.check.sync/view/head:/Ubuntu/Settings/Components/signalbinder.h
<Saviq> mzanetti, problem is you might need to do some reconciliation, especially in the case of floats and such, like which value should you decide on if both sides changed, what if one side is slow to apply etc.
<mzanetti> right...
<mzanetti> still I guess there could be something useful... if you need very special stuff you can do it the old way
<mzanetti> but yeah... there's a danger of making the mistake the uitk does... trying to be too clever and in the end not being useful for anyone
<Saviq> totally
 * mzanetti thinks of some listitems
<dednick> i could propose a branch for the uitk which includes the signal binder. i think the implmentations of the switch/check are to specific for uitk.
<facundobatista> Hola
<Saviq> mzanetti, hah, splash screens are not antialiased ;)
<mzanetti> meh
<Saviq> mzanetti, hum, is it right that music app seems to be exempt from lifecycle still?
<mzanetti> yes
<mzanetti> still no playing music from apps in ubuntu :/
<Saviq> ah, playlist progression :|
<Saviq> is what we're missing
<Saviq> mzanetti, and yes, we know your feeling on our lifecycle ;P
<mzanetti> it wouldn't be so bad if I would see any progress on the background stuff
<mzanetti> dandrader: ping
<dandrader> mzanetti, pong
<mzanetti> dandrader: hey, having some weird issue with the EdgeDragArea. maybe it makes sense to you:
<mzanetti> dandrader: so I start dragging at the right edge and move the finger all across the screen to wards left
<mzanetti> 2 grid units *before* reaching the left edge, dragging goes to false
<mzanetti> (not sure about the 2 grid units - its some half centimeter)
<dandrader> mzanetti, enable debug logs for TouchRegistry and DDA and then show me the log
<mzanetti> dandrader: that debug output is really useful :D
<mzanetti> problem solved
<dandrader> mzanetti, so, what was it?
<mzanetti> enabled went to false
<mzanetti> so it makes sense
<dandrader> mzanetti, :D
<mzanetti> kinda hard to figure otherwise
<mzanetti> but seems you did a good job with that debug stuff
<dandrader> glad you liked it
<mzanetti> dandrader: hey, this report came in. do you think this could be anything related to missing input? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1391149
<ubot5> Ubuntu bug 1391149 in unity8 (Ubuntu) "greeter not reacting to swipes" [Undecided,New]
<mzanetti> dandrader: if you think no, let's assign it to mterry, otherwise could you have a look?
<dandrader> mzanetti, looks like it could be related to the TouchGate in Greeter.qml. But I would rather keep working on shell rotation as I'm on a tight schedule
<mzanetti> dandrader: sure... just wanted to have some first assessment to know where to push it to
<dandrader> mzanetti, I will add a comment there
<mzanetti> thanks
<tsdgeos> pstolowski:
<tsdgeos> ping
<tsdgeos> unping
<tedg> Saviq, So it looks like qtmir is raising sigstop after the mir connection is setup, but it seems like that should be later, no?
<tedg> Saviq, Like after notifications interfaces and other stuff U8 provides are setup?
<Saviq> tedg, well, as I commented I think it'd be better, if possible, if the indicators tried to reconnect
<Saviq> tedg, depends on the definition of unity8 'started'
<tedg> Saviq, The problem is that it's not a "reconnect" issue for notification, but the bigger issue is pulse. QtMir is initializing Mir quicker than Pulse can get setup.
<Saviq> and it's kinda tricky because we'd have to explicitly wait for all the services we know we're waiting on to say "yeah, we good, go!"
<tedg> Saviq, We can't depend on pulse because the upstart job is an touch-specific thing :-/
 * tedg hates on the ubuntu-touch-session package a bit
<tedg> Saviq, Confused? You mean plugins or services?
<Saviq> tedg, well, so us pushing the sigstop further could just mean we're hiding the other issue?
<Saviq> tedg, plugins == services
<Saviq> tedg, like the notifications service is a plugin
<Saviq> everything is a plugin, really
<tedg> Saviq, Ah, okay. That's confusing to me. Not sure why things shipped together need dynamic loading :-)
<tedg> Saviq, So I was thinking just an idle function, when the mainloop gets idle then raise the SIGSTOP.
<Saviq> oh I'm afraid that's gonna be far too late
<tedg> Why?
<tedg> It seems like that's when things have finished their work.
<tedg> Keep in mind that it should happen faster if we stop the CPU from context switching to indicators and the such by removing them from competing for CPU.
<Saviq> tedg, well, that's counter to the fact that ogra wants to start everything in parallel, as early as possible ;)
<Saviq> tedg, because that would mean the UI is set up, the dash started and stopped drawing, things like that
<Saviq> tedg, so you'd actually be able to start using your phone and only then would indicators show up (or well, they wouldn't at all, if you used the phone enough)
<Saviq> tedg, as for "why plugins", all kinds of reasons
<tedg> Generally the goal isn't to start everything at once.
<tedg> You just want as many things as you have cores.
<Saviq> kinda difficult to encode in upstart events
<tedg> It seems to me that there has to be a point where the Unity8 mainloop goes idle.
<tedg> Generally things like phases come out of the setup of the Upstart events.
<tedg> Not officially, but causally. So for instance, we don't limit the indicators to a number, but start them after so that they end up staying out of the way.
<Saviq> tedg, unity8's main loop (i.e. the one on the first thread) is actually Mir, not the Qt one, where all the dbus things happen
<tedg> Ah, okay. So would it be better to put a signal from the U8 application object when it thinks that it's done loading plugins?
<tedg> Or do they all delay their inits?
<Saviq> tedg, it's not just about loading, we'd need each "interesting" bit to report when they're ready
<Saviq> tedg, as you're interested when it actually registers the name on dbus, not earlier than that
<tedg> Saviq, Sure, that's why I was asking if the init was delayed. Sounds like it is.
<tedg> I really feel like we should be more honest in the Unity8 startup reporting to Upstart.
<Saviq> tedg, so if pulse is the real issue, how would delaying "unity8 started" even help? by chance?
<tedg> But it is looking to me like this isn't an "rtm sized" fix.
<Saviq> tedg, I think we just need to be more granular actually
<Saviq> tedg, each service should emit its own 'foo-started' signal
<tedg> Saviq, Well it's just that indicators are getting started exactly at the same time as pulse.
<tedg> Saviq, Almost any delay would help.
<Saviq> tedg, well, yeah, but that's by chance, meaning that you could just as well put "sleep 2" in there...
<tedg> Thinking we might have to override in ubuntu-touch-session until that pulse job can be pushed upstream.
<tedg> Sure, but trying to fix the problem more than put a sleep in.
<tedg> I think the "fixish" is just to override indicator sound to be "start on indicators-start and started pulseaudio"
<tedg> But that can only be in touch, not desktop.
<Saviq> tedg, sounds like a good idea to add an .override then?
<tedg> Saviq, Yeah, I don't like that solution, but looking like the best right now.
<tedg> Saviq, I would still like to move the indicators signal into post-start though if that's cool with you.
<tedg> Saviq, It doesn't fix the bug, but seems more correct.
<Saviq> tedg, sure
<MacSlow> Cimi, what about https://code.launchpad.net/~macslow/unity8/icon-clipping-fix-1378417/+merge/241097 ... did you review it yet?
<Cimi> MacSlow, looked like a no brainer
<MacSlow> Cimi, sure... but you've not touched it :)
<Cimi> MacSlow, if you cannot think of any possibly wrong cases, let's approve
<Cimi> MacSlow, yeah sorry...
<MacSlow> Cimi, np... that's why I asked :)
<MacSlow> Cimi, thx
#ubuntu-unity 2014-11-11
<tsdgeos> mzanetti: you really are very discouraging on your comment
<mzanetti> tsdgeos: yeah... sorry.. but it really feels too dangerous... you're mixing thread contexts a lot in here
<mzanetti> tsdgeos: if you want we can do a hangout and talk about it
<tsdgeos> no i don't want
<tsdgeos> i have better things to do thatn convincing you
<tsdgeos> you can propose something that works
<tsdgeos> since you think the whole approach is crap
<tsdgeos> and can't be salvaged
<mzanetti> tsdgeos: well, do you see my concerns at least or do you think I'm wrong?
<tsdgeos> mzanetti: i do see that you don't think the code is fixable
<mzanetti> tsdgeos: yeah... just adding more mutexes I think won't cut it here
<tsdgeos> you're wrong
<mzanetti> ok
<tsdgeos> but i don't feel free to instruct you
<tsdgeos> well you're actaully right
<tsdgeos> i don't even need any more mutex
<mzanetti> but I'd like to know where I'm wrong
<tsdgeos> but wathever
<tsdgeos> then you should have worded your review better
<mzanetti> and asking you now to explain me where I'm wrong doesn't help any more?
<tsdgeos> meh i hate being sick
<tsdgeos> mzanetti: ok, let's start with the first
<tsdgeos> tell me when why i need a mutex in worker->m_reply
<mzanetti> tsdgeos: ok... that's probably indeed not needed. I thought the abort case is problematic there
<mzanetti> no... it's not... ok
<Saviq> tsdgeos, eat a snickers!
<tsdgeos> Saviq: don't have one at hand, going outside the building will just increase my sickness/grumpyness :D
<Saviq> :)
 * Saviq looks for same-day amazon snickers delivery 
<mzanetti> if you find that, don't tell me where
<tsdgeos> mzanetti: ok, want me to add a comment why since you got confused by it? Do you have a suggestion on the wording of the comment?
<mzanetti> tsdgeos: no :D feel free to call me anything you want
<tsdgeos> oh wait you still think the code can't be fixed
<mzanetti> well, the main reason was the other comment
<tsdgeos> so problably no point on adding a comment
<tsdgeos> ok the other comment
<tsdgeos> mzanetti: you're right that that looks pretty dangerous and i guess it's only working because qtquick is doing some delayed connection of stuff somewhere, but adding a simple QMetaObject::invokeMethod with Qt::QueuedConnection fixes your issue, doesn't it?
<mzanetti> let me have a look
<mzanetti> tsdgeos: right... making setSourceSize invokable and onvoking that queed would probably do it
 * mzanetti tries again
<mzanetti> tsdgeos: right... making setSourceSize invokable and invoking that queued would probably do it
<mzanetti> ok, well then, thanks for explaining. Changing my vote to a needs fixing. Can you also please add a comment for the first question?
<mzanetti> tsdgeos: is the ignoreAbort really needed? I mean, if the future is working already, the reply is already finished and abort won't do anything any more, no?
<tsdgeos> mzanetti: it clears the data from the reply
<mzanetti> oh, really... didn't know that
<tsdgeos> me neither
<mzanetti> ok then it is needed indeed
<tsdgeos> got lots of interesting crashes/errors because of that
<mzanetti> I can imagine
<Saviq> tsdgeos, fun times http://pastebin.ubuntu.com/8938872/ :|
<tsdgeos> damn
<tsdgeos> Saviq: i guess we can't repro, no?
<Saviq> tsdgeos, actually we can, but it needs to be timed
<Saviq> tsdgeos, happens with mterry's branch to skip the second PIN unlock screen if emergency dialer is up
<tsdgeos> i see
<tsdgeos> if we can kind of repro this i don't think it'd be that hard to fix
<Saviq> let's see how often I can get this
<facundobatista> Hola!
<mzanetti> o/
<tsdgeos> mzanetti: any suggestion for the comment?
<tsdgeos> mzanetti: // worker->m_reply is always valid at this point
<tsdgeos> seems a bit weeak
<mzanetti> tsdgeos: yeah, elaborate a bit more please. something like: m_reply has finished at this point and won't be touched any more
<mzanetti> Saviq: can we do such changes in control files now or will that still break with ~rtm? https://code.launchpad.net/~seb128/unity8/set-inline-reply-hint/+merge/240766
<Saviq> mzanetti, it'd have to be "translated" to rtm, the upstream version should have been bumped instead
<seb128> mzanetti, I should append a ~ to the version
<Saviq> seb128, well, we need to be able to depend on that change in u-s-c
<seb128> oh, in fact there is no revision there
<seb128> so it should be fine
<Saviq> seb128, but > 20141105 in rtm might not include that change
<seb128> Saviq, mzanetti, we don't want those changes in rtm anyway
<Saviq> seb128, not now, but we'll have the same problem for ota
<seb128> we have a workaround for rtm
<seb128> Saviq, k, feel free to change it to suit your workflow better
<mzanetti> ok... works for me then... I just wanted to make sure as we broke the train with such things a couple of times already
<Saviq> seb128, https://code.launchpad.net/~seb128/ubuntu-settings-components/define-text-hint-property/+merge/240706/comments/593655
<seb128> Saviq, k
<tsdgeos> mzanetti: actually i'm not sure i can do the invokemethod thing, in my mind invokemethod with a delayed connection should be smart enough to not crash if the receiving object goes away, but i am reading the code and seems it is not :/
<tsdgeos> reading more
<tsdgeos> not a trivial amount of code
<mzanetti> tsdgeos: it is not
<mzanetti> tsdgeos: QPointer helps with that though
 * mzanetti digs out some code
<tsdgeos> sure, but i can't qpointerize Qt code ;)
<tsdgeos> yeah i can add yet another intermediate object
<tsdgeos> meh
<mzanetti> tsdgeos: https://gitorious.org/xbmcremote/xbmcremote/source/44687da6c75326be456d5778d728afcbf1a2386e:libxbmcremote/imagecache.cpp#L167
<mzanetti> tsdgeos: you'd just need to hold the target in a QPointer yourself. the data will be smart enough to go to 0 which in turn makes the invoke smart enough
<mzanetti> invoke just fails if you have a valid address for an invalid object
<tsdgeos> qt should add the qpointer in QPostEvent
<mzanetti> yeah, I guess it should
<mzanetti> not sure about other ramifications with that though
<tsdgeos> but i guess it would be slower
<tsdgeos> hmmm
<tsdgeos> i don't see how that works at all
<mzanetti> the code I linked?
<tsdgeos> yeah, i mean .data() returns a qobject no?
<mzanetti> or 0 if it went away
<tsdgeos> sure
<mzanetti> yeah, invokeMethod(0) doesn't do anything
<tsdgeos> but the problem is if it goes away *after* i call invokeMetho
<tsdgeos> not before
<mzanetti> uh oh
<tsdgeos> before i know it's there
 * mzanetti thinks about it
<tsdgeos> i have a mutex for that :D
<mzanetti> A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he
<greyback> I've always worked under the assumption that invoke doesn't watch the lifetime of the object you pass it
<mzanetti> greyback: it doesn't
<greyback> well I've been right all this time so :)
<mzanetti> greyback: the problem we're facing now is that even though we watch it ourselves, there might be the possibility of it going away in between we call invoke() and it actually happening
<mzanetti> tsdgeos: well, signal/slot connection otherwise, that should be clever enough to disconnect it/ check it when it actually happens
<greyback> mzanetti: yep. signal/slot ideal then
<tsdgeos> mzanetti: on the other hand http://paste.ubuntu.com/8940082/ works just fine
<tsdgeos> and valgrind does not complain at all
<tsdgeos> so it seems indeed somewhere is seeing that has to remove the post
<mzanetti> does invokeMethod use postEvent in the end?
<tsdgeos> yep
<tsdgeos> if it's a queued one
<mzanetti> hmm. ok. then I guess we're good. also I didn't have any troubles with that xbmcremote code I posted above. and it's been in use for quite a while now
<tsdgeos>         QCoreApplication::postEvent(object, new QMetaCallEvent(idx_offset, idx_relative, callFunction,
<tsdgeos>                                                         0, -1, nargs, types, args));
<mzanetti> tsdgeos: you still need the QPointer before the invokation though as it will break passing an invalid address
<tsdgeos> now i want to read the code again to see where it's removing it from the even list
<tsdgeos> mzanetti: no i don't
<mzanetti> or well, some other means of making sure it's there
<tsdgeos> it's guaranteed the pointer is valid at that point
<mzanetti> ok
<tsdgeos> ah right qobject destructor does
<tsdgeos>     if (postedEvents)
<tsdgeos>         QCoreApplication::removePostedEvents(q_ptr, 0);
<tsdgeos> so yeah we're good
<mzanetti> aha! cool
<tsdgeos> so basically you need to guarantee the object is valid until the end of the invokeMethod Queued call
<tsdgeos> after that you're fine filling it
<tsdgeos> killing it
<mzanetti> yep
<Saviq> cwayne, hey, can you assign bug #1389192 somewhere?
<ubot5> bug 1389192 in unity8 (Ubuntu) ""Fitbit" text in Dashboard has poor grammar, capitalization, punctuation, and call to action" [Undecided,New] https://launchpad.net/bugs/1389192
<Saviq> and bug #1389195
<ubot5> bug 1389195 in unity8 (Ubuntu) ""Fitbit" section in Dashboard goes to a near-empty screen when tapped" [Undecided,New] https://launchpad.net/bugs/1389195
<mzanetti> dednick: hey, is this still needed? https://code.launchpad.net/~nick-dedekind/unity8/axis.calculator.first.position/+merge/174262
<cwayne> Saviq: ugh, i marked invalid, will do so again and move to hanloon
<ragnarock> Hi guys ,I am facing some screen issues in my asus x550l 14.10.can I contact  to someone for support and fixing this thing
<Saviq> cwayne, yeah, I know you did, but Matthew just re-confirmed it again, don't we have a public project that we could assign to?
<cwayne> Saviq: no because it's a private scope
<Saviq> :/
<cwayne> Saviq: i just logged the same bug in hanloon and marked this one invalid
<Saviq> cwayne, sounds like it's gonna ping-pong back to you
<Saviq> or well, me
<cwayne> Saviq: i commented with the new bug url
<Saviq> ok thanks
<cwayne> sorry, just get mad that i talked to him on irc and told him this was a private scope that shouldn't have public bugs, bit frustrating when people don't listen
<Saviq> mzanetti, I noticed recently that BFB does not reset the dash to apps properly any more if you have a temp scope open (e.g. store)
<Saviq> works if you're in/over Manage Scopes, but not otherwise
<Saviq> mzanetti, I also had a feature proposal for Tagger - would be nice to have a history of recognized codes, otherwise I had to take photos and then try and recognize them after (which didn't always work depending on how the photo came out)
 * Saviq goes back to filing bugs
<dednick> mzanetti: hm. nope, that's kinda old
<mzanetti> Saviq: ok, yeah, please file some bugs, will implement it when I touch tagger the next time
<mzanetti> Saviq: can we drop this? https://code.launchpad.net/~saviq/unity8/fox-clock-formatting/+merge/198843
<mzanetti> its from 2013 too
<Saviq> mzanetti, done
<Saviq> mzanetti, I got stuck on lockscreen, no crash, did you get anywhere with investigating that?
<mzanetti> let me find the bug
 * Saviq is installing dbg symbols right now, but there's a suspect "recvmsg" in the top thread
<mzanetti> hmm, interesting
<mzanetti> Saviq: so I personally only ever saw this when being away from a computer
<tsdgeos> damn, it's a pain that vivid and rtm are not compatible
 * tsdgeos flashes mako with vivid
<tsdgeos> devel-proposed is now vivid, right
<tsdgeos> ?
<Saviq> tsdgeos, yes
<mhall119> Trevinho_: ping
<mhall119> Trevinho_: bregma: we still don't have any session on Unity 7 for UOS
<mhall119> I think, given the more user/consumer focus of UOS, that we really should have a session on how to use (and get the most out of) the current default desktop
<mhall119> kgunn: we also have no session on Mir, which I think we really need both to talk about what currently works (screenshots now in Unity 8, which is awesome) as well as what's planned for the future (especially concerning desktop feature support)
<kgunn> mhall119: i lost connection for a bit....so what's the also
<mhall119> kgunn: we also have no session on Mir, which I think we really need both to talk about what currently works (screenshots now in Unity 8, which is awesome) as well as what's planned for the future (especially concerning desktop feature support)
<mhall119> kgunn: before the "also" was be asking Trevinho_ and bregma for Unity 7 sessions
<mhall119> kgunn: there's a lot of confusion and open questions about what desktop features Mir will support, UOS is a great opportunity to clear tha tup
<kgunn> mhall119: i proposed this
<kgunn> http://summit.ubuntu.com/uos-1411/kgunn72/meetings
<kgunn> if i could thurs late morning that'd be great
<mhall119> kgunn: thanks, I've added it to the Ubuntu Development track
<mhall119> will ping those track leads to review it
<kgunn> mhall119: i figure i'll show up with a semi-scrubbed roadmap and just talk thru with some time for Q&A
<mhall119> kgunn: sounds like a plan, thanks
#ubuntu-unity 2014-11-12
<tsdgeos> Wellark: is there any reason unity-action-api still uses libhud?
<larsu> what ever happened to the hud?
 * larsu guesses people forgot about it
<tsdgeos> larsu: it's gone
<tsdgeos> we don't ship it in krillin anymore
<tsdgeos> the app itself
<tsdgeos> we still ship libhud2 because  unity-action-api links against it
<tsdgeos> but wihtout the binary i'm not sure if it's needed (maybe it is)
<larsu> are there any plans to resurrect it or is it gone for good?
<tsdgeos> no idea tbh
<seb128> mzanetti, tsdgeos, commented on bug #1391617, it seems that the uitk should use dtr("ubunntu-ui-toolkit"... since the string should be loaded from that domain and not from the application one
<ubot5> bug 1391617 in Ubuntu UI Toolkit "Untranslated label "In Progress" when upgrading system" [Undecided,New] https://launchpad.net/bugs/1391617
<tsdgeos> seb128: ah it may be
<seb128> tsdgeos, I tested that editing the file and using dtr makes the string translated on screen
<tsdgeos> :)
<Saviq> tsdgeos, huh, that's surprising:
<Saviq> property alias image: image
<Saviq> [...]
<Saviq> Image {
<Saviq>   id: image
<Saviq> how's that work?!
<Saviq> ;)
<tsdgeos> namespacing in QML is an amazing thing
<tsdgeos> that's my answer
<tsdgeos> but i agree we could make it a bit better
<tsdgeos> where's that from?
<Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity8/croppedImageSizer/+merge/239832
<Saviq> tsdgeos, no, TBH if that works I like it, no point in having an explicit prop
<Saviq> tsdgeos, just never thought that would work
<tsdgeos> Saviq: well you need the property to expose it to children
<tsdgeos> err
<Saviq> tsdgeos, yeah I know
<tsdgeos> i mean to outside users of the thing
<Saviq> tsdgeos, but I mean that I'd never have tried an alias to an object (vs. a property)
<tsdgeos> ah
<tsdgeos> sure that works
<Saviq> sounds like an undocumented feature
<tsdgeos> i thought you were complaining about the
<tsdgeos> image: image
<Saviq> ah well, that, yeah
<tsdgeos> let me change that
<tsdgeos> and call it innerImage
<tsdgeos> or _image
<tsdgeos> or something
<tsdgeos> done
<Saviq> Cimi, I'm building an rtm silo with all the dash things, it seems to creep up the priority ladder
<mzanetti> seb128: ack, thanks
<Saviq> mzanetti, as discussed, bug #1391798 for you
<ubot5> bug 1391798 in unity8 (Ubuntu) "Left-edge / home does not close temporary scopes" [High,Triaged] https://launchpad.net/bugs/1391798
<mzanetti> Saviq: ack
<Saviq> mzanetti, and the tagger one bug #1391799
<ubot5> bug 1391799 in Tagger "Should have a history of recognized codes" [Undecided,New] https://launchpad.net/bugs/1391799
<mzanetti> cheers. will add it
<mzanetti> Saviq: would the content be enough or do you want the image too?
<Saviq> mzanetti, image a nice addition, but obviously content most important
<Saviq> mzanetti, not even sure image needed at all, after all you rarely get any context in the image
<mzanetti> you can always regenerate the code from the image too
<Saviq> yeah, it's only what would be around the code that could warrant keeping the image
<mzanetti> err, the other way round. if you have the content, tagger lets you generate a code image
<mzanetti> yeah
<Saviq> mzanetti, I think if you actually wanted the image, just take it with the camera (only caveat is that you might fail to recognize it later)
<Saviq> tsdgeos, should I add your most recent branch to the test silo for this?
<Saviq> i.e. is it ~working yet?
<tsdgeos> Saviq: not sure how safe it is
<tsdgeos> Saviq: let's not add it yet
<Saviq> ok
<tsdgeos> Saviq: you're right, i only need m:source and not width and height, problem is that doing it your way may make the code a bit more complex, but let's try it anyway and see what i get
<Saviq> tsdgeos, it's a Needs Information thus
<Saviq> tsdgeos, a TODO would be enough
<tsdgeos> let me have a look
<Saviq> brb
<facundobatista> Holas
<Saviq> o/
 * mzanetti upgrades internet connection... might be offline for a bit
<tsdgeos> Saviq: i've pushed a change to croppedimagesizer so that it's the source that triggers the network request
<tsdgeos> Saviq: have a look plz
<tsdgeos> meaning i'll have to merge the async version one now
<tsdgeos> fun times :D
<tsdgeos> Saviq: i think you were right, now it looks nicer
<Saviq> tsdgeos, meaning it actually changed things visually
<Saviq> ?
<Wellark> tsdgeos: sorry, out sick today.
<Wellark> but to answer your question: hud is still running
<Wellark> nobody has made the decision to discontinue it
<larsu> Wellark: this seems to be a bit of a pattern...
<mzanetti> Saviq: is it possible that a temp scope opens another temp scope, and if yes, will they be stacked or replaced?
<Saviq> mzanetti, replaced
<mzanetti> thanks
 * greyback has errand to run, back in ~1 hour hopefully
<Saviq> tsdgeos, hmm, no sourceSizeChanged at all?
<tsdgeos> Saviq: where?
<Saviq> tsdgeos, ah /me blind
<Saviq> tsdgeos, you refactored into setSourceSize
<tsdgeos> yeah
<Saviq> tsdgeos, just a small nitpick to rename updateImageSize
<mzanetti> mterry: hey, you were right. it was racy. seemed to work on my krillin, but not on mako
<mzanetti> or the other way round. don't remember
<mterry> mzanetti, I tried your updated version and approved
<mzanetti> cool, thanks
<tsdgeos> MacSlow: what do you think about http://paste.ubuntu.com/8965722/ ?
<tsdgeos> it bothers me that you use anchors to set the size
<tsdgeos> and then unset the anchors so you can move it
<MacSlow> tsdgeos, what better solution do you suggest?
<tsdgeos> MacSlow: my suggestion in form of http://paste.ubuntu.com/8965722/
<qengho> compiz (core) - Info: Unity is fully supported by your hardware.
<qengho> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<qengho> Covering all the bases, I guess.
<Saviq> tsdgeos, you got a tag in your branches, please strip
<tsdgeos> damn
<tsdgeos> Saviq: is it 0.1.16 ?
<tsdgeos> it magically appears from nowhere
<Saviq> tsdgeos, no, ~aacid/unity8/photoscopeimprovements
<Saviq> 8.00+14.10.20141013.2-0ubuntu1
<Saviq> stoopid c/p
<Saviq> mzanetti, will you follow up on lp:~aacid/unity8/asyncCroppedImageSizer please
<tsdgeos> ok
<mzanetti> Saviq: yep, wanted to wait for jenkins to build packages to test it
<Saviq> mzanetti, they're in silo
<mzanetti> oh
<Saviq> mzanetti, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-008
<mzanetti> ack, will test now then
<Saviq> mzanetti, and http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-011
<tsdgeos> Saviq: that tag is fine
<Saviq> tsdgeos, interesting
<tsdgeos> photoscopeimprovements$ bzr tags | grep 8.00+14.10.20141013.2-0ubuntu1
<tsdgeos> 8.00+14.10.20141013.2-0ubuntu1 1365
<tsdgeos> MacSlow: test fails in that branch
<MacSlow> tsdgeos, that's odd
<MacSlow> looking into it now
<Saviq> tsdgeos, wonder why my script wants to strip this then
<Saviq> tsdgeos, ignore thus
<tsdgeos> Saviq: don't know
<MacSlow> tsdgeos, hm... make -C builddir testNotifications works fine here
<MacSlow> tsdgeos, do you have output of the failure you're seeing?
<tsdgeos> MacSlow: are you merged with trunk?
<MacSlow> tsdgeos, certainly
<MacSlow> tsdgeos, two days ago
<tsdgeos> MacSlow: http://paste.ubuntu.com/8966214/
<MacSlow> tsdgeos, hm...
<pstolowski> tsdgeos, ping
<tsdgeos> pstolowski: hi
<pstolowski> tsdgeos, hey! thostr_ asked me to target our manage dash changes for this week
<tsdgeos> pstolowski: you'll have coordinate with Saviq i'm out the rest of the week
<thostr_> pstolowski: not getting live this week
<thostr_> but rather prepare everythign so that we just need to push the one magic button
<pstolowski> thostr_, ah, ok, so just a silo
<thostr_> pstolowski: yes
<pstolowski> tsdgeos, ok thanks
<tsdgeos> pstolowski: or with kgunn
<tsdgeos> i think there was a silo already somewhere
<MacSlow> tsdgeos, just merged with branch again... still all notification-tests pass
<tsdgeos> MacSlow: have you tried looping it?
<MacSlow> tsdgeos, no
<kgunn> tsdgeos: pstolowski thostr_ i do have the branches in a vivid silo
<kgunn> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=018
<kgunn> tsdgeos: pstolowski ^ failed to build...but hadn't looked at why
<tsdgeos>  1 FAILED TEST
<tsdgeos> RegistryObject::ScopeProcess::on_process_death(): Process for scope: "testscopeA" exited
<tsdgeos> pstolowski: â ?
<mzanetti> tsdgeos: what's the best way to test the asynccroppedimageresizer?
<MacSlow> tsdgeos, did you make soure you have latest trunk of lp:unity-notifications installed?
<tsdgeos> MacSlow: maybe not ^:^
<tsdgeos> mzanetti: do you have the custom build photo scope?
<MacSlow> tsdgeos, latest is r224
<MacSlow> tsdgeos, btw... looped testNotifications 20 times... all pass
<mzanetti> tsdgeos: doesn't look like
<pstolowski> tsdgeos, can you link complete log file?
<tsdgeos> pstolowski: sure
<tsdgeos> pstolowski: https://launchpadlibrarian.net/189709804/buildlog_ubuntu-vivid-i386.unity-scopes-api_0.6.8%2B15.04.20141110-0ubuntu1_FAILEDTOBUILD.txt.gz
<tsdgeos> MacSlow: ok, i'll go back to it in a sec
<MacSlow> tsdgeos, sure... got the async stuff still too keeping me busy otherwise :)
<pstolowski> tsdgeos, ah, we have been observing sporadic failures on i386 and there were fixes for that, i'm not sure if they landed. unrelated to the changes anyway
<tsdgeos> Saviq: mzanetti: https://code.launchpad.net/~aacid/unity8/make_cmake_happy/+merge/241574
<mzanetti> ack, testing
<mzanetti> anyone knows what the replacement for "ubuntu-device-flash --list-channels" is?
<mzanetti> ah... found it
<mzanetti> tsdgeos: is line 8 in that diff intentional?
<mzanetti> tsdgeos: or a leftover from the asyncimageresizer?
<tsdgeos> it is intentional
<mzanetti> it will conflict with that though
<mzanetti> and the imageresizer is in a silo already
<tsdgeos> it actually won't
<tsdgeos> since i didn't add that line in the asyncimageresizer :D
<tsdgeos> oh i did
<tsdgeos> :D
<mzanetti> ;)
<tsdgeos> it's the same change
<tsdgeos> should be smart enough to merge cleanly
 * tsdgeos tries
<tsdgeos> mzanetti: merges fine here
<mzanetti> ok
<tsdgeos> mzanetti: there's a problem somewhere in the async code
<tsdgeos> having a look
<tsdgeos> hmmm
<tsdgeos> pstolowski: did you guys just land stuff that makes unity8 not compile?
<tsdgeos> or is it me
<pstolowski> tsdgeos, unlikely
 * tsdgeos is confused
<pstolowski> tsdgeos, how does it fail?
<tsdgeos> it complains about moveFavoriteTo not being there
<tsdgeos> but that is the new thing we have yet to add
<tsdgeos> and i'm not using it in this branch
<tsdgeos> ah
<tsdgeos> nothing that a clean build can't fix
<tsdgeos> pstolowski: sorry :D
<pstolowski> tsdgeos, ah, ok, np :)
<mzanetti> paulliu: https://code.launchpad.net/~paulliu/unity8/lp1379384/+merge/238986
<paulliu> mzanetti: ok. thanks
<tsdgeos> mzanetti: false alarm it was a miscompilation here, but there's a test that fails on jenkins
<tsdgeos> trying to loop it and see if it fails
<tsdgeos> mzanetti: can you run make testCard there and see if it fails for you?
<mzanetti> ack
<tsdgeos> mzanetti: ok, tehre was actualyl a bug, just pushed
<tsdgeos> MacSlow: back to your thing
<MacSlow> tsdgeos, ook
<tsdgeos> i can still get the test to fail every single time
<tsdgeos> do i need any other branch of what's there on vivid?
<MacSlow> tsdgeos, no... just that branch, unity-notifications trunk and that's it
<tsdgeos> then i do not understand what's going on
<mzanetti> tsdgeos: yep, makes more sense now with the setting of m_worker
<tsdgeos> MacSlow: i don't even need to loop it, just fails every time
<MacSlow> tsdgeos, btw... the qmltests don't even need the backend (unity-notifications)
<MacSlow> tsdgeos, hm... really no clue what still could be wrong on your side... I started from scratch and did all qml-tests and usual manual tests... nothing fails here.
<MacSlow> tsdgeos, you're on vivid too I assume
<tsdgeos> yes
<MacSlow> tsdgeos, we need some third person to check
<tsdgeos> MacSlow: yeah
<tsdgeos> or jenkins
<MacSlow> tsdgeos, just triggered another build
<greyback> bregma: unity8 works on my amd laptop. With unity8 alone installed, it was crashing on startup in QSensors, but I added the ubuntu-desktop metapackage, and now unity8 works!
<greyback> mouse cursor is a bit messed up tho
<bregma> still using hardware cursor maybe, at a guess
<bregma> greyback, is that installed from the ISO?
<greyback> bregma: originally installed from ISO yes, but then I added ubuntu-desktop
<greyback> before ubuntu-desktop, it was crashing. I'm not sure what I installed that fixed it
<bregma> sounds like a dependency is missing maybe
<greyback> yep
<greyback> think I logged a bug...
<mzanetti> mterry: https://code.launchpad.net/~mterry/unity8/we-are-at-least-beta/+merge/241615/comments/594455
<mterry> mzanetti, I did!
<mterry> huh
<mzanetti> don't tell me they're in trunk again
<mterry> mzanetti, it doesn't have them locally
<mzanetti> mterry: hmm... I branched that branch and ran ./build.sh
<mzanetti> no merge or nothing
<mzanetti> bzr tags shows all of the unity7 ones
 * mterry tries that
<mterry> mzanetti, when I run ./strip-u8-tags.py it doesn't return anything.  Maybe my script is out of date
<mzanetti> mterry: does "bzr tags" list them?
<mzanetti> here's my script: http://paste.ubuntu.com/8973863/
<mterry> mzanetti, I don't think so... I forget exactly which ones are banned.  Let me show you mine
<mterry> mzanetti, http://paste.ubuntu.com/8973871/
<mzanetti> this is what I get: http://paste.ubuntu.com/8973872/
<mzanetti> yeah... your's is bad too
<mzanetti> should only be 7.84 to 8.01
<mzanetti> all those 0.x, upstream etc are from unity7
<mzanetti> basically everything with a ? is bad
<mterry> mzanetti, the strip-u8-tags.py from https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8 doesn't do anything with my branch
<mterry> so maybe the script needs fixing
<mzanetti> indeed... the script doesn't complain here either
<mzanetti> not even on the local checkout I have
<mzanetti> so yeah, there seems to be something the script doesn't catch
<mzanetti> mterry: trunk is still good though
<mzanetti> or Saviq cleaned it already again
<mterry> So I wonder how I got those.  I branched that today
<mterry> Probablye he cleaned today
<mzanetti> yeah. I saw him and Albert talking about tags today
<mzanetti> so probably we had an incident and you branched that minute
<mzanetti> still odd that the script doesn't catch it
<Saviq> mzanetti, the script has a hardcoded list, I didn't spend the time to implement a "is this tag valid? drop, if not" feature, although that probably makes sense, would be more versatile
<Saviq> .NET X-platform, now that's an interesting turn of events
<mzanetti> yeah... seen sabdfl's talk today?
<mzanetti> that was one of the topics
<mzanetti> the new CEO runs all over the place with slogans like "Microsoft loves Linux" for a while already
<Saviq> no, did not see
#ubuntu-unity 2014-11-13
<penghuan> hi, i'm running unity8-desktop-session-mir on ubuntu 14.10, where can i get the log for unity8?
<Saviq> penghuan, ~/.cache/upstart/unity8.log
<liuxg> does anyone know why I got "terminate called after throwing an instance of 'std::length_error'" when i try to a http request using "request->execute(
<liuxg>                     bind(&Client::progress_report, this, placeholders::_1))"??
<liuxg> I am actually following the SDK scope template. In the past, the same code did not have the problem.
<liuxg> my code is at bzr branch lp:~liu-xiao-guo/debiantrial/chinaweatherbad
<penghuan> Saviq, thanks!
<seb128> bah, unity-dash segfault on current rtm
<Saviq> seb128, got .crash?
<seb128> Saviq, yeah, got that
<seb128> it worked for once!
<seb128>     msg=0xb3ff902c "UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is\nrunning, and the correct socket is being used and is accessible. The shell may have\nrejected the incoming connectio"...)
<seb128> that happened after click "back" on the nearby lens, which was taking time to exit, while it was not done yet poping from that one I right edge swiped
<seb128> not easily triggerable using those steps though
<Saviq> seb128, iiinteresting, wonder what that message actually means (could it time out, too)
<Saviq> ugh
<mzanetti> does screen backlight control still work for you guys in vivid?
<mzanetti> desktop, that is
<mzanetti> both, screen and kbd backlight control are gone for me
<mterry> mzanetti, doesn't work as well no
<mterry> mzanetti, no notifications but I think I notice some dimming happening
<mzanetti> no dimming here
<mzanetti> makes me blind at night
<mterry> mzanetti, oh btw, so what's my best solution to the tag nonsense from yesterday?  Fix the script?
<mzanetti> and no keyboard backlight. given I'm already blinded by the scree I then fail to find keys :D
<mzanetti> mterry: yeah, fixing the script would be way to go I guess
<mterry> mzanetti, Saviq: and we ultimately want to drop any tag with a question mark (any bad tag)?
<Saviq> mterry, yeah, if possible
<mzanetti> mterry: hmm... not necessarily... there are situations where valid tags have question marks
<mzanetti> although not sure if one runs the script in those situations
<mterry> Saviq, mzanetti: OK, how about http://paste.ubuntu.com/8987706/ ?  It deletes any bad tag, and avoids the hardcoded list
<Saviq> mterry, sounds like something I wanted to do soon, too ;)
<mzanetti> looks reasonable
<Saviq> mterry, it looks much slower though?
<mterry> Saviq, it's slower yes, but takes a second or two on my machine if doing nothing
<Saviq> mterry, I mean on remote branches
<mterry> Saviq, oh goodness I bet that is slower
<Saviq> mterry, it took like 15s to do it on lp:unity8
<mterry> Saviq, I tend to run locally
<Saviq> mterry, but that doesn't help
<Saviq> mterry, once you pushed
<Saviq> mterry, you can't push a tag deletion
<Saviq> mterry, you need to delete it remotely
<mterry> Saviq, well ok this is slower then.  But it seems to be doing the minimum necessary...
<mterry> At least I don't know enough about bzrlib to know a more optimal way
<Saviq> mterry, yeah, I wonder if you can do something to cache it or something...
<Saviq> mterry, if you care, try and see what you can improve on the script, I'll try later as well
<mterry> Saviq, or maybe just use this logic to expand the hardcoded list
<mterry> "caching the hard way"
<Saviq> mterry, it's a per-branch thing, not sure what can we do there, your approach seems the most flexible and future-proof, I just wonder if it can be made quicker
<Saviq> especially as I like to run it on all the MP'd branches from time to time
<mterry> Saviq, do we know a bzrlib expert?
<Saviq> mterry, wgrant comes to mind
<Saviq> at least he could point to someone else hopefully
<mterry> yar
<mterry> Saviq, asked in #ubuntu-devel
<Saviq> tx
<greyback_> Mirv: what are "qtbase-abi-5-3-0" and "qtdeclarative-abi-5-3-0" ?
<dandrader> dednick, ping
<dednick> dandrader: hey
<Mirv> greyback_: they are imaginary packages provided by libqt5core5a 5.3.0 and libqt5qml5 5.3.0 that get added as dependencies to a package automatically if the package uses private headers/symbols from anywhere qtbase/qtdeclarative. thus they reforce rebuilding all such packages (as included in my Qt landings) when Qt version is updated
<Mirv> greyback_: so the vivid's Qt 5.3.2 packages provide qtbase-abi-5-3-2 and qtdeclarative-abi-5-3-2 accordingly
<Mirv> optimally as little packages as humanly possible depends on them / uses private headers
<Mirv> so I hope eg. webbrowser-app will get rid of those
<greyback_> Mirv: I'm not sure what imaginary packages are - there are no such packages in the repo though
<dandrader> dednick, that fixed it http://bazaar.launchpad.net/~unity-team/unity8/shellRotation/revision/1445
<dandrader> dednick, do you see any potential problems with it
<dandrader> dednick, it's the same approach used for the Launcher
<greyback_> Mirv: my problem is we've a PPA (unity-team/demo-stuff) and installing anything we built recently fails like "qtubuntu-android : Depends: qtbase-abi-5-3-0 but it is not installable"
<Saviq> greyback_, rebuild it
<greyback_> Mirv: what do you suggest we try?
<greyback_> dandrader: ^ you heard the man
<Saviq> greyback_, you need to rebuild against -5-3-2 that got released into vivid now
<dednick> dandrader: yeah, i had in one of my initial branches. dont think there were any troubles. as long as it doesnt break anything else, i dont see any prob.
<greyback_> Saviq: "apt-cache search qtbase" doesn't list it though
<Saviq> greyback_, because it's virtual
<greyback_> is that because it's imaginary?
<Saviq> greyback_, yes
<greyback_> ok
<dandrader> greyback_, ok, I will trigger a rebuild of all the stuff in the PPA then...
<Saviq> â« apt-cache show libqt5core5a | grep -i Provides
<Saviq> Provides: qtbase-abi-5-3-2
<Saviq> greyback_, â
<greyback_> Saviq: yep
<greyback_> just not obvious to me
<Saviq> greyback_, that's because when we link to private bits, we need more than just "version 5" as there's no ABI guarantees
<greyback_> Saviq: sure, I understand why. I just find it hard to detect when packages are virtual
<Saviq> greyback_, and well, yeah, `apt-cache search qtbase-abi-5-3-2` will return the correct package
<Saviq> greyback_, you were just searching for one that wasn't there any more
<greyback_> huh
<Saviq> greyback_, -5-3-0 vs. -5-3-2
<greyback_> no I see that. But I didn't notice that "apt-cache search qtbase" actually returned libqtcore5a
<greyback_> so my bad
<Saviq> now you know :)
<Mirv> greyback_: that's why they are imaginary :) ie. they are "packages" that are "Provides:" from the real packages
<Mirv> greyback_: you need to rebuild qtubuntu
<Mirv> greyback_: if it's vivid and it was built before Qt 5.3.2 landed finally yesterday to release pocket
<greyback_> Mirv: yep all clear now. Rebuild being done
<Mirv> I see, Saviq explained it
<Saviq> Mirv, btw, where do those come from when building? is it some hook to dh_shlibs?
<Saviq> or in .symbols in fact?
<Saviq> couldn't this be solved via .symbols?
<Mirv> Saviq: it's black magic. yes, dh_shlibdeps/dpkg-shlibdeps using /var/lib/dpkg/info/*.symbols
<Mirv> Saviq: so this is defined in the symbols of qtbase + qtdeclarative - private symbols are marked as such, and they give the dependency
<Mirv> it gets even more complicated with rsalveti's true black magic of the gles twin packages on x86. I manage to mess it up a bit every time despite practice.
<Mirv> so certain GLES symbols are specially marked as depending on normal libs on non-x86, and the twin packages instead on x86
<Mirv> hurray whenever Qt gets runtime switching between GL and GLES
<Saviq> indeed :)
<mzanetti> mterry: https://code.launchpad.net/~mterry/unity8/we-are-at-least-beta/+merge/241615/comments/594728
<Saviq> mzanetti, that doesn't matter
<mterry> mzanetti, haha..  hrm
<mzanetti> Saviq: yeah, I know... but we should not use the script on trunk if that's what it does now
<mterry> mzanetti, you said you didn't want tags!  :)
<mzanetti> :D
<mterry> mzanetti, let me test latest version of script
<Saviq> mterry, already ran it on trunk ;)
<Saviq> and is fine
<mzanetti> hmm ok :)
<mterry> mzanetti, OK I think I updated tags on that branch correctly, using a merge from trunk
<mterry> mzanetti, I was using that branch as a guinea pig.  I could imagine one of my interim scripts borked it
<mzanetti> mterry: no worries... I just wanted to raise it, in case the script really destroys it
<mzanetti> ok
<mzanetti> mterry: approved
<mterry> mzanetti, w00t!  we're out of alpha!  :)
<mzanetti> mterry: after all we're 8.01 already
<mzanetti> first bugfix release after stable :D
<mzanetti> which I guess is true for the phone
 * vila_ is vila from a laptop setup for testing
<vila_> swift list --debug hangs
<vila_> meh, damn xchat, wrong channel, sorry for the noise >-}
<Saviq> lp:~mzanetti/unity8/performanceoverlay: would delete 7.85+14.10.20140428.2-0ubuntu1
<Saviq> lp:~mterry/unity8/greeter-profiles: would delete 0.1.16
<mterry> fixed
<mzanetti> the new script?
<mzanetti> or something I should fix in the branch?
<mterry> mzanetti, I think just tags that the new script caught
<Saviq> mzanetti, I'm just uploading the new script
<Saviq> mzanetti, http://people.canonical.com/~msawicz/unity8/strip-tags.py
<mzanetti> Saviq: so I should delete that tag?
<Saviq> mzanetti, it's an invalid tag on your branch, so yeah
<mzanetti> I wonder how that came in though, it's not something we got from uity7
<Saviq> om26er, can you please run â on lp:~om26er/unity8/show_password_on_label_tap, and any local unity8 checkouts you have (just pass the different branches as arguments)
<mzanetti> done
<Saviq> om26er, note you need to run the script on them all, pushing won't help to delete tags
<Saviq> @unity â new strip-tags.py script, one that works for any branch (not unity8-specific any more, thanks mterry!)
<Cimi> Saviq, what you mean not unity8 specific?
<Saviq> Cimi, you can use it for any random branch to clean invalid tags from it
<Cimi> Saviq, how do we know when tags are valid/not?
<Saviq> Cimi, the invalid ones don't relate to a revision
<Cimi> Saviq, moving this to CI?
<Saviq> Cimi, not a good place for it, no
<Saviq> we've had this discussion and have some ideas
<Cimi> yeah, doing it manually for every single branch is not ideal too...
<Cimi> Saviq, maybe just having CI checking for tags
<Saviq> Cimi, that's the thing, you don't need to do it manually, we should be able to not do it at all once all of us get cleaned up
<Cimi> it does not have to remove them, just complain
<Saviq> Cimi, basically, don't worry, I'll tell you
<Cimi> i like that :P
<josharenson> so since gdm doesn't work in 15.04, and lightdm has never worked for me, does anyone have any ideas? My login screen is just black now...
<zbenjamin> josharenson: kdm?
 * zbenjamin runs
<zbenjamin> josharenson: there is also XDM, Slim,lxdm
<zbenjamin> josharenson: ssdm also sounds interesting, its using Qt/QML
<josharenson> zbenjamin, ill try another dm
<zbenjamin> josharenson: you sure that this is not a xserver config/driver problem
<josharenson> I can get a desktop to show if I run startx (Xorg was already running), however unity doesn't start when I do this
<zbenjamin> meh :/
#ubuntu-unity 2014-11-14
<Saviq> om26er, how did you run the script? the tags are still there on your branch?
<Saviq> om26er, you need to actually pass the remote lp: reference to the branch, you can't clean them locally and push, as that will not change the tags remotely (and you'll pull them back again the next time you push)
<om26er> Saviq, aah, I ran the script on the local branch
<Saviq> om26er, yeah, you need to run it on both, tags in bzr are viral
<om26er> Saviq, it took a while. I ran the script on the branch.
<dandrader> MacSlow, hey
<dandrader> MacSlow,  how busy are you atm?
<dandrader> MacSlow, I wonder if you could help out with some notification bugs in the shellRotation branch
<MacSlow> dandrader, quite... but what's up?
<MacSlow> dandrader, sure... I need a break from that odd qmltest-issue anyway
<dandrader> MacSlow, awesome. so here are the bugs: https://docs.google.com/a/canonical.com/spreadsheets/d/140Icn5zcZwMvg1SONrwRKXYip-Pie7jtbEARpWwgxfw/edit#gid=0
<dandrader> MacSlow,  and this is the PPA: https://launchpad.net/~unity-team/+archive/ubuntu/demo-stuff
<dandrader> MacSlow, and the unity8 branch https://code.launchpad.net/~unity-team/unity8/shellRotation
<MacSlow> dandrader, so issues on line 11, 12 and 13
<dandrader> MacSlow, yes
<dandrader> MacSlow, and thanks!
<MacSlow> dandrader, I'll look into those... got already a guess what might be going on
<dandrader> MacSlow, nice. don't forget to update the bug status as you go
<dandrader> (assign to yourself, etc)
<MacSlow> dandrader, only in the spreadsheet? or do we have launchpad-entries for those too?
<dandrader> MacSlow, just the spreadsheet
<MacSlow> dandrader, why is that in a spreadsheet anyway?
<dandrader> MacSlow, because they're bugs in a branch that is not even up for review yet
<MacSlow> dandrader, aic
<dandrader> MacSlow, just push it to lp:~unity-team/unity8/shellRotation yourself
<dandrader> MacSlow, it's a ~unity-team  branch for that purpose
<MacSlow> dandrader, ok
<MacSlow> dandrader, I've pushed the fix for issue in line 11 and13
<MacSlow> dandrader, I can't reproduce the mentioned problem with the dropodwn (line 12)
<dandrader> MacSlow, awesome, thanks!
<dandrader> MacSlow, greyback_ reported it, ask him for details
<MacSlow> greyback_, how did you go about triggering the dropdown of an snap-decision (incoming-call) to go off-screen?
<greyback_> MacSlow: hey, I found with phone in landscape, if I brought up the sd-example-incoming-call example, there was a dropdown in it
<MacSlow> greyback_, correct
<greyback_> MacSlow: if I opened the dropdown, many of its contents went off screen
<greyback_> and I couldn't scroll them or anything
<MacSlow> greyback_, hm... that'll need some though by design... I just don't want to make it flickable (again) it used to be but then was meant to become rigid again.
<greyback_> MacSlow: ok. Could we get you to talk to the right designer about it?
<MacSlow> greyback_, dandrader:did you catch up with Design on shell-rotation bugs in general ?
<greyback_> MacSlow: we've not got that far just yet
<MacSlow> greyback_, I'd say James, Olga and Patrica
<MacSlow> dandrader, ^
<greyback_> since vesar is on leave, we're low in designer input
<MacSlow> that should be the next step imo
<MacSlow> greyback_, Olga andJames have much input regarding ux for notifications (incoming-call) and Patrica is the new overlord... so to say :)
<greyback_> ok, noted
<MacSlow> greyback_, I can't get the notifications to change orientation
<dandrader> MacSlow, what do you mean?
<MacSlow> dandrader, I can't get the expanded snap-decision to change orientation on the phone... it always sticks to portrait-mode
<dandrader> MacSlow, is it inside Shell.qml?
<dandrader> MacSlow, I mean, I child of Shell
<greyback_> MacSlow: works for me
<greyback_> I bring up a notification, then rotate the device. If foreground app supports rotation, then it rotates with the app
<MacSlow> greyback_, I tried that with the terminal... didn't change
<greyback_> MacSlow: try with webbrowser
<MacSlow> greyback_, no matter if I start the snap-decision before or after the web-browser changed orientation... it sticks to portrait
<greyback_> MacSlow: I dunno, you've the PPA installed? I just installed PPA, edited those .desktop files, and it worked
<MacSlow> greyback_, which PPA?
<MacSlow> greyback_, just the shellrotation PPA?!
<greyback_> MacSlow: https://launchpad.net/~unity-team/+archive/ubuntu/demo-stuff
<MacSlow> greyback_, reinstalling everything from that PPA now... just to besure
<MacSlow> greyback_, still nothing
<MacSlow> greyback_, I really don't know what else to try
<greyback_> dandrader|lunch: any idea?
<MacSlow> dandrader|lunch, greyback_: web-browser and system-ssettings do change orientation... but the notification never follows... it always sticks to portrait-mode.
<MacSlow> dandrader|lunch, greyback_: need to go on a quick errand... bbl
<taringen> hi i got problems with unity with a hidpi scale of 2 or higher and window resizing
<taringen> when i enlarge the window of a gtk3 app the right and buttom borders get corrupted borders
#ubuntu-unity 2014-11-15
<taringens> hi any experts on compiz out here?
#ubuntu-unity 2014-11-16
<webliberty> Unity with latest updates zoom text in !menus when Ctrl+"=" was pressed (Ubuntu 14.04 LTS) Who else has this problem?
<webliberty> no one has problems with Ctrl+"+"?
#ubuntu-unity 2015-11-09
<tsdgeos> Mirv: not sure if we told you or you did realize but the support for the audio roles landed in unity8
<Mirv> tsdgeos: I did realize it, and I've rebuilt it in 5.5.1 PPA and I would test it if xenial images were not broken (not sure if they would now be fixed already)
<Mirv> tsdgeos: anyway, it's excellent! a big landing you had.
<tsdgeos> yep :D
<tsdgeos> we roll like that
<Mirv> s/I did realize it/I did publish it/ ;)
<tsdgeos> dednick: did you see daniel's comment in https://code.launchpad.net/~nick-dedekind/qtubuntu/1493530-mimeData/+merge/272630 ?
<tsdgeos> mzanetti: what's the fate of https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 ?
<mzanetti> tsdgeos, I don't know...  I'll ping popey to get one of them merged
<mzanetti> popey, ^ :)
 * popey looks
<dednick> tsdgeos: no i havent
<dednick> Q_ASSERT? not so sure. it seems to call it with null every startup.
<popey> uh
<dednick> tsdgeos: or maybe not. i do keep getting a log message about null clipboard data
<dednick> cant remember where from though...
<dednick> probably server side
<tsdgeos> dednick: not saying he's right or nt, just saying "let's move it forward, he needs an answer" :D
<mzanetti> dednick, hey, any progress on the freezes Saviq reported?
<mzanetti> I had them quite often during the weekend
<dednick> mzanetti: no. i managed to get it to freeze a few times, but didnt have debug symbols. After i installed, i spent about an hour trying to reproduce it with no luck. I'll try again today.
<dednick> mzanetti: when i did get it to freeze, it seemed to be stuck in a loop. was getting loads of log messages from the card creator re "binding loop for height"
<dednick> but there's also another freeze which is happening (in trunk as well i think) where it will freeze for 5-10 seconds and come right again.
<dednick> mzanetti: does yours come right or keep locked?
<mzanetti> dednick, afaict it keeps locked until I open the right edge
<mzanetti> however, if it freezes for multiple seconds, there's the chance that I've just not been patient enough
<dednick> mzanetti: next time it happens can you try wait for a bit?
<mzanetti> ack
<mzanetti> dednick, happens like 5 times a day or so... at least over the weekend
<popey> mzanetti, I don't quite understand which of the two merges should land. there's another linked from that one, and loads of abstentions!
<mzanetti> popey, you decide :)
<Guest78101> mzanetti, same here on arale, constant freezing
<Guest78101> rc-proposed
<mzanetti> yep, rc-proposed
<QUESTION> omg LOL
<QUESTION> can i ask something??
<popey> !ask
<ubot5> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<QUESTION> :))
<davmor2> Guest78101: did you ask the question yet?
<dednick> tsdgeos: i've commented and pushed a change. I don't think we should be clearing the clipboard.
<tsdgeos> oki :)
<tsdgeos> i don't know enough about it tbh
<mzanetti> tsdgeos, ok, all branches merged
<tsdgeos> :)
<tsdgeos> mzanetti: i think you missed https://code.launchpad.net/~mzanetti/unity8/ubuntuanimations/+merge/276511 ?
<mzanetti> indeed
<dandrader> mzanetti, made so that https://code.launchpad.net/~dandrader/unity8/noStretchOnResize/+merge/274752 now does not depend on that qtmir branch anymore
<dandrader> mzanetti, so it can get merged independently
<mzanetti> dandrader, nic
<mzanetti> nice
<dandrader> mzanetti, it will take forever for the qtmir branch to get landed because of other outstanding branches that also change the same code.
<mzanetti> mhm
<dandrader> mzanetti, and I fear leaving that untiy8 branch hanging aroung as that part of the code (desktop window management) is under heavy development, so it can bit rot quite fast
<mzanetti> fair enough, yes
<mzanetti> tsdgeos, hey, https://code.launchpad.net/~aacid/unity8/dash_reset_instead_of_fatal/+merge/274363 links to an abandoned silo
<mzanetti> what's the status? should unity-scopes=8 be landed by us then?
<tsdgeos> mzanetti: pstolowski what happened with that silo?
<mzanetti> tsdgeos, the dash seems to freeze for a couple of seconds frequently since the last landing. any thoughts?
<tsdgeos> hmmm
<tsdgeos> not really let me check the log
<mzanetti> tsdgeos, seems to happen quite often when it is focused
<mzanetti> tsdgeos, only happening with the dash tho afaict
<tsdgeos> mzanetti: i can't find anything obvious
<tsdgeos> even though with the move to 1.3 there's lots of ubuntu shape changes
<pstolowski> mzanetti, tsdgeos i had to free that silo for now cause we were short on silos. will recreate it once aggregators are ready and i can land the feature
<pstolowski> mzanetti, tsdgeos feel free to land your branch with another silo
<tsdgeos> pstolowski: can't since you made me increase the dependencies :D
<pstolowski> tsdgeos, ah, indeed
<tsdgeos> pstolowski: so can i have the names of the branches that it depends on so i can list them in our MR?
<tsdgeos> mzanetti: do you do anything in special? or?
<mzanetti> tsdgeos, this is reproducible quite easily. just focus some other app, after a few secs go back to the dash and continuosly flick it up and down. after some few seconds it will freeze for like 10 secs or so
<mzanetti> tsdgeos, nothing in the logs :/
<tsdgeos> 10 seconds?
<mzanetti> something like that. not always the same amount
<tsdgeos> i thought you meant something like 0.2 seconds :D
<mzanetti> someties like 3 secs, but also have seen 20 too
<tsdgeos> ok, let me try to reproduce it here and i'll try to figure out what's wrong
<mzanetti> cool, thanks
<pstolowski> tsdgeos, https://code.launchpad.net/~stolowski/unity-scopes-shell/diff-updates/+merge/273554
<pstolowski> tsdgeos, and https://code.launchpad.net/~stolowski/unity-api/scope-activate-action/+merge/273557
<tsdgeos> ok, tx, mzanetti i've updated the branches
<Guest42341> tsdgeos, same thing as mzanetti here with arale on rc-proposed, the dash freezes for 2-10 sec
<tsdgeos> greyback_: what can cause this? â
<tsdgeos> qtmir.surfaces: MirSurfaceItem::dropPendingBuffer() surface = qtmir::MirSurface(0x2e1ce10) buffer dropped. 0 left.
<tsdgeos> mzanetti: â i get that as unity8 log when i see the freeze, can you confirm?
<greyback_> tsdgeos: if a surface is set visible=false, and app keeps drawing. We drop those new frames from the app to avoid blocking it
<mzanetti> interesting
<tsdgeos> greyback_: how can i know who 0x2e1ce10 belongs to?
<mzanetti> I think I saw this message even though the surface was visible
<tsdgeos> greyback_: is it possible there's a bug in there? i'm seeing it in conjunction with unity8-dash rendering "freezing" when on the front
<greyback_> tsdgeos: should be printed earlier in the log
<greyback_> tsdgeos: possible, sure.
<mzanetti> dednick, so looks like being occlusion related after all ^
<greyback_> dednick: you were trying to repro that last week ^^
<tsdgeos> greyback_: http://paste.ubuntu.com/13208991/ :/
<greyback_> mzanetti: occlusion is the act of setting surfaces visible=true/false
<mzanetti> yes. I know
<tsdgeos> greyback_: maybe i need to enable more logging?
<greyback_> tsdgeos: from high level, would indicate to me the MirSurfaceItem has visible=false, but app is still drawing somehow.
<greyback_> tsdgeos: there is no more to enable, we should improve that
<mzanetti> greyback_, yep. but the surface *is* visible. so seems like the occlusion branches tell MirSurface it would be not even though it is
<greyback_> mzanetti: a likely theory
<greyback_> I'm assuming this just happens randomly?
<mzanetti> greyback_, quite reproducible
<tsdgeos> it's randomly quite reproducible :D
<greyback_> dednick wasn't able to on Friday, playing around for a good hour
<tsdgeos> i mean you can't make it happen 100% but you can make it happen quite often
<mzanetti> greyback_, open some random app, keep it focused for a few secs, then switch to dash and swipe it up/down frequently. the dash will freeze
<mzanetti> definitely a good 90% hit rate here
<tsdgeos> i've a much lower hit rate
<tsdgeos> maybe 30%
<tsdgeos> but still "reproducible enough"
<mzanetti> krillin here
<tsdgeos> MX4 for me
<tsdgeos> maybe the speedness of the hw "helps"
<greyback_> mzanetti: please add that to the bug, would help
<greyback_> also what device? I suspect a race condition
<greyback_> yeah, my thinking
<mzanetti> greyback_, is there a bug report for it?
<greyback_> dednick ^ ?
<dednick> reading backlog
<dednick> i was getting those messages when the surface was visible in u8
<greyback_> dednick: which would make me suspicious. We shouldn't need to drop frames from a visible surface
<greyback_> only case that would happen is if client not respecting vsync and swapping faster than 60htz
<greyback_> and dash doesn't do that
<mzanetti> oh dear... OTA-8 final freeze is tomorrow
<tsdgeos> greyback_: mzanetti: dednick: so i leave the investigation in your hands? you probably can find a cause/cure faster than me in that area
<mzanetti> tsdgeos, yes, thanks for confirming tho
<dednick> i thought occlusion has landde?
<greyback_> tsdgeos: yep
<dednick> landed
<mzanetti> dednick, yes, it has, which is the issue with the OTA-8 freeze
<mzanetti> dednick, need to ship a fix by tonight I guess, or we'll have to revert
<dednick> mzanetti: ok
<ltinkl> cimi, if you want to review the new deco visuals, be my guest: https://code.launchpad.net/~lukas-kde/unity8/newWindowDecosAndPanel/+merge/276810
<tsdgeos> cimi: so https://trello.com/c/dNjca4ie/229-range-input-filter-widget is all good and ready for review?
<mterry> ltinkl, on your desktopFileActions branch, is there any concern about letting Touch apps define such extra actions and running code that way?
<ltinkl> mterry, right, this is intended more for existing desktop apps (chrome, libreoffice, ...)
<mterry> ltinkl, I know, but there's nothing in this branch restricting it to legacy apps
<ltinkl> mterry, not aware of any touch app that would use this currently
<ltinkl> mterry, it's restricted to the same binary currently (because of the security model)
<mterry> ltinkl, oh I don't see that restricting...
<ltinkl> mterry, but I think apps like the touch webbrowser might want to add a "New tab..." shortcut to its desktop file and handle that within the same instance/window
<mterry> ltinkl, yeah... I'm not worried about legitimate uses.  I'm thinking of malicious apps here
<ltinkl> mterry, in the MP, lines 387-394
<mterry> ltinkl, ah...  it uses app_id there, not the result of exec()
<ltinkl> mterry, I extract the args and pass it to the same binary
<ltinkl> mterry, yeah, it should be safe although the args splitting might be a bit naive
<mterry> ltinkl, my eyes glossed over that and assumed that first argument was the first exec token
<ltinkl> mterry, anyways, the MP could use a review ;)
<mterry> ltinkl, yeah I was about to comment on it, but wanted to talk with higher bandwidth first  :)
<ltinkl> mterry, worth noting I got rid of QSettings there... it was failing badly
<mterry> ltinkl, so now I'm less concerned about malicious apps.  But for a legitimate app, feels odd that I can just put garbage in the first token of the Exec line...
<ltinkl> mterry, yea... our sandboxing wouldn't allow launching another app anyway I bet
<mterry> ltinkl, well this is unity8 launching it.  I could imagine app "malicious.mterry" might try to launch another app like "good.ltinkl" if it was allowed to
<ltinkl> mterry, still I can think of good usecases: file manager, right click on a ZIP file, select "Extract to...", launches some archiver program
<mterry> ltinkl, so sandboxing isn't enough, we definitely should restrict it to same appId
<mterry> ltinkl, like your MP does
<ltinkl> mterry, yea
<ltinkl> mterry, but a I said, I could also think of valid use cases when one might want to launch another app
<mterry> ltinkl, but it just feels weird that "good.ltinkl" if it wants to use these actions has to put in some ignored token on the exec line (presumably its own executable, so maybe it doesn't matter).  But if they put in something else, they don't get any warnings, they just get a different executable than they expected running
<ltinkl> mterry, yeah, perhaps at least a warning would be in place?
<mterry> ltinkl, but that sort of cross-app dependency is not something our app ecosystem is ready for  :)  (unless they are core apps maybe?)
<ltinkl> mterry, dunno really, such cross deps should probably be handled by the content hub
<mterry> ltinkl, yeah.  I was just reiterating that it's good we don't allow launching other appIds right now  :)
<mterry> ltinkl, ok will really review your branch now  :)
<mterry> mzanetti, regarding QSettings vs gsettings for desktop parsing, I remember you looking into that in the past.  What was the story there? <- ltinkl
<ltinkl> mterry, it just failed to parse anything else than the [Desktop Entry] group for me
<mzanetti> mterry, so, QSettings can do it for simple things. If you need more complicated things, QSettings won't do
<ltinkl> mterry, also omitting some regular translated entries
<mterry> ltinkl, silly QSettings
<ltinkl> ah right, I remember
<mterry> mzanetti, yeah we had converted to gsettings already somewhere in unity8 right?
<ltinkl> it fell over when it encountered
<ltinkl> right to left text
<mterry> er... not gsettings.  But glib
<mzanetti> mterry, well, QSettings does not implement the .desktop file spec. It implements the .ini file spec, which happens to be a subset of the .desktop one
<ltinkl> indeed
<mterry> mzanetti, right
<ltinkl> Name[il]=this_is_right_to_left_text
<ltinkl> and QSettings is gone :)
<ltinkl> and doesn't parse anything past this point
<mterry> ltinkl, well looks like it's still used in ./plugins/Unity/Indicators/indicatorsmanager.cpp
<mterry> ltinkl, but that's for actual ini files I think
<mterry> So probably ok
<ltinkl> dunno that code
<ltinkl> mterry, qtmir having similar code is something to worry more
<mzanetti> mterry, ah, did the question arise when reviewing lukas' branch?
<mterry> mzanetti, yeah
<mterry> mzanetti, I was surprised that we still had QSettings code in there actually
<mzanetti> mterry, it was enough for what the launcher needed so far
<mzanetti> but not any more...
<mterry> cool
 * mterry is caught up  :)
#ubuntu-unity 2015-11-10
<tsdgeos> Mirv: ping
<tsdgeos> Mirv: unping
<Mirv> hmm
<tsdgeos> was going to ask about a patch in qtdeclarative, but it's clear i cna look up the patches myself without asking you
<tsdgeos> sorry _)
<Mirv> :)
<doubleDee> hi all, i am running gedit on mir but i see two mouse pointers
<doubleDee> a big one and a little one
<doubleDee> gedit on unity8
<doubleDee> interesting, closing gedit doesn't help/... i'm left with 2 mouse pointers
<tsdgeos> mardy: ping
<mardy> tsdgeos: pong
<tsdgeos> mardy: your "Don-t-change-the-currentItem-after-a-viewport-resize" breaks some other parts of listview :/
<tsdgeos> mardy: this code http://paste.ubuntu.com/13215032/
<tsdgeos> with your patch after removing item 0 we end up in item 1
<tsdgeos> without your patch we end up in item 0 as we should
<tsdgeos> do you have time to investigate?
<mardy> tsdgeos: yep, I'll have a look; do you have a bug filed for that?
<tsdgeos> it's basically https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1508260
<ubot5> Ubuntu bug 1508260 in unity8 (Ubuntu) "un-starring a scope jumps several scopes to the right" [Undecided,New]
<mardy> tsdgeos: interestingly, it doesn't happen if the animation is removed
<tsdgeos> mardy: ok cool, want me to open a bug in the qt bug tracker too since it's present in 5.6 that's going to be released "soon-ish"? maybe they want a revert instead the new feature
<tsdgeos> mardy: yep, i know
<mardy> tsdgeos: I'd appreciate if you opened a bug on the Qt bug tracker *without* asking for a revert, as that bug was kind of hard to work around
<mardy> tsdgeos: while fixing that bug I was thinking of touching other parts that were related to animations, but IIRC aalpert told me it was better to touch as little as possible, so I left them out
<mardy> tsdgeos: it may be that they would fix this issue
<tsdgeos> mardy: i'll create a unit test and post it to the qt bug report
<mardy> tsdgeos: excellent, that will help a lot
<tsdgeos> mardy: https://bugreports.qt.io/browse/QTBUG-49330
<tsdgeos> mardy: want me to assign it to you?
<mardy> tsdgeos: yes please
<tsdgeos> don
<tsdgeos> e
<mardy> tsdgeos: OK, I think I got a possible fix; now I need to clean everything up, update, and test your unit test (but the manual one you gave me before works)
<tsdgeos> nice :)
<mardy> tsdgeos: https://codereview.qt-project.org/#/c/140510/
<tsdgeos> nice :)
<popey> anyone else seeing random freezes in unity8-dash? ?
<popey> on rc proposed krillin
<popey> if i swipe away to another app and come back it refreshes
<popey> but frequently get a locked up dash with icons half loaded
<greyback_> popey: yes, known issue, fix passed QA, should land soon
<popey> greyback_, yay!
#ubuntu-unity 2015-11-11
<tsdgeos> mzanetti: what's your opinion about https://code.launchpad.net/~aacid/unity8/unfavorite_scope_test/+merge/277157 ? It introduces a test that fails with expectFail because Qt is buggy (mardy has a patch to fix it)
<tsdgeos> should we land that test now with the expectFail or wait until Qt is fixed?
<mzanetti> ah, is that the currentIndex on horizontal listview things
<mzanetti> tsdgeos, once Qt is fixed, would the expectFail start failing?
<tsdgeos> mzanetti: of course
<mzanetti> tsdgeos, in that case, we can commit it now
<tsdgeos> ok
<mardy> tsdgeos: do you know when 5.6 is going to be released?
<mardy> tsdgeos: actually, my question is: are we in a hurry with that fix, should I ping someone in IRC to review it, or do we have time?
<tsdgeos> mzanetti: the beta is out "now-ish"
<tsdgeos> er
<tsdgeos> mardy: ââ
<tsdgeos> so i guess it'd be good if we can get it in for the beta at least
<mardy> tsdgeos: OK, I'll ping someone
<tsdgeos> mardy: "We are targeting to put beta out as soon as possible, preferably already during next week. "
<tsdgeos> mardy: try fregl, he's one of the project/product managers on the Quick side afair
<jeembe> hi all
<jeembe> i get 2 mouse pointers when running gedit with gtk mir backend
<jeembe> even when if close gedit i'm left with 2 mouse pointers (2 diff sizes and positions)
<tsdgeos> dandrader: ping
<dandrader> tsdgeos, pong
<tsdgeos> dandrader: the xcursor thing we use is not X dependant at all i guess, no?
<dandrader> tsdgeos, no, it's not. it does use a library to load xcursors but its source code is in the plugin dir
<dandrader> tsdgeos, it's self-contained
<tsdgeos> dandrader: so it's not a problem to use a thread on that code (talking to X from a thread is usually crashy), right?
<dandrader> tsdgeos, yeah, loading xcursors is just regular file IO stuff, thread at will
<tsdgeos> good
<dandrader> tsdgeos, have to mind QQuickImageProvider API though
<tsdgeos> dandrader: that's what i was wondering, if it made sense to convert that QQuickImageProvider to the async version
<dandrader> tsdgeos, cursors are so small
<dandrader> tsdgeos, and they're loaded on demand
<dandrader> tsdgeos, although animated cursors comprise a good number of separate images
<dandrader> tsdgeos, all packaged in a single file though
<dandrader> (the animation frameS)
<dandrader> tsdgeos, but we have no support for animated cursos yet. although that xcursor lib might still load all frame into memory all the same
<dandrader> s/frame/frames
<tsdgeos> back
<tsdgeos> didn't see anything after "tsdgeos, although animated cursors comprise a good number of separate images"
<tsdgeos> dandrader: i said "yeah probably not worth increasing the complexity then until we actually find out it's a bottleneck"
<dandrader>  tsdgeos, all packaged in a single file though
<dandrader>  (the animation frameS)
<dandrader>  tsdgeos, but we have no support for animated cursos yet. although that xcursor lib might still load all frame into memory all the same
<dandrader>  s/frame/frames
<dandrader> tsdgeos, ^^^ that's what you missed
<tsdgeos> k
<greyback> dandrader: I'd quite happily accept your mouse cursor work, leaving app custom animated cursors for a later MP
<greyback> later feature not that high in my priority list
<dandrader> greyback, yeah, I was also thinking whether to have it in a separate MP
<ltinkl> dandrader, btw, what you mentioned about custom bitmap cursors, doesn't the QPlatformCursor already have a helper class to deal with those?
<ltinkl> dandrader, QPlatformCursorImage
<dandrader> ltinkl, the sole purpose of this class is to provide Qt's fallback, built-in, cursors
<dandrader> greyback, there you go https://code.launchpad.net/~dandrader/unity8/fallbackCursorNames/+merge/277288
#ubuntu-unity 2015-11-12
<dandrader> ltinkl, would you have time to review that https://code.launchpad.net/~dandrader/unity8/fallbackCursorNames/+merge/277288 (and related branches)?
<ltinkl> dandrader, yup sure, after I'm done with the new decos
<kgunn> dednick: just in case, you saw bug 1515356
<ubot5> bug 1515356 in Canonical System Image "After a boot the dash doesn't display until touched" [High,Confirmed] https://launchpad.net/bugs/1515356
<kgunn> ?
<dednick> kgunn: yeah.
<dandrader> ltinkl, ok, thanks. just make sure you claim them before you start (to signal you got them)
<ltinkl> dandrader, yup
<mterry> dandrader, we talked about a monitoring version of DDA, right?  Did we decide anything about its feasibility?  I'm going to start looking into that
<dandrader> mterry, well, DDA is getting moved to ubunut-ui-toolkit
<dandrader> mterry, let me find the branch....
<mterry> dandrader, yeah I remember hearing that
<mterry> thanks
<dandrader> mterry, this time it's actually happening :)
<dandrader> mterry, lp:~zsombi/ubuntu-ui-toolkit/migrate_unity8_gestures
<dandrader> mterry, it's almost top-approved
<mterry> dandrader, heh lots of reviewers
<dandrader> mterry, it's a lot of code
<mterry> dandrader, so at a wild guess, this will make it harder for me to trick it into merely monitoring
<dandrader> mterry, let me recap: you want the application to respond normally to the drag from the bottom edge, and at the same time you want unity8 drawing something on top of it, following the gesture?
<mterry> dandrader, basically yes (the drawing something on top of it will be instead, "fading something out as the drag progresses", but yeah
<dandrader> mterry, I guess for now we can modify unity8's DDA to have this "monitoring only" mode
<dandrader> mterry, and later, once untiy8 moves to uitk's SwipeArea, we propose that change to their code base
<dandrader> mterry, or, actually, propose the change and then move unity8 to use uitk SwipeArea
<mterry> dandrader, I'll look into how complicated the change is
<dandrader> mterry, shouldn't be. but it may take a while as you haven't seem the code before
<mterry> dandrader, yeah makes sense.  Good excuse to learn the code a bit  :)
<dandrader> mterry, and now that we know that we will have to move this change into uitk as well, extra care has to be taken on how to expose this in the public API
<mterry> dandrader, yeah, I can't just add toplevel properties called "bool mikesMonitorMode: true"
<dandrader> :-D
<mterry> But first, lunch!  :)
<dandrader> mterry, I think what you have to do in this mode is the following
<dandrader> mterry, not regiter candidacy for touch ownership with the TouchRegistry
<dandrader> mterry, but instead just register yourself as a watcher straight away
<dandrader> mterry, and once you recognize the gesture, do not request ownership over it or grab the touch
<mterry> dandrader, thanks!  will start looking there.  And bug you if I need a rosetta stone  :)
#ubuntu-unity 2015-11-13
<tsdgeos> Mirv: https://codereview.qt-project.org/#/c/140510/ has landed, can we get it asap?
<tsdgeos> mardy: cool â :)
<Mirv> tsdgeos: yes, mardy already noted it
<Mirv> tsdgeos: it's in silo 046 now
<tsdgeos> nice
<Guest42341> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515921
<ubot5> Ubuntu bug 1515921 in unity8 (Ubuntu) "2 mouse pointers when running gedit with gtk mir on Unity8" [Undecided,New]
<Guest42341> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515923
<ubot5> Ubuntu bug 1515923 in unity8 (Ubuntu) "black screen / unity8 freezes when clicking the menus inside gedit gtk mir" [Undecided,New]
<Mirv> tsdgeos: oh right, the DBus patches are another thing why it'd be nice to have Qt 5.6 in 16.04 LTS.
<tsdgeos> Mirv: totally
<Guest42341> 100%
<tsdgeos> Mirv: not sure if it was you or someone else asking but the 5.6 LTS is supposed to be for ~3 years
<Mirv> tsdgeos: someone else
<Mirv> tsdgeos: what do you think about switching to generic bearer plugin for 5.5? that would solve the most pressing network problems on 5.5. although it doesn't mean that the networking wouldn't need fixes later on, but if not doing something we're staying with 5.4...
<tsdgeos> Mirv: i have honestly not been following the discussion
<tsdgeos> switching from nm to generic?
<Mirv> tsdgeos: I think the reasons behind us switching to use NM bearer backend over a year ago were no completely correct.. the 3G connectivity problems were probably not because of that, but the remaining functionality with NM plugin is AFAIK more correct behavior when switching 3g or wifi on/off
<Mirv> tsdgeos: well bug #1508945 explains it, it was the "weather app" bug I reported but found out that it's just the apparmor <-> network manager problem getting worse in 5.5, and again the apparmor rules are not wanted to be relaxed.
<ubot5> bug 1508945 in qtbase-opensource-src (Ubuntu) ""Couldn't load weather data, please try later again!" with Qt 5.5.1" [Undecided,New] https://launchpad.net/bugs/1508945
<Mirv> since apparmor rule changes aren't allowed, one possibility is to trust other components to route network traffic correctly and use a generic bearer in Qt instead, since we don't want Qt controlling network-manager anyway
<tsdgeos> Mirv: for phone apps it might be sufficient yes
<tsdgeos> not sure making it the default "ubuntu desktop" wide makes sense though
<Mirv> tsdgeos: well it is what was default before. but with the newest patches it's also selectable.
<Mirv> tsdgeos: there's the slight problem with the current hard coding to NM that on desktop user might choose to not use NM...
<tsdgeos> sure
<popey> On Ubuntu phone in windowed mode, phone sat in landscape, if you open an app which forces portrait mode, or if you have such an app already open and click it with the mouse, the phone flips to portrait...
<popey> Shouldn't unity 8 ignore portrait .desktop file settings when in windowed mode?
<davmor2> popey: you'd hope so that would be no fun on a monitor
<popey> yeah, dunno what it does with an external display, we didn't have one handy
<tsdgeos> popey: i agree it's weird, i'd say open a bug
<popey> k
<ljp> Mirv: I wrote simple bearer plugin based on connectivity-api https://codereview.qt-project.org/#/c/140752/
<ljp> since the nm bearer plugin won't work due to app armor
<mterry> mzanetti, is there a known problem getting app icons in store on rc-proposed?
<mterry> If I go to a category I don't have cached icons for, they don't load
<mzanetti> mterry, hmm, no, not known
<mterry> Is it just me?
#ubuntu-unity 2015-11-14
<Mirv> ljp: great! I see it's already being mentioned in an e-mail thread where people are trying to come up with a plan on how to proceed with connectivity-api.
<ljp> :)
#ubuntu-unity 2016-11-14
<sil2100> Saviq: ping
<Saviq> sil2100, hey
<davmor2> Saviq: I'll tell you it's all your fault ;)
<pstolowski> mterry, hey, can you take a look at https://code.launchpad.net/~stolowski/unity8-session-snap/thumbnailer-fixes/+merge/310756 ?
<mterry> pstolowski: looking, thanks
<pstolowski> mterry, thanks!
<pete-woods> Saviq: hey. I'm planning to add a new indicator widget for etheret links, I just wanted to check if there were any big MRs is progress for that stuff?
<pete-woods> (doing the touch mode / desktop mode change)
<pete-woods> (or otherwise)
<mterry> pstolowski: so to see the bug before I test your MP, I need a scope that uses thumbnails.  Does the normal Music scope do that?  I'm seeing a Music scope with album art from 7digital
<mterry> pstolowski: or wikipedia?
<mterry> scope
<Saviq> pete-woods, yeah, please coord with Trevinho
<pete-woods> Saviq: right, I'm assuming that's a "yes" then :)
<Saviq> yes
<pete-woods> Saviq: in lieu of a reply yet, does this look like the right MR? https://code.launchpad.net/~3v1n0/ubuntu-settings-components/touch+pointer-styles/+merge/307447
<Saviq> pete-woods, yes, you can base on that
<pete-woods> Saviq: cool, that's really all need (I think)
<pete-woods> the change looks intelligable enough
<Saviq> pete-woods, can use https://bileto.ubuntu.com/#/ticket/2195 for reference, too
<pete-woods> Saviq: this is planned to land as soon as it's ready, right?
<pstolowski> mterry, the only scopes that use image://thumbnailer/ uris for art are music and videos and the problem would only be visible if you had local media files, which I'm not sure is possible to have atm with unity8 snap (due to mediascanner). I noticed the problem with the unity-scope-fake which uses a bunch of uris like this. so for testing i installed it in the unity8 snap
<mterry> pstolowski: hmm, I think we have a fixed mediascanner in silo 2129, though I haven't tested local media.  Let me try that...
<pstolowski> mterry, ah, cool, i didn't know that
<mterry> pstolowski: could use a review: https://code.launchpad.net/~mterry/mediascanner2/snap-root/+merge/310602
<mterry> I don't know if that fixes everything...  but it lets it run anyway
<Saviq> pete-woods, yeah, it's already under britney
<pstolowski> mterry, cool. i'm not familiar with mediascanner code, but that looks simple enough
<pete-woods> Saviq: awesome. will stop bugging you now :)
<mterry> pstolowski: heh, you mentioned it by name, so I assumed you were an expert  :P
<pstolowski> lol
<pstolowski> mterry, i'm pretty sure the problems I found with mime & gdk loaders are genuine. I added some debug to thumbnailer code and found out it considered PNGs to be "text/plain" (and ignored them); after fixing mime problem it failed when processing them clearly pointing at gdk pixbuf modules missing
<pstolowski> mterry, only thing I'm wondering about is what it didn't break any other stuff (especially the lack of mime data)
<mterry> pstolowski: yeah doing some digging, I *think* query-loader is run by dpkg hooks.  And I suspect the mime stuff is too.  So it does seem like something we should do.  But couldn't we also do query-loader like we do the mime stuff?  (i.e. as a static cache file in the snap, instead of HOME?)
<pstolowski> mterry, the generated loaders.cache file has absolute target paths in it (e.g. "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so")
<pstolowski> which makes me wonder if it's not going to break when snap is upgraded and the version in home is only generated once
<mterry> pstolowski: ugh yeah
<mterry> pstolowski: I'm testing my suggested changes to the mime updating code...  I can hit that bug by just noticing that mediascanner ignores my local music (wrong mime type)
<pstolowski> mterry, ah, good
<pstolowski> mterry, we could generate loaders.cache during the build, then (cough) postprocess it with sed..
<mterry> pstolowski: during run time?
<pstolowski> mterry, ah, gosh, you're right, we only know the final path at runtime. so no
<mterry> I mean... we do do that with the fonts file...
<mterry> It's not pretty
<pstolowski> eek
<pstolowski> mterry, i can't top-approve https://code.launchpad.net/~mterry/mediascanner2/snap-root/+merge/310602; apparently i'm community ;) . will need to ask jamesh
<pstolowski> mterry, i'm about eod. i'll continue working on this tomorrow morning to get rid of custom plugin and use postprocess.mk instead; not sure about gdk loaders yet, need to think about it
#ubuntu-unity 2016-11-15
<AndyChow_888> Hello. What does unity-panel-service consist of? It's using 7.9 GB GiB on my system, is this normal?
<AndyChow_888> I'm running a BTRFS balance, btw.
<duflu> AndyChow_888: It consists of code. Sounds like a leak. Please log a bug here: https://bugs.launchpad.net/ubuntu/+source/unity/+filebug
<AndyChow_888> Ok, reported as: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1641820
<ubot5`> Ubuntu bug 1641820 in unity (Ubuntu) "Memory leak" [Undecided,New]
<pstolowski> mterry, hey, just noticed your comment about gdk pixbuf after actually finishing it
<mterry> pstolowski: sorry  :(
<pstolowski> mterry, if you have a better solution feel free to push it
<mterry> pstolowski: well there is this cross-project shared script that sets up a lot of this stuff for us, and I figure we should use that to be on same page
<mterry> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific and others
<mterry> It happens to solve the mime and pixbuf stuff for us
<pstolowski> mterry, ah, right. i didn't think of looking there :/
<mterry> ltinkl: heads up, I just committed a change that uses the snapcraft-desktop-helpers bit and pulls in locales-all.  So your wizard branch should be unblocked I'd guess
<ltinkl> mterry, kk thanks, I'll merge in
<ltinkl> mterry, but it's blocked on the fact we don't quite agree what to show in the wizard (and uss), whether all the available locales or just those with translations
<mterry> tedg: with current fresh u8 snap, snaps aren't launching (but legacy apps are)...
<mterry> ltinkl: you mean u8 and uss disagree or there's a discussion somewhere among product people?
<ltinkl> mterry, u8 and uss will show the same stuff (as we reuse their plugin) but we had a discussion earlier with Saviq
<tedg> mterry: Man, you're screwing with me, I saw the notification while in another channel and couldn't figure out what was happening :-)
<tedg> mterry: Are they showing up in the scope?
<mterry> tedg: ye
<mterry> s
<tedg> Okay, I've just got the failed signal left to connect and then I can go back to getting these branches stable again. Stop adding things for a bit.
<mterry> tedg: error like "Executing XMir on PID: 478XMir has closed unexpectedly"
<tedg> Hmm, that's not good. Do you get a denial in U8 logs?
<mterry> tedg: looks like u8 just gets a "ApplicationManager::onProcessFailed" event -- no other related log messages about the failure
<mterry> ltinkl: you say "~/snap/unity8-session/current/.config/user-dirs.dirs has still values pointing to âx1â" -- I'm not seeing that...
<mterry> ltinkl: did you start fresh or is this some upgrade-from-old-version difficulty?
<ltinkl> mterry, not sure know, will have to try again, you did too many changes :p
<mterry> ltinkl: fair  :)
<mterry> progress!
<ltinkl> mterry, are you building on top of the ubuntu-app-platform?
<mterry> ltinkl: no...  not yet
<ltinkl> mterry, the diff now looks more sensible :) https://code.launchpad.net/~lukas-kde/unity8-session-snap/locale-fixes/+merge/310864
<ltinkl> mterry, what about "shared-mime-info", guess we need it too?
<mterry> ltinkl: shared-mime-info is already in
<ltinkl> mterry, umm where does it get pulled in?
<mterry> ltinkl: as is dmz-cursor-theme from your brnach
<ltinkl> mterry, via the desktop helpers?
<mterry> ltinkl: that list of packages in snapcraft.yaml pulls in dependencies
<ltinkl> ah
<ltinkl> mterry, as long as we're building from debs right :)
<mterry> ltinkl: so I'd say take our your package changes that aren't about language-packs
<mterry> and indicator-keyboard
<ltinkl> mterry, yup... since Saviq wants to bundle all langpacks as a start, I'm gonna include them all
<ltinkl> mterry, then we have to figure out how to query for those in uss/u8
<mterry> ltinkl: also don't need qttranslations5-l10n
<ltinkl> mterry, and show them instead of _all_ locales
<ltinkl> mterry, qttranslations5-l10n also fetched as a dep?
<mterry> yup
<mterry> ltinkl: ^
<ltinkl> kk
<mterry> smoke testing now, hopefully can land soon, looks fine besides
<sil2100> Trevinho: hey!
<sil2100> Trevinho: I see an unity SRU silo in Bileto ready for publish, but the bugs it tries to fix are not prepared from the SRU formality side
<sil2100> Trevinho: (i.e. I don't see all the bugs using the SRU template)
<sil2100> Trevinho: could you take care of that?
<Trevinho> sil2100: sure, it's something we want to do... But i didn't publish it yet because of that and because andyrock has some more tests to do on it
<sil2100> Ah, ok, then good I didn't publish it
<sil2100> As it appears as 'publishable' right now
<ltinkl> mterry, fine with this? https://code.launchpad.net/~lukas-kde/unity8-session-snap/locale-fixes/+merge/310864
<mterry> ltinkl: yeah looks good, just going to give it a sanity test
<mterry> ltinkl: though wait, where did the wizard re-enablement go?
<ltinkl> mterry, we can't re-enable it (just yet)
<mterry> ltinkl: oh bummer
<mterry> what's the issue?
<ltinkl> mterry, wrote earlier ^^ basically Saviq and tsdgeos  don't agree with the fact that we'd list all the available locales
<ltinkl> mterry, so I gotta find a way to query for those langpacks, instead of locales
<Saviq> s/available/existing/
<ltinkl> yeah
<Saviq> locale != language
<mterry> ltinkl: I see -- I didn't realize that was a blocker.  k
<ltinkl> Saviq, sure but it still sets LC_ALL=foo as a result
<Saviq> but you choose a language, not locale - setting locale is a side effect, because that's likely the right thing to do
<Saviq> it'd actually make more sense to base locale off of the time zone setting :P
<ltinkl> Saviq, kind of, yes; but that's another discussion
<Saviq> yup, which is why I don't want to expose *locales* in the wizard, because it doesn't say "Locale" at the top :)
<ltinkl> Saviq, I don't disagree with you, best would be imho to have the lang/locale separation somewhere, the list of translations is too limiting imo
<Saviq> ltinkl, yes, which is what we discussed before, language + separate settings for time, date, monetary preferences, not tied to language/locale at all
<tsdgeos> ltinkl: i don't agree we should list all locales in the language selection screen
<tsdgeos> this is for selecting languages not locales
<tsdgeos> or at least it's called language-plugin
<Saviq> you can set defaults for those based on language, but even *I* really wouldn't know what to choose from a list of 200+ locales to have my preferred setup
<Saviq> the worst thing there is that probably 95% of those locales choose from what? 3 different configs?
<Saviq> so I'm fine with those being used as a source of defaults, but not with exposing the user to that
<pstolowski> mterry, you may want to rename desktop/qt5 to desktop-qt5 (if i remember correctly)
<pstolowski> to avoid the deprecation warning from snapcradt
<mterry> pstolowski: will it find it online?
<mterry> pstolowski: that's a cloud part
<pstolowski> mterry, yep, it should work, that's what a number of projects in snappy-playpen uses (I've just checked)
<mterry> pstolowski: ah great thanks
<pstolowski> mterry, see also https://wiki.ubuntu.com/snapcraft/parts
<mterry> pstolowski: ok updated
<mterry> thx
<pstolowski> yw
<ltinkl> mterry, the paths in user-dirs.dirs are still not good :/ moreover everything (like .cache, .local, etc) got duplicated between ~/snap/unity8-session/x13 and ~/snap/unity8-session/common
<ltinkl> mterry, interestingly, the common dir has the paths right
<mterry> ltinkl: right it would
<mterry> ltinkl: the ones in x13 are not used anymore
<mterry> ltinkl: snapd automatically copies those files around to the new version
<mterry> you can delete them and it'd be fine
<mterry> ltinkl: language packs for br and cy aren't in zesty?
<mterry> oh I may not have overlay installed
<ltinkl> mterry, those are coming from phone, so yeah overlay
<ltinkl> mterry, and, indicator-datetime didn't start in u7 again, even after reboot
<mterry> ltinkl: well do you know why?
<mterry> like is there an erro?
<mterry> error
<ltinkl> mterry, where should I look?
<mterry> ltinkl: ...  i'd start with indicator-datetime's upstart logs
<mterry> in ~/snap/unity8-session/common/.cache/upstart
<ltinkl> mterry, in u7 it doesn't start, which in fact might be related to silo 2195
<ltinkl> mterry, that's the log: http://paste.ubuntu.com/23481550/
<mterry> ltinkl: oh sorry, u7.  sure.  well the only change in the silo is prefixing the command with $SNAP -- do you think SNAP is defined in your u7 environment?
<ltinkl> mterry, nope
<mterry> ltinkl: that log doesn't look great no.  You could try purging the ppa and trying again.  But I really doubt this is caused by the indicator-datetime branch itself.  Possibly something else in the silo?
<ltinkl> mterry, yeah... dunno at this point; it starts tho if I launch the -service manually
<Blue2> Hi
<Blue2> anybody fromthe design team here?
<Blue2> how can you suggest things?
<Blue2> design wise?
#ubuntu-unity 2016-11-16
<ltinkl> mterry, http://paste.ubuntu.com/23486028/
<ltinkl> mterry, now the prob: ubuntu-keyboard-czech : Depends: myspell-cs but it is not going to be installed
<mterry> ltinkl: what's wrong with myspell-cs?
<ltinkl> mterry, if I installed it (or added to the *-packages), it would remove half of my system ;)
<ltinkl> mterry, because I already have hunspell-cs installed (as part of the regular lang pack)
<mterry> ltinkl: seems bad.  But that's not normal...  do you know why it conflicts?
<ltinkl> mterry, and those 2 langpacks are in direct conflict
<ltinkl> mterry, because those langpacks contain duplicated stuff
<mterry> ltinkl: well then they shouldn't both be in stage-packages either, eh
<ltinkl> mterry, I'm gonna add myspell-cs temporarily to show you what would happen
<mterry> ltinkl: but I don't get these problems (on xenial).  Maybe zesty changed
<ltinkl> mterry, I'm on xenial
<ltinkl> mterry, this happens with "myspell-cs" added: http://paste.ubuntu.com/23486046/
<mterry> sure...  but why does this only affect you?
<mterry> Do you have some other packages installed that conflict?
<ltinkl> mterry, nope, no conflicts at all
<ltinkl> mterry, but isn't it obvious? ubuntu-keyboard-czech wants to install myspell-cs which in turn breaks hunspell-cs (which I do have installed)
<mterry> ah so you do have other packages that conflict (hunspell-cs) -- I didn't gather than from before
<mterry> You're saying hunspell-cs is from language-pack-cs, but language-pack-touch-cs wants myspell-cs
<ltinkl> mterry, well they don't conflict atm, they _would_ if I were to install myspell-cs
<ltinkl> mterry, ubuntu-keyboard-czech wants myspell-cs
<mterry> ltinkl: sounds like a bug in our packaging, at the least -- we should settle on one of those?
<mterry> ltinkl: but OK.  I get your problem now though.  I think I can workaround it by dropping all the packages from stage-packages again and just adding a bigger gross LD_LIBRARY_PATH in our wrapper.  Doesn't stop us from getting bit by this in the future, but should work for now
<cimi> pstolowski, hello
<pstolowski> cimi, hi!
<cimi> pstolowski, how are you :)
<pstolowski> cimi, i'm fine, thanks, what's up?
<cimi> pstolowski, I'd like to start a conversation I started with design - basically dash/scopes look a bit empty on tablet/desktop when the window is big enough, because from what I have been told scopes don't provide all the results they have to the dash, but just a few... the reason was to avoid showing the "see more/see less" button on some categories
<cimi> is that right?
<pstolowski> cimi, kind of. netiher shell plugin nor scope knows what the "good" number of results is to fill a row etc. on given display
<pstolowski> cimi, if shell knew if, it could give a hint to the scope about "good number"
<pstolowski> cimi, and it would be up to the scope really to obey or ignore it
<cimi> pstolowski, I was wondering if we could simply provide an API that basically tells the shell/dash "just fill one line then dont show the see more/less button"
<pstolowski> cimi, also, i guess it depends on orientation and if you connect a monitor etc
<cimi> pstolowski, you always give us all the results, but we only show the first required to fill a line
<cimi> imagine you send us 10, on phone we show 2, on tablet 5, desktop 6
<pstolowski> cimi, ah, you mean the shell ignores the rest and discards them?
<cimi> pstolowski, yes, when you set the API to true
<pstolowski> cimi, that could work probably. could a flag in category renderer definition?
<cimi> pstolowski, yes something like that
<pstolowski> s/could a /could be a/
<cimi> pstolowski, that way you always send us all the results you have, and dash on desktop will look more appealing and not so empty :)
<pstolowski> cimi, this makes sense as long as shell plugin is not required to physically do all that in the results models, i.e. if you can apply the limit in the model view
<pstolowski> so when user rotates the device, you simply redraw with different limit
<cimi> pstolowski, we can simply clip or set a maximum height for the grid when we see this new category rendered flag set to true
<cimi> I think that would work easily
<pstolowski> ok, if you say so ;)
<tsdgeos> cimi: man never use the word "easily" :D
<cimi> tsdgeos is right
<cimi> pstolowski, I think that would work.
<pstolowski> cimi, kyleN will be happy if you implement that.. he was struggling to get good-looking resultsets in his scopes on both the phone and tablet...
<cimi> pstolowski, now we need to come up with a good name for that flag, tsdgeos pstolowski suggestions?
<tsdgeos> noShowMore
<pstolowski> tsdgeos, this would have to be used in conjunction with collapsed-rows i presume?
<Saviq> pstolowski, cimi, we *do* have a way to do that already
<Saviq> the scope can tell how many rows to show, even when it sends 100 items
<cimi> Saviq, but showing the see more/see less button
<Saviq> cimi, no, not showing
<Saviq> expandable: false; collapsed-rows: 2; or some such
<cimi> Saviq, WAT
<cimi> Saviq, so basically it's years scopes give us less results because they didn't know they could do that?
<Saviq> they know they can do that
<pstolowski> hmmm i vaguely remember we had this discussion before...
<Saviq> but they still send too little results
<Saviq> we totally did
<cimi> Saviq, read since my first message to pawel, if you have anything to add or we said something wrong
<cimi> pstolowski, Saviq tsdgeos so why scopes only give us sometimes, TWO results? for example music scope, two albums then wide open spaces on the right on desktop/tablet
<Saviq> cimi, because the scope is implemented like that
<pstolowski> Saviq, I don't see 'expandable' in our category renderer docs, so looks like omission on our side
<cimi> Saviq, mistake from scope author who didn't know expandable: false; collapsed-rows: 1?
<tsdgeos> Saviq: are you sure there's an expandable property?
<cimi> Saviq, I have been told by tsdgeos we received 2 results to avoid showing "see more" on the phone, basically
<Saviq> there should've been
<Saviq> there was something that was explicitly making this behaving like that
<tsdgeos> i don't see it
<Saviq> might very well be we lost it in the mean time
<cimi> ok, so it's time to add it then
<Saviq> we've reworked this thing so many times
<pstolowski> cimi, scopes definately set arbitrary limit, e.g. Music aggregator scope forces 2 local results no matter what
<pstolowski> 3 for local music files
<cimi> pstolowski, yeah, I thought that was for the see more/less - maybe if we add this "expandable" property we can change scopes to send a dozen results
<mterry> ltinkl: try buiding a snap now
<ltinkl> mterry, kk
<mterry> ltinkl: and let me know if it works and if you see pulseaudio (which you didn't use to I think, right?)
<ltinkl> mterry, it used to work for me
<mterry> ltinkl: oh ok.  Well let me just know if it builds then.  :)
<Saviq>  this doc doesn't have it either https://docs.google.com/document/d/1NmiM4UCnJgf6IEawmfyTOHRNAA5ZGrqpyrPqPOibwc8/edit
<Saviq>  but I distinctly remember discussing it and would've sworn we had it implemented...
<pstolowski> Saviq, this doc is ancient ;), i don't expect it to match reality
<ltinkl> mterry, looks like it's building fine so far :)
<mterry> ltinkl: nice
<cimi> pstolowski, Saviq so what's next?
<cimi> can we work it out to add this flag?
<cimi> then we can help to patch some of the scopes too
<ltinkl> mterry, snap built fine
<pstolowski> cimi, sounds good to me
<cimi> pstolowski, so I guess "expandable" to add, in combo with collapsed-rows: 1
<pstolowski> cimi, yep
<pstolowski> eod.. cu
<Saviq> cimi, yeah wfm
<dmj_s76> Trevinho: Have you had a chance to look into the g-s-d hidpi code?
#ubuntu-unity 2016-11-17
<Trevinho> dmj_s76: hey, sorry... its quite late here... So I can't now, and andyrock is in holidays, but we'll take care of it.
<vigo> morning
<cimi> morning pstolowski, how are we supposed to proceed implementing what we discusses yesterday? you start working on the API then when you have it we add on the dash or I already add that to the dash? also, do we want to document this somewhere?
<pstolowski> cimi, morning
<pstolowski> cimi, there is no new api, you just need to support it via category renderer attribute, and then we fix scopes
<pstolowski> cimi, and yeah, it needs to be documented in the scopes api doc
<cimi> pstolowski, when will you start that? can I add this to the dash today?
<pstolowski> cimi, ah, I'll probably need to add it to CATEGORY_JSON_DEFAULTS in shell plugin, but that should be enough.
<pstolowski> cimi, let me know when you have a branch and then i'll do it in the plugin and music scope, should be quick
<cimi> pstolowski, oki
<cimi> tsdgeos, still building but I hope that something like this will work http://paste.ubuntu.com/23489853/
<tsdgeos> i guess
<tsdgeos> you'll want some expandable ones in the fake plugin thoguh
<tsdgeos> so you can still see/less more
<cimi> Saviq, interesting, if we set cardtool template collapsed-rows to 0 we were basically hiding see more/less
<cimi> Saviq, maybe this is what you remembered?
<Saviq> cimi, with how many rows?
<cimi> mmm
<cimi> yeah 0 doesnt make much sense
<cimi> tsdgeos, yeah I will tweak just for the first index
<tsdgeos> cimi: it means "show everything"
<tsdgeos> which is not what we want here
<tsdgeos> we want "show 2 rows without see more/less"
<cimi> tsdgeos, need to test it
<tsdgeos> what's the name of the channel with the bileto status reports for silos?
 * tsdgeos forgot
<tsdgeos> Saviq: ââ
<Saviq> tsdgeos, #ubuntu-ci-eng
<cimi> tsdgeos, yeah you're right
<cimi> tsdgeos, works http://paste.ubuntu.com/23489903/
<tsdgeos> you don't need the expanded one, no?
<tsdgeos> after all you're already changing expandable
<cimi> maybe should rename to notExpandable
<cimi> tsdgeos, if I don't change readonly property bool expanded: baseItem.expanded || !baseItem.expandable
<cimi> tsdgeos, then height: expanded ? item.expandedHeight : item.collapsedHeight
<cimi> and height will be of the expanded
<cimi> so I need to force the collapsed height
<cimi> does this make sense?
<tsdgeos> cimi: yes/no maybe
<cimi> :D
<tsdgeos> i guess it depends where you want to make this count
<tsdgeos> and if you want item.exapndedHeight know that it will always be just 2 rows or not
<tsdgeos> or you want to force that at the GSV level
<tsdgeos> both are ok approaches i guess
<tsdgeos> but yeah we need better names for those variables
<tsdgeos> was a bit of a headache reading
<tsdgeos> expanded exandanble and noExpandable
<tsdgeos> :D
<cimi> tsdgeos, better name for template["expandable"] == false?
<cimi> like, the property noExpandable
<cimi> that could be notExpandable
<cimi> or forceNotExpandable
<cimi> or some other crap
<tsdgeos> i like the force
<cimi> tsdgeos, problem is, if expandable is not set, the property forceNotExpandable is true
<cimi> tsdgeos, shall I check for the property to be defined, or I expect pawel to always define expandable to true?
<tsdgeos> no
<tsdgeos> check for it to be defined
<cimi> pstolowski, oki
<cimi> pstolowski, https://code.launchpad.net/~cimi/unity8/dash-forceNotExpandable/+merge/311134
<cimi> pstolowski, building on silo 2202 right now
<pstolowski> cimi, cool, i'll create my part today too
<cimi> tsdgeos, https://code.launchpad.net/~cimi/unity8/dash-forceNotExpandable/+merge/311134
<cimi> pstolowski, managed to get something working?
<pstolowski> cimi, i haven't started yet, about to
<pstolowski> cimi, are we targeting vivid with this fix?
<cimi> pstolowski, I guess too
<cimi> pstolowski, for clicks? ask Saviq too
<pstolowski> ?
<pstolowski> cimi, we've been told to land only critical fixes that are targeted for OTA
<pstolowski> cimi, my stuff is in silo 2217; will try to test tomorrow morning (not sure how exactly since my phone and tablet are vivid)
<pstolowski> the scope will probably need a few iterations to make sure it looks good in all circumstances
<cimi> pstolowski, I only have vivid devices too
<pstolowski> anyway.. i'll figure this out tomorrow. eod, cu!
<cimi> cu!
<mterry> josharenson: hey btw I am aware of your session-icon MP but have been too busy with snappy work
<mterry> josharenson: I will point out that depending on session-lightdm is a sure way to not land for a long time anyway
<mterry> josharenson: I think I need to pull out the mock refactoring in that branch
<josharenson> mterry: haha ok
<josharenson> mterry: 90% of the branch depends on the new mock...
<josharenson> mterry: but I can backport if you think its a better idea
<mterry> josharenson: yeah.  I can't live without that mock refactor
<mterry> That's why I have like 6 branches depending on session-lightdm
<mterry> But I need to pull it out or they'll never land
<mterry> When the u8 snap calms down...
<josharenson> mterry: sure thing
#ubuntu-unity 2016-11-18
<pstolowski> cimi, hey
<tsdgeos> pstolowski: you seen https://code.launchpad.net/~cimi/unity8/dash-forceNotExpandable/+merge/311134 ?
<cimi>  tsdgeos yes, he already has silo and branches
<cimi> I'm testing it too
<tsdgeos> cimi: i've approved it
<tsdgeos> i understand you agreed on the name and stuff
<tsdgeos> :D
<pstolowski> tsdgeos, yes, as cimi said. i've tested it too
<cimi> tsdgeos, only expandable is for him
<cimi> tsdgeos, forceNotExpandable is for us
<tsdgeos> sure
<pstolowski> i still need a branch that documents it
<tsdgeos> morphis: if i wanted to propose a patch for the pulseaudio that is in the stable overlay ppa, how would i do it?
<cimi> tsdgeos, saw https://code.launchpad.net/~josharenson/unity8/autoscroller-alternative/+merge/311207 ?
 * cimi just opened
<tsdgeos> yeah, i re-run the CI
<tsdgeos> there was a crash in one test
<tsdgeos> a bit funky
<tsdgeos> Mirv: so i iinstall silo 1985 and run qmluitests?
<Mirv> tsdgeos: yes please, and/or whatever else it involves. the silo is not complete though but enough for U8.
<tsdgeos> Mirv: https://code.launchpad.net/~aacid/qtmir/build_qt57/+merge/311265
<Mirv> tsdgeos: great, thanks a lot!
<tsdgeos> Mirv: tests will fail
<tsdgeos> sorry didn't check that
<tsdgeos> Mirv: ok, new revision fixes the test
<josharenson> cimi: Any time before EOW to check out the new auto scroller branch? I added it to the silo last night
<cimi> josharenson, tsdgeos mentioned some crashes, I didnt udnerstand what he meant
<josharenson> cimi: in auto scroller or dash refactor?
<cimi> josharenson, mmm autoscroller
<cimi> but let me see
<tsdgeos> there was a crash in prevoius CI run
<tsdgeos> this one was good
<pstolowski> cimi, fyi https://code.launchpad.net/~stolowski/unity-scopes-api/expandable-attribute/+merge/311289 ; let me know if the doc is accurate
 * tsdgeos waves EOW
<josharenson> aw had 1 question for tsdgeos...
#ubuntu-unity 2016-11-19
<salapin> hi
#ubuntu-unity 2017-11-18
<ventrical> hey .. hi
