fluid-work IRC Logs-2013-07-23

Owned by Fluid IRC Log Bot
Last updated: Jul 23, 2013Version comment
7 min read

[08:44:41 CDT(-0500)] <heidiv> hey michelled , i added a couple tiny css jiras to the resource iteration list and will tackle those today. thought next i might look at http://issues.gpii.net/browse/GPII-131 - thoughts?

[09:06:41 CDT(-0500)] <michelled> heidiv: I wonder if you could do some testing of what is currently done

[09:06:49 CDT(-0500)] <heidiv> michelled for sure

[09:06:56 CDT(-0500)] <michelled> it would be good for us to have an idea of our state

[09:07:10 CDT(-0500)] <heidiv> michelled test master or is there a particular branch to check out

[09:07:13 CDT(-0500)] <heidiv> ?

[09:07:13 CDT(-0500)] <michelled> I'm guessing there are a bunch of little things that are currently falling through cracks (smile)

[09:07:27 CDT(-0500)] <michelled> test master

[09:07:35 CDT(-0500)] <heidiv> michelled aye aye! i'm on it.

[09:08:02 CDT(-0500)] <michelled> thx heidiv!

[10:05:25 CDT(-0500)] <heidiv> anastasiac michelled is simplify supposed to remove the main menu?

[10:05:32 CDT(-0500)] <heidiv> i'm guessing… not

[10:05:53 CDT(-0500)] <anastasiac> heidiv, yes, it should remove everything except the article, and it should add a table of contents

[10:06:57 CDT(-0500)] <heidiv> anastasiac interesting… just cos in this case the menu links are for things like "download", "make a copy" "share" etc. vs. navigation within page. but ok!

[10:07:59 CDT(-0500)] <anastasiac> heidiv, this might be something to double-check with vjoanna, but I think those things should still be remove. The goal is to remove distractions, I believe

[10:08:27 CDT(-0500)] <heidiv> right

[10:10:24 CDT(-0500)] <vjoanna> heidiv: i'm not sure i understand, what do you mean by the main menu?

[10:11:06 CDT(-0500)] <heidiv> vjoanna in the case of our resource, the menu on the left. but i agree w anastasiac they it makes sense to remove as it's not relevant to article content really

[10:14:39 CDT(-0500)] <vjoanna> heidiv, yeah that makes sense to me too

[10:16:43 CDT(-0500)] <vjoanna> heidiv: hmm.. now i'm wondering would the 'details' and the 'resources' sections at the bottom of the article be included?

[10:17:20 CDT(-0500)] <heidiv> vjoanna hmm , yes i think so?

[10:17:40 CDT(-0500)] <vjoanna> heidiv, yeah i think so too

[10:18:38 CDT(-0500)] <heidiv> vjoanna k, cool. yeah and need to increase the padding at the bottom of the page so content doesn't get hidden by the DT bar

[12:49:02 CDT(-0500)] <cindyli> hi, Bosmon

[12:50:27 CDT(-0500)] <Bosmon> cindyli QI LI!

[12:51:06 CDT(-0500)] <cindyli> Bosmon: shall our auxiliary schema accommodate the use case that one preference is used by several panels?

[12:51:22 CDT(-0500)] <cindyli> should we make the panel block an array

[12:53:00 CDT(-0500)] <cindyli> i don't think at this point we have the case that one preference needs multiple enactors. but for panels, it does happen with discovery tool

[12:53:51 CDT(-0500)] <Bosmon> cindyli - it can accommodate it

[12:54:01 CDT(-0500)] <Bosmon> Since there is no relationship between the panel's key and the preference

[12:54:05 CDT(-0500)] <Bosmon> It is just "a key"

[12:54:41 CDT(-0500)] <cindyli> ok, panel block will accept an array or an object

[13:06:27 CDT(-0500)] <Bosmon> cindyli - we need it to just accept an object

[13:06:35 CDT(-0500)] <Bosmon> Otherwise we will just be back with the problem we previously had

[13:12:42 CDT(-0500)] <cindyli> Bosmon: having one object accepts multiple panels, would each panel need to be key off a keyword, which leads to, 1. one more nested layer; 2. what that keyword would be

[13:13:19 CDT(-0500)] <cindyli> maybe the keyword doesn't matter, it will be ignored anyway

[13:13:24 CDT(-0500)] <Bosmon> cindyli - there would just be the same level of nesting - since each block in the aux schema is already identified by a key

