[09:56] <didrocks> hey mmrazik|otp, I've a small question :)
[09:56] <mmrazik> didrocks: whats up?>
[09:56] <didrocks> what was the fix from going from ~100 tests failing like https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-trunk/label=master,machine_name=dx-autopilot-intel/382/testReport/
[09:56] <didrocks> to ~30
[09:56] <didrocks> in the 383 run
[09:57] <mmrazik> didrocks: we are running the autopilot tests from Utah/script. We need to export DISPLAY etc there as it is not executed directly from the session
[09:57] <mmrazik> didrocks: it turned out that in such environment autopilot is unable to use compiz-config
[09:57] <mmrazik> and there were tests which are e.g. changing the HUD invcation key via compiz-config
[09:57] <didrocks> mmrazik: hum, I'm afraid thta if it's not running from the session, you will have more test failing because of that
[09:57] <didrocks> like you miss the real dbus session config
[09:58] <didrocks> and other small env issues
[09:58] <mmrazik> didrocks: might be the case. I was briefly talking with thomi about it yesterday. He has an idea to run it from  /etc/xdg/autostart
[09:58] <didrocks> mmrazik: yeah, that would be way better to test on a real config
[09:59] <mmrazik> didrocks: but so far we seems to be fine with regard to environment variables
[09:59] <didrocks> maybe that's why you don't have the migration of keys in compiz
[10:54] <mvo> quick question: where does unity store the launcher items ? is that dconf and com.canonical.unity.launcher.favorites?
[10:59] <mhr3> yep
[11:05] <mvo> thanks! I
[11:06] <mvo> my next question would be: is it somehow possilbe (e.g. via setting of the plugin load path or something) to run unity from the bzr build dir? i.e. (cd build ; ./bin/unity) ? it runs for me, but appears to be not picking up my changes in e.g. launcher
[11:12] <seb128> mvo, looks like http://unity.ubuntu.com/getinvolved/development/unity/ has some wrappers/details on how to do that
[11:13] <seb128> mvo, but unity is a compiz plugin, you might need to copy the .so in the .compiz dir or something
[11:24] <mhr3> mvo, i suggest running the component you're interested in by itself (./launcher/launcher etc)
[11:28] <seb128> mhr3, hey
[11:29] <seb128> mhr3, https://bugzilla.gnome.org/show_bug.cgi?id=686059
[11:29] <seb128> mhr3, is unity double forking as well?
[11:31] <mhr3> seb128, we're just calling glib, which doesn't use DO_NOT_REAP_CHILD
[11:31] <didrocks> Mirv: I guess you did notice that the tests don't pass anymore on arm* making the build failing
[11:32]  * didrocks prays for ci having finally an arm build
[11:32] <seb128> mhr3, that's the fix for gnome-panel: http://git.gnome.org/browse/gnome-panel/commit/?id=76acc5b955b214420a32c827db433ff5ab136c6f
[11:32] <mhr3> seb128, see the comment:
[11:32] <mhr3> It still an incomplete fix for gnome-panel though, as you might have .desktop
[11:32] <mhr3> files using "Exec=pkexec foo" and starting such an application via the menu
[11:32] <mhr3> still fails.
[11:33] <seb128> mhr3, see the further comments :p
[11:33] <seb128> mhr3, or the dummy_child_watch hacks in the patch
[11:34] <mhr3> can't say i like it really
[11:34] <mhr3> it they don't want to reap, do it directly in glib
[11:37] <mhr3> seb128, and iirc now if the parent process does something bad it can burn the child as well
[11:38] <seb128> mhr3, hum, k
[11:38] <seb128> mhr3, you should open a glib bug about it ;-)
[11:39] <mhr3> i'm not really sure what's the correct behaviour, reaping is fine imo, pkexec is being stupid
[11:40] <mhr3> but then again, i'm sure they have reason why they require non-init ppid
[11:42] <seb128> well, we need to address it one way or another, as you say I guess they have reason and will not change pkexec
[11:42] <seb128> so we either need to do the workaround GNOME did (they did the same in shell btw) or to get glib "fixed"
[11:42] <seb128> we can't just sit on "ok, users can't run those under unity"
[11:44] <mhr3> seb128, if the issue was easy to fix it'd be fixed long time ago :)
[11:44] <mhr3> afaict the thing panel/shell are doing aren't exactly safe
[11:44] <seb128> mhr3, which is why I pointed the workaround :p
[11:44] <Mirv> didrocks: yes, that was noticed, although no solution yet. it's good indeed that those are now run for arm
[11:44] <seb128> mhr3, what are you concerned about? is that a theorical issue or a practical one?
[11:45] <mhr3> as i said the parent dieing might affect the child when it's not reaped
[11:46] <mhr3> so for shell it's not really an issue, if shell dies you're screwed eitherway
[11:46] <mhr3> but if apps lens dies, it's no biggie, you wouldn't like if that killed all the apps you started
[11:50] <didrocks> Mirv: it's in the ppa, so in trunk
[11:50] <didrocks> Mirv: it's not run for arm on jenkins :/
[11:51] <seb128> mhr3, hum, right
[11:52] <mhr3> seb128, then again, it's not like every signal was propagated, it might be just sigterm
[11:53] <mhr3> still, doing `killall unity-applica...` and that killing all your apps isn't exactly nice
[11:53] <seb128> mhr3, not acceptable indded
[11:54] <mhr3> seb128, i guess gnomies expect that people don't killall the panel or something :P
[11:55] <ricotz> mhr3, hi, interesting i should remember that ;) since plank suffers from this problem too
[11:57] <mhr3> seb128, i think talking to davidz will be best, seems he'd know about pkexec :)
[11:57] <seb128> mhr3, yeah
[14:19] <larsu> me4oslav, hi :)
[14:20] <me4oslav> so me and larsu we're just talking about system settings > printing. So, what we have now officially as a design spec is this by mpt: https://wiki.ubuntu.com/Printing
[14:21] <me4oslav> I expanded it a bit: https://picasaweb.google.com/100530892038948253747/SystemsSettingsPrinting
[14:21] <larsu> me4oslav, I really like the default/shared thing in the list box
[14:22] <larsu> I wonder how much room it would take away from the printer names, though
[14:22] <larsu> in your mockup, it takes 50% of the width
[14:23] <me4oslav> yeah, my changes include "Sharing" in the combobox and the "default" and "share" in the list box. And how much space it take is relevant to the number of printer the suer has
[14:23] <me4oslav> but generally that "default|share|printer" box is ~ 1/2 the size of the +- bar below
[14:24] <larsu> oh, I mean horizontal space
[14:24] <larsu> printer names can be quite long
[14:24] <larsu> I don't mind the header at all :)
[14:25] <larsu> mpt, I guess that's the reason you put "Set as Default" at the bottom?
[14:25] <me4oslav> well, the listbox vary can be longer if needed :)
[14:26] <larsu> true, and maybe that's not even that much of a problem, now that we have a pretty wide system settings window
[14:26] <mterry> didrocks, just go ahead and reject g-c-c-unity, I'll fix and upload
[14:26] <didrocks> mterry: ok, thanks!
[14:26] <larsu> me4oslav, in general, I much prefer radio buttons over the check item on the right side
[14:27] <larsu> me4oslav, what do you mean by "sharing type"?
[14:27] <me4oslav> larsu - me too (and that's how the Bootloader design spec uses (the "header")
[14:27] <larsu> ah, right!
[14:28] <me4oslav> about the sharing - I litterally have no clue about sharing
[14:28] <me4oslav> if anyone cantell me how ways of sharing a printer I will update the design
[14:28] <me4oslav> I only know network printing sharing and that's it
[14:29] <larsu> it's generally just one binary decision: expose this printer to the network or not
[14:30] <me4oslav> so, nothing else, but network sharing?
[14:30] <me4oslav> perfect, that will make the design much easier
[14:31] <me4oslav> so, the user checks "shared"
[14:31] <me4oslav> than select to witch network to share it
[14:32] <me4oslav> (that will make the combobox jump from "Printer Status" to "Sharing")
[14:32] <larsu> I've never seen that anywhere, but it's an interesting idea
[14:32] <larsu> i.e. share this printer in my home network but not at work?
[14:32] <mpt> hi me4oslav
[14:32] <me4oslav> oh, hi mpt
[14:33] <me4oslav> larsu - so, a printer can be shared in two or more networks?
[14:34] <larsu> me4oslav, no, not right now. I just found the idea interesting :)
[14:34] <me4oslav> that would just mean that the radio buttons on my second sketch should become checkboxes and that'll be enough :)
[14:34] <larsu> right - but CUPS doesn't support that at all afaik
[14:35] <me4oslav> cups doesn't support multiple networks sharing?
[14:35] <larsu> no, a printer is either shared, or not
[14:35] <mpt> larsu, yes, I put "Set as Default" at the bottom because using radio buttons would eat valuable space, and changing the default is a rare thing
[14:35] <mterry> didrocks, back in NEW
[14:35] <didrocks> mterry: will have a look soon. Thanks :)
[14:36] <mpt> larsu, or at least, something that usually isn't done more than once a month or so
[14:37] <me4oslav> I thought the same, but then again I changed it, because I have "Shared" there too and though - would look weird with just "Shared"
[14:37] <larsu> mpt, makes sense. It leads to the same weird situation that we have in the session menu though: I don't know what that check mark means :P
[14:37] <larsu> well, not exactly the same: the session menu has both the check mark and a radio button
[14:38] <mpt> larsu, true, that's a cost.
[14:39] <me4oslav> well, so we have one compromise or another
[14:39] <me4oslav> taking bit of space or having that checkmark
[14:41] <me4oslav> the question I think should be which one is better when it comes in terms of consistency
[14:41] <me4oslav> is the checkmark thing-y used anywhere else?
[14:41] <larsu> me4oslav, yes, in the session menu
[14:42] <me4oslav> right - we have that in the session menu and we have the radio in Bootloader design specs
[14:43] <me4oslav> another way to look at this is we have just "shared|printer" and we have "set as default" + checkbox
[14:44] <me4oslav> mpt - hmm, the checkmark overlaps the printer name on the right side?
[14:45] <mpt> me4oslav, yes, but only for the one that's the default at the moment
[14:45] <me4oslav> yeah, so we either eat space with the radio or overlap the default printer name, right?
[14:48] <me4oslav> I'm not sure I like that overlapping thing-y, I would prefer having a bit longer printing pane and eating bit of space
[14:52] <me4oslav> anyway, apart from default thing-y, mpt larsu - your thoughts on "shared"?
[14:52] <didrocks> mterry: do you know if anything changed recently? I see when bzr bd on unity dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1)
[14:53] <mpt> me4oslav, I don't know. On the one hand, it seems to me that turning sharing on/off would be even less common than changing the default. On the other hand, seeing whether sharing *is* on may be valuable for troubleshooting.
[14:53] <didrocks> I guess it's because we use the 6.12 tarball from the last SRU
[14:53] <larsu> me4oslav, I think it should only be the checkbox for now. The same horizontal-space argument applies: I like it in the list box because it gives a good overview over which printers are shared, but it eats horizontal space
[14:53] <didrocks> I wonder how the merger is working
[14:54] <didrocks> I guess it's pushing different tarballs and not fetching latest one :)
[14:54] <larsu> mpt, do you think sharing on an per-printer basis makes sense even?
[14:54] <mterry> didrocks, yeah I think that's harmless.  I've seen it too
[14:55] <didrocks> yep
[15:03] <mpt> larsu, is that not the case currently?
[15:03] <larsu> mpt, right now you can do both: turn on sharing globally or per-printer
[15:03] <larsu> I don't know the exact semantics right now
[15:04] <larsu> like, what happens when no printer is marked as "shared" but the global sharing switch is turned on
[15:04] <mpt> hmm, that's a challenge
[15:04] <larsu> I think we should either do one or the other, but not both
[15:06] <mpt> larsu, most of the time -- not for hobbyists, but for vast corporate installs -- a printer listed will be one that's shared with you, and you don't have the ability to choose whether it's shared or not, right?
[15:06] <larsu> mpt, right.
[15:06] <me4oslav> wait a sec guys - how does one turn sharing globally?
[15:08] <larsu> me4oslav, in system-config-printer (the window that starts right now when you click "Printers" in system settings): Server (menu item) / Settings / "Publish shared printers connected to this system"
[15:09] <me4oslav> right-y and do we have any of that stuff in the new design specs?
[15:09] <larsu> nope
[15:11] <me4oslav> right and do we need it? What I have in my "sharing pane" is just where to share a printer (in which network)
[15:13] <larsu> I don't know -- I just asked mpt about it :)
[15:14] <me4oslav> same story, if we need it, than we have a challenge
[15:14] <me4oslav> but I have no clue if we actually need it
[17:35] <didrocks> mterry: g-c-c-u is now accepted in proposed (in universe)
[17:35] <didrocks> not sure if we really need a MIR, as it's code already in the distro, I think we can promote it directly
[17:36] <mterry> didrocks, sure
[17:37] <didrocks> mterry: I'm waiting it to migrate to the release pocket (probably tomorrow), not sure what bad things can happen if I promote it if it's copied meanwhile in the release pocket :)
[17:37] <mterry> didrocks, it doesn't conflict with any of the files in g-c-c, but with both installed at same time, you'll have two appearance capplets
[17:38] <mterry> didrocks, so it would be nice to coordinate the seeding of this with an update of g-c-c
[17:38] <didrocks> mterry: yeah, I read the code and how you renamed it :)
[17:38] <didrocks> mterry: agreed, let's do that tomorrow?
[17:38] <mterry> sure
[17:38] <mterry> didrocks, is the 3.6 update ready?
[17:38] <didrocks> great
[17:38] <seb128> didrocks, mterry: not yet but I'm aiming at having it this week
[17:38] <didrocks> mterry: hum, I'm not sure, seb128 should know
[17:38] <seb128> just keep it in universe until then
[17:39] <mterry> seb128, k
[17:39] <didrocks> so let's do with that update
[18:47] <Trevinho> mterry: updated this https://code.launchpad.net/~3v1n0/bamf/remove-gtk2/+merge/134537 ;)
[18:48] <mterry> Trevinho, nice, looking
[19:14] <Trevinho> mterry: thanks
[22:20] <balloons> thomi, whenever your around ping me if you would :-)
[22:21] <thomi> balloons: I'm around now :)
[22:21] <balloons> sweet :-)
[22:21] <balloons> So I'm going to try and put together some resources towards using autopilot to automate some of our manual testcases, and then ubiquity
[22:22] <thomi> cool :)
[22:22] <balloons> I've been messing around with autopilot and have a couple questions I guess  I can ask you now
[22:22] <thomi> fire at will :)
[22:23] <balloons> ok, so I tried to put together a non-unity testcase and get it to run
[22:24] <balloons> In digging around, I had success instantiating  UnityTestCase -- but I'm curious if there's something better I can use
[22:26] <balloons> let me give you a little snippet
[22:26] <balloons> this was the simplest example I could put together: http://paste.ubuntu.com/1371255/
[22:28] <thomi> one second...
[22:30] <balloons> no worries..
[22:30] <thomi> balloons: OK, so if you're trying to create a non-unity test case, you should use autopilot.testcase.AutopilotTestCase
[22:30] <thomi> it contains 'self.keyboard' and 'self.mouse' and none of the Unity-specific stuff
[22:31] <balloons> thomi, ok. I figured there was a generic one.. I didn't see it :-)
[22:31] <balloons> so my first goal was to show how to use the keyboard and mouse commands to automate stuff.. then move into introspection
[22:31] <thomi> yeah - I need to get the docs re-built and uploaded.
[22:31] <thomi> yeah, sounds good
[22:32] <balloons> excellent. So have you spoken with the xpresser folks post-UDS yet?
[22:32] <balloons> or should I just push some patches to X11.py?
[22:32] <balloons> :-p
[22:33] <thomi> balloons: what patches? The conclusion was that we should integrate the image matching parts of xpresser into autopilot.... but so far it's not on anyone's immeadiate TODO list...
[22:34] <balloons> thomi, I could add the stuff I want / need.. I already wrote a proof of concept python app to do the X11 stuff I wanted
[22:35] <thomi> balloons: I'm not aware that anything is missing - what specifically do you need?
[22:35] <thomi> it might already be there :)
[22:35] <balloons> basically performing checksums, reading pixels, etc.. that's the biggest missing piece from autopilot if I'm remembering correctly
[22:35] <thomi> ahhh
[22:35] <thomi> right, sounds like we need to integrate xpresser sooner rather than later
[22:35] <balloons> yea, if you can't introspect at all, your stuff screenreading
[22:36] <thomi> I assumed that for most of the stuff you were doing you'd be able to use the Gtk or Qt supporet
[22:36] <balloons> well, I mean, I think a couple small commits could add everything.. if your open to adding it
[22:36] <thomi> *support
[22:36] <balloons> thomi, yes I think most everything can be introspected, but options are good
[22:36] <thomi> I'm happy to add things, as long as we don't end up re-implementing xpresser - I'd rather integrate that than write it ourselves
[22:37] <thomi> (less code to maintain etc)
[22:38] <balloons> yes yes.. ok, so while I have you, let's talk introspection a bit.. I'm interested in gtk apps to start
[22:38] <balloons> do you have any examples of this -- what's the best place to start digging?
[22:41] <thomi> hmmmm, some documentation would be good huh :)
[22:42] <thomi> alesage: do you have your gedit test code somewhere pubvlic?
[22:42] <thomi> balloons: alesage is the Gtk support person - if there's Gtk-specific issues, he's probably the best person to talk to.
[22:42] <alesage> thomi hi :) let me see . . . hi balloons
[22:42] <balloons> hi alesage :-)
[22:45] <alesage> balloons let me test this before sending it on to you
[22:45] <balloons> alesage, sure thing.. I appreciate it
[22:46] <balloons> thomi, duh! found the base class finally (class AutopilotTestCase(VideoCapturedTestCase, KeybindingsHelper):)
[22:46] <balloons> not sure how I missed that . . .
[22:46] <thomi> balloons: probably because the documentation needs to be much better :)
[22:48] <balloons> it is very unity centric.. confusing to an outsider.. but we'll change that
[22:53] <balloons> ohh.. are there windowing functions.. do things like assert the focused window, move or resize a window, activate a window
[22:53] <balloons> nvm nvm.. found it found it
[22:55] <alesage> balloons, here's a branch with a pretty minimal test lp:~allanlesage/+junk/UDS_AP_session/
[22:56] <thomi> balloons: yes, if you see anything that's unity-specific (even documentation), please file a bug against autopilot
[23:19] <cariveri> bschaefer: hey there :) I dont how to draw the sub_LauncherIcons! please help.
[23:19] <bschaefer> cariveri, what are you stuck on?
[23:20] <cariveri> well, did new SimpleLauncherIcon() (it will be a list of those later) and setEmblem(iconpath). But I dont know how to draw it.
[23:22] <cariveri> Id like to draw it just besides the this LauncherIcon.
[23:23] <bschaefer> hmm well im not 100% how they are being drawn atm...
[23:24] <bschaefer> dig through LauncherController, Launcher, AbstractLauncherIcon, and LauncherIcon
[23:24] <bschaefer> it has to get the icon texture somehow
[23:25] <bschaefer> it looks like they get drawn to the Launcher in Launcher.cpp , DrawContent
[23:28] <bschaefer> also look under unity-shared/IconRenderer.cpp
[23:28] <bschaefer> as you'll use you window you make to draw the icons onto (I would think...)
[23:36] <cariveri> I did not find yet the LauncherIcon that gets drawed in the Launcher::DrawContent .
[23:38] <bschaefer> cariveri, im pretty sure its1928...
[23:38] <bschaefer> but that function is large and I haven't ever really looked at it
[23:38] <bschaefer> start commenting things out and playing around with it :)
[23:43] <cariveri> Oh my god. why could things be as easy as Launcher->Draw(){ ... Rander(_icon); +Render(_icon->subIcons);   };
[23:44] <bschaefer> well...
[23:44] <bschaefer> that im  not sure about :(...
[23:55] <thumper> cariveri: because the launcher is "special" :P
[23:55] <cariveri> lol. trashed unity. will need to reboot it.
[23:56] <bschaefer> cariveri, that is the fun part of messing with unity :)