fluid-work IRC Logs-2011-11-08

[08:11:50 CST(-0600)] <jessm> http://chronicle.com/blogs/profhacker/accessibility-in-a-digital-age-1-5/37141?sid=wc&amp;utm_source=wc&amp;utm_medium=en

[08:24:05 CST(-0600)] <jessm> fluid-everyone: some links worth checking out ^

[08:25:45 CST(-0600)] <Justin_o> jessm: thanks

[09:00:52 CST(-0600)] <jessm> http://yaccessibilityblog.com/wp/accessible-apps-introductory.html

[09:00:58 CST(-0600)] <jessm> disability awareness apps ^

[09:15:45 CST(-0600)] <jhung> justin_o: I was going to start looking into the custom string using demands.

[09:16:17 CST(-0600)] <Justin_o> jhung: cool, did you need a hand with that?

[09:16:43 CST(-0600)] <jhung> justin_o: I tried putting in strings option block into the existing demands block with queueSettings and it doesn't seem to work.

[09:16:50 CST(-0600)] <jhung> Does it need it own demand block?

[09:17:44 CST(-0600)] <Justin_o> jhung: which one did you put it in and where?

[09:18:03 CST(-0600)] <Justin_o> can you send a pastebin of your demands block

[09:18:22 CST(-0600)] <jhung> k

[09:19:14 CST(-0600)] <jhung> justin_o http://pastebin.com/E6WDct3K

[09:21:32 CST(-0600)] <jhung> yura: AJ +1.

[09:25:22 CST(-0600)] <Justin_o> jhung: first question, are you running this through the decapod server or directly from the file system?

[09:26:36 CST(-0600)] <jhung> from the file system justin_o

[09:26:38 CST(-0600)] <anastasiac> michelled, have you started looking into video players yet? any you've already started on that I should skip?

[09:26:56 CST(-0600)] <Justin_o> jhung: okay, you should put this in the other demands block then

[09:27:01 CST(-0600)] <Justin_o> this one is for running from the server

[09:27:12 CST(-0600)] <jhung> ah okay.

[09:27:40 CST(-0600)] <jhung> I see the "fileSystem" context now. I wasn't sure what that was for justin_o.

[09:27:49 CST(-0600)] <jhung> So I will need to duplicate this in both blocks?

[09:28:00 CST(-0600)] <Justin_o> jhung: yes, you will

[09:28:15 CST(-0600)] <jhung> great, thanks justin_o. I'll give this a whirl now...

[09:28:21 CST(-0600)] <Justin_o> alternatively, you could just put it in the Import.js file

[09:28:48 CST(-0600)] <Justin_o> jhung: around line 34

[09:28:57 CST(-0600)] <jhung> true. Then it only needs one copy of the strings.

[09:29:11 CST(-0600)] <Justin_o> jhung: yes

[09:29:13 CST(-0600)] <Justin_o> that's right

[09:29:22 CST(-0600)] <jhung> Makes it a little more intuitive for someone else to come in and edit too, I think.

[09:29:47 CST(-0600)] <michelled> anastasiac: http://videojs.com/

[09:30:06 CST(-0600)] <anastasiac> michelled, I was just looking at that ok, I'll move on to the next one

[09:30:24 CST(-0600)] <michelled> anastasiac: did you send our questions to the list yet?

[09:30:56 CST(-0600)] <anastasiac> michelled, no, I sent them to you and Bosmon for confirmation. Did you not get the email?

[09:31:06 CST(-0600)] <michelled> no, I don

[09:31:20 CST(-0600)] <michelled> don't think so - let me check if if got put into the junk folder

[09:31:20 CST(-0600)] <anastasiac> yesterday at 3:46?

[09:32:23 CST(-0600)] <michelled> anastasiac: ok, I found it

[09:32:55 CST(-0600)] <anastasiac> michelled, was it in your junk folder?

[09:33:19 CST(-0600)] <michelled> no, but it was marked as read even though I hadn't seen it

[09:34:07 CST(-0600)] <anastasiac> michelled, I'm looking into Kaltura

[09:34:28 CST(-0600)] <michelled> ok

[09:40:17 CST(-0600)] <michelled> anastasiac: the last question isn't clear to me

[09:40:28 CST(-0600)] <michelled> other then that they look good