[13:13:37 CDT(-0500)] <Bosmon> So 1. no more nested layer, and 2. the user would invent the key by themselves

[13:18:19 CDT(-0500)] <Bosmon> To be clear, I think we need to adopt a model where each keyed block at the top level in the aux schema accepts 0 or 1 each of a panel, an enactor, and a schema block

[13:18:34 CDT(-0500)] <Bosmon> But only in the case of a schema block does the key mean anything

[13:18:59 CDT(-0500)] <Bosmon> In that case, it becomes the "relative model path" in the top-level "root model"

[13:19:13 CDT(-0500)] <Bosmon> Insofar as that could be considered to "mean anything" since in fact it is just another implementation detail.............

[13:21:16 CDT(-0500)] <cindyli> to clarify, in the case that one preference associates with multiple panels, multiple keyed top level blocks need to be created, right?

[13:25:47 CDT(-0500)] <cindyli> a problem with this solution is, since the top level key is used for shared model that one particular preference only listens to one shared model path, this solution would lead to one pref -> several shared model paths

[13:39:16 CDT(-0500)] <Bosmon> cindyli - the model path is derived only from the schema block for the preference

[13:39:22 CDT(-0500)] <Bosmon> As I mentioned before, in all other cases, the key is ignored

[13:39:30 CDT(-0500)] <Bosmon> So one preference will always be associated with exactly one model path

[13:39:35 CDT(-0500)] <cindyli> ah i see

[13:40:34 CDT(-0500)] <cindyli> seems our current aux builder is retrieving the model path from the wrong place. will fix that

[13:41:08 CDT(-0500)] <colinclark> So, this is an interesting issue

[13:41:31 CDT(-0500)] <colinclark> I think I generally support Bosmon's idea that we should avoid arrays as much as possible in favour of "user-findable" keys

[13:42:02 CDT(-0500)] <colinclark> The problem with an array is that someone who comes along later and tries to override some configuration will need to know the exact location in the array of the thing they want to override

[13:42:14 CDT(-0500)] <colinclark> whereas arbitrary keys are at least vaguely "findable"

[13:42:37 CDT(-0500)] <colinclark> The downside, which I mentioned while we were writing the latest UIO prototutorial is that it's kind of "weird"

[13:43:06 CDT(-0500)] <colinclark> in the sense that one typically imagines their job as filling out a JSON object with specified keys to instruct the framework on what to do

[13:43:28 CDT(-0500)] <colinclark> like, if you want some subcomponents, you specify a component spec at the "components" key

[13:43:47 CDT(-0500)] <colinclark> whereas in this case, the developer is creating freely-named keys that don't correspond to anything--they're just names

[13:44:02 CDT(-0500)] <colinclark> but I think that's something we can easily explain and doesn't represent a barrier to use by any means

[13:53:55 CDT(-0500)] <Bosmon> Thanks, colinclark

[13:54:56 CDT(-0500)] <Bosmon> cindyli - whilst you are taking care of this, do you think you could also look at converting the panel code to using protoTrees, as per http://issues.fluidproject.org/browse/FLUID-4986 ?

[13:55:00 CDT(-0500)] <Bosmon> Cheers!

[13:55:30 CDT(-0500)] <colinclark> cindyli: Converting to prototrees, if it's not too much work, would be hugely helpful also as a source of example code

[13:55:58 CDT(-0500)] <colinclark> Bosmon and I are hoping to create a new prototutorial to explain how developers can write prototrees to create Adjusters for the new Cloud4all editors

[13:56:16 CDT(-0500)] <colinclark> how apt, prototutorials about prototrees

[13:56:25 CDT(-0500)] <colinclark> but some example code will go a long way to helping now

[13:58:37 CDT(-0500)] <cindyli> Bosmon and colinclark, was on a call with yz

[13:59:05 CDT(-0500)] <cindyli> yzen, we are going to split that he will take on protoTree and i continue with aux builder

[14:00:58 CDT(-0500)] <Bosmon> Built of the purest *PROTOMATTER* (smile)

[14:01:04 CDT(-0500)] <Bosmon> Thanks, cindyli

[14:01:50 CDT(-0500)] <cindyli> nah problem.

[14:01:58 CDT(-0500)] <cindyli> thank YOU

[14:38:45 CDT(-0500)] <jhung> heidiv: I've pushed up my changes for DT's contrast theming to my repo. GPII-134.

