[03:10] <grayghost> Can the window menu be attached to the window ... instead of to the top screen bar ?
[03:42] <grayghost> Unity sure is buggy .... is there a way to upgrade backwards to 11.40 ???
[03:42] <grayghost> 11.04
[03:51] <snadge> no
[03:51] <snadge> you're probably better off going forwards, and submitting bugs/feature requests
[03:51] <snadge> or using gnome 3 .. or using gnome 3 in fallback mode, with compiz
[03:52] <snadge> or metacity
[03:54] <grayghost> thanks for the suggestions
[04:05] <snadge> ive been using unity for a while now.. because thats the direction ubuntu is taking
[04:05] <snadge> and i'll be honest.. at first.. i didnt like it
[04:06] <snadge> so i can understand the enormous whinge people are having about it
[04:06] <snadge> it really does suck that classic gnome 2 with compiz had to be deprecated
[04:06] <snadge> because a lot of people were happy with that
[04:07] <snadge> and react unfavourably to either of the two new interface paradigms.. that being unity and gnome shell
[04:07] <snadge> that being said.. im used to using unity now, i understand its shortcuts.. and i know how to use it as efficiently as I was using gnome 2.. prior to that
[04:08] <snadge> i just wish the focus problems would get fixed already
[04:31] <grayghost> snadge: I have installed Gnome 3 ....... so do I have to reboot and select Gnome at login ????
[04:32] <snadge> yes
[04:32] <snadge> and if you want to use the "classic" gnome interface.. instead of gnome-shell
[04:32] <snadge> you might need to google on how to do that, because i forget
[04:32] <snadge> its not selectable from the login screen.. but gnome 3 is
[04:33] <snadge> it autodetects if you have the capability to run gnome-shell.. and uses it
[04:33] <snadge> but theres a way to force it into "2d" fallback mode.. or "classic" desktop
[04:33] <snadge> just be warned that .. gnome 3 fallback mode.. != gnome 2
[08:43] <dyams> saviq: drag n drop is better if we use manual tests?
[08:44] <Saviq> dyams, we should reduce manual tests to a minimum
[08:45] <Saviq> and unless you can confirm it's not feasible to test with testability, I'd like to see that tested automagically
[08:46] <dyams> saviq: as we discussed in the morning, the initiating drag is one big challenge here..(finding co-ordinates)
[08:46] <Saviq> dyams, should be fine with a visual
[08:47] <Saviq> unless Testability only looks in Qt apps?
[08:47] <dyams> saviq: ah, you mean finding the coordinates of a files through testability?
[08:47] <dyams> -s
[08:47] <Saviq> dyams,
[08:48] <Saviq> yeah
[08:48] <Saviq> but I'm unsure whether you can look in the whole desktop or just Qt apps
[08:48] <dyams> saviq: yeah, same here
[08:48] <Saviq> dyams, if you have other stuff to do, lets wait for greyback
[08:49] <dyams> saviq: ok
[09:09] <Saviq> greyback, hey, what's "Appoved by: "? ;)
[09:11] <Saviq> nerochiaro, hey, I've a huge conflict when merging r875 from trunk into shell
[09:12] <nerochiaro>  Saviq: let me look at what it is
[09:12] <Saviq> nerochiaro, "Refactor testing..."
[09:12] <Saviq> nerochiaro, could you maybe take care of that?
[09:13] <Saviq> OTOH...
[09:13] <Saviq> looking at the diff
[09:14] <nerochiaro> Saviq: let me try to do that
[09:15] <Saviq> should be just a matter of "replaying" your changes on top of current shell
[09:15] <nerochiaro> yes
[09:22] <Kaleo> Saviq: having fun heh
[09:24] <greyback> Saviq: mornin'
[09:24] <greyback> Saviq: what did I break now :)
[09:25] <Saviq> Kaleo, ?
[09:25] <Saviq> greyback, nuffin, just asking who made sure we have the beautiful typo in all commit messages into trunk ;)
[09:26] <greyback> Saviq: hmm, blame didrocks :)
[09:26] <didrocks> what what ? ;)
[09:27] <Saviq> didrocks, "Appoved by:"
[09:27] <didrocks> oh :)
[09:27] <didrocks> interesting!
[09:27]  * didrocks fixes one sec
[09:28] <greyback> I'd guess it's when MR set to approved without a comment or actual nominated reviewer (team chosen instead)
[09:29] <Saviq> greyback, no, it seems to be added to every tarmac-merged commit
[09:29] <didrocks> fixed :)
[09:29] <Saviq> and that's all fine, except for the missing r ;)
[09:29] <Saviq> didrocks, cool, now fix our history ;P
[09:30] <Kaleo> Saviq: do you have a crappy machine with 2 monitors?
[09:30] <Saviq> Kaleo, meaning an Atom?
[09:30] <Kaleo> Saviq: (I meant "having fun with the merge of trunk")
[09:30] <Kaleo> Saviq: well, that's a good start
[09:30] <Saviq> Kaleo, yeah, almost done
[09:30] <didrocks> Saviq: fix your code first! :p
[09:30] <Saviq> Kaleo, then yes, I can have one
[09:31] <Saviq> didrocks, I haven't written any code in the last week... reviewing, being an a$$ about missing / broken tests and stuff
[09:31] <Saviq> quite time-consuming, as it occurs
[09:31] <Kaleo> didrocks: does it mean free beer for the team? yes. thank you!
[09:31] <didrocks> Saviq: heh ;)
[09:31] <didrocks> Kaleo: come on, you did worse thing to me than a typo
[09:31] <Kaleo> didrocks: let me think
[09:31] <didrocks> like… upload qt 6 times on a week and half? :)
[09:32] <Kaleo> didrocks: that was _years_ ago :)
[09:32] <didrocks> I was remembering promissed bear!
[09:32] <didrocks> yeah, like 4 months ;)
[09:32]  * Kaleo is hiding
[09:33] <Kaleo> didrocks: did you see all these beautiful automated tests we made for you?
[09:33] <Kaleo> didrocks: it's like Christmas!
[09:33] <Kaleo> didrocks: and by 'we' I mean 'they'
[09:33] <didrocks> Kaleo: heh, you are taking credit! shameful of you :)
[09:34] <Kaleo> didrocks: I wrote part of the broken code they are writing tests for; hence the credit
[09:34] <didrocks> ahah
[09:46] <dyams|lunch> greyback: drag n drop files on launcher tile...
[09:47] <dyams|lunch> greyback: ping
[09:47] <Saviq> dyams|lunch, swallow first
[09:47] <dyams|lunch> saviq: ok
[09:47] <greyback> dyams|lunch: yep
[09:47] <Saviq> ;)
[09:48] <dyams> greyback: testing part, about initiating a file drag through testability
[09:49] <dyams> greyback: i suggested manual test for this branch.. and waiting for your opinion
[09:52] <greyback> dyams: I've never done it before, I don't know how hard it would be. I suppose you could mess around with mouse, but I doubt that would be reliable. Better would be to try to emulate the Drop event somehow.
[09:55] <nerochiaro> Saviq: merged, running tests now
[09:56] <dyams> greyback: dropping is ok, initiating the  a drag
[09:56] <Saviq> nerochiaro, great
[09:56] <dyams> greyback: and finding the coordinates of a file
[09:58] <greyback> dyams: then I don't know.
[09:59] <Saviq> greyback, my idea was to create a tmp dir with a file in it
[09:59] <Saviq> open the dir, and visually grab its coordinates
[09:59] <Saviq> but I've no idea whether we can do visual stuff outside of Qt?
[09:59] <nerochiaro> Saviq: well, not so great. one of the tests closed most of my windows
[10:00] <Saviq> nerochiaro, closed? I think Florian had that issue, too, any idea which one?
[10:00] <nerochiaro> Saviq: no, but i'm gonna find out
[10:00] <greyback> Saviq: not really. Sure we can get coordinates of a  Nuatilus window reasonably reliably, and try to guess coordinates of file icon inside. Not rock-solid but should work
[10:08] <Saviq> greyback, nah, I was thinking the coordinates of a visual asset found on screen
[10:08] <Saviq> but it only works for Qt, does it?
[10:09] <greyback> Saviq: Only for Qt
[10:09] <Saviq> dyams, go for a manual test, then
[10:09] <dyams> saviq: ok, i'll
[10:17] <Saviq> tsdgeos, your launcher dash tests conflicted
[10:17] <tsdgeos> Saviq:do they?
[10:17] <tsdgeos> in -shell you mean?
[10:17] <Saviq> tsdgeos, the merge got rejected
[10:17] <Saviq> tsdgeos, no, the tests
[10:17] <Saviq> into -trunk
[10:18] <Saviq> --
[10:18] <Saviq> +!
[10:18] <tsdgeos> unity-2d_test_dash_launcher_interactions ?
[10:18] <Saviq> yes
[10:18]  * tsdgeos checks
[10:18] <tsdgeos> probably added stuff at the end in some other test too
[10:19] <tsdgeos> yeah added stuff at the end
[10:19] <tsdgeos> and bazzar just went nuts
[10:19] <nerochiaro> Saviq: the issue seems to come from launcher/autohide_show_tests.rb . problems include: qttasserver dies, SUPER gets stuck, and lots of windows get closed when they shouldn't
[10:19] <Saviq> nerochiaro, oh
[10:19] <tsdgeos> tries to merge line by line instead of the whole block :D
[10:20] <nerochiaro> Saviq: i can't see what would cause that though
[10:20] <Saviq> nerochiaro, my qttasserver never died
[10:21] <Saviq> (btw... qttas... sounds like cock in Polish)
[10:21] <Saviq> doesn't help me thinking about it
[10:21] <nerochiaro> Saviq: lol
[10:21] <Saviq> a cockserver
[10:21] <nerochiaro> Saviq: it could be because it's started by one of the terminals that get closed
[10:21] <Saviq> oh
[10:21] <Saviq> yeah
[10:21] <Saviq> that's why it never happened to me
[10:22] <Saviq> I'm testing in a VM
[10:22] <nerochiaro> likely
[10:22] <Saviq> and Florian complained about his terminals getting closed, too
[10:22] <Saviq> let me open some before starting the test
[10:22] <tsdgeos> Saviq: merge pushed
[10:23] <Saviq> tsdgeos, ok, I'll reapprove
[10:29] <Saviq> nerochiaro, I just went through the whole suite twice :/, my terminals are still there
[10:29] <Saviq> let me try on my work desktop, though
[10:30] <nerochiaro> Saviq: i don't doubt it. it's certainly something specific to a certain machine setup
[10:30] <Saviq> nerochiaro, my guess would be that TmpWindow screws something up
[10:30] <Saviq> and kills the wrong terminal
[10:30]  * tsdgeos has the launcher showing in -shell -rtl :-)
[10:30] <tsdgeos> now let's write some tests
[10:30] <nerochiaro> Saviq: very likely
[10:31] <Saviq> tsdgeos, awesome
[10:31] <nerochiaro> Saviq: and it kills the cockserver and when it dies it stops the test mid way and leaves the SUPER key stuck
[10:31] <Saviq> nerochiaro, exactly
[10:31] <Saviq> rotfl
[10:31] <tsdgeos> well, first lets make sure the non -rtl tests still pass :D
[10:32] <Saviq> nerochiaro, tsdgeos - here's an initial plan for merging shell back into trunk http://sketchpad.cc/9yHXNLSxuI
[10:32] <Saviq> feel free to improve
[10:33] <nerochiaro> Saviq: points 6 seems the trickiest
[10:33] <Saviq> nerochiaro, yeah, but for that we have more time
[10:34]  * Saviq still needs to look at unity's approach
[10:34] <Saviq> tsdgeos, did you see? we dubbed qttasserver "cockserver" since that's ~what the pronounciation would mean in Polish
[10:35] <tsdgeos> you sick people...
[10:36] <davidcalle> TV folks, does anyone know when unity-lens-video will be in the archive?
[10:37] <davidcalle> Saviq ^
[10:38] <Saviq> davidcalle, the one we did for ubuntu-tv?
[10:38] <davidcalle> Saviq, yep
[10:38] <nerochiaro> Saviq: apart of the errors, some of the tests that from the merged branches obviously fail (for various reasons, mostly because they expect dash and launcher and not the shell). should i fix them as part of the merge from trunk or do you want another commit, MR and all
[10:38] <nerochiaro> ?
[10:38] <Saviq> davidcalle, then never
[10:38] <Saviq> nerochiaro, did you pull from shell first?
[10:38] <davidcalle> Saviq, do you know why?
[10:38] <nerochiaro> Saviq: yes. the tests i mention are new, i wrote them in that branch of trunk that i just merged
[10:39] <nerochiaro> davidcalle: because it's not a real lens, it just pulls in some fake data
[10:39] <Saviq> nerochiaro, ah ok, I've been fixing the tests as part of merging
[10:39] <nerochiaro> Saviq: i'll do that then
[10:40] <Saviq> davidcalle, it was never meant to be used / supported, at least not in the state it's in now
[10:40] <nerochiaro> Saviq: but there's also one feature that is in trunk but it's not in shell yet and so some of the tests will fail even when adjusted for shell. (in this case, trunk has the panel buttons, shell not yet). what about that one ?
[10:40] <Saviq> it needs to be designed from the ground up
[10:40] <davidcalle> nerochiaro, Saviq, ok. I'm asking because I'm working on the 'real' one at least on two scopes.
[10:40] <Saviq> nerochiaro, make that an "xtest" instead of "text"
[10:40] <Saviq> and add a FIXME there
[10:40] <Saviq> davidcalle, yes we know that
[10:40] <Saviq> well, I do
[10:41] <davidcalle> And they need a lens. :) So I guess I'm doing it too.
[10:41] <nerochiaro> Saviq: ok, sounds good. the buttons thing is in my todo for today anyway
[10:41]  * tsdgeos needs to know the desktop width from testabilty
[10:41] <tsdgeos> any idea?
[10:41] <Saviq> tsdgeos, look at Ugo's tests for shaping
[10:42] <tsdgeos> Saviq: now that i see those tests need to be ported to the new testabilty host/target divide, they still use system and such
[10:43] <Saviq> tsdgeos, true, can you add a card in the kanban?
[10:43] <tsdgeos> yep
[10:51] <Saviq> greyback needs to fix his wifis
[10:51] <tsdgeos> yep
[10:52] <tsdgeos> nerochiaro: just seen that instead of invoking xdotool like you do we can use XDo::XWindow.display_geometry
[10:53] <nerochiaro> tsdgeos: it does exactly the same thing inside, but it's probably nicer
[10:56] <Saviq> greyback, you sir need to fix your wifis :P
[11:02] <Saviq> greyback nerochiaro tsdgeos dyams: standup?
[11:02] <greyback> Saviq: I'm wired now
[11:03] <Saviq> greyback, http://sketchpad.cc/9yHXNLSxuI
[11:04] <nerochiaro> Saviq: give me a sec, i'll be right there when i'm done with a test i'm about to run
[11:12] <nerochiaro> Saviq: ok, i think i'm done with the merge from trunk into shell. i fixed all the tests that were added and disabled one. i didn't do anything about the tests that close terminals by mistake. i'm gonna push. can you please double check it's all right afterwards ?
[11:13] <Saviq> nerochiaro, sure, I wil
[11:13] <Saviq> l
[11:13] <nerochiaro> Saviq: ok, pushed
[11:20] <Saviq> nerochiaro, so "Move updateDashMode ... into QML" is done, right?
[11:22] <nerochiaro> Saviq: yes
[11:22] <Saviq> nerochiaro, do you want to take "Port input_shaping tests to target/host divide" later?
[11:23] <Saviq> or should one of us handle that?
[11:23] <Saviq> nerochiaro, the merge looks good
[11:23] <nerochiaro> Saviq: i don't think i'll have time for that
[11:23] <Saviq> ok
[11:23] <nerochiaro> Saviq: and i don't know much about host/target divide anywa
[11:24] <Saviq> nerochiaro, that's exactly the reason why you should do that ;)
[11:25] <Saviq> nerochiaro, anyway
[11:25] <Saviq> the changes to focuspath got lost from your merge?
[11:25] <nerochiaro> Saviq: if i has more weeks to work on this, i would, but i have only the rest of today
[11:25] <Saviq> nerochiaro, I know, I know, just joking
[11:25] <nerochiaro> Saviq: i merged two commits, didn't I ?
[11:26] <Saviq> let me look at qdiff instead of qlog
[11:26] <nerochiaro> Saviq: qlog shows two, one from me one from renato
[11:26] <Saviq> nerochiaro, yes, but the diff on the merge commit doesn't list the focuspath files
[11:27] <Saviq> but that might be qlog's weirdness
[11:27] <nerochiaro> Saviq: no, i think i fucked up
[11:27] <nerochiaro> Saviq: let me fix that
[11:27] <Saviq> I think you merged but didn't actually carry the diffs over
[11:27] <Saviq> nerochiaro, feel free to overwrite
[11:27] <nerochiaro> Saviq: ok
[11:28] <Saviq> bbiab
[11:28] <nerochiaro> Saviq|afk: fixed and overwritten
[11:29] <Saviq|afk> nerochiaro, thanks
[12:03] <tsdgeos> greyback: there?
[12:04] <tsdgeos> greyback: not needed anymore :D
[12:06] <greyback> tsdgeos: that's exactly what I want to hear :)
[12:06] <tsdgeos> greyback: well, actually now that you're here
[12:06] <greyback> d'oh
[12:06] <greyback> :)
[12:06] <tsdgeos> greyback: the background of the launcher is not simmetric, i.e. the last pixel in the right is transparent-ish
[12:07] <tsdgeos> greyback: i guess i just reverse and create a new png, right?
[12:07] <greyback> tsdgeos: exactly
[12:07] <greyback> tsdgeos: you could rotate the existing PNG
[12:07] <tsdgeos> but in code or do it once and load the rotated png?
[12:08] <greyback> my thinking is if there's only one asset, and designers change the background, we just need to change the asset
[12:08] <greyback> .. if we do it in code
[12:35] <tsdgeos> hmmm
[12:36] <tsdgeos> rtl question
[12:36] <greyback> shoot
[12:36] <tsdgeos> if i type a, l, b, e, r, t
[12:36] <tsdgeos> in a text field
[12:36] <tsdgeos> should i see
[12:36] <tsdgeos> albert
[12:36] <tsdgeos> or
[12:36] <tsdgeos> trebla
[12:36] <tsdgeos> i guess albert
[12:36] <tsdgeos> but i'm not really sure :D
[12:37] <greyback> the first one, but only based on what I've seen so far
[12:37] <greyback> i.e. I'm not 100% certain
[12:37] <greyback> but using other programs in RTL mode, that's the way they work
[12:37] <tsdgeos> yes
[12:38] <tsdgeos> typing rtl is weird
[12:38] <tsdgeos> as far as i understand
[12:38] <tsdgeos> if you type "normal" letters it's not rtl
[12:38] <tsdgeos> then you start typing hebrew and it starts growing in the other way
[12:38] <tsdgeos> which gets ultra confusing if you mix both
[12:38] <greyback> interesting
[12:39] <greyback> and yeah, that must take getting used to
[12:39] <tsdgeos> i don't know how people cope with that
[12:39] <tsdgeos> suddenly the "right" arrow stops going right and starts going left, because you entered a piece of text wrriten in rtl or not
[12:40] <greyback> you could get in a loop, if you write LTR text beside RTL, pressing arrow key will just have cursor just bounce between text
[12:40] <greyback> nah, that can't be right
[12:43] <tsdgeos> i've seen it happen :D
[12:44] <greyback> whoa
[12:45] <dyams> tsdgeos: you should see albert
[12:47] <dyams> tsdgeos: in non-shell rtl, you see albert if you type albert
[13:09] <Saviq> tsdgeos, yeah, even numbers are ltr
[13:09] <Saviq> tsdgeos, so that's ultra confusing
[13:09] <Saviq> as you said
[13:10] <mhall119> gord: can you take a look at http://askubuntu.com/questions/98692/how-to-add-support-for-the-global-menu-to-a-python-non-gtk-non-qt-app?
[13:57] <tsdgeos> Saviq: greyback|lunch: dyams: more rtl stuff, on the dash home, we want the firefox icon to be on the left or in the right side of the grid?
[13:58] <Saviq> tsdgeos, good question, how is it in non-shell?
[13:58] <Saviq> tsdgeos, is there anything related in the MR from Haggai?
[13:58] <Saviq> -g?
[13:58] <tsdgeos> on the left it seems, but the dash pops not closer to the launcher, so i would not take that as an authoritative answer :D
[13:58] <nerochiaro> Saviq: when you have a moment, can you please branch a repo and do a quick test for me ? i suspect there's something weird happening but i'm not sure if it's my env or the code itself
[13:59] <Saviq> nerochiaro, that's most of what I'm doing these days - branching and testing :)
[13:59] <Saviq> so yeah, throw it at me
[14:01] <nerochiaro> Saviq: lp:~unity-2d-team/unity-2d/panel-freeze << run panel, run shell, bring out the dash with super, then click on the maximize button in the panel twice. the panel should freeze and stop responding to any input
[14:01] <tsdgeos> Saviq: on the MR is on the right, so i'll take that as correct
[14:02] <Saviq> tsdgeos, cool
[14:03] <dyams> tsdgeos: Haggai branch is more helpful to verify the shell
[14:03] <greyback> tsdgeos: I wouldn't worry much about it, those home screen icons are disappearing soon
[14:03] <dyams> tsdgeos: he has fixed the dash too
[14:03] <tsdgeos> greyback: are they?
[14:04] <greyback> tsdgeos: yep, instead we'll have a "home lens"
[14:04] <tsdgeos> i see
[14:04] <tsdgeos> ok, i won't care about the brokenness in there
[14:04] <greyback> or possible nothing but a search box. Design isn't concrete
[14:04] <mhall119> didrocks: ping
[14:04] <didrocks> mhall119: hey! :)
[14:04] <mhall119> hey
[14:04] <dyams> tsdgeos: did you get shell launcher RTL working>
[14:04] <mhall119> will you have a bit of time today to talk with me about quickly and singlet?
[14:05] <tsdgeos> dyams: yes
[14:05] <dyams> tsdgeos: branch already in launchpad?
[14:05] <didrocks> mhall119: yeah, in 15 minutes?
[14:05] <dyams> tsdgeos: so how to test RTL now?
[14:05] <tsdgeos> dyams: not yet, i can put it there if you want but there's things that are missing (i.e. keyboard navigation)
[14:05] <dyams> tsdgeos: so how do you test RTL now?
[14:06] <tsdgeos> dyams: you start shell with -reverse
[14:06] <mhall119> didrocks: works for me
[14:06] <dyams> tsdgeos: ah..ok..
[14:06] <dyams> tsdgeos: keyboard nav is ok. does edge hit detection works already?
[14:07] <tsdgeos> dyams: yes
[14:07] <dyams> tsdgeos: in RTL, i mean
[14:07] <dyams> tsdgeos: ok
[14:07] <dyams> tsdgeos: ok..lemme kno when you have a branch
[14:07] <tsdgeos> sure
[14:15] <davmor2> MacSlow: Hey dude with notifyosd is there a plan for it to list the application that triggered the notification?   currently in orca it just says notification notifyosd for everything
[14:19] <Saviq> tsdgeos, can you check out these tests on your side http://pastebin.ubuntu.com/818851/ ?
[14:20] <tsdgeos> Saviq: is this the ones with the xtest?
[14:20] <Saviq> tsdgeos, no, that's just the merge from trunk
[14:20] <tsdgeos> ahh
[14:20] <tsdgeos> right
[14:20] <tsdgeos> actaully they are very very similar to the ones with the xtest :D
[14:20] <tsdgeos> i did not know the ones with the xtest were there and coded new ones
[14:21] <tsdgeos> Saviq: on -shell, right?
[14:21] <Saviq> tsdgeos, yes
[14:21] <Saviq> this is merge + port from trunk to shell
[14:22] <mhall119> didrocks: ready when you are
[14:22] <didrocks> mhall119: sorry, trying to wrap up a discussion and then discuss with you :)
[14:23] <mhall119> didrocks: sure, just ping me when you're ready
[14:25] <tsdgeos> Saviq: there's a bug in the original test
[14:25] <tsdgeos> Saviq: the last test should have a
[14:25] <tsdgeos> XDo::Mouse.move(0, 200, 0, true)
[14:25] <tsdgeos> at the beginning
[14:26] <Saviq> actually it's the first two ones that break here
[14:26] <tsdgeos> err
[14:26] <tsdgeos> actually
[14:26] <tsdgeos>     XDo::Mouse.move(200, 200, 0, true)
[14:26] <Saviq> tsdgeos, would you then fix it for trunk and I'll merge again
[14:26] <tsdgeos> i mean
[14:27] <tsdgeos> Saviq: with http://paste.kde.org/~tsdgeos/193988/ they all pass in my shell
[14:27] <Saviq> tsdgeos, have you seen "MobyBase::BehaviourError: Run failed. Failed to launch application. Exception: The application with Id 21845 is no longer available." before?
[14:27] <tsdgeos> nope
[14:27] <tsdgeos> i mean
[14:27] <tsdgeos> yes
[14:27] <greyback> Saviq: means it fails to launch the app
[14:27] <tsdgeos> happens sometimes
[14:27] <tsdgeos> Saviq: check you don't have a unity-2d-places around
[14:28] <Saviq> good idea
[14:28] <greyback> Saviq: or app shuts down itself
[14:28] <Saviq> so qttasserver should show whassup
[14:28] <Saviq> I mean cockserver
[14:28] <tsdgeos> yep
[14:28] <nerochiaro> Saviq: official name now ? ;)
[14:28] <greyback> Usually if I've old Dash running, the Shell will quit
[14:29] <greyback> Saviq: this is a family IRC channel, we'll have none of that here
[14:29] <Saviq> rotfl
[14:29] <nerochiaro> greyback: no male avians in this channel !
[14:29] <greyback> I pronounce it "cute ass server" actually ;)
[14:29] <Saviq> greyback, you owe me a napkin for cleaning my screen, and don't get any ideas
[14:30] <nerochiaro> rofl
[14:31]  * greyback has many ideas, most of which fail to pass his filth filter
[14:32] <Saviq> tsdgeos, ssoo, can you go and merge trunk into shell then?
[14:33] <Saviq> there's only your dash-launcher-interaction tests commit there
[14:33] <Saviq> tsdgeos, btw, yes, tests from that paste pass fine
[14:36] <didrocks> mhall119: ready! :)
[14:36] <tsdgeos> Saviq: what you mean with if i can merge trunk into shell?
[14:37] <tsdgeos> Saviq: this is the fix for trunk https://code.launchpad.net/~aacid/unity-2d/unity-2d_test_mouse_fixlet/+merge/90441
[14:38] <mhall119> didrocks: hangout, irc, what?
[14:38] <didrocks> mhall119: irc sounds fine
[14:39] <didrocks> mhall119: so, singlet and quickly, I think we need to go through singlet together so that I can see how I can integrate that
[14:39] <didrocks> should I take trunk?
[14:39] <mhall119> didrocks: yeah
[14:40] <mhall119> right now all Singlet does code-wise is hide the GObjects for Unity.Lens and Unity.Scope behind a python metaclass
[14:40] <Saviq> tsdgeos, `bzr switch shell; bzr merge trunk; bzr resolve; bzr push`
[14:40] <Saviq> tsdgeos, that's what I mean by merging trunk into shell
[14:40] <Saviq> tsdgeos, but let me review the above first
[14:40] <mhall119> and it handles all the signal connections automatically
[14:40] <tsdgeos> Saviq: ok
[14:40] <mhall119> but it also has an inner Meta class, like Django models, which lets you give descriptive data about your lens
[14:41] <mhall119> then it has a utility script that will convert that meta data into a .lens and .service files for the lens
[14:41] <didrocks> interesting :)
[14:42] <mhall119> so quickly would let us have templates for those .lens and .service files, and replace strings with project names, correct?
[14:42] <didrocks> mhall119: yeah, I'm pondering if we need to use this MetaClass with quickly
[14:43] <mhall119> didrocks: some of it would still be useful, because it lets you specify how the lens should behave too
[14:43] <mhall119> but the parts that are only used for generating those files we wouldn't need
[14:43] <didrocks> mhall119: ah, do you have any examples?
[14:43] <didrocks> yeah
[14:44] <didrocks> test/singlescope is the simplest lens you can create, right?
[14:44] <mhall119> didrocks: search_on_blank specifies whether the search function should be called when there isn't a search string
[14:44] <mhall119> yeah, singlescope is pretty basic
[14:45] <mhall119> there's also _order variables for category and filter
[14:45] <mhall119> and I think search_hint is used in code as well as for the .lens
[14:46] <mhall119> likely more will be added as things develop
[14:46] <mhall119> so we'll want the Meta class in some form to remain in singlet
[14:46] <didrocks> search_hint is used in the code?
[14:47] <didrocks> (not sure about what you mean by the _order variable)
[14:47] <didrocks> it's to override the default order you have setting in IconViewCategory, for instance?
[14:48] <mhall119> didrocks: it's to specify an order for the categories to be displayed in
[14:48] <mhall119> since the meta-class doesn't necessarily give them to singlet in the order they are defined in the code
[14:48] <mhall119> it passed them as an unordered dict
[14:49] <didrocks> hum? sorry, we probably don't speak about the same thing or I'm not seeing that right:
[14:49] <didrocks> cat1 = IconViewCategory("Cat One", "stock_yet")
[14:49] <didrocks> it's part of class TestLens(SingleScopeLens):
[14:49] <didrocks> (not from the Meta class)
[14:49] <mhall119> yes
[14:49] <didrocks> or is there something obvious I'm missing? :)
[14:50] <mhall119> sorry, conflicting terms
[14:50] <mhall119> Meta is just a normal inner class that holds data about the Lens we're making
[14:50] <mhall119> in this case, TestLens.Meta describes TestLens
[14:50] <didrocks> ok for that :)
[14:51] <mhall119> TestLens inherits from SingleScopeLens
[14:51] <mhall119> SingleScopeLens has a __metaclass__, which is LensBuilder
[14:52] <didrocks> ah, makes more sense :)
[14:52] <mhall119> LensBuilder is given a list of attributes in the class, this includes Meta, cat1, cat2, and search(), from this list of attribute it builds a python class at runtime
[14:52] <mhall119> the reason for category_order is because sometimes LensBuilder gets cat2 first, then cat1
[14:53] <didrocks> what's the second parameter for every category?
[14:53] <didrocks> icon
[14:53] <didrocks> ok :)
[14:53] <mhall119> yes
[14:53] <mhall119> icon
[14:53] <didrocks> this starts to make sense to me :)
[14:54] <didrocks> oh, I think you don't need to freeze_notify() or thaw_notify() with latest dee
[14:54] <didrocks> (well, the one coming in 5.2
[14:54] <didrocks> also there are some changes for "empty" search
[14:55] <mhall119> didrocks: yeah, I need to update it all to Unity5 API
[14:55] <didrocks> ok :)
[14:55] <mhall119> will 5.2 make it into Precise?
[14:55] <didrocks> yeah, next Thursday
[14:55] <mhall119> cool
[14:55] <didrocks> (freeze on Monday)
[14:56] <didrocks> did you have a look at a quickly boiler plate template ?
[14:56] <davmor2> gord: Hud + orca it doesn't read out the options as you go down them
[14:56] <gord> davmor2, i know
[14:56] <davmor2> gord: want a bug?
[14:56] <gord> AlanBell, pointed it out about five seconds after we went public
[14:56] <gord> nah
[14:56] <davmor2> gord: no probs
[14:57] <mhall119> didrocks: yeah, but I wasn't sure about how much of the .lens and .service files I could make with it
[14:58] <didrocks> mhall119: my suggestion would be that we try to remove the .lens and .service generation and put that on the boiler plate
[14:58] <didrocks> (which is named when you quickly "create")
[14:58] <didrocks> then, what we do generally is having a starting binary in bin/
[14:58] <mhall119> ok, so we'll need to fill in things like description, search hint, icon, etc
[14:58] <didrocks> and a module with project_name
[14:58] <mhall119> can we do that with quickly create?
[14:59] <didrocks> containing the other files
[14:59] <didrocks> mhall119: each commands are tied to a template
[14:59] <didrocks> so we just need to write a differente create.py :)
[14:59] <Saviq> note to self: "find -name *moved -o exec rm -R {} +" == "rm -R ."; crap.
[14:59] <didrocks> (also, not everything is mandatory)
[15:00] <mterry> njpatel, heyo.  I'm working on the unity-greeter and animating the scrolling user list.  I'm having a hard time making it smooth (fast is easy, and I have easing, but smooth as in not laggy or whatever).  Are there low-hanging gtk optimizations or common animating pitfalls I might be falling to?
[15:00] <didrocks> mhall119: so we can imagine creating a quickly "describe" command
[15:00] <didrocks> or our template
[15:00] <mhall119> ah, ok
[15:00] <didrocks> for*
[15:01] <mhall119> didrocks: would it make sense to have the custom quickly commands just generate the files like the singlet commands currently do?
[15:01] <didrocks> mhall119: the obvious question is about the src/singlet directory, do you want that being shared and commiting to some API then?
[15:01] <mhall119> or have the quickly command just call the singlet command for that matter
[15:01] <mhall119> singlet will have to become an independent package
[15:01] <mhall119> which users and developers would install
[15:01] <didrocks> mhall119: TBH, I think we shouldn't really on src/singlet/utils.py
[15:01] <tsdgeos> Saviq: greyback: guys, what's AppNameApplet used for?
[15:02] <njpatel> mterry, I guess you're scrolling gtk widgets/
[15:02] <Saviq> tsdgeos, it's the whole thing left of indicators
[15:02] <didrocks> mhall119: ok, so we remove the "generation" part from it
[15:02] <Saviq> tsdgeos, title bar / menubar
[15:02] <didrocks> and just turn it into a python module
[15:02] <mterry> njpatel, yeah, well, scrolling with custom draw code yeah
[15:02] <mhall119> didrocks: we can do away with utils.py by putting that stuff into the quickly template code
[15:02] <tsdgeos> Saviq: ah :D
[15:02] <didrocks> mhall119: exactly
[15:02] <Saviq> or in your case right now it might be: "right of indicators"
[15:02] <mhall119> that works for me, then singlet is just a runtime library
[15:02] <tsdgeos> oh right, it's on the panel
[15:02] <njpatel> mterry, the main thing is to make sure you're not causing too many expose events, which will  be slow. another thing is to just snapshot a widget and paint it's snapshot on expose, instead of making it go through it's entire paint cycle (in which it could be doing other things), again and again
[15:03] <didrocks> mhall119: excellent! and so, we need to create a boiler plate :)
[15:03] <didrocks> mhall119: I think we can keep it into one file, meaning, not having a real module
[15:03] <mhall119> didrocks: yes
[15:03]  * Saviq loves BackupPC
[15:03] <didrocks> mhall119: so, I would suggest bin/<project_name>
[15:03] <mhall119> keep what into one file, the lens code template?
[15:03] <didrocks> yeah
[15:03] <njpatel> mterry, I hope that makes sense, it's difficult to get right, through :/
[15:03] <didrocks> and this import from singlet
[15:03] <mhall119> ok
[15:04] <didrocks> then in data/ the .lens and .service
[15:04] <njpatel> mterry, the other thing is to make sure you're not accidently setting off expose/draw events outside of the widget (like accidently causing the entire window to redraw)
[15:04] <mterry> njpatel, snapshotting will be tough, as we apply a fade-out alpha as things scroll away.  Any common reasons for exposing too much?
[15:05] <didrocks> mterry: so, you told that some metadata are needed to be duplicated?
[15:05] <didrocks> oupss mhall119 ^^
[15:05] <njpatel> mterry, timers that are too fast (so you're drawing multiple times between a vsync for no reason), widgets automatically calling expose on their parents or ancestors (gtk-window), which cause the entire app to repaint
[15:06] <mterry> njpatel, my timers are 16ms.  too fast?
[15:07] <tsdgeos> Saviq: i think there's a bad merge, Dash.qml uses DashDeclarativeView.FullScreenMode, and there's no DashDeclarativeView anymore
[15:07] <didrocks> mhall119: basically, even the dbus name seems to be based on the project name (which is good :))
[15:07] <Saviq> nerochiaro, ^^
[15:07] <njpatel> mterry, one sec, let me dig up some old code to see what i did :)
[15:07] <didrocks> mhall119: maybe for the search_hint (if you need it in the code too, it can load from the .lens file? (we have to take into account the "trunk" and "installed" case)
[15:09] <Saviq> tsdgeos, lineno?
[15:09] <tsdgeos> Saviq: 68
[15:09] <tsdgeos> Saviq: well, not bad merge per se, just that needs to be fixed because of -shell is different
[15:09] <Saviq> tsdgeos, in Dash.qml?
[15:09] <Saviq> tsdgeos, looks good to me
[15:09] <tsdgeos> Saviq: yes
[15:09] <njpatel> mterry, used the same in unity, but now checking an actual gtk app
[15:09] <Saviq> tsdgeos, sure you're on current shell?
[15:09] <Saviq> not on trunk?
[15:09] <tsdgeos> Saviq: there is no more DashDeclarativeView in shell
[15:10] <Saviq> rno?
[15:10] <tsdgeos> no
[15:10] <Saviq> revno?
[15:10] <Saviq> tsdgeos, yes, and there is no DashDeclarativeView in what I'm looking at
[15:10] <njpatel> mterry, same in gwibber
[15:10] <Saviq> only ShellDeclarativeView
[15:10] <tsdgeos> ah
[15:10] <tsdgeos> ok
[15:10] <mhall119> didrocks: search_hints is set to self._lens.props.search_hint
[15:10] <Saviq> tsdgeos, sounds like you have your branches mixed up
[15:10] <tsdgeos> maybe i'm old and need to remerge
[15:10] <njpatel> mterry, i'd override some draw calls to just paint a flat colour and see if it makes a difference
[15:10] <mhall119> not sure if that's necessary or not, but it was in the example code I based my lenses off of
[15:10] <njpatel> (and then work on from there)
[15:11] <Saviq> tsdgeos, you might need to overwrite shell
[15:11] <mterry> njpatel, ok, will try
[15:11] <Saviq> tsdgeos, 'cause Ugo had an issue earlier
[15:11] <Saviq> but you'd have to be very unlucky to have gotten that
[15:11] <tsdgeos> all is fine
[15:11] <tsdgeos> i was missing a merge
[15:11] <Saviq> ok
[15:11] <Saviq> brb
[15:11] <njpatel> mterry, also, make sure no calculations/external calls are happening in any of the draw() overrides as much as possible, as that'll slow things down
[15:11] <didrocks> mhall119: I think maybe it's when you want to override the search_hint in the .lens file, mhr3 ? ^
[15:11] <mhall119> didrocks: maybe
[15:11] <mhall119> I just cargo-culted stuff from davidcalle
[15:12] <mterry> njpatel, I do do some calculations for easing...  Is there a trick to calculate those up front or something?
[15:12] <mhr3> didrocks, mhall119 what's the issue?
[15:12] <didrocks> mhall119: let's see if it's useful, if it's not, I think we can avoid putting a value by default to not override the .lens file (but still let it so that people who wants to override can)
[15:13] <mhall119> mhr3: is setting self._lens.props.search_hint in lens code necessary if we have a search_hin in the .lens file?
[15:14] <njpatel> mterry, they should be okay, normally you'd calculate the overall factor or progress when the timeout callback is called, before queue_draw() is called, though, as I said, it's just mathes, I don't think it'll be that bad
[15:14] <mhr3> mhall119, i think so, the string from the lens file is used only before the lens loads... although it might ignore an empty string coming from a lens... not sure
[15:15] <didrocks> mhall119: if you can test with an empty text, that would be interesting
[15:15] <nerochiaro> Saviq: tsdgeos: i think i fixed that
[15:15] <mhall119> mhr3: the string in the .lens is only used before it loads?
[15:15] <didrocks> in that case, no need to read from the .lens file
[15:15] <davidcalle> mhr3, is set_reply_hint supposed to work now?
[15:15] <tsdgeos> nerochiaro: yes, sorry, my bad, it's all ok
[15:15] <mhall119> didrocks: I'll need to update singlet to unity5 before I can test
[15:15] <nerochiaro> tsdgeos: ok, great
[15:15] <mhr3> davidcalle, sending over dbus? yes; displaying it? no
[15:15] <davidcalle> mhall119, let me check.
[15:16] <davidcalle> mhr3, ok :)
[15:16] <mhall119> didrocks: so the next concern is making sure that the packaging we generate is appropriate for submitting lenses to the ARB
[15:16] <didrocks> mhall119: yeah, I think this is 1. ;) 2. is to put the lens boiler plate, using a packaged singlet module in one file (not very different to your test/ file)
[15:16] <mhall119> stuff like putting things in /opt/
[15:16] <didrocks> mhall119: yeah, that's one of the issue
[15:16] <didrocks> mhall119: the .lens detected by unity are only in /usr
[15:16] <didrocks> mhall119: and some for the .service file
[15:16] <mhall119> right
[15:16] <mhr3> mhall119, that's how i understood it
[15:16] <didrocks> same*
[15:17] <didrocks> mhall119: the unity one can be easy, the dbus service…
[15:17] <mhall119> should still be easy, shouldn't it?
[15:17] <didrocks> I'm trying to warn the ARB for that since it's created
[15:17] <didrocks> mhall119: politically, it's difficult :
[15:17] <didrocks> :)
[15:17] <mhall119> but not difficult to put stuff in /usr/share/unity?
[15:17] <didrocks> ah
[15:17] <didrocks> no :)
[15:17] <didrocks> but I guess the ARB didn't want that?
[15:18] <mhall119> davidcalle: for your lenses/scopes, where did you put the .lens and .service files?
[15:20] <davidcalle> mhall119, didrocks : about the search_hint : if the .lens file is empty string, it picks up from the daemon. If the daemon is empty string, nothing is ever displayed.
[15:20] <mhall119> ok, so didrocks I think we can just have that in the code template and not in the .lens
[15:21] <didrocks> mhall119: or singlet can read it from the .lens file?
[15:22] <nerochiaro> Saviq: please ignore the branch i asked you to test earlier. I instead pushed a workaround for that issue I mentioned and put everything for review at https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-panel-dash-buttons/+merge/90450  (this supercedes the old panel buttons for dash MR you already reviewed)
[15:22] <didrocks> davidcalle: thanks for the info ;)
[15:22] <nerochiaro> Saviq: there's a fixme in the code where the workaround is
[15:22] <mhall119> it doesn't seem the search_hint in the .lens does much
[15:22] <davidcalle> mhall119,  both in /usr/ with every file name prefixed by "extras-"
[15:22] <mhall119> davidcalle: ah, was that the ARB's approved solution?
[15:22] <nerochiaro> Saviq: also i'm gonna submit the new buttons assets as a separate MR, since it's not strictly related to just bringing back the buttons functionality
[15:23] <didrocks> mhall119: oh, you want completely removed from the .lens file?
[15:23] <didrocks> mhall119: that would make sens as it's shouldn't be displayed before the lens daemon is started
[15:23] <mhall119> yeah
[15:23] <didrocks> ok, let's do that for now (so not in the .lens file)
[15:24] <didrocks> mhall119: ok, so I think unfortunately for you that the 2 first steps are for you :)
[15:24] <davidcalle> mhall119, yes. If you are still on Oneiric, you can install unity-lens-utilities for usc and check what it looks like in /usr/share/unity/lenses . It ain't pretty :)
[15:24] <didrocks> 1. bump to 5.0 api
[15:24] <davidcalle> s/for/from
[15:24] <didrocks> 2. have singlet as a python module and a boilerplate in bin/ using it (and no more generation of a .lens file)
[15:25] <mhall119> didrocks: /w 41
[15:25] <mhall119> bah
[15:25] <didrocks> :)
[15:25] <didrocks> we don't handle the case if someone wants to change the dbus name?
[15:25] <didrocks> (that's where reading from the .lens file can help)
[15:25] <mhall119> didrocks: aah, that was another one that was in both code and .lens
[15:25] <didrocks> or we have a defined name based on lens name from the start?
[15:26] <didrocks> yeah, we can either:
[15:26] <didrocks> - force it or fix it
[15:26] <didrocks> s/or/and
[15:26] <didrocks> - or we can put in the .lens file and read from there
[15:26] <mhall119> I think we make a sane default in both, based on the project name, and if they want to change it they'll have to change it in both
[15:26] <didrocks> agreed
[15:27] <didrocks> do you agree with the 2 first steps? Then, I'll try to turn your bin/ file to a quickly template, creating the .lens, .service and generating the code, packaging…
[15:28] <mhall119> didrocks: yeah, should I package singlet for universe or extras?
[15:28] <didrocks> mhall119: I would say it can be in universe
[15:28] <tsdgeos> Saviq: ping
[15:28] <mhall119> ok
[15:29] <mhall119> didrocks: sounds good to me then
[15:29] <didrocks> mhall119: ping me if you need review/sponsoring :)
[15:29] <tsdgeos> greyback: ping to you too
[15:29] <mhall119> didrocks: s/if/when/
[15:29] <didrocks> heh ;)
[15:30] <didrocks> mhall119: thanks a lot, I think we have a good plan :)
[15:30] <mhall119> cool, thanks for the help
[15:30] <mhall119> hopefully I'll have time to start hacking on singlet again today
[15:30] <Saviq> tsdgeos, yeah, here
[15:30] <greyback> tsdgeos: here
[15:31] <tsdgeos> greyback: Saviq: so i think i'm on a point in which the rtl that is missing in -shell is the same that is missing in non shell, i.e. i'm starting to merge stuff from the MR of hagggai
[15:31] <Saviq> tsdgeos, please have a separate MR for that
[15:32] <tsdgeos> greyback: Saviq: so i'm wondering what you guys prefer me to do, add his stuff in my code or just push the code i have now?
[15:32] <Saviq> tsdgeos, push what you have now
[15:32] <tsdgeos> makes sense
[15:32] <tsdgeos> i was in "fix all rtl mode" :D
[15:32] <Saviq> yeah :)
[15:32] <greyback> woo RTL people will love you
[15:34] <tsdgeos> Saviq: so that merge you wanted me to do, still want me to do it?
[15:34] <Saviq> tsdgeos, I was waiting for tarmac to pick up the latest MR
[15:34] <tsdgeos> Saviq: ah, ok
[15:34] <Saviq> it doesn't seem to have done that yet
[15:35] <Saviq> or did it...
[15:35] <tsdgeos> i got the mail
[15:35] <tsdgeos> so it probably did
[15:35] <Saviq> I didn't
[15:36] <Saviq> ok then let me try again and I'll let you know if I fail
[15:36] <Saviq> tsdgeos, you grab something from kanban afterwards
[15:36] <tsdgeos> i found another bug regargind focus handling
[15:36] <tsdgeos> going to tackle that now
[15:37] <Saviq> yep saw that
[15:38] <tsdgeos> Saviq: greyback: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/+merge/90455
[15:39] <didrocks> mhall119: good luck with the hacking :)
[15:39] <Saviq> tsdgeos, re input shaping, you don't seem to have done anything with the mask
[15:40] <tsdgeos> Saviq: i haven't but i can click on the dash, i.e. "it works"
[15:40] <Saviq> tsdgeos, I mean just the corner
[15:40] <Saviq> it has the rounded mask applied
[15:40] <Saviq> if you haven't touched it
[15:41] <Saviq> it will be... cutting off the right hand part of the dash
[15:41] <tsdgeos> looks fine i think
[15:42] <Saviq> tsdgeos, it looks fine, yes
[15:42] <Saviq> but try putting a gedit window behind the dash
[15:42] <Saviq> and move your mouse close to the lower corners of the dash
[15:42] <Saviq> or use tests/getshape to get a PNG of the window's shape
[15:42] <Saviq> you'll see what I mean
[15:43] <tsdgeos> ah, i see what you mean
[15:43] <tsdgeos> ok, put it to needs fixing :D
[15:43] <Saviq> yup
[15:44] <Saviq> huh, you got linked to https://bugs.launchpad.net/unity-2d/+bug/920894 ...
[15:44] <tsdgeos> so the getshape thing tests that?
[15:44] <ubot5`> Launchpad bug 920894 in unity-2d "wrong use-struts key in gsettings schema causes gsettings-data-convert crash" [Undecided,Fix committed]
[15:44] <Saviq> tsdgeos, yes
[15:45] <tsdgeos> i did?
[15:45] <Saviq> tsdgeos, think that's some LP's weirdness
[15:45] <Saviq> tsdgeos, getshape gets a window's shape from X and puts it into a png
[15:45] <tsdgeos> Saviq: probably due to revision 936
[15:45] <tsdgeos> the LP thing i mean
[15:45] <Saviq> tsdgeos, yeah, why is that there btw?
[15:46] <Saviq> nerochiaro's tests generate the "expected" input shape with imagemagick
[15:46] <Saviq> and then compare the two images
[15:46] <tsdgeos> because it did not let me do a message log on commit
[15:46] <tsdgeos> i did merge
[15:46] <tsdgeos> commit
[15:46] <Saviq> oh
[15:46] <tsdgeos> and did "autocommit" without a message log
[15:46] <Saviq> interesting
[15:46] <Saviq> nvm
[15:46] <tsdgeos> don't know why
[15:46] <Saviq> tsdgeos, btw, did you do anything to get -reverse working properly or did it just happen for you?
[15:47] <nerochiaro> Saviq: sometimes the shape is generated with IM, sometimes it's a fixed image, sometimes a combination of both
[15:47] <tsdgeos> Saviq: just works
[15:47] <Saviq> nerochiaro, yeah yeah, I was oversimplifying
[15:47] <nerochiaro> Saviq: oh, ok, thought there was a problem with it (wasn't reading all the scrollback)
[15:48] <Saviq> nerochiaro, nah, I was just describing how the tests work and what getshape is for
[15:49] <Saviq> tsdgeos, all in all, you just need some RTL tests in input_shaping.rb, too
[15:49] <tsdgeos> Saviq: yep
[15:49] <Saviq> should be easy to adapt them
[15:50] <greyback> tsdgeos: how do you set RTL mode in the tests?
[15:50] <tsdgeos> greyback: -reverse
[15:50] <nerochiaro> Saviq: MR for new panel button assets submitted separately as https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-panel-newbuttons/+merge/90458
[15:51] <Saviq> nerochiaro, thanks
[15:51] <greyback> tsdgeos: ahh, I didn't know about that
[15:52] <Saviq> greyback, yeah, that was a pro tip from a proper Qt coder, not like us, only doing fun QML stuff ;)
[15:53] <Saviq> tsdgeos, the home screen in RTL is moved to the right, did you just ignore that due to home screen being replaced soon or?
[15:53] <tsdgeos> Saviq: yes
[15:53] <tsdgeos> Saviq: there's a comment in there ;)
[15:53] <greyback> Saviq: :P
[15:53] <Saviq> ooh fun stuff
[15:54] <Saviq> tsdgeos, ok, I was only going functional on it
[15:54] <Saviq> you can go left from the lens bar into the launcher
[15:54] <tsdgeos> Saviq: sure, from that point on, nothing works
[15:54] <tsdgeos> left is right and right is left
[15:54] <tsdgeos> and your world is sad
[15:54] <tsdgeos> that's what haggais MR fixes
[15:54] <cyphermox> how do I enable debug mode for Unity, to display the debug messages from LOG_DEBUG .... ?
[15:57] <Saviq> tsdgeos, yeah, I know, but I mean that you _can_ go from lens bar to launcher
[15:57] <Saviq> which shouldn't happen, left or right
[15:57] <Saviq> kanban card added
[15:57] <tsdgeos> shouldn't happen?
[15:57] <tsdgeos> oh :D
[15:58]  * tsdgeos actually likes it
[15:58] <Saviq> tsdgeos, design doesn't
[15:58] <tsdgeos> just don't tell them ;-)
[15:58] <Saviq> tsdgeos, I would like to be able to navigate between launcher and dash, sure
[15:58] <Saviq> not sure there's a huge usecase, though
[15:59] <tsdgeos> not really
[15:59] <Saviq> and definitely not when you can only go from the lens bar
[15:59] <Saviq> and not the rest of the dash
[15:59] <Saviq> it's a leftover from tv, really
[15:59] <tsdgeos> yep
[16:01] <Saviq> tsdgeos, re getshape bindir, you had to have that for out-of-source builds?
[16:01] <tsdgeos> Saviq: nerochiaro: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_get_shape_builddir/+merge/90462 for weirdos like me? pretty please
[16:01] <tsdgeos> Saviq: yep
[16:01] <greyback> tsdgeos: your autohide test file is broken, the comments are missing from line 176 on
[16:01] <Saviq> tsdgeos, no weirdos at all, I'm going to build out of source very soon, too
[16:02] <Saviq> tsdgeos, esp. moving between shell and non-shell
[16:02] <Saviq> is a pain
[16:02] <tsdgeos> greyback: hmmm, which file?
[16:02] <greyback> tsdgeos: ./launcher/autohide_show_tests_rtl.rb
[16:04] <nerochiaro> tsdgeos: sorry, i'm not sure what you need there
[16:04] <tsdgeos> greyback: wops
[16:05] <tsdgeos> nerochiaro: it's just so that i can build in a different dir
[16:05] <tsdgeos> it's the same way we get the paths in run-tests.rb
[16:05] <tsdgeos> i did not invent anything, just copied from greyback
[16:06] <Saviq> hey all, EOW for me, have a great weekend and see you next week
[16:06] <greyback> Saviq: have a good one
[16:06] <greyback> tsdgeos: in MM, the launcher tooltips are showing on the wrong monitor
[16:07] <nerochiaro> tsdgeos: didn't test it, but makes sense to me
[16:07] <tsdgeos> greyback: err? me?
[16:07] <greyback> tsdgeos: is there any other tsdgeos here :)
[16:07] <tsdgeos> greyback: no, but what does MM have to do with me?
[16:07] <tsdgeos> greyback: or you mean rtl + MM ?
[16:08] <greyback> tsdgeos:  yep
[16:08] <greyback> I'm reviewing your RTL stuff now
[16:08] <tsdgeos> greyback: and it works with current unity-2d ?
[16:08] <greyback> tsdgeos: I believe so, lemme check
[16:08] <tsdgeos> greyback: take into account i only made it work the same as unity-2d, which is almost "not working at all"
[16:09] <greyback> tsdgeos: actually I'm wrong, it's broken there too. My bad
[16:10] <tsdgeos> greyback: ok
[16:10] <tsdgeos> greyback: added you to https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_get_shape_builddir/+merge/90462 too
[16:10] <greyback> tsdgeos: ok
[16:31] <tsdgeos> nerochiaro: fancy a small discussion about getshape tests?
[16:37] <nerochiaro> tsdgeos: i'm in a meeting now
[16:37] <tsdgeos> ok
[16:38] <tsdgeos> nerochiaro: morning then
[16:38] <tsdgeos> happy WE to all
[16:38] <tsdgeos> nerochiaro: next week i mean :D
[16:38] <nerochiaro> tsdgeos: ok, monday morning. happy weekend
[16:38] <nerochiaro> hope it doesn't rain
[16:38] <nerochiaro> i've got a calcotada going ;)
[18:50] <bil21al> how to install indicator time and date in unity ?
[18:51] <Daekdroom> indicator-datetime package, s9iper1
[18:52] <s9iper1> daekdroom:can you tell me the exact commend?
[18:53] <Daekdroom> s9iper1, sudo apt-get install indicator-datetime
[18:53] <s9iper1> daekdroom:thanks
[19:14] <s9iper1> om26er: is the unity hud is for precise with unity 5.0  or also support 11.10
[19:14] <s9iper1> ?
[19:14] <om26er> no its for precise only
[19:14] <s9iper1> ok thanks
[22:51] <AlanBell> I am doing a bit of messing about with ccsm to make it more robust, smooth off any rough edges and sharp corners etc
[22:51] <AlanBell> what I am finding is that changing a plugin activation status unloads and loads the whole stack, which often segfaults like this http://paste.ubuntu.com/819346/
[22:52] <mhall119> that seems excessive
[22:53] <AlanBell> it looks to me like unity is not cleanly unloading itself and leaves hanging pointers to things and causes it all to fail in a most undignified way
[22:55] <AlanBell> mhall119: I am not 100% sure it is intentionally unloading and reloading the stack, but I think it is. Plugin loading order is kind of important for some of them
[23:06] <mhall119> ah, is this a lazy way of avoiding calculating dependency resolution?
[23:08] <mhall119> AlanBell: if those are nux bugs, please let me know when you file them so I can keep track of it
[23:09] <AlanBell> I have no idea if they are nux bugs. They look like they are happening in C++ code, therefore are not CCSM's fault
[23:09] <mhall119> right, but we still need bug reports to fix them
[23:09] <mhall119> maybe if we fix those, ccsm won't segfault anymore
[23:09] <AlanBell> might be unity failing to release some nux based assets
[23:10] <AlanBell> I will try and reproduce it on a cleaner machine
[23:13] <AlanBell> as far as I can make out when a plugin is turned on or off it itterates through the list of all plugins which are supposed to be active, and calls plugin.Read()
[23:15] <AlanBell> which I suspect tells the plugin to read and apply it's changed config settings, and enables it if it wasn't previously enabled. At this point everything vanishes from the screen, the segfault happens and after a while it all comes back (sometimes with a bit of prompting from a tty session)