[09:01:30 CDT(-0500)] <akshay> Hello michelled!
[09:23:47 CDT(-0500)] <system64> michelled: Any suggestions on how I can make my component more accessible?
[09:31:17 CDT(-0500)] <michelled> hi system64, what have you built so far with your component?
[09:53:24 CDT(-0500)] <system64> michelled: I've got the basic video conference room functionality working.
[09:54:38 CDT(-0500)] <michelled> that's great, system64
[09:58:00 CDT(-0500)] <system64> michelled: Right now there isn't much to configure in the component. I have added option for taking room name and signalling server.
[09:58:10 CDT(-0500)] <michelled> in terms of accessibility, perhaps you can first go through this list that anastasiac put together: http://wiki.fluidproject.org/display/docs/Quick-and-Dirty+Website+Accessibility+Tests+-+and+Fixes
[09:59:05 CDT(-0500)] <michelled> you might also be interested in this page: http://wiki.fluidproject.org/display/fluid/Laser+Eye+Checklist
[10:05:54 CDT(-0500)] <system64> Thanks, I'll go through the checklist again
[10:08:16 CDT(-0500)] <system64> michelled: I was trying to add mute and fullscreen buttons to all the video tiles. But couldn't get them working for remote video tiles, since they were dynamically added.
[10:08:23 CDT(-0500)] <heidiv> michelled anastasiac shall we skype about jiras for disc tool ? just chatted w Justin_o and i can help w low contrast theme and icon colour research
[10:08:38 CDT(-0500)] <heidiv> or chat here
[10:09:18 CDT(-0500)] <system64> michelled: I tried jQuery on but it still didn't work.
[10:10:41 CDT(-0500)] <michelled> system64: what browsers did you try it in?
[10:11:54 CDT(-0500)] <anastasiac> heidiv, I'm available, not sure about michelled
[10:12:10 CDT(-0500)] <Justin_o> heidiv: just chatting with jhung as well, you'll probably want to include him in your chat
[10:12:19 CDT(-0500)] <heidiv> cool
[10:12:35 CDT(-0500)] <michelled> I'm available 
[10:13:20 CDT(-0500)] <heidiv> cool don't see u on skype michelled
[10:14:16 CDT(-0500)] <system64> michelled: Only tested in chrome
[10:14:43 CDT(-0500)] <michelled> maybe try FF and see if you get different results
[10:15:58 CDT(-0500)] <system64> Also, I'm creating some markup for video controls in js right now. Is there a better way for that?
[10:16:08 CDT(-0500)] <heidiv> anastasiac jhung michelled chat after stand up?
[10:16:25 CDT(-0500)] <anastasiac> works for me
[10:16:37 CDT(-0500)] <jhung> sure works for me heidiv
[10:17:21 CDT(-0500)] <Justin_o> yzen, cindyli: did you want to get together to talk about the schema work we have for this week
[10:17:39 CDT(-0500)] <cindyli> sure, Justin_o
[10:17:56 CDT(-0500)] <Justin_o> cindyli, yzen: would you like to meet now
[10:18:08 CDT(-0500)] <cindyli> sure
[10:18:53 CDT(-0500)] <yzen> sure
[10:22:27 CDT(-0500)] <colinclark> system64: You'll probably want to give the Infusion Renderer a shot for generating markup without doing it in code
[10:22:54 CDT(-0500)] <colinclark> It's got a bit of a steep learning curve, but it's worth learning
[10:23:15 CDT(-0500)] <colinclark> I'm curious to try out what you've built so far, system64. Is it in a Github repo somewhere?
[10:24:40 CDT(-0500)] <system64> colinclark: You can try it here http://goo.gl/AJN8A
[10:25:58 CDT(-0500)] <system64> You'll need to run the demo on a server, since getusermedia won't work on local file system
[10:28:43 CDT(-0500)] <system64> colinclark: I did read about the renderer in the docs, couldn't figure out how the component trees worked?
[10:35:22 CDT(-0500)] <colinclark> system64: Cool, I'll check it out
[10:35:23 CDT(-0500)] <colinclark> As for component trees, what specifically didn't you understand?
[11:35:00 CDT(-0500)] <colinclark> Hey yzen, did Bosmon send you this yet? https://github.com/maxogden/dat
[11:35:04 CDT(-0500)] <colinclark> It's quite interesting
[11:35:14 CDT(-0500)] <yzen> nope
[11:35:47 CDT(-0500)] <colinclark> He refers to "SLEEP," which appears to just be the CouchDB replication protocol
[11:36:13 CDT(-0500)] <colinclark> It's nice to hear some of our ideas about data-orientation echoed
[11:39:11 CDT(-0500)] <yzen> colinclark: now i remember seeing a tweet about it
[12:20:27 CDT(-0500)] <Justin_o> Bosmon: hello.. are you there right now.. cindyli, yzen, and I had a couple things to run by you for the schema work
[12:28:02 CDT(-0500)] <Bosmon> Hi Justin_o
[12:28:20 CDT(-0500)] <Justin_o> Bosmon: hello
[12:28:34 CDT(-0500)] <Justin_o> Bosmon: I'll start off with the easier question
[12:28:42 CDT(-0500)] <Justin_o> Bosmon: what is the plural form of schema
[12:28:44 CDT(-0500)] <Justin_o> ?
[12:29:29 CDT(-0500)] <anastasiac> Justin_o: schemata or schemas
[12:29:35 CDT(-0500)] <anastasiac> ?
[12:30:37 CDT(-0500)] <Justin_o> anastasiac: thanks we've been debating a bit about which form to use with the UIO related grades
[12:31:31 CDT(-0500)] <yzen> schemae?
[12:32:04 CDT(-0500)] <anastasiac> merriam-webster says schemata or schemas
[12:32:13 CDT(-0500)] <anastasiac> +1 for schemas
[12:33:07 CDT(-0500)] <Bosmon> yzen - not schemae since it is Greek and not Latin
[12:45:27 CDT(-0500)] <heidiv> greggy does ATutor have a "low contrast" theme?
[12:46:32 CDT(-0500)] <greggy> heidiv: The default theme is fairly low contrast
[12:46:48 CDT(-0500)] <heidiv> greggy ok
[12:46:49 CDT(-0500)] <greggy> there isn't one specifically
[12:46:54 CDT(-0500)] <heidiv> k
[12:46:55 CDT(-0500)] <heidiv> thanks!
[12:47:15 CDT(-0500)] <greggy> using AFA one could create their own however
[12:47:43 CDT(-0500)] <greggy> heidiv: ^
[12:48:25 CDT(-0500)] <heidiv> greggy AFA?
[12:48:39 CDT(-0500)] <greggy> AccessForAll Preferences
[12:48:45 CDT(-0500)] <heidiv> right
[13:02:32 CDT(-0500)] <Justin_o> Bosmon, cindyli, anastasiac, yzen: sorry i disappeared for a bit there
[13:02:42 CDT(-0500)] <Justin_o> are people happy with schemas then?
[13:02:45 CDT(-0500)] <yzen> yes
[13:03:13 CDT(-0500)] <Bosmon> Justin_o - did you have some things to query?
[13:03:26 CDT(-0500)] <Justin_o> Bosmon: yes
[13:04:09 CDT(-0500)] <Justin_o> Bosmon: the other one was about how to get the other info we need for the settings panels from the primary schema.. so we have a method for getting the default model and the related model relay binding between the various pieces
[13:04:23 CDT(-0500)] <Justin_o> but we don't have a means to get things like min/max and enum
[13:04:44 CDT(-0500)] <Justin_o> Bosmon: cindyli, yzen, and I were putting out some ideas after stand up today
[13:05:39 CDT(-0500)] <Bosmon> Justin_o - I expect you would get them from the relevant SCHEMA GRADDE
[13:08:34 CDT(-0500)] <Justin_o> here were a couple of the ideas were were throwing around
[13:08:35 CDT(-0500)] <Justin_o> http://pastie.org/private/joujbu7uhezkgwx1unama
[13:08:58 CDT(-0500)] <Justin_o> Bosmon: the question is more how do we get it from the relevant schema grade?
[13:09:17 CDT(-0500)] <Bosmon> Justin_o - how could you avoid getting it from there
[13:09:26 CDT(-0500)] <Bosmon> It doesn't seem to require any extra machinery of the type you have drafted there
[13:09:39 CDT(-0500)] <Justin_o> Bosmon: i don't think you could avoid it, but how would you know what to take and put where?
[13:09:46 CDT(-0500)] <Justin_o> Bosmon: really
[13:10:12 CDT(-0500)] <Bosmon> Justin_o - how would you know what to take with what you have written there
[13:10:20 CDT(-0500)] <Justin_o> Bosmon: do you think you could explain how you think the current machinery would work, I can't quite picture it right now
[13:11:09 CDT(-0500)] <Bosmon> Justin_o - you would use FLUID-5067 to look up the associated schema grade, and then get the fields out of it
[13:14:17 CDT(-0500)] <Justin_o> Bosmon: but how would you know that minimum goes to range.min
[13:14:32 CDT(-0500)] <Bosmon> Justin_o - how would you know it with the scheme you have written there!
[13:14:39 CDT(-0500)] <Bosmon> At least JSON Schema is a public standard
[13:14:45 CDT(-0500)] <Justin_o> it's on the left side
[13:14:58 CDT(-0500)] <Bosmon> And how does it help that it is on the left side?
[13:15:10 CDT(-0500)] <Bosmon> Someone still needs to know to read it : P
[13:15:49 CDT(-0500)] <Justin_o> Bosmon: i mean to say that the information is at least present.. we don't have anything at the moment that would tell us where to put the minimum, maximum, and/or enum values from the primary schema into a settings panels options
[13:17:34 CDT(-0500)] <Bosmon> Justin_o - ok, the 1st version of what you have sketched out there looks good
[13:18:34 CDT(-0500)] <yzen> woo hoo
[13:18:42 CDT(-0500)] <Justin_o> haha
[13:19:05 CDT(-0500)] <Justin_o> yzen: i thought you'd like it.. actually after having to write it, it definitely looked better than option 2
[13:21:22 CDT(-0500)] <Justin_o> cindyli, yzen: do we have other questions for Bosmon ?
[13:21:42 CDT(-0500)] <yzen> Justin_o: Bosmon not at the moment i guess
[13:22:00 CDT(-0500)] <cindyli> same here
[13:23:01 CDT(-0500)] <Justin_o> okay.. thanks for your help Bosmon
[13:56:30 CDT(-0500)] <Justin_o> michelled: i just pushed up jhung's FLUID-4997 pull request.. do you think you could look at FLUID-5067 and FLUID-5076
[13:56:48 CDT(-0500)] <michelled> Justin_o: sure
[13:56:57 CDT(-0500)] <Justin_o> michelled: thanks
[13:57:01 CDT(-0500)] <michelled> np
[13:57:55 CDT(-0500)] <michelled> Bosmon: I'm looking at the 5067 pull request
[13:58:06 CDT(-0500)] <michelled> are you expecting people to use indexDefaults directly?
[14:04:48 CDT(-0500)] <Bosmon> michelled - yes
[14:05:07 CDT(-0500)] <Bosmon> In particular, in code held in the "UIOptions Builder"
[14:07:29 CDT(-0500)] <michelled> Bosmon: from the JIRA, I see that this functionality allows us to look up related grades. Am I understanding that correctly?
[14:07:56 CDT(-0500)] <Bosmon> michelled - that is right
[14:08:54 CDT(-0500)] <michelled> I don't actually find 'indexDefaults' to be a very clear name. Perhaps it's just that I'm missing some context.
[14:09:24 CDT(-0500)] <Bosmon> michelled - it allows the user to index the material which is held in the defaults for a particular grade
[14:09:36 CDT(-0500)] <Bosmon> That is, they supply a function which boils down the defaults to an "index key"
[14:09:42 CDT(-0500)] <Bosmon> It is then the index key by which one looks up the grade
[14:10:22 CDT(-0500)] <Bosmon> In the case of UIO, these index keys are the things we used to call "common grades" but I think we are now calling something like "preference keys" or so
[14:10:26 CDT(-0500)] <Bosmon> I forget the exact name we decided on
[14:16:03 CDT(-0500)] <michelled> Bosmon: by the time this line gets executed, what does the defaultsStore have in it? https://github.com/amb26/infusion/blob/24a637361a46325aa273fea1ccc5be060d275ea2/src/webapp/framework/core/js/Fluid.js#L1360
[14:17:19 CDT(-0500)] <Bosmon> michelled - the defaultsStore holds records for every component which has registered fluid.defaults()
[14:18:44 CDT(-0500)] <michelled> do demands or options ever alter the defaults store?
[14:20:27 CDT(-0500)] <Bosmon> michelled - yes, they do, since FLUID-5033 went in, component defaults can be reloaded
[14:20:47 CDT(-0500)] <colinclark>
[14:25:10 CDT(-0500)] <michelled> ah, right
[14:28:52 CDT(-0500)] <michelled> Bosmon: I think I'd still have trouble explaining to someone when they would use index defaults.
[14:29:10 CDT(-0500)] <Bosmon> michelled - I think I would too
[14:29:17 CDT(-0500)] <michelled> hehe
[14:29:23 CDT(-0500)] <Bosmon> Luckily the only people we expect to be using it for now are quite clear about why they want it
[14:29:31 CDT(-0500)] <Bosmon> Aren't they, Justin_o, cindyli and yzen
[14:29:53 CDT(-0500)] <michelled> can one of you explain to me why you want it?
[14:31:25 CDT(-0500)] <Justin_o> michelled: basically we want to do a reverse look up of a component/grade
[14:31:52 CDT(-0500)] <Justin_o> that is to look up a component based on some characteristic rather than by name
[14:32:56 CDT(-0500)] <michelled> Justin_o: where 'characteristic' is the preference key?
[14:33:05 CDT(-0500)] <Justin_o> michelled: yes
[14:33:26 CDT(-0500)] <michelled> Bosmon: am I right that
[14:33:36 CDT(-0500)] <michelled> indexDefaults doesn't actually do the looking cup?
[14:34:01 CDT(-0500)] <michelled> it returns the structure that Justin_o would use to look up the component/grade he cares about?
[14:34:05 CDT(-0500)] <Bosmon> michelled - no, it actually does the looking up
[14:34:16 CDT(-0500)] <Bosmon> It just embeds the result of the looking up in that structure
[14:34:36 CDT(-0500)] <Bosmon> It's not the most efficient system, but it matches the usage pattern we expect for now
[14:34:52 CDT(-0500)] <Bosmon> In the future we might use it as part of an authoring tool where we would need better performance
[14:35:15 CDT(-0500)] <michelled> fair enough. I'm wondering if we should rename it to include the word 'find' or 'lookUp'
[14:35:28 CDT(-0500)] <michelled> it would then be more clear why we have this public API
[14:37:00 CDT(-0500)] <Bosmon> I don't think it would be any clearer IMO
[14:37:06 CDT(-0500)] <Bosmon> You could say that what it does is to "build an index"
[14:37:15 CDT(-0500)] <Bosmon> In which someone can later do the looking up
[14:37:39 CDT(-0500)] <Bosmon> As per the API comment you can see that these "indexes" might someday be persistent
[14:38:03 CDT(-0500)] <Bosmon> Which is why the API currently accepts the currently unused "indexName" argument
[14:39:38 CDT(-0500)] <Bosmon> If we changed its name, it would prevent a change in implementation strategy occuring later
[14:40:43 CDT(-0500)] <Justin_o> Bosmon: what does the structure it returns look like exactly
[14:41:05 CDT(-0500)] <Bosmon> Justin_o - it returns a structure whose keys are the "index strings" and whose values are lists of grades matching that index
[14:42:15 CDT(-0500)] <Bosmon> In the future, the framework might maintain this index structure "live" in the style of a "CouchDB view"
[14:42:27 CDT(-0500)] <Bosmon> But right now it is computed from scratch every time you make a call to the API
[14:42:40 CDT(-0500)] <michelled> Bosmon: so in Justin_o's case, he'd pass in all the index strings he cares about and the function would build a structure that would tell him all the grades related to each index string?
[14:43:07 CDT(-0500)] <Bosmon> michelled - the function computes the complete index
[14:43:18 CDT(-0500)] <Bosmon> Justin_o then looks up the strings he is interested in in the returned structure
[14:45:53 CDT(-0500)] <Justin_o> Bosmon: is the list grade names or actual component references?
[14:46:06 CDT(-0500)] <Justin_o> or maybe at this stage this doesn't matter
[14:46:39 CDT(-0500)] <Bosmon> Justin_o - it contains grade names
[14:48:35 CDT(-0500)] <colinclark> Bosmon: You were telling me about your experience debugging with the Renderer
[14:48:40 CDT(-0500)] <colinclark> tell me more about what it was like
[14:48:47 CDT(-0500)] <Bosmon> colinclark - it was awful
[14:48:54 CDT(-0500)] <Bosmon> Since you need to know how it is implemented : P
[14:49:08 CDT(-0500)] <Bosmon> And what is worse, it is implemented as the accretion of perhaps 3 separate attempts at the same problem
[14:49:31 CDT(-0500)] <Bosmon> There are "original component trees", "dehydrated component trees" and "protoComponent trees"
[14:49:48 CDT(-0500)] <Bosmon> I was convinced that the component tree that the Pager had generated was invalid, since I couldn't recognise its structure
[14:50:21 CDT(-0500)] <Bosmon> But it turns out that it was fine, it was just another of the strange unofficial variants the we supported
[14:51:16 CDT(-0500)] <Bosmon> This hugely increases the premium on our centring all of our efforts on just ONE bizarre JSON declarational format, that of standard IoC component trees, and creating appropriate tooling and documentation around it
[14:51:17 CDT(-0500)] <colinclark> Yeah, that's pretty terrible
[14:51:25 CDT(-0500)] <colinclark> indeed
[14:51:37 CDT(-0500)] <colinclark> What can be done to help Renderer users today, do you think?
[14:51:37 CDT(-0500)] <Bosmon> All of the renderer component formats need to be abolished
[14:52:00 CDT(-0500)] <Bosmon> unfortunately in doing so we will end up exacerbating what was always another of the worst aspects of the "old renderer", that is its performance
[14:52:18 CDT(-0500)] <Bosmon> The initial performance of the "new renderer" will be worse still, until we can come up with some "clever tricks"
[14:52:38 CDT(-0500)] <colinclark> We've talked a bit about some of those clever tricks...
[14:52:45 CDT(-0500)] <colinclark> but perhaps you want to summarize them again here?
[14:52:53 CDT(-0500)] <colinclark> or perhaps I'm just distracting you from more important work
[14:53:12 CDT(-0500)] <Bosmon> We need a way to bypass almost 100% of the IoC instantiation machinery where we can recognise that the component which will be constructed is in some sense "extremely simple"
[14:53:29 CDT(-0500)] <Bosmon> That is to do essentially zero options expansion and merging, and to construct no "shadow record" at all
[14:53:41 CDT(-0500)] <colinclark> By what means could we identify a thing's simplicity?
[14:53:49 CDT(-0500)] <colinclark> And what makes something "extremely simple" in IoC terms?
[14:54:04 CDT(-0500)] <Bosmon> I realised during today's shower time that the essential thing we can't do without is the "instantiator record" without which we couldn't efficiently tell where there was a component at all
[14:54:07 CDT(-0500)] <Bosmon> But that should be relatively cheap
[14:54:33 CDT(-0500)] <Bosmon> colinclark - the things that will be judged "extremely simple" are i) AT LEAST the things which directly correspond to today's "renderer components" but ii) hopefully in the end some wider class of things
[14:55:03 CDT(-0500)] <Bosmon> So in the work of abolishing the renderer we will construct new "real grades" for example fluid.renderer.uiInput etc.
[14:55:11 CDT(-0500)] <Bosmon> An actual grade corresponding to each "old renderer component"
[14:55:48 CDT(-0500)] <Bosmon> Now people are free to use all the IoC machinery available to elaborate these grade instances into bigger components, by supplying them with dynamic grades, demands blocks, etc.
[14:56:30 CDT(-0500)] <Bosmon> But in the case that the framework can detect up front that they have no new interesting grade content, it should just bypass all of the IoC system, and even the standard lifecycle system too, etc.
[14:56:51 CDT(-0500)] <colinclark> Right, that makes sense
[14:56:54 CDT(-0500)] <Bosmon> And just instantiate a "shell component" which may even get further economies through the use of (horrors!) prototypal inheritance
[14:57:25 CDT(-0500)] <Bosmon> That is, if it can be PROVED that something is just a fluid.renderer.uiInput component, rather than instantiating a complete one, we should just pick a prototype off the shelf and stick a couple of fields in it
[14:57:51 CDT(-0500)] <Bosmon> Under this model, the "new renderer" need not be much more expensive than the old one
[14:57:57 CDT(-0500)] <colinclark> We'd literally accomplish this via JS's prototypes?
[14:58:01 CDT(-0500)] <Bosmon> And may in time pave the way to even more aggressive optimisations
[14:58:02 CDT(-0500)] <Bosmon> Yes
[14:58:23 CDT(-0500)] <Bosmon> I think we will need to start using JS prototypes increasingly once we start optimising the IoC system in any case
[14:58:37 CDT(-0500)] <Bosmon> There are plenty of situations which are already ripe for it, including the "root merge policy" which is now really quite huge
[14:59:15 CDT(-0500)] <Bosmon> But in theory the use of these "shell components" could help us get economies in all kinds of other situations where we couldn't before
[14:59:39 CDT(-0500)] <Bosmon> For example in the CSpace "giant page with 1000 widgets" it's clear that perhaps there are only 12 or so kinds of different widgets on the page
[14:59:49 CDT(-0500)] <colinclark> I guess in the super advanced future we'll just end up with regular objects and "arrow functions" and the possibility of prototypes where appropriate
[14:59:55 CDT(-0500)] <colinclark> just in time for IE 20 
[14:59:58 CDT(-0500)] <Bosmon> arrow functions!!
[15:00:28 CDT(-0500)] <colinclark> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions
[15:00:45 CDT(-0500)] <colinclark> Your Friend Alex Russell-ism
[15:02:05 CDT(-0500)] <Bosmon> So horrible and worthless
[15:02:12 CDT(-0500)] <Bosmon> Well, at least they capture the "this" pointer
[15:02:25 CDT(-0500)] <colinclark> That's really all we'd want anyway
[15:02:40 CDT(-0500)] <Bosmon> Well, but we don't want it!
[15:02:46 CDT(-0500)] <Bosmon> What is the "this" value for a free function?
[15:03:04 CDT(-0500)] <Bosmon> "We don't want that" : P
[15:04:09 CDT(-0500)] <colinclark> Presumably it's the same as for any other free function
[15:04:35 CDT(-0500)] <colinclark> I mean, really it's the privacy of Crockford "module pattern" that we decided we didn't want
[15:04:40 CDT(-0500)] <Bosmon> Yes
[15:04:44 CDT(-0500)] <Bosmon> Lots of things we don't want
[15:04:44 CDT(-0500)] <colinclark> nor the constant need to call Object.bind()
[15:05:00 CDT(-0500)] <colinclark> and so arrow functions give us the only thing we're really interested in
[15:05:11 CDT(-0500)] <Bosmon> But what is that thing?
[15:05:19 CDT(-0500)] <Bosmon> I don't think they even give us one thing we're interested in
[15:05:24 CDT(-0500)] <colinclark> which is the ability to lexically bind "this" to an object's method when it is called as a free function
[15:05:33 CDT(-0500)] <Bosmon> Since we plan in the future to only code with free functions
[15:05:43 CDT(-0500)] <colinclark> In that case, we don't even care about that
[15:06:14 CDT(-0500)] <Bosmon> We stopped writing objects with methods in 2011 : P
[15:07:39 CDT(-0500)] <colinclark> I can still find dozens of that = … assignments throughout our framework code
[15:08:54 CDT(-0500)] <Bosmon> colinclark - can you give an example?
[15:09:17 CDT(-0500)] <colinclark> I think we both have more interesting conversations to have at this point
[15:10:11 CDT(-0500)] <Bosmon> ok
[15:13:23 CDT(-0500)] <Bosmon> There should be about 50 or so less of them once my next pull gets in
[15:13:33 CDT(-0500)] <Bosmon> Now I just need to rewrite anastasiac "fiveStar" demo : P
[15:13:56 CDT(-0500)] <Bosmon> Which I believe is the last example left of an "old that" in the framework image
[15:14:32 CDT(-0500)] <colinclark> cool
[15:20:12 CDT(-0500)] <colinclark> Hey nanook_, how's it going?
[15:20:34 CDT(-0500)] <nanook_> hey colinclark
[15:20:44 CDT(-0500)] <nanook_> trying out curb's foundation
[15:20:47 CDT(-0500)] <nanook_> zurb*
[15:20:57 CDT(-0500)] <nanook_> got sass, compass setup
[15:22:45 CDT(-0500)] <colinclark> cool
[15:23:27 CDT(-0500)] <colinclark> I like Foundation's documentation and very visual examples
[15:23:45 CDT(-0500)] <colinclark> http://foundation.zurb.com/templates.php
[15:23:56 CDT(-0500)] <colinclark> http://foundation.zurb.com/grid-example3.php
[15:24:19 CDT(-0500)] <colinclark> If we ever revive the FSS, this is exactly the sort of thing that can make users' lives easier
[15:24:21 CDT(-0500)] <nanook_> yea! and i've heard its a lot easier to style than bootstrap
[15:24:52 CDT(-0500)] <colinclark> Interesting
[15:25:25 CDT(-0500)] <nanook_> also, bootstrap uses LESS
[15:25:34 CDT(-0500)] <colinclark> ah yes, that's right
[15:26:04 CDT(-0500)] <Bosmon> And we certainly need a new framework logo in the style of a blond chick on the phone : P
[15:26:08 CDT(-0500)] <colinclark> For those of us working on icon fonts, Foundation has a nice page documenting theirs: http://zurb.com/playground/foundation-icons
[15:26:23 CDT(-0500)] <colinclark> Bosmon is referring to http://sass-lang.com/
[15:26:28 CDT(-0500)] <colinclark>
[15:26:40 CDT(-0500)] <colinclark> I still quite like the Infusion logo, whatever it is
[15:26:51 CDT(-0500)] <colinclark> but I guess it will soon be "passé"
[15:27:15 CDT(-0500)] <colinclark> now that Jony Ive has decreed flat to be "the new black"
[15:27:46 CDT(-0500)] <Bosmon> I was going to make some disparaging comment about French accents, but given the recent raid by the French government on Apple stores, they can do no wrong in my eyes
[15:27:54 CDT(-0500)] <nanook_> Haha.. how do you know she's blonde?
[15:28:32 CDT(-0500)] <Bosmon> I like our logo too
[15:28:43 CDT(-0500)] <Bosmon> And I don't want to have to throw away the mugs I have with it on : P
[15:29:18 CDT(-0500)] <colinclark> I guess we have two logos...
[15:29:22 CDT(-0500)] <colinclark> one for Fluid and one for Infusion
[15:29:26 CDT(-0500)] <colinclark> This is the Infusion one: http://wiki.fluidproject.org/download/attachments/24939866/INFUSION_orange.png?version=1&modificationDate=1305123162481
[15:29:28 CDT(-0500)] <nanook_> Offtopic: I'm not sure if you've seen this.. but its hilarious: http://jonyiveredesignsthings.tumblr.com/
[15:29:28 CDT(-0500)] <Bosmon> Don't forget the one for Kettle
[15:29:44 CDT(-0500)] <Bosmon> Which I believe is shortly to be applied to a fresh github project....
[15:30:26 CDT(-0500)] <colinclark> nanook_: this is hilarious
[15:30:38 CDT(-0500)] <colinclark> I thought I was alone in thinking that the new flat iOS look was insane
[15:30:58 CDT(-0500)] <colinclark> oh yes, the Kettle logo!
[15:31:23 CDT(-0500)] <colinclark> Beloved by tea drinkers across the Greater Boulder region
[15:31:31 CDT(-0500)] <Bosmon> I do like "Jony Ive redesigns music bands"
[15:32:21 CDT(-0500)] <nanook_> Which one's the kettle logo?
[15:33:11 CDT(-0500)] <Bosmon> Just got down to : "Jony Ive redesigns the charging screen.
[15:33:11 CDT(-0500)] <Bosmon> Irony: this is actually the charging screen in iOS7."
[15:35:48 CDT(-0500)] <nanook_> colinclark Bosmon: What IDEs/editors do you use for web-dev?
[15:36:00 CDT(-0500)] <Bosmon> nanook_ - best not to ask me
[15:36:05 CDT(-0500)] <Bosmon> I defer to colinclark to asnwer as someone cool
[15:36:34 CDT(-0500)] <colinclark> oh
[15:36:43 CDT(-0500)] <colinclark> I tend to defer to yzen for cool advice
[15:36:51 CDT(-0500)] <colinclark> but since his IDE costs money...
[15:36:59 CDT(-0500)] <colinclark> I use TextMate
[15:37:09 CDT(-0500)] <colinclark> these days, I gather the cool kids are flocking to Sublime Text
[15:37:17 CDT(-0500)] <colinclark> which has the added advantage of running across all platforms
[15:37:24 CDT(-0500)] <colinclark> but it too costs money
[15:37:36 CDT(-0500)] <yzen> SUBLIME
[15:37:37 CDT(-0500)] <yzen>
[15:37:42 CDT(-0500)] <nanook_> I've been trying out web storm for the past few days..
[15:37:55 CDT(-0500)] <nanook_> their Live Edit is pretty awesome!
[15:38:02 CDT(-0500)] <nanook_> but yeah.. it costs money
[15:38:18 CDT(-0500)] <Bosmon> IDEs that cost money!
[15:38:21 CDT(-0500)] <yzen> cool, it supports typescript
[15:38:23 CDT(-0500)] <Bosmon> I'm uncool, but not quite that uncool
[15:38:42 CDT(-0500)] <nanook_> Bosmon: whats an uncool editor? i'm curious
[15:38:53 CDT(-0500)] <Bosmon> Astonishingly and horrifyingly, I still use Eclipse......
[15:39:04 CDT(-0500)] <colinclark> Typescript is cool?
[15:39:39 CDT(-0500)] <nanook_> Ah! I tried aptana for a while. its pretty decent IMO
[15:39:57 CDT(-0500)] <Bosmon> I couldn't stand Aptana
[15:40:09 CDT(-0500)] <Bosmon> Bizarrely I use a JS plugin that Adobe released for Eclipse in 2007 and then forgot about
[15:40:30 CDT(-0500)] <colinclark> so funny
[15:40:32 CDT(-0500)] <nanook_> Isn't Aptana Eclipse with some plugins?
[15:40:43 CDT(-0500)] <Bosmon> I plan to carry on in this way until we can move 100% of our development to a good web IDE
[15:40:45 CDT(-0500)] <colinclark> Didn't you decompile it or something, Bosmon, to change some hard-coded colours?
[15:40:49 CDT(-0500)] <Bosmon> colinclark - I did, yes
[15:41:00 CDT(-0500)] <Bosmon> It hard-coded some of the HTML colours to black
[15:41:11 CDT(-0500)] <colinclark> I'm embarrassed to admit that I occasionally play around with Adobe Brackets and think it's ok
[15:41:21 CDT(-0500)] <colinclark> My primary feature requirement in an "IDE" is to utterly lack features
[15:41:31 CDT(-0500)] <Bosmon> I guess mine is similar
[15:41:31 CDT(-0500)] <nanook_> The inline CSS edit in brackets is really cool
[15:41:39 CDT(-0500)] <Bosmon> Although I would express it as "not to get in my way"
[15:41:40 CDT(-0500)] <colinclark> But it is nice to have an inline linter
[15:41:50 CDT(-0500)] <Bosmon> That is, not to type anything automatically for me that I then have to delete
[15:41:59 CDT(-0500)] <colinclark> yes
[15:42:32 CDT(-0500)] <colinclark> My only complaint about TextMate is that I haven't figured out how to make the file panel black
[15:42:34 CDT(-0500)] <colinclark> but I can live with that
[15:42:42 CDT(-0500)] <Bosmon> The JS plugin in the latest Eclipse is less disastrous than before but still unusable
[15:42:53 CDT(-0500)] <Bosmon> Amazingly, despite showing me some linting errors, it wouldn't actually show me syntax errors : P
[15:43:07 CDT(-0500)] <Bosmon> This is the kind of blunder that IBM's India devs seem prone to
[15:43:19 CDT(-0500)] <nanook_> Textmate has been getting awesome off late, silently
[15:43:24 CDT(-0500)] <colinclark> it has, yes
[15:43:32 CDT(-0500)] <Bosmon> Also they NEARLY got "keyword matching" working
[15:43:42 CDT(-0500)] <Bosmon> But I would actually like MORE highlighting of matching strings and not less
[15:44:03 CDT(-0500)] <Bosmon> With the way our framework works now, you very often want to match "keywords" even when they are within strings
[15:44:31 CDT(-0500)] <Bosmon> Given our framework directives are becoming increasingly embedded within strings held in JSON blocks
[15:46:28 CDT(-0500)] <Bosmon> Much to the hatred of type theorists everywhere
[15:47:21 CDT(-0500)] <nanook_> Bosmon: what do you mean by "keyword matching" ?
[15:48:46 CDT(-0500)] <Bosmon> nanook_: I think it is a feature sometimes called "highlight matching keywords"
[15:49:00 CDT(-0500)] <Bosmon> When you select a particular string in the buffer, it will automatically highlight all other strings which match it
[15:49:28 CDT(-0500)] <Bosmon> I find it perhaps the #1 useful feature when dealing with JS files since often it is the only way to monitor a refactoring process
[15:49:45 CDT(-0500)] <Bosmon> We don't, after all, have any tools that have any insight into the structure of our code, the way we did in the Java days
[15:49:51 CDT(-0500)] <Bosmon> So "highlight matching keywords" is really it
[15:50:54 CDT(-0500)] <nanook_> So find and replace across files?
[15:50:58 CDT(-0500)] <nanook_> something like that
[15:51:11 CDT(-0500)] <Bosmon> Well yes, only it is instant
[15:51:24 CDT(-0500)] <Bosmon> You don't do anything to request it, as soon as you highlight any text, it updates automatically
[15:59:49 CDT(-0500)] <michelled> Bosmon: I'm still not happy with the name indexDefaults but I can't think of anything better. I'm hoping when yzen, cindyli and justin_o use it, a better name will present itself. I'm about to push your pull request. I suppose we should add this to the list of things that need to be documented before the next release.
[16:00:03 CDT(-0500)] <Bosmon> michelled - thanks
[16:00:10 CDT(-0500)] <Bosmon> Although I don't think we expect this to be a very popular API
[16:00:54 CDT(-0500)] <michelled> true, but I suppose we never know how someone will use the framework
[16:01:07 CDT(-0500)] <Bosmon> It's just barely above the "NON-API" level that we typically comment
[16:03:16 CDT(-0500)] <colinclark> Why are you unhappy with this name, michelled?
[16:04:00 CDT(-0500)] <michelled> colinclark: because I don't think it's clear why someone would use this function
[16:04:20 CDT(-0500)] <michelled> and since we aren't marking it at NON-API, I feel we should be more clear
[16:04:25 CDT(-0500)] <colinclark> What cases do you anticipate them using it?
[16:04:26 CDT(-0500)] <Bosmon> michelled - I feel that is more a reflection on the function than the name
[16:04:27 CDT(-0500)] <michelled> but I really don't have a better name
[16:05:00 CDT(-0500)] <colinclark> michelled: ^
[16:06:33 CDT(-0500)] <michelled> colinclark: right now it's there so that we can find related ants
[16:06:48 CDT(-0500)] <colinclark> who?
[16:07:02 CDT(-0500)] <michelled> yzen, cindyli and justin_o