...
[13:23:47 CDT(-0500)] <jhernandez> clown: do you want me to go for it? or you want to?
[13:25:53 CDT(-0500)] <anastasiac> Justin_o and cindyli, I'm working on docs for the prefs framework Builder. I notice that it "is an" aux builder, but "has a" primary builder. Is there a particular reason why the two were implemented differently? e.g. why is the aux builder not a subcomponent, or why is the primary builder not a grade?
[13:25:54 CDT(-0500)] <clown> Let me, jhernandez.
[13:26:54 CDT(-0500)] <jhernandez> clown: thank you!
[13:27:10 CDT(-0500)] <clown> what I would do for the test is: 1. search('tuxguitar'), 2. check the return value, 3. run install, 4. search and see that the 'data' field shows that it's installed, 5. run remove, 6. search and see that the data field now says available.
[13:27:13 CDT(-0500)] <clown> how does that sound?
[13:27:30 CDT(-0500)] <Bosmon> Justin_o - won't it be great when renderer component trees are abolished 
[13:27:35 CDT(-0500)] <jhernandez> clown: sounds great
[13:27:52 CDT(-0500)] <jhernandez> :]
[13:27:53 CDT(-0500)] <clown> jhernandez: is there anything like "assert()" for testing in this case?
[13:28:10 CDT(-0500)] <jhernandez> yup
[13:28:13 CDT(-0500)] <clown> maybe I should look at other test examples.
[13:28:15 CDT(-0500)] * jhernandez looks
[13:29:12 CDT(-0500)] <Justin_o> Bosmon: yes.. it will be
[13:30:08 CDT(-0500)] <jhernandez> clown: in GPII, we use tests like this one -> https://github.com/javihernandez/linux/blob/packagekitBridge/node_modules/gsettingsBridge/tests/gsettingsTests.js
[13:30:23 CDT(-0500)] <clown> jhernandez: thanks, one other question...
[13:31:01 CDT(-0500)] <jhernandez> another example: https://github.com/javihernandez/linux/blob/packagekitBridge/node_modules/orca/test/orcaSettingsHandlerTests.js
[13:31:02 CDT(-0500)] <Justin_o> anastasiac: i'm trying to remember, perhaps cindyli will recall, but i believe that the primaryBuilder is a subcomponent because of some issues with grade merging
[13:31:24 CDT(-0500)] <clown> when tuxguitar is installed on fedora, the data property is "installed:fedora". Is it "installed:opensuse" for you?
[13:31:31 CDT(-0500)] <jhernandez> but take into account that we're testing specific GPII functionalities and the payloads around
[13:31:43 CDT(-0500)] <jhernandez> let me check
[13:31:44 CDT(-0500)] <clown> that is, is it always "installed:<something>"
[13:31:47 CDT(-0500)] <clown> ?
[13:32:52 CDT(-0500)] <clown> also: time lines: I'm chairing a teleconfernce in half an hour, for an hour. I won't really start this until later today, early tomorrow. Is that okay?
[13:33:59 CDT(-0500)] <jhernandez> okay
[13:34:00 CDT(-0500)] <jhernandez> np
[13:34:04 CDT(-0500)] <jhernandez> and ...
[13:34:16 CDT(-0500)] <jhernandez> yes, I think that "installed" is something generic
[13:34:41 CDT(-0500)] <jhernandez> still installing tuxguitar ...
[13:34:49 CDT(-0500)] <clown> cool. I was looking for something to compare against that would appear on all platforms.
[13:35:09 CDT(-0500)] <jhernandez> (or maybe just stalled?)
[13:35:13 CDT(-0500)] <cindyli> anastasiac, Justin_o, unfortunately, i don't rmb too 
[13:35:17 CDT(-0500)] <clown> yes, it took me about 2 minutes to install tuxgutiar here. This will require a "timeout" between installing and removing.
[13:35:38 CDT(-0500)] <anastasiac> ok, Justin_o and cindyli, thanks for trying to remember
[13:35:47 CDT(-0500)] <Justin_o> sorry
[13:35:53 CDT(-0500)] <jhernandez> defintely we need a status callback function and log what is coming from packagekit
[13:36:15 CDT(-0500)] <jhernandez> ok
[13:36:18 CDT(-0500)] <jhernandez> clown:
[13:36:22 CDT(-0500)] <jhernandez> before
[13:36:24 CDT(-0500)] <clown> yes?
[13:36:27 CDT(-0500)] <jhernandez> {
[13:36:27 CDT(-0500)] <jhernandez> "id": "tuxguitar;1.2-10.1.1;i586;repo-12.3-oss",
[13:36:27 CDT(-0500)] <jhernandez> "name": "tuxguitar",
[13:36:27 CDT(-0500)] <jhernandez> "version": "1.2-10.1.1",
[13:36:27 CDT(-0500)] <jhernandez> "data": "repo-12.3-oss"
[13:36:29 CDT(-0500)] <jhernandez> }
[13:36:32 CDT(-0500)] <jhernandez> after
[13:36:43 CDT(-0500)] Wiki Markup <jhernandez> { id: 'tuxguitar;1.2-10.1.1;i586;installed', name: 'tuxguitar', version: '1.2-10.1.1', data: 'installed' }
[13:37:14 CDT(-0500)] <jhernandez> you can just look for the word 'installed' on data
[13:37:29 CDT(-0500)] <clown> right. That's what I was hoping, jhernandez.
[13:37:43 CDT(-0500)] <jhernandez> nice!
[13:37:48 CDT(-0500)] <clown> Ok. I have to run now and get things set up for my telecon, jhernandez.
[13:37:56 CDT(-0500)] <jhernandez> go for it
[13:37:57 CDT(-0500)] <clown> Talk to you later, and thanks for all the help.
[13:38:00 CDT(-0500)] <jhernandez> and thank you!
[13:38:08 CDT(-0500)] <clown> my pleasure.
[13:38:15 CDT(-0500)] <jhernandez> all mine
[13:38:16 CDT(-0500)] <jhernandez> 
[13:38:20 CDT(-0500)] <clown> lol
[13:51:46 CDT(-0500)] <Bosmon> Justin_o - unfortunately my implementation of the new model relay system isn't ready yet
[13:51:58 CDT(-0500)] <Bosmon> Do you still want us to talk about it at tomorrow's COMUNITY METING?
[13:52:08 CDT(-0500)] <Bosmon> I guess I know enough about it to describe how it will work ....
[13:52:13 CDT(-0500)] <Justin_o> Bosmon: i think that was for next weeks anyways.. so you still have time
[13:52:30 CDT(-0500)] <Bosmon> Really? I thought we had said Oct 2
[13:52:33 CDT(-0500)] <Bosmon> What is tomorrow's about?
[13:52:35 CDT(-0500)] <Justin_o> Bosmon: http://wiki.fluidproject.org/display/fluid/Community+workshops
[13:52:38 CDT(-0500)] <Bosmon> Thanks
[13:52:52 CDT(-0500)] <Justin_o> Bosmon: we can change the topic though, if you'd like to talk about that tomorrow
[13:53:08 CDT(-0500)] <Bosmon> No, next week works fine
[13:53:09 CDT(-0500)] <Justin_o> or anastasiac might want to do more documentation
[13:53:13 CDT(-0500)] <Justin_o> Bosmon: okay.. cool
[14:04:02 CDT(-0500)] <Justin_o> Bosmon, anastasiac: do we have any docs with the fully hydrated component trees still
[14:04:39 CDT(-0500)] <anastasiac> hm...
[14:04:42 CDT(-0500)] * anastasiac searches
[14:05:13 CDT(-0500)] <anastasiac> we have this page, Justin_o: http://wiki.fluidproject.org/display/docs/ProtoComponent+Types
[14:05:20 CDT(-0500)] <anastasiac> is that what you're looking for?
[14:06:23 CDT(-0500)] <Justin_o> anastasiac: not really sorry.. i want the old style.. before protocomponents
[14:06:30 CDT(-0500)] <anastasiac> ah
[14:06:31 CDT(-0500)] <anastasiac> hm
[14:06:58 CDT(-0500)] <Justin_o> Bosmon: do you know in the old style are children the only point of nesting where the nested object would have an ID and valuebinding
[14:07:22 CDT(-0500)] <anastasiac> how about this, Justin_o? http://wiki.fluidproject.org/display/Infusion13/Renderer+Component+Trees
[14:07:46 CDT(-0500)] <Bosmon> http://wiki.fluidproject.org/display/Infusion13/Fluid+Renderer+-+Background
[14:07:51 CDT(-0500)] <Bosmon> This page also describes them
[14:07:58 CDT(-0500)] <Bosmon> yes, "children" is the only route for nesting components
[14:09:32 CDT(-0500)] <Justin_o> Bosmon: thanks
[14:14:08 CDT(-0500)] <cindyli> Bosmon: in IoC testing system, can I pass an argument list to an event listener? for example,
[14:14:10 CDT(-0500)] <cindyli> sequence: [{
[14:14:10 CDT(-0500)] <cindyli> listener: "fluid.tests.checkTopComponents",
[14:14:10 CDT(-0500)] Wiki Markup <cindyli> event: "{fluid.tests.videoPlayerMediaPanels}.events.onReady"
[14:14:10 CDT(-0500)] <cindyli> }]
[14:14:52 CDT(-0500)] <cindyli> i tried to pass an "args" option but doesn't work
[14:15:38 CDT(-0500)] <Bosmon> cindyli - "doesn't work" is the classic terrible problem report
[14:15:48 CDT(-0500)] <cindyli> haha
[14:15:53 CDT(-0500)] <Bosmon> You can see some examples of "args" in the "TestingTest.js" test cases
[14:16:03 CDT(-0500)] <Bosmon> What kind of "doesn't work" did you experience?
[14:16:31 CDT(-0500)] <Bosmon> I guess there isn't an example of "args" with "listener" ....
[14:16:38 CDT(-0500)] <cindyli> i did, the test cases with "args" are all for modelChanged type of listener, not any for event listeners
[14:17:12 CDT(-0500)] <cindyli> well, modelChanged is an event too i guess, but perhaps being processed differently
[14:17:31 CDT(-0500)] <Bosmon> I see
[14:17:36 CDT(-0500)] <Bosmon> Actually, what would you want "args" to do in this case?
[14:17:43 CDT(-0500)] <Bosmon> I guess some boiling
[14:17:48 CDT(-0500)] <cindyli> exactly
[14:18:01 CDT(-0500)] <Bosmon> What in particular do you want to boil into the signature?
[14:18:06 CDT(-0500)] <cindyli> and "expectedResult", "testType"
[14:18:20 CDT(-0500)] <Bosmon> aha
[14:18:29 CDT(-0500)] <Bosmon> Yes, it seems this isn't implemented
[14:18:33 CDT(-0500)] <Bosmon> Would you like to implement it? : P
[14:18:54 CDT(-0500)] <cindyli> sure
[14:19:35 CDT(-0500)] <Bosmon> I'll be happy to review your pull
[14:19:35 CDT(-0500)] <cindyli> a bit scary to modify framework code but you will review it anyway
[14:19:54 CDT(-0500)] <Bosmon> Well, I think it's time for people to stop being scared
[14:20:04 CDT(-0500)] <cindyli> will give a try
[14:20:30 CDT(-0500)] <Bosmon> It should only take an "if" statement and a call to fluid.expandOptions...
[14:20:41 CDT(-0500)] <Bosmon> Actually my latest pull request with declarative change binding contains a good example of how to do this
[14:20:50 CDT(-0500)] <Bosmon> The current framework code for event boiling is very convoluted
[14:20:50 CDT(-0500)] <cindyli> ah ha
[14:20:57 CDT(-0500)] <Bosmon> But the change binding pull takes a much more direct approach
[16:01:44 CDT(-0500)] <yzen_> Bosmon: hi