[01:25] <andyrock> thumper, hi
[01:25] <thumper> hi andyrock
[01:26] <thumper> how goes your study?
[01:26] <andyrock> can i work on this bug https://bugs.launchpad.net/unity/+bug/819721?
[01:26] <andyrock> thumper, quite good :)
[01:27] <andyrock> this bug is marked as "in progress" since 2011-10-19...
[01:28] <thumper> andyrock: I suggested that bug to bschaefer :)
[01:28] <thumper> let me find something chunky for you...
[01:28] <andyrock> thumper, ah ok... but i think that i've found the problem
[01:28] <thumper> oh?
[01:29] <thumper> and it is?
[01:29] <andyrock> I've to do some tests but i'm quite sure...
[01:29] <thumper> andyrock: a key thing here is "can we test it in an automated way?"
[01:29] <andyrock> a no initialization
[01:29] <thumper> haha
[01:30] <andyrock> problem
[01:30] <thumper> sounds plausable
[01:30] <andyrock> in nux::GraphicsDisplayX11...
[01:30] <thumper> oh really?
[01:30] <thumper> ha
[01:31] <andyrock> _global_pointer_grab_active is not initializzed
[01:31]  * thumper goes to open source
[01:31] <andyrock> and it's used to grab the mouse
[01:32] <andyrock> this explains why the probelm happens just at the login
[01:32]  * thumper nods
[01:32] <thumper> good find
[01:33] <thumper> that class is crazy big
[01:33] <andyrock> so if bschaefer is online he can look to it...
[01:34] <thumper> the interesting question is how do we write a test for it?
[01:35] <andyrock> mmmh, is there a way to create fake X event?
[01:36] <andyrock> I mean I know how create X event from xlib
[01:36]  * thumper looks for jay
[01:36] <bschaefer> andyrock: hey im here
[01:36] <andyrock> bschaefer, about quicklist problem...
[01:37] <andyrock> have you found a fix?
[01:37] <bschaefer> andyrock: not yet, but I see what you suggested
[01:37] <thumper> what we want to be able to do is to construct a graphics display object to test
[01:37] <bschaefer> (or said, I can see if that fixes it)
[01:38] <thumper> bschaefer: it looks most likely to fix it
[01:38] <thumper> bschaefer: also I'm guessing there are other members not initialized there too
[01:38] <thumper> probably worth a look
[01:38] <thumper> it is a massive class
[01:38] <bschaefer> thumper: yeah that would explain whats going on
[01:38] <bschaefer> andyrock: thanks, will take a look into, and see if I can find anything else not inited
[01:39] <bschaefer> that needs to be
[01:39] <andyrock> using an hack in unity fix this problem to...
[01:39] <andyrock> i mean:
[01:39] <andyrock> GrabPointer();
[01:39] <andyrock> UngrabPointer();
[01:39] <andyrock> and again...
[01:39] <andyrock> GrabPointer()
[01:40] <andyrock> just to init everything we need
[01:40] <bschaefer> there was also the similar problem with the dash on start up
[01:40] <thumper> andyrock: ew...
[01:40] <andyrock> bschaefer, i know
[01:41] <andyrock> thumper, i know that the hack sucks but it's how i found the problem :)
[01:41] <thumper> andyrock: don't get me wrong, it is a great find
[01:43] <andyrock> thumper, another question... can someone reviews this branch https://code.launchpad.net/~andyrock/unity/fix-875467/+merge/79638
[01:43] <andyrock> please...
[01:43]  * thumper looks
[01:43] <andyrock> it's a low priority bugs
[01:43] <andyrock> but a bug is a bug
[01:45] <thumper> andyrock: that code will blow up
[01:45] <thumper> andyrock: I'll give a more complete review when I'm done with sam
[01:47] <andyrock> thumper, thanks
[01:51] <andyrock> I'm going to bad (3:00 AM here)... see you tomorrow
[01:52] <thumper> andyrock: ok
[02:00] <bschaefer> thumper: yeah that fixed it
[02:01] <thumper> bschaefer: awesome
[02:01] <thumper> bschaefer: that also explains why it only sometimes happened
[02:01] <bschaefer> thumper: just need to figure out the best way to actually do it
[02:01] <thumper> do it?
[02:01] <thumper> or test it?
[02:01] <bschaefer> i mean better way
[02:01] <bschaefer> then GrabPointer
[02:01] <bschaefer> and UnGrab
[02:01] <thumper> oh, fix nux
[02:01] <bschaefer> yeah
[02:01] <bschaefer> and how to test it...
[02:01] <thumper> that is why I was pinging Jay
[02:02] <bschaefer> I see, it also looks like it fixed my Dash too
[02:02] <thumper> bschaefer: make a nux branch that initializes all of the GraphicsDisplay
[02:02] <thumper> (using initializer lists)
[02:02]  * thumper looks at the time
[02:02] <bschaefer> alright!
[02:02]  * thumper runs to collect kids
[02:03] <bschaefer> have fun
[02:15] <thumper> bschaefer: once you have that, we can talk to jay about the best way to instantiate one and check :)
[02:15] <bschaefer> ok, none of it was in an init list so it is taking a little time
[02:15] <bschaefer> thumper: plus i wanna check I get everything :)
[02:16] <thumper> bschaefer: cool
[02:19] <thumper> bschaefer: did you mention that this may also fix bug 860805?
[02:19] <thumper> bschaefer: or is that something else?
[02:20] <bschaefer> Yeah, it seemed to be fixed also, but I wanna log out and do some more testing before i say a definite yes
[02:20] <bschaefer> thumper: ^
[02:20] <thumper> bschaefer: awesome
[02:20] <bschaefer> thumper: which I will do when I am done with this :)
[02:20] <thumper> bschaefer: two bugs with one fix :)
[02:21] <thumper> bschaefer: I'll put you down for these two bugs then
[02:21] <thumper> bschaefer: and you can link it to your nux branch
[02:21] <thumper> bschaefer: what's your LP id?
[02:21] <bschaefer> thumper: yeah, if it isen't then it is very similar
[02:21] <bschaefer> brandontschaefer
[02:25] <thumper> ta
[03:36] <bschaefer> thumper: sadly it didn't fix the dash, but it has to be very simillr, so I will start looking into that.
[03:36] <bschaefer> similar*
[04:02] <bschaefer> thumper: https://code.launchpad.net/~brandontschaefer/nux/fix-819721
[04:02] <bschaefer> fix for when you wanna call jay n
[04:02] <bschaefer> in*
[08:45] <andyrock> thumper, about this: https://code.launchpad.net/~andyrock/unity/fix-875467/+merge/79638
[08:46] <andyrock> i just have to add the get_icon_name_from_g_icon in the impl namespace?
[11:15] <apw> can anyone tell me where to find the documentation for the expected semantics of t
[11:15] <apw> the unity desktop.  its silly i have to keep asking if my observed behaviour is "right"
[11:15] <apw> but until i have that.  i assume that i should expect new windows to appear on the same monitor as the cursor ?
[11:41] <smspillaz> apw: I'm pretty sure that the smart placement code puts the window in the most optimal space on the last active monitor
[11:42] <apw> smspillaz, ok so its definatly not putting it on the last active monitor most of the time for me, in this example when running gitk
[11:44] <apw> smspillaz, ok so bzr vis does appear on the right one, but thats not 'full screen', any idea what determines whether a window is full screen or not when its created ?
[11:48] <smspillaz> some windows palce themselves
[11:48] <smspillaz> *place
[11:48] <smspillaz> some tcl/tk applications do this iirc
[12:27] <Jonii> How did I check if I had Unity 2d or 3d?
[12:28] <smspillaz> Jonii: alt-tab
[12:28] <smspillaz> JanC: if you have tiles that match what you've got on the launcher, its 3d, otherwise 2d
[12:28] <Jonii> I don't understand
[12:30] <Jonii> Icons that show up after alt-tab are included in launcher, and they look more or less the same(the size is different)
[12:30] <smspillaz> you're using 3D then
[12:30] <smspillaz> (though, I haven't checked if 2D has implemented this feature)
[12:31] <Jonii> So, it means my graphics device has to use 3d-acceleration and that is why Ubuntu is draining my battery so ridiculously fast?
[12:31] <smspillaz> Jonii: not necessarily
[12:33] <smspillaz> Jonii: the battery drain is a combination of that, a kernel bug and a few other things likely
[12:33] <smspillaz> the 3D unit of your graphics hardware will remain on regardless of whether or not you're using unity 2d or unity 3d because they both use the same codepaths on the gpu
[12:34] <smspillaz> (and I beleive that having the 3D unit and the memory controller on is now mandatory these days in the kernel mode-setting world)
[12:34] <smspillaz> and then there are a few inefficiencies in the way that unity-3d does its painting, which are being worked on
[12:34] <Jonii> So switching from unity 3d to 2d is unlikely to fix my ubuntu?
[12:35] <smspillaz> you may get a slight power boost, sure, but I don't think it will be drastic
[12:37] <Jonii> Currently Ubuntu drains the battery roughly twice as fast as Windows 7
[12:37] <smspillaz> *shrug* It's worth testing in your case I suppose
[12:38] <Jonii> How to change?
[12:38] <smspillaz> log out, click on the settings cog next to your username, pick "Unity 2D", log in
[12:39] <Jonii> Shutdown is not needed?
[12:39] <smspillaz> nope
[12:39] <Jonii> Then I'll try that right now ->
[12:39] <smspillaz> ok
[12:44] <Jonii> Humm, maybe 1W less
[16:50] <mhr3> apinheiro, hey, can you tell me something about the atk objects, particularly when are they destroyed
[16:50] <apinheiro> mhr3, hi
[16:51] <apinheiro> they are destroyed when the bridge doesn't require them anymore
[16:51] <apinheiro> usually, when the ui object is destroyed
[16:51] <apinheiro> they "survive" a little
[16:51] <apinheiro> the ATs are notified, and then not used anymore
[16:51] <mhr3> apinheiro, what does a little mean?
[16:51] <apinheiro> so after that the bridge made a g_object_unref and remove it
[16:51] <apinheiro> ok, from the beginning
[16:52] <apinheiro> an atk object is a kind of proxy of the UI objects
[16:52] <apinheiro> so for a gtkbutton, you usually have an atkobject
[16:52] <apinheiro> the one asking for a ref of that object is the atk-bridge
[16:52] <apinheiro> atk-bridge communicate with the registry
[16:52] <apinheiro> ATs (AT == assistive technology)
[16:53] <apinheiro> ask the registry for apps, and also for their contents
[16:53] <apinheiro> so a atkobject is alive as long as it is relevant to that AT
[16:53] <apinheiro> when the UI object is destroyed
[16:53] <apinheiro> the atkobject usually remains alive, although changing his state
[16:54] <apinheiro> and after that the bridge usually makes a unref, so then destroyed
[16:54] <apinheiro> mhr3, anyway, why asking?
[16:54] <apinheiro> do you plan to work with atkobjects in some app?
[16:54] <mhr3> is there any possibility that the atk object and it's methods are being called after the associated widget dies?
[16:55] <apinheiro> yes, that it is usual
[16:55] <mhr3> apinheiro, there's some bug i'm trying to fix
[16:55] <apinheiro> this is the reason the atkobject needs to be connected to the destruction of that object
[16:55] <apinheiro> a atkobject also have states
[16:55] <apinheiro> one of his states is ATK_STATE_DEFUNCT
[16:56] <apinheiro> that means that the ui object related to that atkobject is dead
[16:56] <mhr3> so instead of weak_refing the gtkobject i can just check the state?
[16:56] <apinheiro> yes, you can check the state
[16:56] <apinheiro> in fact, a lot of the methods on a atk implementation already made that check
[16:56] <apinheiro> if atk_state_defunct then return;
[16:57] <mhr3> apinheiro, yea, the stacktrace i see is that get_n_children was called, and then it crashes
[16:57] <apinheiro> anyway, atk-bridge was changed recently, and it usually doesn't interact with a object on defunct state
[16:57] <apinheiro> and about <mhr3> so instead of weak_refing the gtkobject i can just check the state?
[16:57] <apinheiro> as far as I remember, the way this is implemented on gtk is with weak_refs
[16:58] <apinheiro> I mean that the atkobject adds a weak_ref
[16:58] <apinheiro> so if the ui object is destroyed
[16:58] <apinheiro> it changes the state to DEFUNCT, and also set his reference to the ui object to NULL
[16:58] <apinheiro> mhr3, do you have here the bug number?
[16:58] <mhr3> sure, let me get it
[16:58] <apinheiro> lamalex, btw, did you see yesterday my question?
[16:59] <apinheiro> do I need to resubmit my branch review proposal?
[17:00] <mhr3> apinheiro, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/863720
[17:00] <lamalex> apinheiro, no you shouldn't need to
[17:01] <apinheiro> lamalex, ok thanks
[17:01] <apinheiro> mhr3, is this the proper link? I get a "this page doesn't exist"
[17:01] <apinheiro> well, it also says "or you may not have permission to see it. " :P
[17:02] <mhr3> apinheiro, try again
[17:02] <apinheiro> hmm the panel service
[17:02] <apinheiro> I solved a crash on the panel service recently
[17:02] <apinheiro> let me see
[17:03] <mhr3> apinheiro, yea... too many crashes in it :P
[17:03] <apinheiro> https://bugs.launchpad.net/unity/+bug/843280
[17:03] <apinheiro> mhr3, could you check if that fix is included on your code?
[17:04] <mhr3> apinheiro, if it's fix released, it is :)
[17:04] <apinheiro> yes, makes sense :P
[17:04] <mhr3> the question if the reporter had it... :/
[17:04] <mhr3> the question is if the reporter had it... :/
[17:04] <apinheiro> ah, were you able to reproduce it?
[17:05] <mhr3> apinheiro, not exactly this one, but a similar stacktrace
[17:05] <mhr3> also in the same func, same line
[17:06] <mhr3> unfortunately i reproduced it randomly, dont have an exact way to do it :/
[17:06] <apinheiro> well, with the panel there are some race conditions :/
[17:06] <apinheiro> they had some random crashes in the past, not only with a11y enabled
[17:07] <mhr3> yep, i fixed a few unrelated ones :)
[17:07] <mhr3> but since i was able to make it crash, this one isn't fixed yet
[17:08] <apinheiro> let me see, the last one I fixed was just a wrong way iterating an array
[17:08] <mhr3> apinheiro, so anyway my basic question is - can the get_n_children be called when the atkobject is defunct?
[17:08] <apinheiro> lets see if it is a obvious issue
[17:08] <apinheiro> mhr3, it shouldn't
[17:09] <apinheiro> in theory if the object is defunct the bridge will not called it
[17:09] <apinheiro> but in theory ;)
[17:09] <apinheiro> this can be a bug there
[17:09] <mhr3> i'll check in atk
[17:09] <apinheiro> atk-bridge
[17:10] <apinheiro> mhr3, the bridge source code is at at-spi2-atk
[17:11] <mhr3> apinheiro, in gnome?
[17:12] <apinheiro> mhr3, http://git.gnome.org/browse/at-spi2-atk
[17:12] <apinheiro> mhr3, that append_cache_item on the backtrace
[17:12] <apinheiro> on cache-adaptor.c
[17:13] <apinheiro> that file belongs to at-spi2-atk
[17:14] <apinheiro> mhr3, take a look to the code
[17:14] <apinheiro>     if (!atk_state_set_contains_state (set, ATK_STATE_MANAGES_DESCENDANTS) &&
[17:14] <apinheiro>         !atk_state_set_contains_state (set, ATK_STATE_DEFUNCT))
[17:14] <apinheiro>       {
[17:14] <apinheiro>         gint childcount, i;
[17:14] <apinheiro>         childcount = atk_object_get_n_accessible_children (obj);
[17:14] <apinheiro>         for (i = 0; i < childcount; i++)
[17:14] <apinheiro> that atk_object_get_n_accessible_children
[17:14] <apinheiro> is that line 153 on the backtrace
[17:15] <mhr3> apinheiro, damn :(
[17:15] <apinheiro> and as you can see, it test if the object is defunct
[17:15] <mhr3> and i though it'd be an easy fix :P
[17:15] <apinheiro> anyway, next question is if they are properly updating the defunct state
[17:15] <apinheiro> I thought that you were talking about a gtk bug
[17:15] <apinheiro> but the panel-service creates custom atk objects
[17:15] <apinheiro> for non-gtk objects
[17:16] <mhr3> i think it isn't in gtk/atk
[17:16] <apinheiro> this code was mostly written by rodrigo moya
[17:16] <apinheiro> I just fixed some bugs, so I don't know all the details
[17:16] <apinheiro> let me check a mon
[17:16] <mhr3> yea np, i'll dig into it deeper, thanks anyway
[17:17] <mhr3> and i already talked to rodrigo ;)
[17:17] <apinheiro> well, just grepping for DEFUNCT I don't find anything
[17:17] <apinheiro> anyway on panel_indicator_entry_accessible_get_n_children
[17:17] <apinheiro> it already does this:
[17:17] <apinheiro>   g_return_val_if_fail (PANEL_IS_INDICATOR_ENTRY_ACCESSIBLE (accessible), 0)
[17:17] <apinheiro> hmm, forget that
[17:18] <apinheiro> that it just a test that the accessible object is still an accessible object
[17:18] <apinheiro> sorry for the noise
[17:18] <mhr3> the problem is that priv->entry is either something odd or NULL
[17:19] <mhr3> but yea, now i realized that we're connecting to non-gtk objects, so maybe there should be something to set the DEFUNCT state?
[17:19] <apinheiro> mhr3, yes true, thats the line
[17:19] <apinheiro> mhr3, probably
[17:20] <apinheiro> when this accessible object is created is because there are a entry
[17:20] <apinheiro> in fact a entry->menu
[17:20] <apinheiro> so you could do that, check if that object is destroyed
[17:21] <apinheiro> mhr3, you could go to your original weak_ref test
[17:21] <apinheiro> and if it is true that the object is destroyed
[17:21] <apinheiro> then it would be required to add the DEFUNCT nits on that custom atk object
[17:21] <apinheiro> that means notify that the state change to DEFUNCT
[17:21] <mhr3> apinheiro, yep, that should work, the problem is that i can't reproduce it easily :/
[17:22] <apinheiro> and update panel_indicator_entry_accessible_ref_state_set accordingly
[17:22] <apinheiro> mhr3, yes that kind of bugs are the worst
[17:22] <apinheiro> when you say that you can't reproduce it easily what means?
[17:22] <apinheiro> that you usually need about 10 attempts to reproduce, 30 min?
[17:23] <mhr3> that it's completely random
[17:23] <mhr3> i reproduced it while working on completely different bug
[17:23] <apinheiro> hmm, but the bug description says "This bug is highly reproducible."
[17:23] <mhr3> maybe for them :P
[17:24] <apinheiro> ;)
[17:25] <apinheiro> well, anyway, just in case I will add a summary of this conversation to the bug
[17:25] <apinheiro> taking a look to the parent
[17:25] <apinheiro> panel-indicator-accessible
[17:25] <mhr3> cool, thx
[17:25] <apinheiro> there are a callback for indicator_entry_removed
[17:25] <apinheiro> so that means that indicator_entry are usually removed
[17:26] <apinheiro> so makes sense on the accessible object to be sure that the object are still there
[17:33] <apinheiro> mhr3, hmm, btw, on the initialize it checks priv->entry->label and priv->entry->image to check the role and name
[17:33] <apinheiro> but on ref_child it exposes priv->entry->menu
[17:33] <apinheiro> probably you should ask rodrigo about this ;)
[17:33] <mhr3> apinheiro, we have a lot of crashers and none of them were in ref_child :)
[17:34] <apinheiro> well, on get_n_children it also checks the menu
[17:34] <apinheiro> what I mean is that object seems to be exposing the menu, but on the initialize it ignores it
[17:39] <mhr3> apinheiro, that's fine, the entry object has label(+image) *and* menu
[17:40] <mhr3> so initialize is fine
[17:40] <apinheiro> mhr3, ok
[17:41] <apinheiro> pity that I have just added the comment on the bug ;)
[17:42] <mhr3> yey, i reproduced it!
[17:43] <apinheiro> mhr3, with a weak_ref?
[17:44] <mhr3> apinheiro, no, just added some debug which didn't really get called
[17:44] <mhr3> apinheiro, and i also pressed enter too soon so i didn't have a chance to inspect the locals :/
[17:44] <mhr3> crap
[18:12] <om26er> kamstrup, Hi any thoughts on bug 842108 also what do you think if its Unity bug or lens?
[18:13] <kamstrup> om26er: i think it must be a bug in unity-lens-applications
[18:13] <om26er> kamstrup, it only happens with alt-f2 though, i'll add the lens as affects :)
[18:14] <kamstrup> om26er: yeah, I noticed
[18:14] <kamstrup> om26er: and is it only evolution? both gedit and gcalctool work...
[18:15] <om26er> kamstrup, try typing 'empathy'
[18:15] <kamstrup> om26er: hmmm, that follows the same pattern as evo
[18:15] <kamstrup> there are two hits
[18:15] <kamstrup> $name-settings
[18:15] <kamstrup> and it removes the $name hit
[18:17] <mgedmin> over here Alt-F2 nautilus finds 'nautilus-actions-config-tool' and a whole bunch of other stuff, doesn't find nautilus itself
[18:17] <om26er> the same pattern :)
[18:18] <mgedmin> I remember some pain trying to restart unity with Alt-F2 unity; thankfully Alt-F2 unity --replace works fine
[18:18] <om26er> smspillaz, Hi, you around?
[18:19] <om26er> smspillaz, this bug 875557 and a bunch other came through the SRU update :/
[18:20] <mgedmin> oh, hey, I've seen this one too, was just about annoyed enough to try to file it, but couldn't figure out how to reproduce it!
[18:36] <andyrock> om26er, htorque scrolling with touchpad in the dash is broken right?
[18:37] <htorque> andyrock: gimme a second
[18:37] <om26er> andyrock, seems to have regressed :/
[18:38] <htorque> works here, but i'm not up-to-date. would i need trunk for this?
[18:39] <andyrock> om26er, damn...
[18:39] <om26er> wfm too :(
[18:39] <om26er> hahah i was using two fingers scrolling but side scrolling was enabled :p
[18:39] <htorque> ;)
[18:40] <andyrock> i'm using two fingers scrolling
[18:40] <andyrock> too...
[18:40] <andyrock> htorque, can you try with two finger scrolling please?
[18:41] <htorque> updating first :)
[18:41] <om26er> andyrock, two finger scrolling works
[18:42] <andyrock> om26er, on my pc two finger scrolling doesn't work
[18:42] <andyrock> side scrolling works
[18:42] <htorque> works here too.
[18:43] <andyrock> jaytaoko1, around?
[18:45] <andyrock> summarizing...
[18:45] <andyrock> for me
[18:45] <htorque> anyone here good at reading valgrind logs? want to make sure bug 886467 gets assigned to the right place (i added unity today as it happened on my "trunk" testing machine).
[18:45] <andyrock> * 2 finger scrolling doesn't work
[18:45] <andyrock> * edge scrolling woks
[18:45] <andyrock> for om26er
[18:45] <andyrock> * 2 finger scrolling works
[18:46] <andyrock> * edge scrolling doesn't works
[18:46] <andyrock> for htorque
[18:46] <andyrock> * 2 finger scrolling works
[18:46] <andyrock> * edge scrolling works
[18:46] <andyrock> right?
[18:46] <om26er> both scrolling methods work for om26er :)
[18:47] <andyrock> om26er, have you nux and unity from trunk?
[18:47] <om26er> no, latest in oneiric
[18:47] <htorque> i'm on precise, compiling nux & co. from trunk right now.
[18:48] <andyrock> om26er, ok
[18:48] <andyrock> htorque, i'm on oneiric
[18:48] <andyrock> you can build unity from trunk using oneiric ;)
[18:49] <jaytaoko1> andyrock: hello
[18:49] <htorque> andyrock: oneiric? what's that? no machine's running that here anymore. :P
[18:50] <andyrock> jaytaoko1, two finger scrolling doesn't works in dash
[18:50] <andyrock> known bug?
[18:50] <andyrock> nux and unity from trunk
[18:50] <andyrock> htorque, eheheh i've not so much time now
[18:51] <andyrock> yesterday i've spent the night to fix "qucklist problem after the login"
[18:52] <andyrock> and for a month  i've study hard
[18:52] <andyrock> *I have studied
[18:53] <jaytaoko1> andyrock: it is working fine on my laptop
[18:53] <jaytaoko1> andyrock: however, I am not at the latest version
[18:53] <jaytaoko1> andyrock: I will have to upgrade and check again
[18:54] <andyrock> jaytaoko1, don't worry...
[18:58] <andyrock> mmm... it doesn't work well if you use the two finger scrolling on a dash icon
[19:11] <htorque> andyrock: i'm now on trunk and scrolling works with mouse wheele, touchpad edge scrolling, two finger scrolling (w/ and w/o horizontal scrolling enabled). though, two finger scrolling seems rather sensitive - i just opened six instances of a program. :D
[19:11] <htorque> *wheel
[19:17] <andyrock> try two finger scrolling inside the dash, without hovering any icons
[19:17] <andyrock> it works right?
[19:19] <htorque> andyrock: yeah, with and without hovering icons.
[19:20] <andyrock> htorque, thanks
[19:20] <htorque> yw! :)
[20:24] <bschaefer> thumper: hey are you around?
[20:45] <thumper> bschaefer: am now
[20:45] <thumper> bschaefer: set up in my favourite cafe
[21:38] <bschaefer> thumper: nice, just got back from a few errands.
[21:38]  * thumper is still here
[21:38] <bschaefer> thumper: sorry it took so long to get that branch up, that class was huge and it wasn't in order at first and I wanted to triple check it was working
[21:38] <thumper> bschaefer: that's fine
[21:39] <thumper> I have an overly agressive imapfilter rule right now
[21:39] <thumper> I need to tweak it so code review email that is directed to me stays in my inbox if unread
[21:39] <bschaefer> thumper: haha, yeah I need to get mine set up. Never have I ever felt so popular from an email
[21:40] <bschaefer> thumper: I didn't submit it for a merge yet because I wanted you to take a look at it (even though it was a simple init list)
[21:40] <bschaefer> thumper: and I am currently looking for the problem with the dash
[21:40] <thumper> bschaefer: do you realise that you can propose for merging, but mark it work in progress?
[21:40] <thumper> bschaefer: that way no review email goes out, but you can see the diff
[21:41] <bschaefer> thumper: I do now
[21:41] <thumper> bschaefer: when proposing, expand the extra options
[21:41] <thumper> bschaefer: and uncheck "ready for review" or whatever it is
[21:41] <bschaefer> thumper: good to know, as I haven't really proposed many branches yet
[21:41] <thumper> bschaefer: has you pushed your nux branch to LP?
[21:42] <thumper> bschaefer: that's fine, I can help you though it all
[21:42] <bschaefer> thumper: yeah
[21:42] <bschaefer> https://code.launchpad.net/~brandontschaefer/nux/fix-819721
[21:42] <thumper> ok, so propose it for merging :)
[21:42] <bschaefer> thumper: doing that right now :)
[21:46] <bschaefer> thumper: branch is proposed
[21:47] <thumper> kk
[21:47] <thumper> I'll take a look
[21:56] <bschaefer> thumper: ugg i noticed a mistake. Line 82
[21:56] <bschaefer> I accidentally removed that
[21:57] <bschaefer> (fixed, ill wait to see if you find anymore before I push)
[22:00] <thumper> bschaefer: if you fix and push, the diff will update
[22:02] <bschaefer> thumper: done
[22:02] <thumper> jaytaoko1: you around?
[22:04] <bschaefer> thumper: should I change the reviewer to jay?
[22:05] <thumper> bschaefer: I'm trying to work out how to test this
[22:05] <thumper> bschaefer: ideally we'd like an automated test
[22:05] <bschaefer> thumper: yeah, I haven
[22:05] <thumper> right now that class has a private constructor
[22:06] <thumper> so it makes it harder to test
[22:06] <bschaefer> made a gui test before so this will be interesting
[22:06] <bschaefer> could we just make a public method that is only enabled when an ifdef TEST etc..
[22:07] <thumper> Nah...
[22:07] <bschaefer> saw something like that in xapian...
[22:07] <thumper> Perhpas what we do is this...
[22:07] <thumper> make a trivial app that just brings up a window
[22:07] <thumper> once it is up, we do some testing internally to assert the state of the variables
[22:07] <thumper> then trigger an exit
[22:08] <thumper> make the main return value represent the test result
[22:08] <thumper> 0 is good
[22:08] <thumper> 1 is bad
[22:08] <bschaefer> alright, how would we assert data that is hidden?
[22:08] <thumper> there are some very simple nux apps already in the examples directory
[22:08] <bschaefer> yeah I have seen those
[22:09]  * thumper thinks and looks at the code again
[22:10] <thumper>  bool GraphicsDisplay::PointerIsGrabbed()
[22:10] <thumper> the test apps we create are going to be mind blowingly simple to start with
[22:10] <thumper> we then need to make sure that the app is built as part of make check
[22:10] <thumper> and executed
[22:11] <bschaefer> ok
[22:11] <thumper> there is code in the test directory that does the google test stuff
[22:11] <bschaefer> ok, should be fun to figure this out
[22:11] <thumper> while you are there, you could make PointerIsGrabbed a const function
[22:12] <thumper> bschaefer: I've just pasted a log of this chat into the review :)
[22:12] <bschaefer> alright, so simply make an app; then have it assert the value of the PointerIsgrabber() return 0 as good and 1 as bad
[22:12] <bschaefer> that should be a good starting ground to have more test within nux
[22:13] <thumper> yep, sounds good
[23:31] <bschaefer> thumper: so basically I used the test_entry_focus.cpp to base the new test off, and have it create init a window then use this to check what the value is.
[23:31] <bschaefer> nux::GetGraphicsDisplay()->PointerIsGrabbed() == true ? assert = 1 : assert = 0;
[23:32] <bschaefer> i should check for false, since I assume assert is 1 just in case it is not inited
[23:44] <andyrock> gord, around?
[23:46] <thumper> andyrock: gord is on leave until next week
[23:46] <thumper> bschaefer: use a global return value (ick, I know)
[23:47] <thumper> bschaefer: don't call it assert (that is a reserved work - or it should be)
[23:47] <andyrock> thumper, do you know if the using of the mouse wheel onto dash scrollbar is disabled by design?
[23:48] <thumper> andyrock: my guess is no
[23:48] <bschaefer> thumper: ok, was trying to avoid a global. I think getting it into the make file is going to be more annoying part
[23:50] <thumper> bschaefer: sometimes a global is needed, and for this it makes sense
[23:51] <bschaefer> thumper: yeah, I didn't think it was needed because I could do the check in the main
[23:51] <bschaefer> thumper: but I will move it to the init function now, because that is better
[23:51] <thumper> really?
[23:51] <thumper> hmm...
[23:51] <thumper> init is good
[23:52] <bschaefer> thumper: yeah since you can use the GetGraphics function
[23:52] <bschaefer> nux::GetGraphicsDisplay()->PointerIsGrabbed()
[23:53] <thumper> bschaefer: I think doing it in the main loop is better as the window has been created
[23:53] <bschaefer> thumper: yeah I can show you what I have to see if you like it
[23:53] <bschaefer> thumper: before moving the stuff around
[23:53] <thumper> sure
[23:54] <jaytaoko1> thumper: ping
[23:54] <thumper> jaytaoko1: hi
[23:54] <bschaefer> http://pastebin.com/heiwPbB3
[23:55] <bschaefer> will change the variable though!
[23:55] <thumper> jaytaoko1: bschaefer has a branch that changes the GraphicsDisplay for X11 to intiailise the variables
[23:55] <thumper> jaytaoko1: we are working out how to get a simple automated test :)
[23:55] <thumper> jaytaoko1: this was the cause of the quicklist not getting focus the first time
[23:56] <jaytaoko1> thumper: Ok, I saw the branch
[23:56] <thumper> jaytaoko1: is there an event in nux we can connect to when the views are shown?
[23:57] <thumper> jaytaoko1: also, how can we close the nux window from an internal function?
[23:57] <jaytaoko1> thumper: let me check...
[23:57] <thumper> jaytaoko1: here is what we want to do:
[23:57] <thumper> Pop up a window
[23:57] <thumper> Once it has been all set up, query some internal state
[23:57] <thumper> then close the window and shutdown
[23:58] <bschaefer> thumper: well not calling Run will make the window not pop up while leaving all the inited variables
[23:58] <bschaefer> (tested it by removed the inited var)
[23:58] <bschaefer> removing*
[23:59] <thumper> bschaefer: but it isn't really indicitive of what happens