[14:39:49 CDT(-0500)] <heidiv> jhung aha! can you also close GPII-144 , duplicate

[14:42:06 CDT(-0500)] <jhung> willdo heidiv

[14:45:47 CDT(-0500)] <jhung> heidiv: I'm looking at GPII-143, and perhaps it's been fixed with GPII-134.

[14:46:24 CDT(-0500)] <heidiv> jhung oh yeah?

[14:47:37 CDT(-0500)] <jhung> yeah. The colour scheme changed a bit, so it looks a bit better than before heidiv.

[14:47:51 CDT(-0500)] <heidiv> jhung might still need a upper border or somethin?

[14:48:26 CDT(-0500)] <jhung> The background is now black for the DT in contrast mode. But the hide/show panel needs something.

[14:51:53 CDT(-0500)] <mbrenn_iskme> hi colinclark: I have a question about the daily build of the Discovery Tool demo

[14:53:24 CDT(-0500)] <colinclark> sure, mbrenn_iskme

[14:54:42 CDT(-0500)] <mbrenn_iskme> at the link I have here: http://build.fluidproject.org/prefsEditors/demos/discoveryTool/

[14:55:06 CDT(-0500)] <mbrenn_iskme> I notice that the speak enactor doesn't seem to function

[14:55:21 CDT(-0500)] <mbrenn_iskme> was wondering if this is because it is still under development?

[14:55:29 CDT(-0500)] <colinclark> Which browser are you using, mbrenn_iskme?

[14:57:02 CDT(-0500)] <jhung> heidiv: I'm going to work on converting those demo images into SVG so we can get started on creating those text labels / descriptions.

[14:57:20 CDT(-0500)] <mbrenn_iskme> have tried in both Chrome and Firefox, I can't tell what the issue is in Chrome, looks like FF doesn't support the audio resource type the feature uses

[14:57:23 CDT(-0500)] <heidiv> jhung sounds good

[14:58:19 CDT(-0500)] <colinclark> mbrenn_iskme: So there is currently a bug in Firefox related to the TTS enactor

[14:58:30 CDT(-0500)] <colinclark> yzen is currently working on it, he can probably point you to the JIRA ticket for it

[14:58:53 CDT(-0500)] <mbrenn_iskme> great

[14:59:13 CDT(-0500)] <colinclark> Firefox does indeed support the audio format and element that we are using, but there is a bug related to the events that fire when an audio element is ready to play

[14:59:46 CDT(-0500)] <colinclark> I believe that the TTS enactor hasn't yet been hooked up to the Discovery Tool, which is why you're not hearing any sound in Chrome

[15:00:14 CDT(-0500)] <colinclark> As far as I know, yzen is also working on that effort as well

[15:00:27 CDT(-0500)] <colinclark> mbrenn_iskme: Why do you ask?

[15:00:44 CDT(-0500)] <yzen> mbrenn_iskme, colinclark yes this is the branch that i m in right now https://github.com/yzen/prefsEditors/tree/GPII-125 , media related events seem to just die in ff

[15:02:09 CDT(-0500)] <mbrenn_iskme> colinclark: we are interested in having our developers fork the preference editor code and work on integrating parts of it in to OER Commons

[15:02:44 CDT(-0500)] <colinclark> mbrenn_iskme: It would be very helpful if your developers work with yzen to do that

[15:02:52 CDT(-0500)] <colinclark> so that they are fully up to speed on what we're doing and where we're going

[15:04:56 CDT(-0500)] <mbrenn_iskme> yes, I want to make sure we are working with the most up to date versions of your code, and make sure we are collaborating fully

[15:06:04 CDT(-0500)] <colinclark> cool

[15:08:04 CDT(-0500)] <mbrenn_iskme> yzen: would it be best to set up a time to chat to discuss logistics?

[15:09:19 CDT(-0500)] <yzen> mbrenn_iskme: definitely, if you have a doodle poll we can find the time that works best for everyone, colinclark ?

[15:11:33 CDT(-0500)] <colinclark> sure

[15:13:04 CDT(-0500)] <mbrenn_iskme> yzen: great I will create a doodle, will an meeting between you, myself, colinclark, and Andrey (our developer) be sufficient?

[15:13:19 CDT(-0500)] <yzen> i believe so

[15:13:48 CDT(-0500)] <colinclark> sure