fluid-work IRC Logs-2013-12-19

Owned by Fluid IRC Log Bot
Last updated: Dec 19, 2013
11 min read

[07:23:25 CST(-0600)] <jhung> Good morning Justin_o - I pushed up changes for FLOE-128 last night. Please take a look. (smile)

[07:29:04 CST(-0600)] <Justin_o> jhung: thanks.. i'll pull those down

[07:30:04 CST(-0600)] <jhung> Justin_o, on the positive side, I think I understand Bootstrap's grid system better, oh vey!

[07:31:08 CST(-0600)] <Justin_o> jhung: that's good (smile)

[07:31:30 CST(-0600)] <Justin_o> you might need to document that, or teach it to us someday (smile)

[07:33:25 CST(-0600)] <Justin_o> jhung: so the button doesn't stick out anymore, but it's still cut off..

[07:33:32 CST(-0600)] <Justin_o> did you want to screen share and I can show you?

[07:34:24 CST(-0600)] <jhung> sure Justin_o

[08:25:33 CST(-0600)] <cindyli> michelled: the generalization of caption inputs components doesn't seem can be quickly done. I'm going to add a todo comment in the code for it to be improved in the future.

[08:26:31 CST(-0600)] <michelled> thx cindyli

[08:28:17 CST(-0600)] <cindyli> michelled: the pull request for the captions panel is back ready - https://github.com/fluid-project/metadata/pull/7

[08:28:59 CST(-0600)] <michelled> thx cindyli

[08:29:08 CST(-0600)] <cindyli> np

[08:37:59 CST(-0600)] <jhung> Justin_o: I've updated FLOE-128. Hopefully this will be it. (smile)

[08:58:37 CST(-0600)] <Justin_o> jhung: cool.. thanks.. i'll take a look at it again

[09:05:54 CST(-0600)] <jhung> danaayotte_: let me know when you want to chat about FLOE-130. We'll probably do it over skype and do some screen sharing.

[09:06:33 CST(-0600)] <danaayotte_> will do jhung, thanks. I'm in a meeting until about 11. Will ping you after that.

[09:07:27 CST(-0600)] <jhung> np danaayotte_

[09:20:05 CST(-0600)] <Justin_o> jhung: the "OK" button wraps to a new line, is that what you wanted?

[09:20:56 CST(-0600)] <jhung> Justin_o: you think it's okay? This way you can see more of the text area.

[09:21:39 CST(-0600)] <Justin_o> jhung: it's better than the button cutting off (smile) I think i'd prefer it beside, but i'm fine if you and danaayotte_ are happy with it

[09:22:07 CST(-0600)] <jhung> Although having the OK button on the same line looks better Justin_o

[09:22:29 CST(-0600)] <jhung> Let me do a quick modification and see how it looks...

[09:22:35 CST(-0600)] <Justin_o> okay

[09:28:16 CST(-0600)] <jhung> Justin_o: I pushed up a change. It looks better with the button on the same line.

[09:28:27 CST(-0600)] <Justin_o> jhung: cool, thanks

[09:30:57 CST(-0600)] <Justin_o> jhung: looks better.. if you have time for nitpicking.. if you could make the padding to the right of the "OK" button match that of the padding to the left of the editor controls

[09:31:12 CST(-0600)] <Justin_o> jhung: that might help get some more room for the url bar

[09:31:38 CST(-0600)] <Justin_o> although now that i look at it, that may already be true for the mobile size anyways

[09:33:33 CST(-0600)] <jhung> Justin_o: So that's okay?

[09:34:07 CST(-0600)] <Justin_o> jhung: i think so.. i can show danaayotte_ if you like

[09:34:51 CST(-0600)] <danaayotte_> sure Justin_o

[09:35:20 CST(-0600)] <Justin_o> danaayotte_: whenever works for you

[09:45:07 CST(-0600)] <amilchev> hi, Justin_o

[09:45:51 CST(-0600)] <amilchev> Justin_o: sorry for forgetting to remove some old (and not needed) code, it's been a rush these days

[09:46:43 CST(-0600)] <amilchev> Justin_o: about the comment you referenced to cindy - the one with styling the radio buttons

[09:47:36 CST(-0600)] <amilchev> Justin_o: cindy had prepared a solution here https://github.com/cindyli/prefsEditors/tree/alex-gpii-271, more specifically https://github.com/cindyli/prefsEditors/blob/alex-gpii-271/src/shared/adjusters/js/Panels.js#L280

