[01:51] <snadge> where is smspillaz ;)
[02:06] <thumper> sleeping probably
[02:24] <thumper> Ideas for testing welcome: https://code.launchpad.net/~thumper/unity/fix-865840/+merge/89812
[02:29] <bschaefer> thumper, hey. So I have a question about what I should be working on next.
[02:30] <thumper> how's your valgrind?
[02:30] <bschaefer> thumper, need to practice using it!
[02:30] <thumper> bschaefer: ok...
[02:31] <thumper> alias valgrind-unity='G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=50 --leak-check=full --track-origins=yes --log-file=unity-valgrind.`date +%Y%m%dT%H%M%S`.txt compiz --replace 2>&1 | tee /home/tim/unity-valgrind.`date +%Y%m%dT%H%M%S`.log'
[02:31] <thumper> bschaefer: there is my alias
[02:31] <thumper> bschaefer: you'd need to change the path
[02:31] <thumper> bschaefer: what I do is switch to vt1 and make sure that the appropriate bits are exported
[02:31] <thumper> function use-local-compiz
[02:31] <thumper> {
[02:31] <thumper>   export DISPLAY=:0
[02:31] <thumper>   export COMPIZ_CONFIG_PROFILE=ubuntu
[02:31] <thumper> }
[02:32] <thumper> from my .bashrc
[02:32] <thumper> running under valgrind makes it very slow
[02:32] <thumper> but it is gathering nice data
[02:32] <thumper> try it a few times
[02:32] <thumper> and perhaps we could have a talk to go through some output
[02:32] <bschaefer> thumper, cool, I dont think I have ever used alias before but it makes sense
[02:32] <thumper> bschaefer: put that in your .bashrc file too
[02:33] <bschaefer> thumper, alright, doing that right now
[02:37] <bschaefer> thumper, ok, done with that. Now using that which will put the logs files in ~/unity-valgrind.* and looking thought those for mem leaks?
[02:37] <bschaefer> looking through those*
[02:39] <thumper> one of those will be the output from the console
[02:39] <thumper> the other will be the valgrind output
[02:39] <thumper> the .txt file I think is the valgrind one
[02:39] <thumper> with the .log being the console log output from unity
[02:40] <thumper> there are interesting things with uninitialised reads/writes/jumps to
[02:40] <thumper> they often relate to uninitialised variables
[02:40] <thumper> along with the potential / definite leaks
[02:41] <bschaefer> thumper, you are right about it being slower, but it's all working
[02:41] <bschaefer> and cool this should be fun to dig through
[03:04] <bschaefer> thumper, so I just found 3 in LauncherModel.cpp. Should I just make a branch and request a merge?
[03:17] <thumper> bschaefer: sure
[03:25] <dyams> good morning
[03:27] <thumper> hi dyams
[03:28] <dyams> thumper: hi :)
[03:30] <bschaefer> thumper, alright done. https://code.launchpad.net/~brandontschaefer/unity/uninitialized-launcher-model/+merge/89819
[03:32] <thumper> bschaefer: hang on
[03:32] <thumper> bschaefer: those variables have default constructors
[03:32] <thumper> bschaefer: they are std::lists
[03:32] <thumper> bschaefer: they don't need to be explicitly initialized
[03:35] <bschaefer> thumper, hmm well valgrind doesn't seem to complain anymore about though
[03:35] <thumper> bschaefer: can you pastebin me the valgrind log?
[03:37] <bschaefer> thumper, it's not showing up anymore and I removed that one...which I shouldn't have but I was testing if valgrind would complain again
[03:37] <bschaefer> thumper, Ill delete the init and then restart valgrind one sec
[03:38] <bschaefer> it was a un inited stack error though; and it pointed to LauncherModel::Populate().
[03:49] <thumper> bschaefer: it and it2 :)
[03:51] <bschaefer> thumper, dang, I just saw it point to that file then saw the 3 Base vars were not inited and I couldn't find the class
[03:51] <bschaefer> then you said it was a list, then I found the typedef...
[03:51] <bschaefer> that explains that :)
[03:52] <bschaefer> thumper, It looks like just it2 needs to be removed; and it looks like it gets inited in the for loops
[03:54] <thumper> bschaefer: ok, so change your branch to revert your other commit (you could just uncommit it (then revert)), and change it to delete it2
[03:54] <thumper> bschaefer: bonus points for changing the for loops to range based for loops
[03:56] <bschaefer> thumper, alright; and will try to change to use a range. (Looking it up!)
[04:00] <bschaefer> thumper, so I would use for_each and then make a new private function which does those 2 lines of code
[04:03] <bschaefer> thumper, opps never mind...
[04:04] <bschaefer> thumper, found out what I needed, I need to start reading the new c++ standard...
[04:41] <bschaefer> thumper, alright pushed, getting bzr to push took a little
[09:18] <Saviq> hey greyback, one question about testability-verify-...
[09:18] <greyback> Saviq: shoot
[09:19] <Saviq> `raise if PASSTHROUGH_EXCEPTIONS.include?...` sounds like it shouldn't raise if PASSTHROUGH_EXCEPTIONS contains that Exception class? do I get that right?
[09:23] <greyback> Saviq: yeah, that's correct. And I'm missing the definition of PASSTHROUGH_EXCEPTIONS in my MR!
[09:23] <Saviq> greyback, but also, if I understand ruby correctly (and I might not), the line:
[09:24] <greyback> It's so that the test runner won't catch errors like NoMemoryError, SignalException, Interrupt, SystemExit
[09:24] <Saviq> raise if PASSTHROUGH_EXCEPTIONS.include? $!.class
[09:24] <Saviq> will _only_ raise if the condition is true?
[09:24] <Saviq> greyback, I removed the Approved status from the MR so that tarmac doesn't merge
[09:25] <greyback> Sorry, let me start again
[09:26] <greyback> "raise if PASSTHROUGH_EXCEPTIONS.include?" *will* raise if the exception thrown is one of the PASSTHROUGH exceptions, i.e. if NoMemoryError occurs, it is caught by run(), but then raised again
[09:26] <Saviq> ah so those aren't treated as failures
[09:26] <greyback> exactly
[09:26] <Saviq> or errors
[09:26] <Saviq> they basically stop the test
[09:26] <greyback> indeed
[09:27] <Saviq> makes sense, only maybe we should call that list something else?
[09:27] <Saviq> like CRITICAL_EXCEPTIONS or something?
[09:27] <greyback> Can do. I just copied what Test::Unit was using. But that's a better name IMO
[09:28] <Saviq> cool
[09:32] <Saviq> dyams, hey, re remove-unused-code-shell-launcher-animation - do you think we could have a test to ensure no regressions there?
[09:33] <Saviq> greyback, that's actually a question for you, too ^ - do we yet have a plan of how to test transitions? are we targeting that at all?
[09:33] <greyback> Saviq: define "transitions" for me please, animations between states?
[09:33] <Saviq> greyback, yes
[09:34] <Saviq> greyback, the above is about animating the launcher position
[09:34] <Saviq> maybe we could have visual verification with 3-4 steps along the way
[09:34] <Saviq> that might not be fast enough, though
[09:35] <greyback> Saviq: right, I'd be concerned how reliable that would be
[09:35] <Saviq> yup, exactly
[09:35] <Saviq> we could test the value of x along the way, though
[09:35] <Saviq> again - in 3, 4 steps
[09:36] <Saviq> just to verify it reaches the in-between states and doesn't go full-on at once
[09:36] <dyams> saviq: one sec
[09:36] <greyback> That's something that needs more research, how to do timing-measurements with testabililty. How to check a quantity changes smoothly from x to y in time t.
[09:37] <Saviq> yeah and also the issue I can think of now is that there's always a resolution, and qml uses reals for animations
[09:37] <dyams> saviq: it was a dead code.. hence removed
[09:38] <Saviq> dyams, that's fine, but removing dead code calls for ensuring it was dead by a test ;)
[09:38] <greyback> Saviq: Checking the value a few times might do then
[09:38] <Saviq> but you would have to use ranges
[09:38] <Saviq> 'cause the actual value would be something like 23.2131412321
[09:39] <Saviq> and again, it might miss 23 completely if the animation is fast enough that with every frame it skips some values
[09:40] <Saviq> that calls for video verification...
[09:40] <Saviq> anyway
[09:40] <Saviq> some time later
[09:40] <dyams> saviq: :) sure...
[09:40] <Saviq> dyams, nevermind, looks like there's no way yet to test that yet
[09:41] <Saviq> and the current tests already ensure the launcher works good enough
[09:41] <dyams> saviq: true
[09:41] <tsdgeos> greyback: some questions about testability-target-host-split, ready for them? or busy?
[09:41] <greyback> tsdgeos: in meeting, 5-10 mins
[09:41] <JohnLea> mhall119; hyia, to answer your earlier question:  each Lens should be for a specific data type, e.g. Music, Books, Sheet Music, News, Photos, Comics, etc...  If a Lens for a content type already exists, it is hoped other developers will contribute scopes to interface new sources of data with the Lens.  So if a 'Comics' Lens already exists, we would hope that a Indian comic fan would write a scope to pull content from say http://onlin
[09:41] <JohnLea> eindiancomics.blogspot.com/ into the comics Lens.  We would want to discourage them from writing another Lens, because it is more useful to users to have less Lenses interfacing with more sources of content.  Part of the value the Dash gives to users is content aggregation, and while a proliferation of Lenses would make life more difficult, a proliferation of scopes is very useful and desirable.  Basically the rule is "If a Lens alre
[09:41] <JohnLea> ady exists for the data type, focus on writing scopes for that Lens.  No not create a new Lens, if you need to modify the Lens contact the Lens author and contribute a patch"
[09:44] <Saviq> dyams, one thing you could test close to that code is manualSliding
[09:44] <Saviq> we don't yet have it in -shell
[09:44] <dyams> saviq: ok, but this branch if for shell itself
[09:45] <Saviq> dyams, yes I know
[09:45] <Saviq> will test and review properly soon
[09:45] <dyams> saviq: thank you :)
[09:45] <Saviq> ok dyams do your stuff, Kaleo will be doing the gesture stuff anyway, he'll do the tests for that
[09:46] <dyams> saviq: ok
[10:10] <dyams> nerochiaro: ping
[10:10] <nerochiaro> dyams: yes ?
[10:11] <dyams> nerochiaro: Bfb activate is using DBus to display Dash. no?
[10:11] <tsdgeos> dyams: no if you merge my branch
[10:11] <dyams> nerochiaro: ah..ok
[10:11] <nerochiaro> dyams: it was, but i'm removing this
[10:11] <tsdgeos> nerochiaro: you are?
[10:12] <nerochiaro> tsdgeos: yep, we had a discussion with Kaleo yesterday and there will be some restructuring in that part
[10:12] <nerochiaro> tsdgeos: what are you working on ?
[10:12] <dyams> nerochiaro: sure. that was my concern.
[10:12] <tsdgeos> nerochiaro: i did that already
[10:12] <tsdgeos> that = do not use dbus
[10:13] <nerochiaro> tsdgeos: what do you use instead ?
[10:13] <tsdgeos> nerochiaro: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_no_dbus_to_ourselves/+merge/89247
[10:14] <nerochiaro> tsdgeos: dyams: nevermind, the stuff i'm working on is not related
[10:14] <nerochiaro> was my mistake
[10:14] <tsdgeos> nerochiaro: ok :D
[10:15]  * nerochiaro needs another cup of tea
[10:15] <nerochiaro> sorry guys
[10:15] <Saviq> tsdgeos, you saw my comment on that? can you please go through all the changes and ensure they are tested?
[10:15] <tsdgeos> Saviq: i did
[10:16] <Saviq> ok
[10:16] <tsdgeos> Saviq: there's two changes, 1 to bfb, that is tested already elsewhere, 2 to alt+f2 to open the dash, i'm trying to test that now but failing
[10:16] <tsdgeos> somehow i can get testability to introspect unity-2d-places (in unity-2d)
[10:17] <tsdgeos> any idea why that might be happening?
[10:17] <dyams> nerochiaro: ok
[10:18] <dyams> tsdgeos: I hope removed that DBus call in your new branch already
[10:18] <Saviq> tsdgeos, you _can_?
[10:18] <tsdgeos> Saviq: i can't :D
[10:19] <tsdgeos> well, i can but there's only one child shown in tdriver_visualizer
[10:19] <tsdgeos> which means it's not very useful
[10:19] <Saviq> tsdgeos, you'll have to take that with greyback
[10:20] <tsdgeos> yep
[10:20] <tsdgeos> waiting for him
[10:20] <dyams> tsdgeos: one child of what?
[10:20] <tsdgeos> was in a 5 min meeting 30 min ago
[10:20] <tsdgeos> dyams: in the tdriver_visualizer tree, there's the "sut" root and then there is just one child "unity-2d-places"
[10:21] <tsdgeos> but i can't see the rest of stuff inside it
[10:21] <dyams> tsdgeos: ask tdriver to refresh in 5 secs, in the mean time open the dash and the lense you want
[10:22] <tsdgeos> ahh
[10:22] <tsdgeos> that worked
[10:22] <tsdgeos> cool
[10:22] <dyams> tsdgeos: yes
[10:27] <greyback> tsdgeos: ok, I'm free now. What did I miss :)
[10:28] <tsdgeos> greyback: nothing important, just some comments about your merge for the split thing
[10:28] <greyback> tsdgeos: they're very important :)
[10:28] <Saviq> greyback, your fail-not-error branch got merged (even though I changed its status to Needs Review...)
[10:28] <tsdgeos> greyback: there's a "sleep 1" in a test that seems like it might be better to do in a separate MR?
[10:29] <greyback> tsdgeos: Hmm, possibly. I noticed that the delay was needed when I made that split. It caused the test to fail, so I added it.
[10:29] <tsdgeos> greyback: also i was wondering about the tests you have commented with "#Disabling this failing test due to poor window Xid detection by xdotool - fix on the way"
[10:30] <greyback> My thinking was to keep the tests passing.
[10:30] <tsdgeos> greyback: not that i care much about that sleep 1, i understand it's a "fix the test because of this feature uncovers a bug in the test", so it's ok
[10:30] <tsdgeos> greyback: when is the "fix" for those arriving?
[10:30] <tsdgeos> greyback: i'd say it's better if we keep them failing so we realize there's some things that don't yet work?
[10:31] <greyback> tsdgeos: yeah, xdotool's search gives you every XId an application has. Often an app has more than one. xdotool gives you them all, but only one is the actual visible window, and it's not obvious which
[10:31] <tsdgeos> not sure if we use those features though
[10:31] <greyback> tsdgeos: I've a branch with a in-progress fix in my machine
[10:33] <greyback> If we are testing if an application is started by the dash, or want to move application window around, we need a reliable search
[10:34] <tsdgeos> ok
[10:34] <greyback> tsdgeos: I've no objection to having tests failing in trunk right now. In which case I'll remove these comments & stuff
[10:34] <tsdgeos> so i'd prefer if we keep the failing tests
[10:34] <tsdgeos> as something we know has to be fixed
[10:34] <greyback> fair enough
[10:34] <tsdgeos> greyback: also are we getting an "official" qttasserver in precise? Would be cool not to depend on your ppa
[10:35] <greyback> tsdgeos: Yeah, that's something I mean to do :(
[10:35] <greyback> it's on my todo list
[10:36] <tsdgeos> ok
[10:36] <Saviq> tsdgeos, greyback what about disabling them with xtest?
[10:37] <Saviq> so that they don't contaminate the test results? I know that might reduce the apparent need to fix them
[10:37] <greyback> Saviq: I also have on my todo list a way of counting all disabled tests, so they're not forgotten about
[10:40] <tsdgeos> Saviq: i'm not sure a real fail is a contamination of the test results, but i'm ok with wathever the bigger team decides i was just exposing my opinions :-)
[10:41] <Saviq> tsdgeos, remember that once the auto- stuff is implemented a failed test means no merge
[10:42] <tsdgeos> Saviq: ok, then yes, we need to hide fails
[10:42] <tsdgeos> greyback: i'll approve the MR then
[10:43] <greyback> tsdgeos: I'll remove those little comments & bits.
[10:43] <tsdgeos> greyback: read up, Saviq has a good reason to leave that commented
[10:44] <greyback> tsdgeos: ah yes. You had another comment about me missing something from the README
[10:44] <tsdgeos> greyback: it is in the README, but not in the wiki, the stuff about adding the ppa
[10:45] <greyback> tsdgeos: ohhh, that had me confused
[10:47] <Saviq> tsdgeos, re root file tests - only the last test actually fails
[10:48] <Saviq> looks like verify_not() works kind of weird
[10:49] <tsdgeos> Saviq: what you mean with "only the last test actually fails" ?
[10:49] <Saviq> tsdgeos, the first two tests pass
[10:49] <Saviq> the first one is ok to pass
[10:49] <Saviq> but the second should fail, no?
[10:49] <tsdgeos> all of them should pass
[10:49] <Saviq> tsdgeos, not when I only merged the tests on stock unity-2d-shell
[10:50] <Saviq> tsdgeos, I'm testing the tests themselves
[10:50] <tsdgeos> well, you can't tests the tests on stock unity-2d-shell
[10:50] <Saviq> I can
[10:50] <tsdgeos> sure
[10:50] <tsdgeos> but does not make sense
[10:50] <Saviq> does
[10:50] <tsdgeos> the feature is not there
[10:50] <Saviq> exactly
[10:50] <Saviq> so the tests should fail
[10:51] <Saviq> that's exactly what tests should do
[10:51] <Saviq> if the feature isn't there
[10:51] <tsdgeos> that if the previous code was good enough
[10:51] <Saviq> sure
[10:51] <tsdgeos> i can't help that when previously you gave
[10:51] <tsdgeos> -thisissomeshit
[10:51] <tsdgeos> it did not fail
[10:51] <Saviq> tsdgeos, yes, of course
[10:51] <Saviq> tsdgeos, but the second test should fail
[10:51] <tsdgeos> ok
[10:52] <tsdgeos> so let's start again because i'm confused then :D
[10:52] <Saviq> tsdgeos, "Verify app does not start without a rootqml parameter" does not fail
[10:52] <Saviq> on stock shell
[10:52] <Saviq> unity-2d-shell launches fine
[10:52] <Saviq> and that should be a fail, shouldn't it?
[10:53] <tsdgeos> yes
[10:53] <tsdgeos> it should
[10:53] <Saviq> exactly
[10:53] <Saviq> it doesn't
[10:53] <tsdgeos> i see
[10:53] <tsdgeos> let me have a look
[10:53] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_choose_root_file/+merge/89290/comments/193480
[10:54] <Saviq> tsdgeos, just `bzr merge lp:~aacid/unity-2d/unity-2d-shell_choose_root_file -c922` into unity-2d-shell
[10:54] <tsdgeos> sure
[10:55] <Saviq> I'm not sure the first test makes sense, though
[10:55] <Saviq> not as part of root qml file test, at least
[10:55] <Saviq> whether shell launches or not should probably be a separate test somewehre
[10:55] <tsdgeos> i can remove it if you want
[10:55] <Saviq> I think it's just cruft in there
[10:56] <tsdgeos> ok
[10:56] <tsdgeos> gone
[10:58] <Saviq> dyams, please do not commit tests in one commit with the fix, makes it difficult to check whether the tests fail without the fix
[10:59] <dyams> saviq: ok
[10:59] <dyams> saviq: will have separate branch for tests from now on.
[10:59] <Saviq> dyams, not necessarily separate branches
[11:00] <Saviq> dyams, just separate commits at least
[11:00] <dyams> saviq: ok, sure
[11:00] <Saviq> dyams, we'll probably have some guidelines on that soon
[11:00] <Saviq> already discussed that with Gerry and Ugo
[11:00] <dyams> saviq: ok
[11:04] <greyback> Saviq: dyams: tsdgeos stand-up?
[11:04] <Saviq> greyback, I've a meeting, IIRC, let me verify
[11:04] <greyback> Saviq: np
[11:04] <Saviq> ah no, it got moved
[11:04] <Saviq> coming
[11:05] <Saviq> nerochiaro, standup?
[11:05] <nerochiaro> Saviq: sure, hold on
[11:05] <Saviq> holding
[11:06] <Saviq> dyams, ?
[11:06] <Saviq> dyams, standup
[11:06] <Saviq> ?
[11:09] <dyams> saviq: oops
[11:09] <Saviq> dyams, come on in, we already started
[11:10] <dyams> saviq: yes...coming
[11:13] <didrocks> hey greyback
[11:13] <greyback> didrocks: yo
[11:13] <didrocks> greyback: small question, I'm implementing the unity settings for https://docs.google.com/document/d/1ILTJDiDCd25Npt2AmgzF8aOnZZECxTfM0hvsbWT2BxA/edit?hl=en_US#heading=h.jztfy8l5q9v5
[11:14] <didrocks> so, the question is: do you have similar settings for 2d?
[11:14] <didrocks> if not, it will be good that you point the same value :)
[11:15] <greyback> Indeed. So, we have our own dconf value for autohide on/off
[11:15] <greyback> We used to have the left-corner option, I can't remember if it was removed or not.
[11:15] <snadge> fix the god damn focus problem
[11:15] <snadge> beforei put my fist through several pcs
[11:15] <snadge> i cant believe that doesnt shit anybody else to tears ;)
[11:16] <greyback> snadge: unity or unity2d?
[11:16] <snadge> unity
[11:16] <snadge> same problem manifests as 2 symptoms in particular.. right click menu, sometimes disappears when you move the mouse over it
[11:17] <snadge> also the autocomplete feature when typing into firefox location bar.. doesnt work.. even though you are clearly typing text into it.. both problems happen when you switch from another workspace to the workspace in question
[11:17] <snadge> and its not easily reproduceable.. some kind of race condition
[11:18] <snadge> smspillaz knows about it at least
[11:19] <didrocks> greyback: hum, so I'll need to listen to unity-2d and 3d keys it's a pain :/
[11:19] <didrocks> greyback: especially that one is in gsetting and the other in gconf
[11:20] <snadge> it happens on every pc i use unity on though
[11:20] <didrocks> greyback: anyway, let's do it this way for now, I'll look at the settings, you need to have the icon size though
[11:23] <greyback> didrocks: we need it? Really?
[11:23] <didrocks> greyback: well, the option will be there
[11:23] <htorque> hi all! is indicator-loader3 supposed to work with the appmenu right now?
[11:23] <htorque> when i try to start it (running metacity), i get this: http://paste.ubuntu.com/814857/ and an empty loader window.
[11:23] <didrocks> and you will get bugs I guess about "why does it work in 3D"
[11:23] <greyback> didrocks: sure.
[11:24] <greyback> didrocks: ok, we had preliminary work done on that, will revisit
[11:25] <greyback> didrocks: I'll send you a email with where we save settings.
[11:25] <didrocks> greyback: thanks :)
[11:26] <Saviq> Kaleo, we'd like you to come in to discuss approaches to multimonitor support in unity-2d-shell
[11:26] <Saviq> Kaleo, dyams is only here for another hour, otherwise we can do it tomorrow morning
[11:26] <Saviq> (yes, I know you only have half an hour now)
[11:27] <dyams> saviq: Will have the same QML FilterCheckOption.qml for new renderer filter-check-option-compact too.
[11:27] <Saviq> dyams, yup
[11:28] <dyams> saviq: Or shall we have a separate one already? Just for future purpose?
[11:29] <Saviq> dyams, the file will have to be named FilterCheckOptionCompact.qml, 'cause that's how we're loading the filter renederers
[11:29] <Saviq> getting rid of hyphens and word/camelCasing
[11:29] <Saviq> dyams, it's probably best to either have an abstract one
[11:29] <Saviq> and two inheriting from them
[11:30] <Saviq> or just the compact one inheriting from the standard one
[11:30] <Saviq> for such a small difference the latter is probably better
[11:30] <dyams>  saviq: sure, lets have separate qml already
[11:35] <dyams> saviq: yes, very small difference indeed
[11:37] <tsdgeos> Saviq: pushed a change to the tests of the rootqml thing, should behave correctly now (i.e fail without the feature and work with it)
[11:37] <Saviq> tsdgeos, thanks
[11:39] <Saviq> greyback, did you see that your fail-not-error branch got merged? you didn't manage to get the tweaks in
[11:40] <greyback> Saviq: yep:( Revert or do follow-up?
[11:40] <Saviq> greyback, follow-up
[11:40] <greyback> Saviq: *nod*
[11:41] <tsdgeos> greyback: you say merge error fixed in https://code.launchpad.net/~gerboland/unity-2d/testability-target-host-split/+merge/89743 but last commit is from 18 hours ago?
[11:41] <Saviq> tsdgeos, the qml file in root-qml-arg is +x?
[11:41] <greyback> tsdgeos: hmm, didn't I push?
[11:42] <tsdgeos> Saviq: should not be, let me check
[11:42] <tsdgeos> Saviq: it's not here, do yo see it there?
[11:42] <Saviq> tsdgeos, yeah, I wonder why
[11:43] <Saviq> oh no
[11:43] <Saviq> it's not now
[11:43] <Saviq> I think it's VBox's shared folder issue
[11:43] <Saviq> ignore
[11:43] <tsdgeos> ok :D
[11:44] <tsdgeos> greyback: seems not?
[11:44] <greyback> tsdgeos: did you do an actual pull? I did push
[11:44] <tsdgeos> greyback: no, i'm just looking at https://code.launchpad.net/~gerboland/unity-2d/testability-target-host-split/+merge/89743
[11:44]  * tsdgeos pulls
[11:44] <greyback> tsdgeos: yeah me too. But just in case LP is confused
[11:45] <tsdgeos> no, nothing got here when pulling
[11:45] <tsdgeos> r877 is the last one
[11:45] <greyback> tsdgeos: hmmm
[11:45] <greyback> tsdgeos: wrong fecking branch.
[11:45] <greyback> tsdgeos: sorry, my bad
[11:47] <Saviq> Kaleo, added you to https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_choose_root_file/+merge/89290 - please have a quick look and comment whether that's what you had in mind
[11:48] <Saviq> dyams, are you working in a RTL env?
[11:48] <Saviq> dyams, if so, it would be great if you could tackle the RTL issues as it's difficult to test for us
[11:49] <greyback> tsdgeos: ok, should be there now. Sorry about that
[11:50] <tsdgeos> greyback: approved that for you
[11:50] <dyams> saviq: no, but i needed to check it, hence tried once
[11:50] <greyback> tsdgeos: thank you
[11:50] <dyams> saviq: I'm LTR only :)
[11:50] <Saviq> dyams, oh ok
[11:51] <Saviq> that's actually what I thought, but just noticed all the RTL related things you put on the wiki
[11:51] <Saviq> dyams, also, the [] is supposed to show who's working on the issue
[11:51] <dyams> saviq: yeah
[11:51] <Saviq> are you working on the RTL issues you encountered?
[11:51] <Saviq> or plan to
[11:51] <dyams> saviq: who is working... oh ok..
[11:52] <Saviq> ;
[11:52] <Saviq> ;)
[11:52] <dyams> saviq: :) it is the name of the reporter yet
[11:52] <dyams> saviq: no, thats what I felt :)
[11:53] <Saviq> dyams, please get rid of those you've assigned yourself to that you don't plan on working on
[11:53] <dyams> saviq: i remove my name there
[11:54] <dyams> saviq: yes, done
[11:54] <greyback> Saviq: note this branch: https://code.launchpad.net/~haggai-eran/unity-2d/rtl-rebased/+merge/82151
[11:54] <greyback> Saviq: he's done a lot of work on RTL support for unity-2d
[11:54] <Saviq> greyback, yeah, I know
[11:54] <greyback> Saviq: ok good
[11:55] <dyams> greyback: I think it should have been split into pieces.
[11:55] <dyams> greyback: I mean Haggai's branch
[11:55] <greyback> dyams: me too
[11:56] <Saviq> do you? the diff isn't that big, really
[11:56] <greyback> Saviq: it wouldbe easier to test in smaller chunks
[11:56] <Saviq> trye
[11:56] <Saviq> *true
[11:56] <Saviq> I don't like the "switch keys" approach
[11:57] <Saviq> ah nvm
[11:57] <greyback> PL/EN?
[11:57] <Saviq> it's just used in one place anyhow
[11:57] <Saviq> greyback, no, left/right
[11:57] <greyback> Saviq: oh right
[11:58] <Saviq> he has a function there that switches left for right and the other way around if RTL
[11:59] <Saviq> anyway
[11:59] <greyback> true, I thought it was wordaround for panel-service not being rtl friendly
[11:59] <greyback> anyhoo
[12:01] <greyback> Saviq: the resizable-tiles stuff is needed for unity-2d.
[12:01] <Saviq> greyback, hrm?
[12:02] <greyback> Saviq: you removed it from shell, no?
[12:02] <Saviq> greyback, you mean resizable launcher?
[12:02] <greyback> Saviq: yes that's it, sorry
[12:02] <tsdgeos> nerochiaro: did you discover how to invoke slots from testability?
[12:03] <Saviq> greyback, yeah I reverted it for it needed revisiting
[12:03] <Saviq> greyback, there was a whole bunch of 0.21321434312 * some value
[12:03] <greyback> Saviq: yeah, I didn't like that either
[12:03] <dyams> tsdgoes: call_method() might work
[12:04] <Saviq> greyback, we should probably discuss that with design - what're the designed proportions between all the parts
[12:04] <Saviq> whether it's a preset margin
[12:04] <Saviq> stuff like that
[12:04] <Saviq> greyback, so that's going to be supported in unity in 12.04
[12:04] <greyback> Saviq: must talk to Kaloe about it. I assume he showed that work to the Designers
[12:04] <Saviq> ?
[12:05] <Saviq> and we need to have that in -2d, too?
[12:05] <greyback> Saviq: there'll be a setting for it, so yes
[12:05] <Saviq> ok, then maybe that calls for a design bug to describe the layout like that
[12:05] <greyback> Saviq: there's a setting for it in gnome-control-centre, and unit supports it, so I guess we should too
[12:06] <Saviq> if they say tile.width == 0.23242341 * launcher.width then that's what we'll do
[12:06] <Saviq> but I don't think we should reverse-engineer it
[12:06] <Saviq> applying those values to the commit I reverted should be easy enough
[12:06] <greyback> Saviq: sure
[12:07] <greyback> Why do I expect a "do what Unity does" reply :)
[12:08] <greyback|lunch> bbiab
[12:08] <nerochiaro> tsdgeos: sorry, didn't see the message. no, i didn't because all i needed was to click something so i just used the tap() method that all objects returned from testability have
[12:08] <tsdgeos> nerochiaro: ok, i found call_method, that is supposed to work according to docu, but doesn't either :-/
[12:09] <nerochiaro> tsdgeos: :(
[12:09] <nerochiaro> tsdgeos: why do you need to call methods anyway ? clicking on things will be too complex ?
[12:10] <tsdgeos> nerochiaro: well it's a method that happens when you alt+f2, wanted to go the method way instead of alt+f2, but i'll just "type" the shortcut
[12:11] <nerochiaro> tsdgeos: seems a better test to me to actually simulate the shortcut
[12:11] <nerochiaro> tsdgeos: so you test that it works too
[12:11] <tsdgeos> yeah
[12:11] <tsdgeos> thogh that is not what i specifically wanted to test :D
[12:11] <tsdgeos> i just want to test that stuff still works after not using dbus anymore
[12:11] <tsdgeos> but yeah
[12:11] <tsdgeos> it doesn't hurt using Altf2
[12:12] <nerochiaro> tsdgeos: the only time when one shouldn't do this kind of stuff is when the position of what i need to click is too complex to find out, IMHO. and yeah, you want to test something else, but if alt+f2 doesn't work it doesn't really matter if what comes after works or not, after all ;)
[12:28] <kamstrup> JohnLea: as soon as you have time, can you do a design review of https://code.launchpad.net/~kamstrup/unity/home-lenses/+merge/89669 please? I attached two screenies
[12:28] <kamstrup> ping me if you need more
[12:29] <JohnLea> kamstrup; thanks, give me 10 min and I'll get back to you
[12:29] <kamstrup> awesome
[12:42] <mhall119> kamstrup: the code samples in https://code.launchpad.net/unity-lens-sample look to be based on Unity 3
[12:43] <mhall119> can we either get those updated or removed?  They seem to be causing some confusion with new Lens developers
[12:47] <kamstrup> mhall119: I can only agree... What do you think? Is it worth the effort to update them, or are there enough examples out there in the wild?
[12:48] <kamstrup> I guess the biggest deal about them is that we have some "canonical examples" of lenses
[12:48] <kamstrup> (not meaning "canonical" as the company, but as the word :-))
[12:52] <tsdgeos> greyback|lunch: i guess i have to rewrite all my unmerged tests now that you merged your split stuff, right?
[13:05]  * dyams launchpad is slow today...or is it my connection?
[13:08] <JohnLea> kamstrup; sorry for the delay in doing the review, still on my to do list.  will get back to you soon
[13:14] <JohnLea> kamstrup; looks good to me, other than the missing divider line (ignoring the layout positioning issues that affect the Dash as a whole).
[13:18] <kamstrup> JohnLea: yeah, that's another bug. I already pinged MacSlow about it
[13:19] <mhall119> kamstrup: I think we have enough python examples, but the developers I heard from is using vala, are there any good vala examples?
[13:20] <mhall119> kamstrup: I also think we should provide more comprehensive examples in https://wiki.ubuntu.com/Unity/Lenses
[13:21] <mhall119> for instance, https://wiki.ubuntu.com/Unity/Lenses#Using_the_Lens_Object never shows the proper constructor for the Lens daemon
[13:21] <mhall119> so the developer was using the constructor from the unity-lens-sample branches, which still use the Unity 3 Unity.Activation parent
[13:22] <arand> Which resolutions for icons does Unity use by default? Is there any benefit to installing x64 and x128 versions if they are just resized versions of a x256 image?
[13:23] <Saviq|mtg> tsdgeos, hey, reviewing your struts branch now - any reason why you did create an onChanged signal for enabled but not for edge?
[13:24] <Saviq|mtg> tsdgeos, also, looks to me like we can drop the useStrut property altogether?
[13:24] <kamstrup> mhall119: right. The default unity lenses are a tad complex as introductory examples, so it might be worth doing. Shouldn't be a big job anyway
[13:25] <Saviq|mtg> tsdgeos, adding as comments on the MR
[13:27] <greyback> tsdgeos: sorry yeah, they'll need changes. Since it's my fault, I can fix them up for you
[13:39] <mhall119> kamstrup: I shared a google doc with you
[13:39] <mhall119> JohnLea, davidcalle and I are working on a set of recommendations for lens and scope authors
[13:40] <mhall119> and I would appreciate your input as well
[13:41] <kamstrup> cool, i'll have a look tonight, right now I am crazy busy :-)
[13:42] <mhall119> no problem
[13:46] <tsdgeos> greyback: no, it's ok, i'll do them
[13:46] <greyback> tsdgeos: ok. apologies again
[13:51] <dandrader> hi. "super + w" shows all windows from all workspaces. Is there a shortcut for showing only the windows from the current workspace?
[13:53] <JohnLea> mhall119; did you get my message in IRC from earlier today?
[13:56] <tsdgeos> Saviq: Launcher is also valid, but i changed it for consistency sake
[13:56] <Saviq> tsdgeos, thanks
[13:56] <tsdgeos> Saviq: i mean, otherwise the verify would complain
[13:56] <tsdgeos> if you put some random text there it does
[13:56] <Saviq> tsdgeos, I know
[13:57] <Saviq> but I was just surprised to see Launcher there
[13:57] <tsdgeos> Saviq: yeah, c&p from the wrong place
[13:57] <jo-erlend> there's no session menu in the 12.04 lightdm greeter. How do I switch to another session? I'd like to test Unity 2D.
[13:57] <tsdgeos> Saviq: don't merge any of the _test_ branches yet, they need changes due to greyback's changes today
[13:58] <mhall119> JohnLea: yeah, I've added that to the doc, thanks
[13:58] <Saviq> tsdgeos, I'm not, they're assigned to Gerry, I'll let him do it, I'm just commenting where I find things while testing stuff for shell
[13:59] <greyback> tsdgeos: Saviq I plan to write a mail with guidelines today. Do:/Don't: etc
[13:59] <Saviq> cool
[13:59] <mhall119> JohnLea: I think we just need something explicitly description the purpose of scopes, and then just some polish and it's good to go
[13:59] <tsdgeos> Saviq: want to discuss https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_readd_struts_support/+merge/89690 ?
[13:59] <Saviq> tsdgeos, sure
[14:00] <tsdgeos> Saviq: by droping the useStrut propertly you mean from unity2dpanel ?
[14:01] <Saviq> tsdgeos, yes
[14:01] <Saviq> tsdgeos, I didn't see any uses for it anymore?
[14:01] <tsdgeos> Saviq: unity-2d-panel uses it
[14:02] <Saviq> tsdgeos, ok then I didn't find that
[14:02] <tsdgeos> well, not the property itself, but the methods, i can remove the property declaration if that's what you meant
[14:02] <mhall119> can anybody help jo-erlend with switching sessions in the new lightdm?
[14:02] <tsdgeos> the property itself is not really needed per se
[14:03] <jo-erlend> I tried editing .dmrc, but that seems to get overwritten so that session=ubuntu-2d becomes session=ubuntu.
[14:03] <tsdgeos> Saviq:
[14:03] <tsdgeos> wops :D
[14:03] <jo-erlend> I've also tried to edit /etc/lightdm/lightdm.conf, but that didn't change anything either.
[14:04] <tsdgeos> Saviq: did you read what i said about "i can remove the property but not the methods", i think it still makes sense to have the property if we have the methods and the property was there already after all
[14:04] <Saviq> tsdgeos, of course, I didn't see it used anywhere at all
[14:04] <tsdgeos> ok
[14:04] <tsdgeos> next
[14:05] <tsdgeos> Saviq: about the changed signal, i did only add the one for enabled since it was the one that i really needed to propagate to unity-2d-panel siince it had that signal, i can add the one for edge if you want, do it?
[14:06] <Saviq> no, that's fine
[14:06] <tsdgeos> oki
[14:06] <Saviq> I simply missed its use there, must've not looked at the code carefully enough
[14:06] <jo-erlend> ok. I take the hint.
[14:06] <tsdgeos> Saviq: about the StrutManager "location", yeah i am unsure about it myself
[14:07] <Saviq> tsdgeos, the "other managers" fit in the shell itself, I'd rather have it there
[14:07] <tsdgeos> ok, let's put it there and see if it still works
[14:07] <Saviq> remember to have its width and height be that of launcherLoader
[14:08] <tsdgeos> not sure i understand what you mean there
[14:09] <tsdgeos> you mean
[14:09] <tsdgeos> height: launcherLoader.item.height
[14:09] <tsdgeos> ?
[14:11] <Saviq> tsdgeos, no item in thee
[14:11] <Saviq> there
[14:11] <Saviq> launcherLoader.height / launcherLoader.width
[14:11] <tsdgeos> ok
[14:11] <Saviq> that's what the shape uses, too
[14:23] <tsdgeos> Saviq: oki, pushed
[14:23] <Saviq> tsdgeos, yup, seen that
[14:23] <Saviq> going to test again and approve
[14:24] <tsdgeos> awesome
[14:35] <Saviq> there's going to be a huge code-dump into shell soon ;)
[14:43] <Saviq> tsdgeos, any pointers as to how to adapt the tests for super / alt+f2 to -shell?
[14:44] <Saviq> I tried adding an objectName to the Dash and using @app.Dash() but failed, what am I missing?
[14:44] <tsdgeos> Saviq: no sure, actually i haven't done it, i can do that after fixing the other tests that need tweaking after greyback changes
[14:45] <Saviq> tsdgeos, if I don't manage within 5 mins I'll leave you to it
[14:46] <tsdgeos> oki
[14:50]  * AlanBell likes the look of the HUD stuff
[14:53] <Saviq> tsdgeos, think I got it
[14:54] <tsdgeos> nice
[14:56] <Saviq> tsdgeos, here's a diff from your test branch http://pastebin.ubuntu.com/815405/
[14:56] <Saviq> will be useful when merging
[14:57] <tsdgeos> makes sense
[14:57] <Saviq> I only wonder why we're getting strings instead of bools, any idea?
[14:58] <tsdgeos> everything is returned as string
[14:58] <tsdgeos> if you see in lots of places we to
[14:58] <tsdgeos> .to_i
[14:58] <Saviq> ah
[14:58] <greyback> yep, everything
[14:58] <tsdgeos> to get the integer
[14:58] <Saviq> so .to_b will get me bools
[14:58] <Saviq> ?
[14:58] <greyback> and there's no to_b :(
[14:58] <Saviq> ok
[14:58] <tsdgeos> not sure if there's a .to_bool :D
[14:58] <greyback> nope, checked
[14:58] <greyback> It can be added, but pfft
[14:58] <Saviq> stoopids
[14:58] <tsdgeos> or .to_i "works" for bools too
[14:59] <greyback> does it? ruby complains about mixing types usually
[15:00] <Saviq> https://code.launchpad.net/unity-2d/+activereviews
[15:00] <Saviq> tarmac is going to crap on me in a sec, I just know it
[15:01] <tsdgeos> greyback: updated my 3 _test_ MR to use the new split target/host commands
[15:02] <greyback> tsdgeos: thank you, will look at them in about an hour
[15:02] <greyback> have lightning talk to prep
[15:04] <tsdgeos> no worries
[15:04] <greyback> Saviq: ah, PASSTHROUGH_EXCEPTIONS is ok, since I inherit from a class which defines it
[15:07] <Saviq> greyback, oh ok
[15:07] <Saviq> no point in renaming, too, then
[15:07] <greyback> not really
[15:07] <Saviq> tsdgeos, hey we got a conflict in struts
[15:07] <Saviq> can you merge please?
[15:08] <tsdgeos> ohhh
[15:08] <tsdgeos> yep
[15:08] <Saviq> tsdgeos, not your fault, I was merging 5 MRs one after the other
[15:08] <tsdgeos> sure
[15:16] <tsdgeos> Saviq: pushed
[15:16] <Saviq> tsdgeos, thanks
[15:21] <Andy80> hi
[15:21] <Andy80> Kaleo: ping
[15:24] <tsdgeos> Saviq: you creating all the kanban cards?
[15:25] <Saviq> tsdgeos, yes
[15:25] <tsdgeos> anything i have to do with them?
[15:25] <tsdgeos> move them to coded/done ?
[15:25] <Saviq> tsdgeos, not yet
[15:25] <tsdgeos> ok
[15:25]  * tsdgeos does nothing
[15:25] <Saviq> I'll let you know when it's ready for you guys to move them around
[15:27] <Saviq> tsdgeos, you updated the wiki I see with all the merges I did?
[15:28] <tsdgeos> Saviq: yep
[15:28] <tsdgeos> Saviq: well, only for those marked with [ALBERT]
[15:31] <Saviq> tsdgeos, yes, of course
[15:39] <mhall119> kamstrup: can you tell me what happened to the UnityActivation interface from Unity 3?
[15:39] <mhall119> was it replaced by something new in Unity 4, or just not needed at all anymore?
[15:40] <kamstrup> mhall119: from 3 to 4 we went from overriding an async method in a ginterface (utterly unlikely to ever work in pygi in our lifetimes) to using a signal based approach where you subscribe to a bog standard gobject signal
[15:40] <kamstrup> and from 4 to 5 it was unchanged
[15:41] <mhall119> kamstrup: so it's not needed anymore?
[15:42] <kamstrup> mhall119: is UnityActivation still in libunity? That would be weird...
[15:43] <kamstrup> phew, it's not :-)
[15:43] <kamstrup> just Unity.ActivationResponse... that is an enum used as return val for the signal
[15:45] <mhall119> kamstrup: right, but it's still in the old sample code we were talking about earlier
[15:45] <mhall119> I'm writing a response to someone who's still trying to use it
[15:45] <kamstrup> mhall119: ah, that way
[15:45] <mhall119> so the answer is to use scope.activate_uri.connect(on_uri_activated); instead, right?
[15:46] <mhall119> (in vala)
[15:54] <tsdgeos> greyback: Saviq: "Move the mouse away from the launcher area, press alt+f1, move the mouse to the launcher, press esc" this behaviour is different between unity-2d and -shell, i think the unity-2d behaviour is the correct one, can you verify so i add it to the merge plan?
[15:59] <Saviq> tsdgeos, I think it's already added as "Toggling the Dash by hitting Super key twice, taking focus away from the previous application."
[16:00] <Saviq> yup, looks related
[16:00] <Saviq> might just need a comment about the other way to trigger that issue
[16:02] <greyback> tsdgeos: yes, unity-2d behaviour is correct (I remember this from a few months ago)
[16:03] <tsdgeos> Saviq: not sure they are related, i'll add it just to make sure we don't miss it
[16:05] <Saviq> Kaleo, "ruby run-tests.rb -n test_`cat | sed s/\\\\W/_/g`"
[16:05] <Saviq> after you run that paste the name of the test into the terminal
[16:05] <Saviq> and go ctrl+d twice
[16:15] <mhall119> davidcalle: hey, would you have some time today to talk about your experience with the ARB process for your utility lense?
[16:27] <jono> tedg, hey
[16:27] <jono> is the HUD code available now?
[16:28] <tedg> jono, To everyone but you, I don't want to see your crazy patches :-)
[16:28] <jono> tedg, LOL
[16:28] <tedg> GPLv3 + the standard jono clause
[16:28] <jono> haha
[16:28] <jono> is there a place to file bugs yet?
[16:28] <tedg> Heh, NO!
[16:28] <Saviq> tsdgeos, can you run the test suite on current unity-2d-shell and see whether you get a weird behavior from the launcher (I do)
[16:28] <tedg> http://launchpad.net/indicator-appmenu/+filebug
[16:29] <tsdgeos> Saviq: in a sec
[16:29] <jono> tedg, cool - and which PPA will it be in now?
[16:29] <tedg> jono, It's in Unity Team, HUD
[16:29] <tedg> jono, ppa:unity-team/hud
[16:29] <jono> thanks tedg
[16:29] <jono> I will move to that PPA
[16:30] <jono> and file bugs in indicator-appmenu
[16:30]  * tedg needs to too
[16:30] <jono> do I need to tag the bugs in any way?
[16:30] <tedg> jono, Uhm, haven't thought about it.  I guess we'll solve that problem if we get a bunch...
[16:30] <tedg> I guess I should write up what is the most useful.
[16:31] <jono> if I do ubuntu-bug indicator-appmenu, will it work on a package from a PPA though?
[16:31] <tedg> jono, Err, I don't know if I've got the apport hook in that package...
[16:32] <tedg> jono, Yeah, looks like it.
[16:35] <tsdgeos> Saviq: i get some unexpected errors yes
[16:36] <Saviq> nerochiaro, tsdgeos: all the cards are in leankit now, please update them as your progress goes
[16:36] <tsdgeos> Saviq: http://paste.kde.org/~tsdgeos/192038/ Errors 1, 2 and 4 are expected because of the "Dash Home" thing, the others, no idea why they fail
[16:36] <nerochiaro> Saviq: ok. thanks for putting them there
[16:37] <Saviq> tsdgeos, actually for me the suite passed
[16:37] <gord> tedg, think we need to turn off ignoring terminals now?
[16:37] <tsdgeos> Saviq: lol :D
[16:37] <Saviq> tsdgeos, but the launcher showed at x = LAUNCHER_WIDTH at some point
[16:37] <tsdgeos> Saviq: no, didn't get that
[16:37] <Saviq> tsdgeos, as for the others
[16:37] <Saviq> you didn't built getshape did you
[16:37] <tedg> gord, Heh, yeah, probably.
[16:38] <tedg> gord, Probably not the standard use-case anymore ;-)
[16:38] <tsdgeos> Saviq: hmmm, i did make, do i need something extra?
[16:38] <gord> tedg, apart from hud-cli people of course :) actually seen a lot of interest in that
[16:38] <Saviq> tsdgeos, cmake first?
[16:38] <tsdgeos> sure :D
[16:38] <Saviq> tsdgeos, verify that you have a tests/getshape/getshape binary
[16:38] <Saviq> and that it runs
[16:38] <tsdgeos> ah, maybe it doesn't support out of dir builds
[16:38] <Saviq> maybe make clean first
[16:38] <Saviq> eh?
[16:38] <tsdgeos> must be that
[16:38] <Saviq> unity-2d doesn't support shadow builds at all :D
[16:39] <davidcalle> mhall119, I don't have the time right now, but tomorrow?
[16:39] <tsdgeos> i've been building in a separate dir since the beginning with no problem at all
[16:40] <mhall119> davidcalle: tomorrow would be great, just let me know when you're available
[16:40] <Saviq> tsdgeos, very interesting, where do you get your qml files from, then?
[16:40] <davidcalle> mhall119, sure
[16:40] <tedg> gord, https://bugs.launchpad.net/indicator-appmenu/+bug/921056
[16:40] <Saviq> as they are not (well, were not) copied when building in a shadow dir
[16:40] <tsdgeos> Saviq: from where the source code is
[16:40] <tsdgeos> just works
[16:41] <Saviq> must've gotten fixed at some point
[16:41] <Saviq> when I wasn't paying attention
[16:41] <gord> AlanBell, ^^ :)
[16:41] <AlanBell> hi
[16:41] <tsdgeos> Saviq: but no i did not see stuff move around weirdly, maybe you had a unity-2d-launcher around while testing unity-2d-shell and that caused the weirdness ?
[16:41] <tsdgeos> i had that situation before
[16:42] <tsdgeos> and it's confusing :D
[16:42] <Saviq> might have
[16:42] <Saviq> let me try again
[16:43]  * AlanBell tries HUD with Orca
[16:43] <Saviq> tsdgeos, it's the always visible test
[16:44] <Saviq> tsdgeos, I'm thinking available_area takes struts into account
[16:44] <tsdgeos> Saviq: hmmm, ah, right, merged struts + resizing
[16:44] <tsdgeos> and it moves itself
[16:44] <tsdgeos> :D
[16:44] <Saviq> exactly
[16:44] <tsdgeos> sad
[16:44] <Saviq> we need a test for that
[16:44] <Saviq> adding a card in the kanban
[16:45] <tsdgeos> yeah
[16:45] <tsdgeos> Saviq: do we have kanban cards for stuff like "    Move the mouse away from the launcher area, press alt+f1, move the mouse to the launcher, press esc, launcher should not close"
[16:45] <tsdgeos> ?
[16:46] <AlanBell> hmm, can't see any of unity with orca right now :(
[16:47] <brendand> i've just installed the HUD and it's pretty neat, but not behaving at all like i'd expect it to
[16:47] <brendand> e.g.
[16:48] <Saviq> tsdgeos, yes
[16:48] <Saviq> tsdgeos, nerochiaro is taking care of that
[16:48] <tsdgeos> hmm, my name is in the wiki :D
[16:48] <Saviq> tsdgeos, it's in "Next" in Bug Fixes lane
[16:48] <Saviq> tsdgeos, must've missed the change somewhere
[16:49] <brendand> if i have Firefox open and type 'Sou' then it shows Tools > Web Developer > Page Source as the first option
[16:49] <Saviq> if you're already on it, assign the card to yourself
[16:49] <brendand> if I continue to type 'Sour' that option disappears
[16:49] <brendand> if i type 'Source' then there is nothing
[16:49] <tsdgeos> Saviq: well, none of the one in nerochiaro are that bug, it turns out the bug is in intellihide, nothing to do with what is written in those cards
[16:49] <brendand> This happens in pretty much every app with any menu item you can think of
[16:50] <brendand> Also, I don't think it's necessarily a good idea to show options from the menus of other open applications
[16:50] <seb128> brendand, like which other applications?
[16:51] <Saviq> tsdgeos, I thought 'Ensure dash toggle returns focus' would take care of that, looks very similar
[16:51] <seb128> brendand, the example you describe seems like a bug, ping ted when he's around I guess or file a bug
[16:51] <Saviq> unless I misunderstood your issue, let me try again
[16:51] <tsdgeos> Saviq: it's not about focus, it's about the launcher clsoing when it should not
[16:51] <AlanBell> gord: ok, I restarted and orca reads unity now
[16:51] <brendand> seb128 - mainly from g-c-c
[16:51] <seb128> brendand, g-c-c = gnome-control-center? that has no menus
[16:51] <AlanBell> I get "HUD frame" and it can read the content of the field you type in
[16:52] <Saviq> tsdgeos, ok I see
[16:52] <AlanBell> gord: but it does not read the items in the list below the field you can navigate to and flat review mode doesn't work there either
[16:52] <Saviq> tsdgeos, your description didn't have a "have a window overlapping the launcher"
[16:52] <Saviq> tsdgeos, feel free to add the card and assign yourself to it
[16:52] <tsdgeos> Saviq: bug in the bug description :D
[16:52] <jackyalcine> Just got an update about the HUD interface for Ubuntu and how it dealt with speech control
[16:52] <Saviq> tsdgeos, I've to EOD
[16:52] <jackyalcine> *speech recognition I meant.
[16:52] <tsdgeos> Saviq: ok, will do
[16:53] <brendand> seb128 - ok. with Thunderbird in focus, searching for 'Settings' starts to bring up e.g. Sound Settings
[16:53] <Kaleo> nerochiaro: there are no automated tests yet for either the panel or the dash, interesting
[16:53] <AlanBell> jackyalcine: yeah it needs to generate jsgi files for the grammar of the menu structure I think
[16:53] <gord> AlanBell, yeah I need to do some work there
[16:53] <nerochiaro> Kaleo: there are some indirectly for the dash in the shell directory
[16:54] <brendand> seb128 - file bugs against unity? or something else?
[16:54] <seb128> brendand, indicators are always listed
[16:54] <Kaleo> nerochiaro: that's not in trunk
[16:54] <seb128> brendand, unity tagged "hud"
[16:54] <nerochiaro> Kaleo: it's in shell, yes
[16:54] <Kaleo> nerochiaro: not very helpful for me
[16:54] <AlanBell> jackyalcine: then use sphinx or pocketsphinx to get words
[16:54] <seb128> brendand, the idea is that you can do stuff like mute the sound or reply to a contact which has a pending message in the messaging menu from it
[16:55] <jackyalcine> The programmatic approach for recognition is quite simple, it's a matter of accuracy.
[16:55] <seb128> brendand, that behing anywhere, so it's not really a bug
[16:55] <nerochiaro> Kaleo: i was planning to add some as part of this task for the panel/dash interaction (i have them already in a shell branch but i might as well add them in with this stuff we're looking at in trunk)
[16:55] <brendand> seb128 - ok. but perhaps the focused app should be higher priority?
[16:55] <seb128> brendand, that's likely yes
[16:55] <Kaleo> nerochiaro: only add tests that test what you changed please
[16:55] <jackyalcine> AlanBell: tbh, if I could find someone that's presently working on it, I'd collab with them.
[16:55] <jackyalcine> Do you know of any?
[16:55] <Kaleo> nerochiaro: (for these MRs)
[16:55] <nerochiaro> Kaleo: fair enough
[16:56] <nerochiaro> Kaleo: i'll add the others as part of the MR to add back panel buttons for the dash in shell
[16:56] <Saviq> Kaleo, there are some tests awaiting merge
[16:56] <Kaleo> nerochiaro: I foresee 2 tests for the first MR
[16:56] <Saviq> at least one merge is for the dash, none for panel, though
[16:57] <Kaleo> nerochiaro: 1st test: depending on the dconf key making sure the maximisation state is respected
[16:57] <Kaleo> nerochiaro: 2nd test: clicking on the maximise button in the panel; making sure the dash reacts properly
[16:57] <Kaleo> nerochiaro: what do you reckon?
[16:57] <AlanBell> jackyalcine: I am interested in doing some proof of concept stuff around that
[16:58] <Kaleo> Saviq: are any of the tests you are thinking about testing these kind of things?
[16:58] <nerochiaro> Kaleo: also bring out the dash, change dconf key, check dash has changed state properly
[16:58] <Saviq> Kaleo, there are tests for the dash showing on <super> and <alt+f2>, so definitely a good place to start
[16:58] <Kaleo> nerochiaro: fair enough
[16:58] <mhall119> who can I ask questions to about the new HUD?
[16:58] <Kaleo> Saviq: we can maybe borrow test code from there indeeed
[16:59] <Kaleo> Ã-e
[16:59] <Kaleo> mhall119: I thing tedg wherever he is
[16:59] <Kaleo> mhall119: gord too I believe
[16:59] <Saviq> nerochiaro, btw, your input-shape tests will be broken by your dash-buttons-in-panel change, no?
[16:59] <nerochiaro> Saviq: no, they don't change the shape
[17:00] <Saviq> nerochiaro, but there's no button
[17:00] <Saviq> ah wait
[17:00] <Saviq> ok
[17:00] <Saviq> nvm
[17:00] <nerochiaro> Saviq: :)
[17:00] <Saviq> the button is for collapsing
[17:00] <nerochiaro> yes
[17:00] <Saviq> oh, btw, maybe that's what we should use the minimize button for
[17:00] <Saviq> instead of the weirdly placed X
[17:00] <Saviq> it's not going to be minimize per-se but still
[17:01] <nerochiaro> Saviq: might be a good idea, but let's respect the design for now
[17:01] <Saviq> aaanyway, EOD, see you all tomorrow
[17:01] <Saviq> of course
[17:01] <nerochiaro> Saviq: see you
[17:01] <Saviq> babay
[17:04] <mhall119> oh ew, HUD messed up my alt+tab scale plugin
[17:04] <mhall119> super+tab that is
[17:04] <mhall119> so, maybe not HUD, but something in that last dist-upgrade
[17:06] <mhall119> it was the launcher switcher initiation that did it, fixed now
[17:07] <greyback> Kaleo: I've some dash tests that were reviewed, need fixing. One of which tested Dash maximize by clicking panel maximize. Then nerochiaro started something similar, so I've laid off it a little and then got diverted. Will get back to it 2moro
[17:08] <greyback> nerochiaro: that wierdly placed X is not in the design any more. It probably will go, replaced by new home screen
[17:08] <brendand> https://bugs.launchpad.net/unity/+bug/921077
[17:11] <jackyalcine> Where do I find code to pick at on the HUD? C++ dev here.
[17:16] <Kaleo> greyback: please give that test to nerochiaro so that it can finish it :)
[17:16] <gord> jackyalcine, depends on your interestest, the backend service that provides the data is at https://code.launchpad.net/~ted/indicator-appmenu/hud whereas the client side code lives at http://code.launchpad.net/~gordallott/unity/hud
[17:17] <nerochiaro> Kaleo: i have already tests that do the same thing, as greyback said
[17:17] <greyback> Kaleo: I pointed him to it some time ago
[17:18] <nerochiaro> Kaleo: they are in the branch to bring back the dash buttons to the panel in the shell
[17:18] <nerochiaro> Kaleo: greyback: so, no worries, there will be tests for the dash buttons in the panel
[17:19] <nerochiaro> but right now i have this annoying headache so i'm gonna lay down for today with a nice painkiller. i may get back to this stuff later tonight
[17:19] <nerochiaro> Kaleo: greyback: ^
[17:20] <greyback> nerochiaro: go rest
[17:20] <greyback> I'm hoping it's not testability's fault :)
[17:21] <Kaleo> nerochiaro: take care!
[17:21] <Kaleo> greyback: it's your fault :)
[17:21] <Kaleo> isn't it always? :)
[17:22] <nerochiaro> nah, it's just me not sleeping enough yesterday for totally unrelated reasons
[17:22] <greyback> Kaleo: harsh :(
[17:23] <Kaleo> nerochiaro: rest well friend
[17:23] <greyback> nerochiaro: take it easy
[17:23] <greyback> Kaleo: no good-manager cookies for you :P
[17:23] <Kaleo> greyback: I just had 2 cookies
[17:23] <Kaleo> greyback: but whatever :)
[17:39] <balloons> a little feedback on HUD guys -- the blog postings don't seem to mention you need to hit 'alt' to have HUD show up (I was able to find it buried on Oli's page I believe tho). Just an FYI, overall everyone I've spoken to has been really excited by it
[17:41] <jackyalcine> balloons: this is a fact.
[17:41] <jackyalcine> you know who's planning to begin the speech work?
[17:42] <balloons> jackyalcine, ?
[17:43] <jackyalcine> http://www.omgubuntu.co.uk/2012/01/hud-new-unity-feature/ mentions that Hub would include speech recognition.
[17:44] <balloons> ahh.. voice recognition you mean
[17:45] <balloons> yes, I am not sure who/when will be doing that work, but it's certainly another compelling piece of using this
[17:59] <jackyalcine> balloons: well, I'm hoping to work on it with those involved.
[18:00] <mhall119> gord: where should we file bugs against HUD?
[18:01] <gord> mhall119, ui side, http://bugs.launchpad.net/unity - matching, tracking and all the other stuff. http://bugs.launchpad.net/indicator-appmenu
[18:01] <mhall119> gord: thanks
[18:02] <mhall119> is there a wiki page for HUD yet, that has links to those and the description of which to use for what kinds of bugs?
[18:02] <mhall119> and for /unity bugs, should we use a certain tab for HUD bugs?
[18:03] <gord> no wiki page yet, if you want to tag the unity bugs with "hud" that would help
[18:10] <mhall119> https://bugs.launchpad.net/unity/+bug/921112
[18:31] <utlemming> question about the HUD pre-release....how do I invoke the HUD?
[18:33] <utlemming> oh, nevermind
[18:59] <jackyalcine> utlemming: gotta press alt right?
[19:00] <utlemming> jackyalcine: right, it seems a bit flaky for me though
[19:00] <jackyalcine> Hmm.
[19:06] <mhall119> just tap alt, if you hold it it focuses on the global menu
[19:09] <mhall119> gord: can you give me any details about how an app developer would give initial "hints" to the HUD?
[19:11] <gord> mhall119, ask tedg :) he's in #ayatana and #ubuntu-devel
[19:22] <balloons> gord, mhall119 I'm writing a blog post containing a howto for filing bugs on HUD.. if you have anything additional to add, speak now :-)
[19:23] <Daekdroom> Aww. I was about to file one.
[19:29] <mhall119> balloons: I'm going to get a wiki going for it, if you can fill in the bug filing part
[19:29] <balloons> sure thing
[19:55] <mhall119> balloons: https://wiki.ubuntu.com/Unity/HUD if you could fill in details
[19:56] <thumper> balloons: make them add a tag for hud :)
[19:57] <balloons> thumper, yes, in my post I mention tagging hud bugs in unity with hud
[19:57] <balloons> http://www.theorangenotebook.com/2012/01/testing-hud-heads-up-display.html
[19:57] <balloons> check it out and see if I missed anything
[19:57] <balloons> thanks ;-)
[20:00] <balloons> mhall119, is there a pre command of some sort for the wiki? or how would you format commands meant to be entered in the terminal?
[20:00] <mhall119> {{{ }}} I think
[20:00] <mhall119> {{{\n command\n }}}
[20:00] <balloons> i'll try.. thanks
[20:01] <mhall119> aren't wikis fun?
[20:01] <balloons> used to mediawiki syntax...
[20:01] <balloons> but yes, I <3 wiki's -- apparently I'm one of the few
[20:01] <mhall119> that's okay, we'll break you of that
[20:02] <mhall119> uh oh, I think the wiki is dead
[20:04] <tedg> mhall119, Is this useful for your wiki page?  http://bazaar.launchpad.net/~ted/indicator-appmenu/hud/download/head:/hudarchitecture.svg-20111019043745-t9zh424t1ldhnz7k-2/HUD%20Architecture.svg
[20:04] <tedg> mhall119, It was done originally to explain the concepts, not sure if it's useful generally.
[20:05] <balloons> might work as part of the arch section
[20:05] <balloons> mhall119, {{{ }}} worked, thanks
[20:06] <mhall119> tedg: sure would be
[20:08] <mhall119> tedg: I took the text in the overview section from mark's blog, can you you check over it and maybe add a bit of an introduction?
[20:09] <mhall119> thumper: when will be a good time to chat again today?
[20:09] <tedg> mhall119, Hmm, let me revise that diagram.
[20:10] <thumper> mhall119: in a few hours
[20:11] <mhall119> thumper: 2200 or 2300?
[20:11] <mhall119> actually, I can't do 2300 today
[20:11] <mhall119> if you can't do 2200, how about tommorrow?
[20:20] <tedg> mhall119, Can you repull that diagram?  I simplified it a bunch.  I think that makes it clearer.
[20:25] <mhall119> tedg: done
[20:25] <tedg> mhall119, Great!  Thanks!
[20:55] <balloons> unity --reset seriously rules..
[21:14] <thumper> mhall119: it'll have to be tomorrow
[21:17] <mhall119> thumper: ok
[21:29] <I4NI> Hello
[21:30] <I4NI> I have a question for those who would be willing to answer it.
[21:31] <I4NI> In my attempt to update the repositorys after getting the ppa for unity-hud it has failed to fetch the packages stating a 404.
[21:31] <I4NI> How do I fix this?
[21:32] <I4NI> Hello
[21:35] <popey> I4NI: hello
[21:35] <popey> I4NI: can you install pastebinit and then issue "sudo apt-get update | pastebinit"
[21:37] <I4NI> Okay, did that
[21:37] <popey> did it give you a link?
[21:38] <popey> I4NI: are you running 12.04?
[21:38] <I4NI> no, 11.10
[21:38] <I4NI> does it require 12.04
[21:38] <I4NI> ?
[21:38] <popey> yes
[21:39] <I4NI> oic ty
[21:40]  * popey wonders why the hud doesnt find the 'download' menu in firefox
[21:43] <varun06> can we try HUD in Oniric?
[21:44] <popey> I think it's only available for precise right now
[21:56] <balloons> yes, no ppa for oneiric
[21:56] <balloons> the changes are large, requiring new versions of unity, etc
[21:57] <varun06> can I use precise as daily driver
[21:57] <varun06> I mean is it stable enough to try
[21:57] <balloons> varun06, depending on your comfort level, yes.. The goal this cycle is to have daily quality with no breaking updates
[21:58] <bschaefer> thumper, thank you for signing that. I also just push more to this merge.  https://code.launchpad.net/~brandontschaefer/unity/uninitialized-launcher-model/+merge/89819
[21:58] <varun06> update-manager-d should update my 11.10
[21:58] <bschaefer> thumper, which cleans it up a bit
[21:59] <balloons> Usage: update-manager [options]
[21:59] <balloons> Options:
[21:59] <balloons>   -c, --check-dist-upgrades
[21:59] <balloons>                         Check if a new Ubuntu release is available
[21:59] <balloons>   -d, --devel-release   Check if upgrading to the latest devel release is
[21:59] <balloons>                         possible
[22:00] <varun06> thanks
[22:01] <balloons> yw.. just make sure your comfortable with the idea that things could break, and there will be bugs :-)
[22:02] <varun06> I am a tester, so not a new thing :)
[22:03] <balloons> great! feedback and bug reports would be wonderful
[22:07] <varun06> don't know why, but update-manager-c/d not working on my machine
[22:07] <varun06> I am entering command and pressing enter
[22:07] <varun06> nothing is happening
[22:20] <balloons> you need to use sudo varun06
[22:20] <balloons> sudo update-manager -c -d
[22:33] <bernie> would it be possible to make the workspace switcher icon go away if the expo plugin is not enabled in compiz? it took me a long time to figure out why in my desktop it's a dead icon and it took me a long time to figure out why i had this dead icon on my dock...
[22:35] <thumper> hi bernie
[22:35] <thumper> bernie: do you only have one workspace?
[22:36] <Daekdroom> The icon does something even when you have only one workspace.
[22:36] <Daekdroom> (or atleast it used to)
[22:36] <thumper> what does it do?
[22:37] <bernie> thumper: no, I have 4 workspaces arranged horizontally
[22:38] <thumper> bernie: and you don't like the expo?
[22:38] <Daekdroom> It's possible it doesn't work for 4 workspaces arranged horizontally.
[22:38] <bernie> Daekdroom: in my case, it doesn't do anything when i click on it. If I enable the Expo plugin in compiz, then it comes back to life.
[22:40] <thumper> Daekdroom: it does, I used to have the arranged that way
[22:41] <thumper> bernie: it seems reasonable, can you file a bug on unity?
[22:44] <bernie> thumper: sure, thanks
[22:49] <mhall119> gord: tedg: why would HUD find inkscape's "File > Export Bitmap" when I type "Exp" but not "Export"?
[22:50] <mhall119> infact, it seems to be better and finding a near match than an exact match
[22:50] <Daekdroom> mhall119, that might explain why I never find what I want to
[22:51] <mhall119> it also doesn't seem to work on gnome-terminal when that has focus, instead showing me options for chromium still
[22:51] <mhall119> it seems that whenever one of my gnome-terminal windows has focus, it uses the menu of the previously-focused app
[22:56] <tedg> mhall119, Yes, we've blacklisted the terminal for debugging.
[22:56] <tedg> mhall119, The search is basically untunned.  We got it in a good state, but it needs to be much better.
[22:57] <mhall119> ah, so I probably didn't need to file https://bugs.launchpad.net/unity/+bug/921269
[22:57] <mhall119> tedg: can you comment on that bug about blacklisting gnome-terminal for now, in case others stumble upon it too
[22:57] <mhall119> I assume it'll be unblacklisted eventually
[23:00] <bernie> thumper: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/921271
[23:00] <thumper> bernie: ta
[23:03] <bernie> thumper: btw, in enabling and disabling Expo i managed to make compiz hang. Then, when I killed compiz, the whole X session died!
[23:03] <bernie> thumper: do you know who could take a look at my Xorg.0.log?
[23:03] <tedg> mhall119, Can't right now, but I will.  Need to get dinner ready.
[23:03] <tedg> 'night folks.
[23:04] <bernie> it's a long-standing bug, I've seen it at least twice: http://codewiz.org/pub/Xorg-crashed-on-compiz-close.0.log
[23:04] <bosyi> hi people
[23:06] <bosyi> when trying to instal HUD on 12.04 with ppa of unity 5.0 also it propose to me to delete ubuntu-desktop and unity
[23:09] <bosyi> someone have that issue?
[23:09] <mhall119> who knows whom I could talk to about uTouch from an application developer's perspective?
[23:10] <thumper> mhall119: try cnd
[23:10] <cnd> mhall119, if you don't mind, hop into #ubuntu-touch :)
[23:11] <cnd> that's where the utouch devs hang out
[23:15] <AlanBell> anyone know what hud-dump-application   hud-list-applications  hud-verify-app-info actually do?
[23:25] <Saviq> AlanBell, they're debugging tools that deal with the HUD database
[23:41] <AlanBell> Saviq: yeah, I can't get them to do a lot
[23:41] <AlanBell> I kind of want all the strings of an application's menus