[09:40:39 CST(-0600)] <michelled> I think we should send them to Tona so she can start to think about them

[09:40:43 CST(-0600)] <michelled> there are a lot there

[09:41:50 CST(-0600)] <anastasiac> michelled, re the last question: You can't tell what it's about at all, or you just think it's badly worded?

[09:42:29 CST(-0600)] <michelled> is it a question for Tona? or a comment that we need to look into what's possible technically?

[09:43:03 CST(-0600)] <anastasiac> michelled, I'm not sure - I think Bosmon wanted us to add the question to the list so we don't forget about it, but I think it's a technical question

[09:45:17 CST(-0600)] <anastasiac> michelled, I'll email Tona and cc the list. I'll point everyone to the questions as well as the feature list. Sound good?

[09:45:39 CST(-0600)] <michelled> anastasiac: I rephrased it - can you see if it makes sense now?

[09:45:48 CST(-0600)] <anastasiac> yes, I just saw that - looks great

[09:45:52 CST(-0600)] <michelled> anastasiac: yep, sounds good

[10:09:39 CST(-0600)] <jhung> justin_o: did we decide to make all our decapod-0.5a changes directly in the master files, or did we decide to make specific decapod-0.5a files and add those?

[10:09:46 CST(-0600)] * jhung memory is fuzzy

[10:11:02 CST(-0600)] <jhung> btw justin_o: I think we may want to include Type 3 in the export too. It's working fairly well.

[10:11:50 CST(-0600)] <jhung> It's language independent because it does a vector trace of the content on the pages. So it may end up working well for some materials.

[10:17:22 CST(-0600)] <Justin_o> jhung: i think we were going to try to add new files if possible/appropriate

[10:18:09 CST(-0600)] <Justin_o> jhung: can you send me the info on command line arguments to get genpdf to generate the various pdf types

[10:18:24 CST(-0600)] <jhung> sure

[10:19:00 CST(-0600)] <Justin_o> jhung, thanks

[10:19:33 CST(-0600)] <jhung> justin_o: decapod-genpdf.py -d bookDir -t 1 -p outPDF.pdf image1.png image2.png

[10:19:49 CST(-0600)] <jhung> change the arguments to match what you have.

[10:20:05 CST(-0600)] <jhung> -t 1 for type 1, -t 2 for type 2, etc.

[10:20:13 CST(-0600)] <Justin_o> jhung: ah okay, thanks

[10:23:48 CST(-0600)] <anastasiac> michelled: http://html5video.org/wiki/HTML5_Player_Comparison

[10:24:30 CST(-0600)] <jhung> justin_o, jessm - I've uploaded output examples from latest genpdf here. http://wiki.fluidproject.org/display/fluid/Decapod+Weekly+Meeting+Notes

[10:27:09 CST(-0600)] <Justin_o> jhung: thanks, type 3 looks a bit like a ransom note

[10:41:43 CST(-0600)] <jhung> justin_o: yeah, it certainly looks like that, but it's pretty cool. The size difference is pretty amazing. From 16MB to 400KB.

[10:42:19 CST(-0600)] <Justin_o> that is pretty dramatic

[10:43:11 CST(-0600)] <jhung> so with these custom strings for 0.5a going into the Import.js file, should I create a separate Import-05a.js file or put it in and create Jiras for the strings to be changed later?

[10:43:15 CST(-0600)] <jhung> ^justin_o

[10:43:48 CST(-0600)] <Justin_o> jhung: interesting.. so these strings are exclusive to 0.5a?

[10:44:11 CST(-0600)] <Justin_o> if so then i think you should instead make a new demands file

[10:44:21 CST(-0600)] <Justin_o> and put them into demands blocks after all

[10:45:43 CST(-0600)] <jhung> but is that the strategy we want for the long term? Maintaining two string blocks for demo and server instances seems a bit cumbersome.

[10:46:36 CST(-0600)] <jhung> btw, I just checked out the type 3 PDF on my iphone and it looks pretty good. It's legible and loaded incredibly fast. I think that's what you want for that use case.

[10:46:50 CST(-0600)] <Justin_o> jhung: that's great

[10:47:05 CST(-0600)] <Justin_o> jhung: as for the long term work flow, no that's not what we want