[09:48:40 CST(-0600)] <amilchev> Justin_o: but after saving, the styling breaks as you can see in her code

[09:52:53 CST(-0600)] <Justin_o> amilchev: no worries, totally understand the rush.. as for this last part, can you file a new jira for this too then.. if things are working now, we'll get to this post pilot.. maybe add a the jira number to the comment you have in the code already

[09:54:32 CST(-0600)] <amilchev> Justin_o: ok, I can do that - should I fire the other two jiras you suggested?

[09:56:09 CST(-0600)] <amilchev> Justin_o: the other jira* (singular) - about moving the "enum" strings into the messageBundle

[10:04:46 CST(-0600)] <Justin_o> amilchev: yes.. you can create a single jira for that and reference the two enums..

[10:04:50 CST(-0600)] <Justin_o> amilchev: thanks

[10:05:27 CST(-0600)] <Justin_o> amilchev: could you please let me know when you have pushed up all your changes?

[10:08:16 CST(-0600)] <amilchev> Justin_o: just did, thanks

[10:09:01 CST(-0600)] <Justin_o> amilchev: thanks

[10:12:28 CST(-0600)] <amilchev> Justin_o: to whom should I assign the jiras for the enums and for the styling bug?

[10:12:50 CST(-0600)] <amilchev> not exactly a styling bug but you know what i mean

[10:15:07 CST(-0600)] <Justin_o> amilchev: hmm.. i guess that's a kasparnet question

[10:15:24 CST(-0600)] <Justin_o> amilchev: if you can leave them unassigned, that might be the way to go for now

[10:19:27 CST(-0600)] <amilchev> Justin_o: ok, I'll just try to explain best what exactly is needed

[10:23:14 CST(-0600)] <amilchev> Justin_o: I'll let you know when they're ready, I'll be leaving now, bye!

[10:50:14 CST(-0600)] <Justin_o> yzen: i'm passing off the gpii pull requests to you.. https://github.com/GPII/prefsEditors/pulls I believe amilchev has addressed or filed jiras for the last comments I had. As for chris, I've left one more, which will likely result in a file being removed. Not sure if he will get to that today or tomorrow.

[10:50:24 CST(-0600)] <yzen> Cool

[11:01:03 CST(-0600)] <Justin_o> yzen: is there an easy way to set the value of something declaratively.. for example if i wanted to set a member value after an event has fired

[11:28:26 CST(-0600)] <Justin_o> cindyli: pushed up some more changes for FLOE-125.. not quite there yet, but getting closer

[11:28:42 CST(-0600)] <cindyli> cool. thanks, Justin_o

[11:38:50 CST(-0600)] <colinclark> hey yzen, do you have time for a few dumb questions from me?

[11:39:19 CST(-0600)] <yzen> colinclark: fire away

[11:41:23 CST(-0600)] <colinclark> sorry, my parents are singing

[11:41:24 CST(-0600)] <colinclark> one sec

[11:51:30 CST(-0600)] <colinclark> ok, sorry

[11:52:05 CST(-0600)] <colinclark> yzen: Is http://issues.gpii.net/browse/GPII-269 part of your current work on GPII-75?

[11:52:11 CST(-0600)] <yzen> yes

[11:52:17 CST(-0600)] <colinclark> That's great

[11:52:37 CST(-0600)] <colinclark> I'm reading Boyan's email and wondering if there's another side to all of this

[11:53:17 CST(-0600)] <colinclark> Some of the details are a bit fuzzy

[11:53:28 CST(-0600)] <colinclark> But I'm assuming we're going to need to launch the PCP for the user, perhaps automatically

[11:53:40 CST(-0600)] <colinclark> Or will that happen via a desktop shortcut

[11:53:47 CST(-0600)] <colinclark> kasparnet might know this more clearly than me

[11:54:09 CST(-0600)] <yzen> colinclark: i think kasparnet was thinking the latter

[11:54:30 CST(-0600)] <colinclark> So both the PCP and the PMT will be launched via different desktop shortcuts?

[11:55:14 CST(-0600)] <yzen> i think so

[11:55:41 CST(-0600)] <yzen> i think the main issue re GPII-290 is the external user listener , e.g. RFID etc

