[06:56:43 CDT(-0500)] <fouks_f> guys is this the place to ask for help if I can't figure out how to use the fluid video player ?
[07:01:30 CDT(-0500)] <jhernandez> fouks_f: hey!
[07:01:40 CDT(-0500)] <jhernandez> I guess that this could be a good place to ask
[07:01:48 CDT(-0500)] <jhernandez> also there is #fluid-tech
[07:02:23 CDT(-0500)] <fouks_f> so the tech channel is more appropriate ?
[07:03:32 CDT(-0500)] <jhernandez> maybe
[07:04:24 CDT(-0500)] <jhernandez> anyway
[07:04:39 CDT(-0500)] <jhernandez> I think that we're mostly the same people on both channels
[07:04:44 CDT(-0500)] <jhernandez> :]
[10:12:04 CDT(-0500)] <Justin_o> yzen: renderer question for you.. when using a fluid.renderer.selection.inputs renderer expander.. can you only set the text of a label and nothing else.. can you use decorators or anything?
[10:14:35 CDT(-0500)] <yzen> Justin_o: id think you should be able to use decorators
[10:18:33 CDT(-0500)] <Justin_o> yzen: any idea how you would add one
[10:18:35 CDT(-0500)] <Justin_o> ?
[10:18:52 CDT(-0500)] <yzen> do you have an example of your tree so far ?
[10:20:21 CDT(-0500)] <Justin_o> yzen: you can look at the contrast adjuster panel from the preferences framework https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L232-L300
[10:20:38 CDT(-0500)] <Justin_o> yzen: i'm trying to see if we can get rid of the style function that has to run after rendering
[10:21:15 CDT(-0500)] <yzen> Justin_o: so can you have a decorators block in tree:
[10:21:25 CDT(-0500)] <yzen> afaik you should be able to
[10:23:16 CDT(-0500)] <yzen> cindyli: hi
[10:23:27 CDT(-0500)] <cindyli> hi, yzen
[10:24:36 CDT(-0500)] <yzen> cindyli: question about distributeOptions, can we delete things somehow ?
[10:25:19 CDT(-0500)] <cindyli> yzen: you can pass down emptyComponent 
[10:25:28 CDT(-0500)] <cindyli> you wanna delete an option?
[10:25:35 CDT(-0500)] <yzen> cindyli: yes
[10:26:27 CDT(-0500)] <cindyli> yzen: you can certainly pass down a null or undefined, but don't think you can delete the path completely
[10:26:50 CDT(-0500)] <yzen> alright ill try thanks
[10:27:01 CDT(-0500)] <cindyli> np
[10:33:11 CDT(-0500)] <Justin_o> yzen: i'll try that, but what would i use as the key?
[10:34:00 CDT(-0500)] <yzen> Justin_o: so decorator will be the key, not sure what it'd be attached to
[10:50:20 CDT(-0500)] <Justin_o> yzen: yes.. i was just thinking that.... i guess i could give it a try and see what happens
[11:08:57 CDT(-0500)] <Justin_o> yzen: so this doesn't seem to have any affect http://pastie.org/private/vjrfanbtln2jq22t1j8g
[11:09:34 CDT(-0500)] <yzen> is the class added to anything at all ?
[11:15:23 CDT(-0500)] <yzen> cindyli: is it possible to distribute options to siblings ?
[11:16:03 CDT(-0500)] <Justin_o> yzen: i couldn't find it anywhere
[11:16:08 CDT(-0500)] <yzen> hmm
[11:16:16 CDT(-0500)] <yzen> it might be a bug in the renderer perhaps
[11:17:07 CDT(-0500)] <Justin_o> yzen: okay.. thanks
[11:27:12 CDT(-0500)] <cindyli> yzen: no, i don't think it's possible to distribute options to siblings
[11:34:55 CDT(-0500)] <yzen> Bosmon:
[12:56:59 CDT(-0500)] <Justin_o> Bosmon: are you there?
[12:57:08 CDT(-0500)] <Bosmon> Hi Justin_o
[12:57:42 CDT(-0500)] <Justin_o> Bosmon: hello.. i just wanted to follow up on that conversation cindyli and I were having with you the other day about message bundles and message lookup
[12:58:58 CDT(-0500)] <Justin_o> Bosmon: I think we were talking about it in this log http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2013-10-10
[12:59:06 CDT(-0500)] <Bosmon> Justin_o - yes
[12:59:44 CDT(-0500)] <Justin_o> Bosmon: I think we left off with cindyli's question "do you mean to have 2 message bundles, one is the message resolver, the other contains string mappings"
[12:59:50 CDT(-0500)] <Bosmon> Yers
[13:00:00 CDT(-0500)] <Bosmon> I don't think I could understand that question
[13:00:11 CDT(-0500)] <cindyli> haha
[13:00:17 CDT(-0500)] <Bosmon> I believe my idea was to compose a bundle out of IoC references
[13:00:25 CDT(-0500)] <Bosmon> Rather than using 1 expander per reference, which is incredibly cumbersome
[13:01:07 CDT(-0500)] <Justin_o> Bosmon: should each component have its own messageResolver?
[13:01:25 CDT(-0500)] <Justin_o> Bosmon: what do you mean by compose a bundle out of IoC references?
[13:01:29 CDT(-0500)] <Bosmon> Justin_o - possibly .....
[13:01:46 CDT(-0500)] <Bosmon> Justin_o - it seems that all that is required is for one component to have a bundle composed out of a selection of messages held in other bundles?
[13:04:21 CDT(-0500)] <Justin_o> Bosmon: I think the messageLoader combines the bundles from all of the components into a single bundle. Is that correct cindyli?
[13:04:42 CDT(-0500)] <cindyli> exactly, Justin_o
[13:04:46 CDT(-0500)] <cindyli> and Bosmon
[13:05:13 CDT(-0500)] <Justin_o> cindyli: how do we prevent collisions?
[13:05:37 CDT(-0500)] <cindyli> Bosmon: no prevention. the latter would overwrite the former
[13:06:02 CDT(-0500)] <cindyli> ou, wrong direction. Justin_o: ^
[13:06:13 CDT(-0500)] <Justin_o> no problem
[13:07:18 CDT(-0500)] <Justin_o> Bosmon: so i guess the question would be "how to use this combined bundle" in each component without requiring the expander.
[13:09:31 CDT(-0500)] <Bosmon> Justin_o - I'm still not really sure I understand what kind of use case this is
[13:09:40 CDT(-0500)] <Bosmon> Why are we combining several bundles into one here?
[13:09:41 CDT(-0500)] <Justin_o> Maybe this will help a bit
[13:09:42 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/docs/Localization+in+the+Preferences+Framework
[13:10:24 CDT(-0500)] <Justin_o> Bosmon: ^
[13:12:39 CDT(-0500)] <Bosmon> Wow, this is quite a thorough document
[13:12:45 CDT(-0500)] <Bosmon> But it still doesn't quite answer my question
[13:13:00 CDT(-0500)] <Bosmon> Is it simply the fact that we have ended up with different names for the same strings, in different scopes?
[13:14:14 CDT(-0500)] <Justin_o> i don't think so.. i think we have it so that each panel can supply it's own message bundle and the message loader does the loading of it in and combines them all into a single message bundle for the entire prefs stack
[13:15:01 CDT(-0500)] <Bosmon> expander: {
[13:15:02 CDT(-0500)] <Bosmon> func: "fluid.slidingPanel.lookupMsg",
[13:15:02 CDT(-0500)] <Bosmon> args: [" .msgBundle", "slidingPanelShowText"]
[13:15:02 CDT(-0500)] <Bosmon> }
[13:15:47 CDT(-0500)] <Justin_o> Bosmon: wouldn't you have to do a lookup or resolve to get the string out?
[13:17:16 CDT(-0500)] <Justin_o> since it's in a messageResolver
[13:17:36 CDT(-0500)] <Bosmon> Justin_o - well, you might, but perhaps it needn't look like this : P
[13:17:51 CDT(-0500)] <Justin_o> Bosmon: okay.. what would you suggest?
[13:19:18 CDT(-0500)] <Bosmon> Well, there are two main options ..... one, a "resolvePathSegment" method, or two, the "compact expander syntax"
[13:19:36 CDT(-0500)] <Bosmon> It may well be worth trying to get the former working, since it will be a nice general facility
[13:20:47 CDT(-0500)] <Justin_o> Bosmon: okay, would resolvPathSegment be on the Resolver itself?
[13:21:03 CDT(-0500)] <Bosmon> Justin_o - yes - well, you can put it where you like
[13:21:18 CDT(-0500)] <Justin_o> Bosmon: you mean a method on the component itself?
[13:21:21 CDT(-0500)] <Justin_o> then
[13:21:24 CDT(-0500)] <Bosmon> You could even dump a fake "strings" object that just contains it
[13:21:39 CDT(-0500)] <Bosmon> And then you would be able to resolve options.strings.slidingPanelShowText or whatever
[13:21:54 CDT(-0500)] <Bosmon> Although that would prevent you from using that area for literal strings
[13:22:04 CDT(-0500)] <Justin_o> Bosmon: yes..
[13:22:16 CDT(-0500)] <Justin_o> Bosmon: so we'd still end up with an expander per string
[13:22:17 CDT(-0500)] <Bosmon> This is a somewhat halfbaked area of the framework, but it will save a lot of time here
[13:22:21 CDT(-0500)] <Bosmon> Justin_o - you wouldn't
[13:22:31 CDT(-0500)] <Bosmon> I think you haven't understood about the "resolvePathSegment" method
[13:22:31 CDT(-0500)] <Justin_o> if we didn't use the expander for the entire strings block
[13:22:42 CDT(-0500)] <Bosmon> This is a framework facility which allows custom resolving of EL path segments
[13:22:51 CDT(-0500)] <Justin_o> ah.. i haven't
[13:22:57 CDT(-0500)] <Justin_o> can you explain it a bit more
[13:22:59 CDT(-0500)] <Bosmon> For example, it is the thing which allows .dom.thing to be resolved into the DOM binder's "locate" method
[13:23:24 CDT(-0500)] <Bosmon> Similarly it would enable .stringBundle.slidingPanelShowText to be resolved into the message resolver etc.
[13:24:21 CDT(-0500)] <Justin_o> Bosmon: okay.. so first question.. for every strings in your stings block you would have a reference to .stringBundle.slidingPanelShowText
[13:24:47 CDT(-0500)] <Bosmon> Justin_o - ideally you would have no references at all
[13:24:55 CDT(-0500)] <Bosmon> How are these strings used, in any case?
[13:25:56 CDT(-0500)] <Justin_o> Bosmon: there are two cases 1) in the renderer.. which i think means the message resolver took care of everything and we didn't need to worry about what's in the strings block 2) through some jquery method
[13:26:07 CDT(-0500)] <Justin_o> for cases where the renderer isn't used
[13:26:34 CDT(-0500)] <Bosmon> ok
[13:26:49 CDT(-0500)] <Bosmon> So it looks like this scheme will be helpful to take case or case 2)
[13:26:51 CDT(-0500)] <Bosmon> of case 2)
[13:26:55 CDT(-0500)] <Bosmon> Until we get ourselves a proper renderer
[13:28:25 CDT(-0500)] <Justin_o> Bosmon: so that means that when we want to use a string in a component direcctly we wouldn't use something like that.options.strings.slidingPanelShowText and instead would call that.stringBundle.slidingPanelShowText
[13:28:42 CDT(-0500)] <Bosmon> Justin_o - yes, something like that
[13:29:03 CDT(-0500)] <Justin_o> Bosmon: okay... is there any documentation or something you could point me at for writing such a facility
[13:29:16 CDT(-0500)] <Bosmon> Justin_o - I don't believe so
[13:29:25 CDT(-0500)] <Bosmon> anastasiac might know
[13:29:37 CDT(-0500)] <Justin_o> Bosmon: ah.. she's off for the rest of the day 
[13:29:55 CDT(-0500)] <Bosmon> Well, it's easy enough
[13:30:05 CDT(-0500)] <Bosmon> You just create a "thing" with a method on it called "resolvePathSegment"
[13:30:10 CDT(-0500)] <Bosmon> Similarly to the way the current DOM binder does
[13:33:08 CDT(-0500)] <Justin_o> Bosmon: ah okay.. so basically i use an expander there that returns a proper object
[13:34:10 CDT(-0500)] <Bosmon> Justin_o - yes
[13:34:17 CDT(-0500)] <Bosmon> And you can put this into some base grade of the panel
[13:34:24 CDT(-0500)] <Bosmon> Given it is the same for every component
[13:35:00 CDT(-0500)] <Justin_o> Bosmon: thanks.. makes sense.. i'll look into that
[13:42:10 CDT(-0500)] <Justin_o> Bosmon: hmm.. just looking at this a bit more closely.. so 1) this won't mess up the DOM binder right.. and will it only work through IoC?
[13:42:46 CDT(-0500)] <Justin_o> the and there is 2)
[13:43:58 CDT(-0500)] <Bosmon> Justin_o - right
[13:44:30 CDT(-0500)] <Justin_o> Bosmon: okay.. and in cases where they need to access it directly though a that object and not IoC they will have to do the lookup manually?
[13:45:04 CDT(-0500)] <Justin_o> Bosmon: also we have cases where were are converting namespaced keys with an array
[13:46:56 CDT(-0500)] <Justin_o> Bosmon: for example https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/messages/contrast.json
[13:48:15 CDT(-0500)] <Justin_o> i suppose the lookup can also attempt to determine if a namespace exists if string itself doesn't exist
[13:50:51 CDT(-0500)] <Bosmon> Justin_o - noone needs to access things directly
[13:51:20 CDT(-0500)] <Justin_o> Bosmon: okay.. and how did the dom binder link to the "dom" path segment
[13:51:32 CDT(-0500)] <Bosmon> Justin_o ?
[13:51:37 CDT(-0500)] <Justin_o> Bosmon: i can only see this that.resolvePathSegment = that.locate;
[13:51:43 CDT(-0500)] <Bosmon> Justin_o - that's it
[13:51:46 CDT(-0500)] <Bosmon> That is the entire mechanism
[13:51:49 CDT(-0500)] <Justin_o> but how does that translate to " .dom.something"
[13:52:03 CDT(-0500)] <Justin_o> how does it know about the "dom" portion of the path segment
[13:52:13 CDT(-0500)] <Bosmon> Justin_o - the "dom" portion is the address of the DOM binder itself
[13:52:42 CDT(-0500)] <Justin_o> ah i see
[13:53:22 CDT(-0500)] <Justin_o> okay.. so i need a member on the component that resolves to the message resolver and then i set the resolveSegmentPath on that to the lookup method
[14:07:34 CDT(-0500)] <Justin_o> Bosmon: i've filed a jira http://issues.fluidproject.org/browse/FLUID-5180
[14:10:54 CDT(-0500)] <Bosmon> Thanks, Justin_o
[14:10:55 CDT(-0500)] <Bosmon> Very clear
[14:11:18 CDT(-0500)] <Justin_o> Bosmon: thanks
[23:44:35 CDT(-0500)] <colinclark> yzen: zomg
[23:45:02 CDT(-0500)] <yzen> colinclark: hey
[23:45:12 CDT(-0500)] <colinclark> fucking node.js
[23:46:25 CDT(-0500)] <colinclark> A line like this has cost me a couple hours of debugging time: https://github.com/fluid-project/kettle/blob/master/kettle.js#L26
[23:47:05 CDT(-0500)] <colinclark> not that line, in particular, but one like it
[23:47:25 CDT(-0500)] <yzen> hm, how come?
[23:47:59 CDT(-0500)] <colinclark> Well, it's interesting
[23:48:20 CDT(-0500)] <colinclark> So, I have a module and an app
[23:48:32 CDT(-0500)] <colinclark> The module is called node-flocking, and it is a "Node wrapper" around Flocking
[23:48:37 CDT(-0500)] <colinclark> which of course depends on Infusion
[23:49:08 CDT(-0500)] <colinclark> The application is a Node.js that uses node-flocking
[23:49:15 CDT(-0500)] <colinclark> of course, it too uses Infusion
[23:49:34 CDT(-0500)] <colinclark> Today, I thought, "I should make Flocking a proper Node module"
[23:49:50 CDT(-0500)] <colinclark> and so I did something like this: https://github.com/colinbdclark/node-flocking/blob/master/index.js#L13
[23:50:12 CDT(-0500)] <colinclark> So, node-flocking has its own copy of Infusion
[23:50:19 CDT(-0500)] <colinclark> and then my app, in turn, has its copy of Infusion
[23:50:35 CDT(-0500)] <colinclark> The thing is, they're separate instances of Infusion
[23:51:11 CDT(-0500)] <colinclark> thus the result of require("fluid") in node-flocking is different from the same line in my app
[23:51:16 CDT(-0500)] <yzen> colinclark: ya i was a bit worried about it some time ago but then convinced myself that as long as the commit aha of my infusions is in sync in kettle and universal I'm ok
[23:51:32 CDT(-0500)] <colinclark> It's worse than that
[23:51:48 CDT(-0500)] <colinclark> So IoC in my app can't see references to "flock"
[23:52:34 CDT(-0500)] <colinclark> because the instance of fluid in the app, including its "global namespace," is isolated from that in node-flocking
[23:52:48 CDT(-0500)] <colinclark> or this Bosmon's theory, anyway
[23:53:02 CDT(-0500)] <colinclark> it's essentially impossible to actually make the two worlds meet directly, I think
[23:53:12 CDT(-0500)] <Bosmon> For reference here is the only lore I have found on this issue: http://justjs.com/posts/singletons-in-node-js-modules-cannot-be-trusted-or-why-you-can-t-just-do-var-foo-require-baz-init
[23:53:44 CDT(-0500)] <Bosmon> "If your main project also requires "shared," and that copy is installed with npm first before either one or two is installed with npm, and they depend on the same version, then npm will be clever and install the module only once at the main project's level, allowing the require statements in one/index.js and two/index.js to search upwards in the tree until they find the same file and return
[23:53:44 CDT(-0500)] <Bosmon> the same object."
[23:54:01 CDT(-0500)] <Bosmon> It seems very chancy
[23:54:33 CDT(-0500)] <yzen> oh ya that too, i think only 1 will be installed
[23:54:47 CDT(-0500)] <yzen> so recursively if she's match it will be the top level infusion
[23:56:34 CDT(-0500)] <colinclark> certainly npm hasn't done this in my case
[23:56:42 CDT(-0500)] <colinclark> though that may well be due to incompetence on my part
[23:57:30 CDT(-0500)] <colinclark> I guess I could blast the deeper copy of Infusion and see if it has any impact
[23:57:42 CDT(-0500)] <yzen> i would try that yes