[10:47:36 CST(-0600)] <Justin_o> we would want the default strings to probably be in the components options block directly

[10:47:51 CST(-0600)] <Justin_o> we can then use some other means, possible demands blocks to adjust the strings

[10:49:03 CST(-0600)] <Justin_o> the local preview isn't for production, it's really only for development. Meaning it's not as necessary to localize those as it is for the production strings

[10:49:39 CST(-0600)] <jhung> justin_o, true. But someone coming in from the outside may not know the difference (like how I didn't know there difference initially).

[10:51:01 CST(-0600)] <Justin_o> jhung: that's true, i imagine it will need to be part of the documentation.. in the end though i think we'll want some other means of allowing our users to localize the application

[10:51:16 CST(-0600)] <Justin_o> probably through some general config file or something

[10:51:30 CST(-0600)] <Justin_o> so they don't have to run around creating demands or changing options for every component

[10:51:33 CST(-0600)] <Justin_o> jhung: ^

[10:51:56 CST(-0600)] <jhung> justin_o, I agree. A more central location since it'll be a pain to edit multiple files. Easier if it was in a single file.

[10:52:23 CST(-0600)] <Justin_o> jhung: totally… now we just need to know how to do that

[10:52:34 CST(-0600)] <Justin_o> i guess we need to figure out where it should live and etc.

[10:52:38 CST(-0600)] <jhung> okay, in that case then I'll do separate string blocks in the demands.js file. I'll be sure to document this in code and on Jira.

[10:52:40 CST(-0600)] <Justin_o> probably will need to be managed by the server too

[10:52:45 CST(-0600)] <jhung> justin_o yeah.

[10:52:57 CST(-0600)] <Justin_o> jhung: that's great, thanks

[12:05:04 CST(-0600)] <jhung> justin_o, a bit off topic, but still relevant to Decapod.

[12:05:18 CST(-0600)] <Justin_o> jhung: okay

[12:05:44 CST(-0600)] <jhung> michelled sent me a link to an OCR tool for iOS. Images are sent to a server and the server returns an OCR'ed document.

[12:06:02 CST(-0600)] <jhung> Does our current architecture allow us to do similar?

[12:06:12 CST(-0600)] <jhung> (current proposed architecture I mean)

[12:07:59 CST(-0600)] <Justin_o> jhung: hmm.. not exactly sure what you're asking.. do you mean "Does the UI specific portion and the genpdf portion need to be on the same machine?"

[12:09:18 CST(-0600)] <jhung> justin_o: I guess what I'm asking is the architecture flexible enough that someone with a mobile phone can send an image wirelessly to a Decapod server, and for the Decapod server to send back an OCR'ed document.

[12:09:41 CST(-0600)] <Justin_o> jhung: ah okay

[12:09:42 CST(-0600)] <Justin_o> yes

[12:10:16 CST(-0600)] <Justin_o> jhung: basically the goal is to have a RESTful architecture.. so it will all be about urls

[12:11:08 CST(-0600)] <Justin_o> the phone would have to send a POST to a specific url to upload the image, send PUT to another URL to trigger the export generation, and finally use a GET to grab the url to the exported file

[12:11:46 CST(-0600)] <Justin_o> if the decapod server is exposed to the web, you could do all of that without going through our decapod client

[12:12:04 CST(-0600)] <jhung> Excellent justin_o. So we'll work on a Decapod app for iOS for next release?

[12:12:11 CST(-0600)] <Justin_o> haha

[12:12:25 CST(-0600)] <Justin_o> okay, how much are we going to sell it for

[12:13:26 CST(-0600)] <jhung> Free. We'll just plaster annoying ads in the OCR'ed documents.

[12:13:56 CST(-0600)] * jhung being very sinister.

[12:14:14 CST(-0600)] <Justin_o> haha

[12:14:18 CST(-0600)] <Justin_o> that's truly evil

[12:15:52 CST(-0600)] <jhung> Some call it evil. I call it opportunistic.

[13:24:51 CST(-0600)] <athena> hey fluid folks - anyone around who can point me to how to set a title in a link from the renderer?

[13:27:28 CST(-0600)] * athena pokes Bosmon experimentally

[14:36:50 CST(-0600)] <Bosmon> Hi there athena - for stuff like that you should just use the "attrs" decotrator

[14:36:54 CST(-0600)] <Bosmon> decorator

[14:37:26 CST(-0600)] <athena> i think perhaps i'm just having trouble mapping the value

[14:37:31 CST(-0600)] <Bosmon> http://wiki.fluidproject.org/display/fluid/Renderer+Decorators

[14:37:33 CST(-0600)] <athena> got the attrs decorator working with static text

[14:37:37 CST(-0600)] <Bosmon> ah, I see

[14:37:57 CST(-0600)] <athena> so for the target, i have: target: "${{story}.link}"

[14:38:27 CST(-0600)] <athena> if i try something like: decorators: { attrs: { title: "${{story}.description}" } }, i don't get any title set

[14:38:31 CST(-0600)] <athena> i assume i've done something wrong

[14:39:36 CST(-0600)] <Bosmon> Well, I suspect you haven't

[14:39:42 CST(-0600)] <Bosmon> This is probably a bug in the protocomponent expander

[14:39:47 CST(-0600)] <athena> uhoh!

[14:39:49 CST(-0600)] <Bosmon> yura might know, as well

[14:39:49 CST(-0600)] <athena>

[14:40:24 CST(-0600)] <Bosmon> Well, it looks like they receive SOME expansion

[14:40:38 CST(-0600)] <athena> i know we bound interesting things to attributes in the past, but i guess that was pre proto-component days

[14:41:23 CST(-0600)] <Bosmon> If you set a breakpoint around line 205 of RendererUtilities.js, try and see what your tree gets expanded to

[14:41:42 CST(-0600)] <athena> errr our fluid file is all concatenated together

[14:41:53 CST(-0600)] <Bosmon> That hardly seems wise

[14:42:03 CST(-0600)] <athena> well it does seem more performant!

[14:42:05 CST(-0600)] <Bosmon> Anyway, the line says, "tree = that.renderer.expander(tree)"

[14:42:08 CST(-0600)] <athena> ok

[14:42:19 CST(-0600)] <Bosmon> So if you can find that line, take a look at what the tree is like before and afterwards

[14:44:25 CST(-0600)] <athena> will do

[14:44:37 CST(-0600)] <Bosmon> It looks by eye as if you should be able to expect this to work

[14:46:26 CST(-0600)] <Bosmon> If the tree looks ok, you can trace the fetching of the reference through another couple of places

[14:46:42 CST(-0600)] <Bosmon> in fluid.extractContextualPath there is a line var fetched = env[parsed.context]

[14:46:52 CST(-0600)] <Bosmon> You can set a conditional breakpoint there on context === "story"

[14:46:59 CST(-0600)] <Bosmon> And see what happens when it gets hit

[14:47:13 CST(-0600)] <Bosmon> Sorry, parsed.context === "story"

[14:47:43 CST(-0600)] <athena> looks ok - just reports what i typed

[14:48:55 CST(-0600)] <Bosmon> ?

[14:48:59 CST(-0600)] <Bosmon> What do you mean?

[14:49:10 CST(-0600)] <Bosmon> It is not getting expanded?

[14:49:40 CST(-0600)] <athena> well, i don't know what it's actually supposed to look like

[14:49:46 CST(-0600)] <athena> however, that second line reports this when paused: ReferenceError: context is not defined

[14:51:00 CST(-0600)] <Bosmon> I meant to say parsed.context === "story"

[14:52:42 CST(-0600)] <Bosmon> After the "tree = that.renderer.expander(tree)" operates, you should be seeing a fully expanded tree, with some value inside title: on each of the lines

[14:53:02 CST(-0600)] <Bosmon> rows

[14:53:37 CST(-0600)] <athena> ok, let me look

[14:54:35 CST(-0600)] <Bosmon> You might see any number of things that have gone wrong... for example, the whole decorator has gone missing.... or the title value has been fetched to "undefined"... or it has not been expanded at all

[14:54:39 CST(-0600)] <Bosmon> Who knows

[14:54:44 CST(-0600)] <Bosmon> I guess the 2nd possibility is the most likely one

[14:54:53 CST(-0600)] <athena> so which variable is this tree suposed to be in?

[14:55:04 CST(-0600)] <Bosmon> It gets put back into the same variable, "tree"

[14:55:10 CST(-0600)] <Bosmon> "tree = that.renderer.expander(tree)"

[14:55:21 CST(-0600)] <Bosmon> As this executes, the prototree is replaced with its expanded version

[14:55:23 CST(-0600)] <athena> oh, this is back at the first breakpoint?

[14:55:32 CST(-0600)] <Bosmon> Yes, that's the first place to study

[14:55:40 CST(-0600)] <athena> ah ok

[14:55:42 CST(-0600)] <Bosmon> To see if you can figure out what the expanded tree looks like

[14:56:02 CST(-0600)] <Bosmon> Once you have found the place where your decorator should appear and seen what has happened to it, we can try to debug the expansion chain to see why it happened

[14:57:09 CST(-0600)] <athena> i'm afraid i'm really not sure what i'm supposed to be looking for

[14:57:32 CST(-0600)]

[14:58:19 CST(-0600)] <athena> but it does just seem to be what i fed it

[15:18:36 CST(-0600)] <Bosmon> I see

[15:18:41 CST(-0600)] <Bosmon> So, it sounds like it isn't being expanded at all

[15:18:55 CST(-0600)] <Bosmon> I guess the other things, like link target, ARE being expanded?

[15:18:58 CST(-0600)] <Bosmon> athena^

[15:27:18 CST(-0600)]

[15:27:27 CST(-0600)] <athena> but the end result does work for everything but that title

[15:27:31 CST(-0600)] <Bosmon> This is after the expander, right?

[15:27:36 CST(-0600)] <Bosmon> Have you stepped over that line to the other side?

[15:28:17 CST(-0600)]

[15:31:53 CST(-0600)] <athena> ahh

[15:32:02 CST(-0600)] <athena> yeah perhaps i'm just stopped in the middle of it

[15:32:06 CST(-0600)] <Bosmon> ok

[15:35:03 CST(-0600)] <athena> ok!

[15:35:04 CST(-0600)] <athena> finally, sorry about that

[15:35:09 CST(-0600)] <athena> yes, it's getting title: undefined

[15:35:19 CST(-0600)] <Bosmon> ok

[15:35:25 CST(-0600)] <Bosmon> That makes at least some sense

[15:35:33 CST(-0600)] <Bosmon> But target is not undefined?

[15:36:57 CST(-0600)] <athena> correct

[15:37:07 CST(-0600)] <Bosmon> Ok

[15:37:14 CST(-0600)] <athena> so does the string ${{story}.description} sound correct?

[15:37:22 CST(-0600)] <Bosmon> Do you want to double-check that your model is ok before we go on to look at the expansion pipeline?

[15:37:25 CST(-0600)] <athena> i'd be using the same style i'm using for value, target, etc.?

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

[15:37:42 CST(-0600)] <athena> well, that same string is being bound successfully to the value of another node at hte same level

[15:37:45 CST(-0600)] <athena> so i assume the model is ok

[15:38:07 CST(-0600)] <Bosmon> !!

[15:38:13 CST(-0600)] <Bosmon> I see

[15:38:21 CST(-0600)] <athena> i have storyLink: { target: "${{story}.link}", decorators: { attrs: { title: "${{story}.description}" } } },

[15:38:22 CST(-0600)] <Bosmon> What does the node look like that it is bound to

[15:38:25 CST(-0600)] <athena> then storySummary: { value: "${{story}.description}" }

[15:38:31 CST(-0600)] <Bosmon> Ok

[15:38:33 CST(-0600)] <Bosmon> Very interesting

[15:38:55 CST(-0600)]

[15:39:04 CST(-0600)] <athena> just a simple representation of RSS feed items

[15:39:44 CST(-0600)] <Bosmon> It might be best if you can just zip up a test case for me

[15:39:59 CST(-0600)] <Bosmon> Just a thing containing some static JSON for your feed, and a little bit of code

[15:44:47 CST(-0600)] <athena> thanks

[15:44:49 CST(-0600)] <athena> ok, i'll try and do that this evening

[15:44:56 CST(-0600)] <athena> maybe see if i can duplicate it with a more contained example

[15:45:08 CST(-0600)] <athena> this poor portlet is a little pasta-y

[16:03:49 CST(-0600)] <athena> ok, think we're heading out soon

[16:03:55 CST(-0600)] <athena> thanks for the help Bosmon, will be in touch