[11:56:24 CST(-0600)] <kasparnet> colinclark, yzen: I believe the plan is to launch the PMT using a desktop shortcut, and then launch the PCP from the PMT

[11:56:58 CST(-0600)] <kasparnet> at least that's the decision as I remember it from a PCP/PMT meeting a while back

[11:57:31 CST(-0600)] <kasparnet> jessm: do you remember this ^?

[11:59:41 CST(-0600)] <jessm> kasparnet: i think that's right

[12:02:11 CST(-0600)] <colinclark> kasparnet: Okay, just so I'm clear...

[12:02:20 CST(-0600)] <colinclark> There will be one desktop shortcut

[12:02:30 CST(-0600)] <colinclark> which will launch the PCP

[12:05:24 CST(-0600)] <colinclark> and from the PCP, the user can click the "All Preferences" button to get to the PMT

[12:05:28 CST(-0600)] <colinclark> is that correct, kasparnet?

[12:06:23 CST(-0600)] <colinclark> yzen: While we're waiting for kasparnet, I have another question...

[12:06:25 CST(-0600)] <colinclark> How will the PCP get the user's token and preference set?

[12:06:37 CST(-0600)] <colinclark> When it starts up, will it make a request via web sockets to the local Flow Manager?

[12:06:44 CST(-0600)] <colinclark> and if so, is that feature also part of GPII-75?

[12:06:49 CST(-0600)] <yzen> not really

[12:07:16 CST(-0600)] <yzen> so personally it's not 100% clear to me how PCP will have the token, that's what 290 is about imo

[12:07:35 CST(-0600)] <yzen> PCP talks to the flow manager over web sockets only to make updates

[12:08:35 CST(-0600)] <colinclark> So Boyan's email was suggesting that we don't need GPII-290

[12:08:47 CST(-0600)] <colinclark> but you're thinking-as I am-that in fact it's critical for end-to-end integration?

[12:12:58 CST(-0600)] <colinclark> It turns out I am somewhat incorrect

[12:13:04 CST(-0600)] <colinclark> and vjoanna will set me straight (smile)

[12:20:20 CST(-0600)] <vjoanna> kasparnet, colinclark: I think the design intention is that the user opens the PMT from a desktop shortcut. Here they could create an account. On closing the PMT, the PCP launches and persists. The PCP closes if the user opens the PMT or logs out. The PCP reopens if the user closes the PMT or logs back in.

[12:20:44 CST(-0600)] <vjoanna> jessm, danaayotte: does this sound right ^

[12:21:46 CST(-0600)] <kasparnet> colinclark: sorry, dinner was ready so jumped afk to eat

[12:21:49 CST(-0600)] <kasparnet> yes, that's correct

[12:23:19 CST(-0600)] <kasparnet> colinclark: ok - made it down to vjoanna's comment, and that might be more correct (smile)

[12:25:25 CST(-0600)] <jessm> vjoanna: +1 that's what I've understood

[12:25:35 CST(-0600)] <jessm> kasparnet: i think folks have gone to get grub on this end too

[12:26:04 CST(-0600)] <kasparnet> jessm: hehe cool

[12:26:06 CST(-0600)] <kasparnet> thanks

[13:20:01 CST(-0600)] <colinclark> Ok, so there's a bit more for us to think through

[13:20:16 CST(-0600)] <colinclark> So in the case of a first-time launch of the PMT, we don't need to worry about the user's token

[13:20:24 CST(-0600)] <colinclark> but if they subsequently launch the PMT, we do need to know it

[13:20:39 CST(-0600)] <colinclark> similarly, we need some means to tell the PCP what the user's token is

[13:21:16 CST(-0600)] <colinclark> if we're autolaunching the PCP, we can use our current Launch Handler to do this and to pass the user's token as a query parameter in the URL

[13:21:39 CST(-0600)] <colinclark> but for the PMT, we need some means whereby it can request the user's token

[13:21:46 CST(-0600)] <colinclark> kasparnet: Is this making sense to you? ^

[13:25:33 CST(-0600)] <kasparnet> yeah, it does

[13:26:38 CST(-0600)] <kasparnet> colinclark: I seem to remember us talking about some completely different use case where exposing the token would be helpful... though I forget what it was exactly

[13:30:38 CST(-0600)] <colinclark> yzen: So what would it mean from a development perspective to add support for querying the user token via web sockets?

[13:31:01 CST(-0600)] <colinclark> In other words, what would someone actually have to do?

[13:32:23 CST(-0600)] <yzen> well on the server that would mean having the sockets io handler that would resolve such requests, on the client it would mean connecting to the specific url with web sockets and sending some sort of message ,

[13:36:50 CST(-0600)] <kasparnet> yzen: is GPII-270 dependent on GPII-75 (pull request wise)?

[13:37:04 CST(-0600)] <yzen> yes

[13:37:07 CST(-0600)] <yzen> no tests

[13:37:12 CST(-0600)] <kasparnet> yzen: also without the tests?

[13:37:26 CST(-0600)] <yzen> yes tests will be added after 75

[13:37:51 CST(-0600)] <kasparnet> yzen: ok, but if nick wants to try it out with the RB MM he wouldn't need to merge in GPII-75

[13:37:53 CST(-0600)] <kasparnet> ?*

[13:38:19 CST(-0600)] <yzen> np

[13:38:20 CST(-0600)] <yzen> np

[13:38:23 CST(-0600)] <yzen> urgh

[13:38:25 CST(-0600)] <yzen> no

[13:38:56 CST(-0600)] <kasparnet> ok, cool

[13:39:07 CST(-0600)] <kasparnet> haha

[13:41:27 CST(-0600)] <kasparnet> yzen: ok so I'm getting lost in all the negatives here.. let me try again

[13:41:37 CST(-0600)] <yzen> so

[13:41:47 CST(-0600)] <yzen> 270 does not depend on 75

[13:42:01 CST(-0600)] <kasparnet> ok cool!

[13:42:02 CST(-0600)] <yzen> but it can't be merged until the 75 is in and i can write tests for 270

[13:42:59 CST(-0600)] <kasparnet> thanks yzen (smile)

[13:43:04 CST(-0600)] <yzen> np )

[13:54:51 CST(-0600)] <jhung> Justin_o: for syntax highlighting for the markup viewer, are we using lib/highlight/styles/github.css

[13:54:52 CST(-0600)] <jhung> ?

[13:55:58 CST(-0600)] <jhung> Justin_o: I'm looking at pull request 12 and noticed it was removed - I suspect this may be needed? https://github.com/fluid-project/metadata/pull/12/files

[14:03:30 CST(-0600)] <colinclark> kasparnet: So what do you think we should do about the issue of passing the user token to the PCP/PMT?

[14:10:02 CST(-0600)] <jessm> is Bosmon2 awake?

[14:15:03 CST(-0600)] <jessm> cindyli: anastasiac: i'm looking to get a comprehensive list of places the Vid. Player is – so far i have IDI, WordPress, ATutor and SNOW. does either of you know of other places where it's been integrated?

[14:15:10 CST(-0600)] <jessm> and cindyli did it ship in ATutor?

[14:15:46 CST(-0600)] <cindyli> as far as i know, not in ATutor yet, jessm

[14:16:44 CST(-0600)] <anastasiac> jessm, afaik, that list looks pretty good. I did have a few questions a week or two ago from an Astea developer about the video player; not sure where they're integrating it

[14:19:47 CST(-0600)] <jessm> cindyli: anastasiac: thanks muchly

[14:21:03 CST(-0600)] <jessm> anastasiac: do we know where david fourney was looking to integrate the vid. player? from the list thread?

[14:24:24 CST(-0600)] <colinclark> jessm: he is now, yes. Bosmon2 ^

[14:25:07 CST(-0600)] <jessm> Bosmon2: I'm trying to track down links to work we've done for a report to our funder on Floe. I wondered if you knew of any url for the PhET collaboration?

[15:09:58 CST(-0600)] <Justin_o> Bosmon2: are you there?

[15:29:26 CST(-0600)] <Justin_o> Bosmon2: if you are around tomorrow morning Easter Time, I could use some help with debugging.. If you want to look it at another time, you can look at https://github.com/jobara/metadata/tree/FLOE-125.

[15:29:39 CST(-0600)] <Bosmon> Hi jessm

[15:29:48 CST(-0600)] <Bosmon> Easter Time? : P

[15:29:59 CST(-0600)] <Bosmon> What kind of problem are you having, Justin_o?

[15:30:07 CST(-0600)] <Justin_o> Bosmon2: the steps are 1) add a url for the video and press okay 2) change some of the values in the metadata

[15:30:17 CST(-0600)] <Justin_o> 3) hit restart and add a new video url and press okay

[15:30:25 CST(-0600)] <Justin_o> 4) notice that the old values are still there

[15:30:51 CST(-0600)] <Justin_o> what's weird is that we cleared the parent model that the sub components are attached to, reset the markup, destroyed the sub components and recreated them

[15:31:12 CST(-0600)] <Justin_o> Bosmon: Easter time sounds happier (smile) or hoppier maybe

[15:33:30 CST(-0600)] <Justin_o> Bosmon: i'm going to be heading out for the day soon.. do you have any thoughts and what time do you think you'll be on tomorrow?

[15:34:31 CST(-0600)] <Bosmon> Justin_o - my feeling is that it may be related to the bug that I am constantly bugging you about (smile)

[15:34:45 CST(-0600)] <Justin_o> Bosmon: oh no ;(

[15:34:45 CST(-0600)] <Bosmon> The one detected by FLUID-4890

[15:34:58 CST(-0600)] <Justin_o> have you happened to figure out what's causing that?

[15:35:13 CST(-0600)] <Bosmon> It is a kind of effect that is extremely likely, given that it seems that the whole preferences editing framework seems to be regularly making use of destroyed components

[15:35:31 CST(-0600)] <Bosmon> Justin_o - I haven't, other than it being some kind of implementation error in the preferences framework : P

[15:36:01 CST(-0600)] <Justin_o> Bosmon: (smile) okay.. the metadata demo doesn't use the prefs framework, save for the model relay

[15:36:06 CST(-0600)] <Bosmon> For example, I suspect it is very likely that the ModelRelay or some other kind of model binding is continuing to bind onto your destroyed component

[15:36:18 CST(-0600)] <Justin_o> Bosmon: well there we go

[15:36:32 CST(-0600)] <Justin_o> Bosmon: is your model relay framework ready to go?

[15:36:40 CST(-0600)] <Bosmon> Justin_o - yes

[15:36:52 CST(-0600)] <Justin_o> are there any examples of use that we can follow?

[15:36:58 CST(-0600)] <Bosmon> But it does need to go through a few hurdles yet

[15:37:03 CST(-0600)] <Bosmon> For a start it needs to be reviewed

[15:37:08 CST(-0600)] <Justin_o> (smile)

[15:37:20 CST(-0600)] <Bosmon> And - I suspect it will cause major upheaval to move all of prefs editing over to it

[15:37:23 CST(-0600)] <Justin_o> well we'd need to have it by tomorrow morning unfortunately

[15:37:36 CST(-0600)] <Bosmon> And - it won't actually remedy the core failure which is being detected by FLUID-4890

[15:37:41 CST(-0600)] <Bosmon> Since your component lifecycle will stay the same

[15:37:42 CST(-0600)] <Bosmon> Yes

[15:37:50 CST(-0600)] <Bosmon> It will not be ready by tomorrow morning (smile)

[15:38:30 CST(-0600)] <Justin_o> Bosmon: so the metadata work is pretty exclusive of the prefs framework.. except for the model relay (sad) i suppose we could try falling back to some other form of model sharing and see if that works

[15:38:43 CST(-0600)] <Justin_o> any other recommendations on that front?

[15:38:56 CST(-0600)] <Bosmon> Justin_o - there is a field "applierid" which is attached to every ChangeApplier

[15:39:05 CST(-0600)] <Bosmon> Which may be useful for you debugging which applier you are actually connected to

[15:39:33 CST(-0600)] <Justin_o> right.. i was trying to remember what i was debugging with before for the panels work..

[15:39:37 CST(-0600)] <Bosmon> This may help you discover where the old values are coming from, or why the old listeners have not been unbound

[15:39:37 CST(-0600)] <Justin_o> okay we can try to look at that

[15:39:56 CST(-0600)] <Justin_o> Bosmon: that makes sense

[15:40:24 CST(-0600)] <Bosmon> The "old ModelRelay" does have a branch which is meant to unbind it from a component on destroy

[15:40:36 CST(-0600)] <Bosmon> So it's worth stepping through that to see if for some reason it is ineffective

[15:41:05 CST(-0600)] <Justin_o> okay.. will do.. thanks for the help

[15:41:32 CST(-0600)] <Bosmon> In particular you can see this implementation - "fluid.prefs.modelRelay.removeListeners"

[15:43:16 CST(-0600)] <Justin_o> Bosmon: thanks