[07:50:34 EST(-0500)] * EricDalquist (n=EricDalq@adsl-76-208-68-161.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work <colinclark> fluid.tinyMCE.inlineEdit = function (container, options) ; <Bosmo1> that.events.onBeginEdit.addListener(function() ); <Bosmo1> that.events.afterFinishEdit.addListener(function() ); <Bosmo1> return function()
[08:05:11 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[08:53:53 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:25:27 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:27:49 EST(-0500)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:28:52 EST(-0500)] * fj4000 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:29:23 EST(-0500)] <anastasiac> Justin_o, I will have a look at Bosmon's fix for FLUID-1944
[09:29:39 EST(-0500)] <Justin_o> anastasiac: thank you
[09:29:56 EST(-0500)] <Justin_o> i think there may still be that extra comma problem... i'll let you know the line number if i find it
[09:31:49 EST(-0500)] <anastasiac> line 48, Justin_o
[09:32:12 EST(-0500)] <Justin_o> oh you found it okay.. thanks
[09:32:21 EST(-0500)] <anastasiac> yes - gotta love Aptana 
[09:32:27 EST(-0500)] <anastasiac> big red X in the margin
[09:32:33 EST(-0500)] <Justin_o> oh.. that will help
[09:38:37 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[09:38:54 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:43:12 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:43:23 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621564.dsl.bell.ca) has joined #fluid-work
[09:53:23 EST(-0500)] <colinclark> Justin_o: You saw my FLUID-1768 patch last night?
[09:53:40 EST(-0500)] <Justin_o> I am updating the daily build now
[09:53:54 EST(-0500)] <Justin_o> colinclark: i believe i saw the commit
[09:54:13 EST(-0500)] <Justin_o> or the comment of fluid-work
[09:54:19 EST(-0500)] <colinclark>
[09:54:24 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:54:43 EST(-0500)] <colinclark> Cool. It hasn't been reviewed yet, I guess, but if you want to get started early with testing SWFUpload 2.2.0, feel free to give it a shot.
[09:55:04 EST(-0500)] <colinclark> I'm finding the VM juggling process a bit of a challenge, balancing different browsers alongside different Flash versions. 
[09:55:25 EST(-0500)] <Justin_o> yes.. it can be
[09:56:25 EST(-0500)] <Justin_o> also i was speaking to bosmon about fluid-1830... he's not sure the appropriate way to do the unit tests because the editors
[09:56:37 EST(-0500)] <Justin_o> namely they aren't included in our source
[09:56:43 EST(-0500)] <Justin_o> colinclark: ^
[09:56:48 EST(-0500)] <EricDalquist> CSS question, is it better to target CSS to elements via IDs or named classes?
[09:57:26 EST(-0500)] <colinclark> EricDalquist: fj4000 can probably give you a much better answer...
[09:57:29 EST(-0500)] <colinclark> but it depends.
[09:57:49 EST(-0500)] <colinclark> IDs are going to be more specific than classes, which can sometimes be a benefit.
[09:58:00 EST(-0500)] <colinclark> We've been building our skinning system almost entirely with classes...
[09:58:22 EST(-0500)] <EricDalquist> that's what I thought
[09:58:23 EST(-0500)] <colinclark> feeling like it was better for a solution where assumptions about the whole document can be risky.
[09:58:49 EST(-0500)] <colinclark> fj4000: Any thoughts?
[09:58:51 EST(-0500)] <fj4000> you should really try to stick to classes if possible
[09:59:13 EST(-0500)] <fj4000> ids are great for use as hooks and the occasional override
[09:59:36 EST(-0500)] <fj4000> but they can make you css britle
[10:00:04 EST(-0500)] <fj4000> just my 2c
[10:00:49 EST(-0500)] <EricDalquist> thanks for the input
[10:01:02 EST(-0500)] <EricDalquist> we have some folks new to doing UI development in a portal
[10:01:36 EST(-0500)] <EricDalquist> and trying to convince them that they need to do things via classes since the IDs generally contain the dynamically generated portlet namespace key
[10:02:02 EST(-0500)] <fj4000> your going to find the power of classname combinations can help keep you css and markup very very clean
[10:02:06 EST(-0500)] <fj4000> and flexible
[10:02:16 EST(-0500)] <fj4000> yes, absolutely
[10:03:09 EST(-0500)] <fj4000> IDs as namespaces and classnames for presentation data sounds like a great strategy
[10:04:04 EST(-0500)] <EricDalquist> thanks for the conformation as well
[10:04:14 EST(-0500)] <fj4000>
[10:04:56 EST(-0500)] <EricDalquist> at first they came to me yesterday asking how to generate the CSS from a jsp so they could target it to the namespaced IDs 
[10:06:13 EST(-0500)] <fj4000> you mean like #namespace .myClass {} ?
[10:06:42 EST(-0500)] <EricDalquist> like generating a CSS class like #elementId_namespace {}
[10:07:25 EST(-0500)] <EricDalquist> lots of the ids look like id="filterDiv_filterKey_fitlerOpt_portletNamespace" where filterKey, filterOpt and portletNamespace are dynamic
[10:07:25 EST(-0500)] <fj4000> yech
[10:07:29 EST(-0500)] <EricDalquist> yup
[10:07:43 EST(-0500)] <EricDalquist> the ids work very well like that for doing JS callbacks
[10:08:01 EST(-0500)] <EricDalquist> you can find exactly the element you want and your ensured there aren't conflicts on the page via the portletNamespace
[10:08:35 EST(-0500)] <EricDalquist> I just have a few more emails worth of convincing that styling of an element like that should all be done via class=""
[10:09:01 EST(-0500)] <fj4000> just show them how LITTLE code they would need to write 
[10:09:31 EST(-0500)] <fj4000> when you can recycle combinations to create the layout your after!
[10:10:35 EST(-0500)] <EricDalquist>
[10:15:23 EST(-0500)] <colinclark> Justin_o: Sorry, I missed your comment. Let me check.
[10:16:17 EST(-0500)] <Justin_o> colinclark: that's okay, i believe bosmon is still on his way into work
[10:16:37 EST(-0500)] <colinclark> Justin_o: He's so generous to describe FCKEditor as having a "Christmas tree of decorations."
[10:16:45 EST(-0500)] <colinclark> I might have put it differently.
[10:17:10 EST(-0500)] <Justin_o> he's very festive
[10:19:29 EST(-0500)] <colinclark>
[10:20:17 EST(-0500)] <Justin_o> colinclark: i'm starting to slim down the bug parade... how do you think it is looking for uploader related issues
[10:20:57 EST(-0500)] <colinclark> Lemme take a look, on second.
[10:21:19 EST(-0500)] <Justin_o> sure
[10:22:21 EST(-0500)] <colinclark> Justin_o: The Uploader blockers are all on their way, assuming fj4000 is going to work with Eli sometime today to deal with the CSS.
[10:22:45 EST(-0500)] <Justin_o> yep...
[10:22:52 EST(-0500)] <Justin_o> i'll check in with them on that
[10:23:31 EST(-0500)] <Justin_o> have you taken a look at the patch for Fluid-1948
[10:23:33 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[10:23:48 EST(-0500)] <anastasiac> hi, Bosmon
[10:24:11 EST(-0500)] <Bosmon> Hi
[10:24:13 EST(-0500)] <colinclark> Justin_o: It's on my list.
[10:24:14 EST(-0500)] <anastasiac> colinclark and I were just having an IM discussion about the global FCKeditor_OnComplete function
[10:24:20 EST(-0500)] <Bosmon> Ah yes
[10:24:20 EST(-0500)] <Justin_o> colinclark: thanks
[10:24:26 EST(-0500)] <Bosmon> It is actually no longer 100% necessary
[10:24:39 EST(-0500)] <Bosmon> Since I discovered last night a simpler way of getting the initial value into FCKEditor
[10:24:46 EST(-0500)] <colinclark> Bosmon: how?
[10:24:59 EST(-0500)] <Bosmon> Ah well, you see
[10:25:08 EST(-0500)] <Bosmon> It was suggested by an analogous problem with TinyMCE
[10:25:16 EST(-0500)] <Bosmon> These pieces of code really are incredibly shitty
[10:25:24 EST(-0500)] <colinclark> No kidding.
[10:25:39 EST(-0500)] <Bosmon> It seems that during initialisation, there is a moment that they claim to exist but nonetheless do not honour changes to values made via their APIs
[10:25:55 EST(-0500)] <colinclark> oh god
[10:25:56 EST(-0500)] <Bosmon> I write for posterity that the developers of TinyMCE and FCKEditors are shitheads
[10:26:01 EST(-0500)] <Bosmon> Anyway
[10:26:22 EST(-0500)] <colinclark> I'd like to add the SWFUpload developer to that list, but I had to be mean.
[10:26:24 EST(-0500)] <Bosmon> It seems that, if you fail to get sense out of them in one angle, if you instead still go back to the "in process of destruction" textarea they are based on
[10:26:25 EST(-0500)] <colinclark> hate
[10:26:32 EST(-0500)] <Bosmon> And set the value on that
[10:26:42 EST(-0500)] <Bosmon> Then generally they will pick up the value from there "in time"
[10:26:47 EST(-0500)] <colinclark> wow
[10:26:54 EST(-0500)] <colinclark> odd and frightening
[10:27:00 EST(-0500)] <Bosmon> Yes, it really is
[10:27:10 EST(-0500)] <colinclark> So are you considering modifying your implementation?
[10:27:18 EST(-0500)] <Bosmon> I found with some testing that my complex event-based thing would not work for the SECOND FCKEditor of a set
[10:27:21 EST(-0500)] <Bosmon> I fixed it already
[10:27:27 EST(-0500)] <colinclark> Where?
[10:27:36 EST(-0500)] <Bosmon> That is, the event is only delivered ONCE, for the all-time loading of the FCKeditor code
[10:27:51 EST(-0500)] <Bosmon> Nonetheless, it can still be possible for the SECOND FCKEditor you try to invoke to be "not ready"
[10:28:01 EST(-0500)] <Bosmon> Well, I mean, that global callback is now disused in trunk
[10:28:03 EST(-0500)] <Bosmon> If you notice
[10:28:11 EST(-0500)] <Bosmon> Both of the "accessors" now use this trick I just mentioned
[10:28:36 EST(-0500)] <anastasiac> so - the global function is not used, and can be deleted??
[10:28:38 EST(-0500)] <colinclark> So anastasiac can just hose this global callback/
[10:28:43 EST(-0500)] <colinclark> beat me to it
[10:28:52 EST(-0500)] <Bosmon> Well, I left it there
[10:28:54 EST(-0500)] <Bosmon> "For a convenience"
[10:29:04 EST(-0500)] <anastasiac> whose convenience??
[10:29:07 EST(-0500)] <Bosmon> As it stands, there is no way that more than one person can register as a listener for this event
[10:29:14 EST(-0500)] <Bosmon> Because of the way it is structured
[10:29:20 EST(-0500)] <Bosmon> The convenience of the PUBLICK!
[10:29:40 EST(-0500)] <colinclark> Bosmon: So are you advocating leaving it?
[10:29:50 EST(-0500)] <Bosmon> Yes
[10:29:55 EST(-0500)] <Bosmon> Do you think it should go?
[10:30:05 EST(-0500)] <colinclark> So then there is the natural ambiguity of "which fluid?"
[10:30:24 EST(-0500)] <Bosmon> Well, to be sure
[10:30:33 EST(-0500)] <colinclark> Since this is a global callback, we'll have to be content with it being ambiguous.
[10:30:49 EST(-0500)] <Bosmon> But that is elegance itself, compared to contemplating the phenomenon of a man engaged in the act of cutting off his own head
[10:30:59 EST(-0500)] <colinclark> wow
[10:31:08 EST(-0500)] <colinclark> that's a slightly disturbing analogy
[10:31:08 EST(-0500)] <colinclark>
[10:31:34 EST(-0500)] <anastasiac> indeed :-/
[10:31:41 EST(-0500)] <colinclark> what is it a reference to?
[10:32:18 EST(-0500)] <colinclark> Ok, so anastasiac, you're find to add fluid to the list of declared globals, and perhaps a comment saying, "this global function will refer to whichever version of Fluid Infusion was first loaded.
[10:32:32 EST(-0500)] <Bosmon> Isn't it the last loaded?
[10:32:49 EST(-0500)] <Bosmon> Here we go:
[10:32:55 EST(-0500)] <Bosmon> "My good sir, the awkwardness of your position is grace itself compared with that of a man engaged in the act of cutting off his own head."
[10:33:00 EST(-0500)] <Bosmon> http://math.boisestate.edu/GaS/mikado/libretto.txt
[10:33:02 EST(-0500)] <colinclark> var fluid = fluid || fluid_0_6;
[10:33:18 EST(-0500)] <Bosmon> Right
[10:33:28 EST(-0500)] <Bosmon> But the actual ENTRY of the callback is achieved by simple file inclusion
[10:33:35 EST(-0500)] <Bosmon> Hmm...
[10:33:36 EST(-0500)] <colinclark> aha, haven't you been quoting a lot of William Gilbert librettos recently?
[10:33:54 EST(-0500)] <Bosmon> OK, I see
[10:33:59 EST(-0500)] <colinclark> yes
[10:34:04 EST(-0500)] <Bosmon> Each included file will simply rebind the callback to the "same thing"
[10:34:38 EST(-0500)] <Bosmon> At least it does something that is consistent with something else
[10:34:53 EST(-0500)] <colinclark> yeah, it's fine
[10:35:12 EST(-0500)] <colinclark> it should just be clear what the consequence of being this horribly global is.
[10:35:29 EST(-0500)] <colinclark> the comment above it is pretty sufficient
[10:35:53 EST(-0500)] <colinclark> So Bosmon, anastasiac has a small patch of tweaks to InlinEditIntegrations.js
[10:36:08 EST(-0500)] <Bosmon> cool
[10:36:17 EST(-0500)] <Bosmon> Including the comma?
[10:36:20 EST(-0500)] <anastasiac> actually, they've been committed (all save this last)
[10:36:22 EST(-0500)] <anastasiac> yes, including the comma
[10:36:24 EST(-0500)] <colinclark> ok
[10:36:28 EST(-0500)] <Bosmon>
[10:36:36 EST(-0500)] <anastasiac> I'll commit this last, then someone can review
[10:36:45 EST(-0500)] <colinclark> It includes a few name changes, and the addition of an inlineEditDropdown() creator function.
[10:36:51 EST(-0500)] <Bosmon> I realised in talking to Justin_o that I must have left out some of the vital files from TinyMCE
[10:36:55 EST(-0500)] <Bosmon> Some that contain some of the icons
[10:36:57 EST(-0500)] <colinclark> aha
[10:37:01 EST(-0500)] <Bosmon> I assumed that lower panel was meant to be blank
[10:37:09 EST(-0500)] <Bosmon> But apparently it has functional, but invisible icons in it
[10:37:28 EST(-0500)] <Bosmon> Cool, what name changes do we have
[10:37:33 EST(-0500)] <colinclark> I like how you've kept track of these various configurations by storing them in fluid.defaults()
[10:37:43 EST(-0500)] <colinclark> "fluid.inlineTinyMCE"
[10:37:50 EST(-0500)] <colinclark> "fluid.inlineFCKEditor"
[10:37:59 EST(-0500)] <colinclark> I think that's it, right anastasiac?
[10:38:08 EST(-0500)] <anastasiac> I was wondering about that! I hover over the bar, and get the tooltips
[10:38:14 EST(-0500)] <anastasiac> colinclark, yes
[10:38:39 EST(-0500)] <Bosmon> Well, you have renamed all of the other namespaces to match?
[10:38:53 EST(-0500)] <colinclark> anastasiac: indeed
[10:39:21 EST(-0500)] <anastasiac> only the names of the defaults were changed
[10:39:28 EST(-0500)] <colinclark> These guys should match:
[10:39:28 EST(-0500)] <Bosmon> That doesn't seem very sensible
[10:39:29 EST(-0500)] <colinclark> fluid.tinyMCE = {};
[10:39:39 EST(-0500)] <Bosmon> The names of the defaults used to match the names of the creator function namespaces
[10:39:55 EST(-0500)] <anastasiac> right, gotcha
[10:39:58 EST(-0500)] <Justin_o> fj4000: is Fluid-1901 finished, and if not will you have time to before the end of the week. I'm thinking about pulling it from the bug parade
[10:40:15 EST(-0500)] <fj4000> let me take a look
[10:40:20 EST(-0500)] <colinclark> So I was wrangling with SWFUpload and Flash 10 until 1 am last night...
[10:40:28 EST(-0500)] <Bosmon> And if you are going to rename those, to something longer, I would prefer you did something regular
[10:40:34 EST(-0500)] <Bosmon> Like fluid.inlineEdit.tinyMCE
[10:40:42 EST(-0500)] <colinclark> that would be fine
[10:40:51 EST(-0500)] <fj4000> Justin_o there are some basics there....
[10:41:05 EST(-0500)] <fj4000> i was hoping to get some more time to make more demos, but the core ideas are there
[10:41:07 EST(-0500)] <Bosmon> Although that does now create a file inclusion order risk
[10:41:30 EST(-0500)] <colinclark> Bosmon: well, it's safe to assume that this should go after InlineEdit.js, isn't it?
[10:41:39 EST(-0500)] <colinclark> Since it depends on it.
[10:41:41 EST(-0500)] <Bosmon> Well, is it?
[10:42:01 EST(-0500)] <Justin_o> fj4000: i'll try to take a look at your patch then and make a decesion later... thanks
[10:42:05 EST(-0500)] <colinclark> I'd say so, yes.
[10:42:06 EST(-0500)] <fj4000> Justin_o: could you take a look at fluid-components/html/FSS.html and let me know if you think it needs more demos to be considered "done" ?
[10:42:12 EST(-0500)] <fj4000> yes, thanks
[10:42:26 EST(-0500)] <Bosmon> Well, without this change, it would be possible for them to be included in an arbitrary order
[10:42:42 EST(-0500)] <Bosmon> And as I think as we have discovered, under some loading models, some browsers do not guarantee to respect a particular order
[10:42:55 EST(-0500)] <colinclark> Bosmon: Then you'll have to live with non-regular naming here.
[10:43:06 EST(-0500)] <Bosmon> Why is that?
[10:43:19 EST(-0500)] <colinclark> Well, you can have one or the other, it appears.
[10:43:24 EST(-0500)] <Bosmon> I see no justification for non-regular naming
[10:43:51 EST(-0500)] <colinclark> So then you are stuck with a specific inclusion order.
[10:44:12 EST(-0500)] <Bosmon> Well, how about calling the defaults "fluid.tinyMCE.inlineEdit"
[10:44:21 EST(-0500)] <Bosmon> etc.
[10:44:58 EST(-0500)] <colinclark> Fine by me.
[10:45:03 EST(-0500)] <Bosmon> ok, cool
[10:45:09 EST(-0500)] <colinclark> anastasiac: Cool?
[10:45:38 EST(-0500)] <anastasiac> I don't mind renaming, but I'm not quite clear on why?
[10:45:50 EST(-0500)] <Bosmon> Well, I wasn't quite clear on why you renamed them to start with
[10:45:57 EST(-0500)] * anastasiac hasn't had her second cup of coffee yet)
[10:46:00 EST(-0500)] <colinclark>
[10:46:05 EST(-0500)] <Bosmon> But, based on some assumptions about why you did it, I think this proposal is better
[10:46:16 EST(-0500)] <anastasiac> the defaults were for a flavour of inline edit, but made no mention of inline edit in their name
[10:46:24 EST(-0500)] <Bosmon> Right
[10:46:27 EST(-0500)] <colinclark>
[10:46:44 EST(-0500)] <Bosmon> But as they were, they matched a particular namespace regularly, which meant that in the future, it might be possible to locate them automatically
[10:46:58 EST(-0500)] <colinclark> right
[10:47:00 EST(-0500)] <Bosmon> In the way that we have in the past for various flavours of "defaults"
[10:47:04 EST(-0500)] <anastasiac> ?
[10:47:06 EST(-0500)] <Bosmon> For example, those for subcomponents or components
[10:47:13 EST(-0500)] <colinclark> Since, anastasiac, you've seen that we often refer to things by their names...
[10:47:32 EST(-0500)] <colinclark> Subcomponents instantiated as "fluid.fileQueueView," for example.
[10:48:05 EST(-0500)] <colinclark> If defaults and creators remain totally consistent, it means that we would be able to, with a name, be able to both look up its defaults and instantiate
[10:48:07 EST(-0500)] <colinclark> For example.
[10:48:07 EST(-0500)] * anastasiac is sure there's still something she's not getting
[10:48:28 EST(-0500)] * anastasiac sees a light!
[10:48:41 EST(-0500)] <anastasiac> ok, you're talking about having the defaults have the same name as the creator
[10:48:47 EST(-0500)] <colinclark> anastasiac: you got it
[10:48:57 EST(-0500)] <anastasiac> so that would be fluid.inlineEditFCK ?
[10:49:03 EST(-0500)] <anastasiac> which is the name of the creator?
[10:49:44 EST(-0500)] * anastasiac hears crickets
[10:49:48 EST(-0500)] <anastasiac> am I still not getting it?
[10:50:48 EST(-0500)] <Bosmon> Well, we don't actually have a specific component hierarchy in this area yet
[10:50:53 EST(-0500)] <Bosmon> But that doesn't mean we won't someday
[10:50:58 EST(-0500)] <Bosmon> In fact, we probably should
[10:51:26 EST(-0500)] <colinclark> anastasiac: You're definitely right here. The creators and the defaults need to match.
[10:51:36 EST(-0500)] <colinclark> Then Bosmon is wondering about the whole hierarchy of the name space.
[10:52:05 EST(-0500)] <anastasiac> start with fluid.inlineEdit, move to fluid.inlineEdit.tinyMCE, fluid.inlineEdit.dropdown ?
[10:52:17 EST(-0500)] <Bosmon> Well, we have a problem with that approach, as I mentioned before
[10:52:30 EST(-0500)] <Bosmon> Since this relies on access to the name "fluid.inlineEdit" which is declared in another file
[10:52:34 EST(-0500)] <anastasiac> yes
[10:52:39 EST(-0500)] <colinclark> I think we probably just need to suck it up and force an order.
[10:52:43 EST(-0500)] <colinclark> It's unavoidable.
[10:52:47 EST(-0500)] <Bosmon> Which is why I proposed organising around these names around the names we do have control over
[10:52:52 EST(-0500)] <Bosmon> fluid.tinyMCE.inlineEdit
[10:52:53 EST(-0500)] <Bosmon> etc.
[10:52:59 EST(-0500)] <anastasiac> there are lots of other cases in which we force an order
[10:53:02 EST(-0500)] <anastasiac> we're already doing it
[10:53:04 EST(-0500)] <Bosmon> Are there?
[10:53:06 EST(-0500)] <Bosmon> Such as where?
[10:53:11 EST(-0500)] <colinclark> jQuery before Fluid
[10:53:19 EST(-0500)] <colinclark> Fluid before any other component
[10:53:32 EST(-0500)] <Bosmon> Oh well
[10:53:33 EST(-0500)] <colinclark> These things break if the order is not correct.
[10:54:38 EST(-0500)] <colinclark> And I believe we can be confident that inclusion order will always be respected in all browsers.
[10:54:52 EST(-0500)] <Bosmon> Yes, for files that are written "physically"
[10:55:13 EST(-0500)] <colinclark> As opposed to injected later? Yes, you're right.
[10:57:04 EST(-0500)] <anastasiac> Bosmon, colinclark: a double-check about this renaming:
[10:57:17 EST(-0500)] <anastasiac> the objects containing the accessors (e.g. fluid.tinyMCE.inlineEditViewAccessor)
[10:57:28 EST(-0500)] <anastasiac> they can't be renamed to fluid.inlineTinyMCE, right?
[10:57:47 EST(-0500)] <colinclark> no
[10:59:23 EST(-0500)] <colinclark> So the thing to do is to move everything into second-tier namespace...
[10:59:33 EST(-0500)] <colinclark> which we have sort of not quite decided on.
[10:59:43 EST(-0500)] <colinclark> But taking Bosmon's suggestion...
[11:00:09 EST(-0500)] <colinclark> you'd be moving the creator function for the tinymce rich editor into the tinyMCE object
[11:00:54 EST(-0500)] <Bosmon> Or you could do it the other way
[11:00:55 EST(-0500)]
[11:00:58 EST(-0500)] <Bosmon> So long as there is some regular rule
[11:01:05 EST(-0500)] <Bosmon> fluid.inlineEdit.tinyMCE =
[11:01:12 EST(-0500)] <Bosmon> If you think that would be clearer for external users
[11:01:14 EST(-0500)] <colinclark> right
[11:01:20 EST(-0500)] <colinclark> and then the defaults would similarly reflect this structure.
[11:01:26 EST(-0500)] <anastasiac> what is fluid.inlineEdit.tinyMCE equal to??
[11:01:32 EST(-0500)] <anastasiac> the creator function?
[11:01:39 EST(-0500)] <anastasiac> or the object containing the accessors?
[11:01:43 EST(-0500)] <colinclark> the former
[11:01:46 EST(-0500)] <colinclark> sorry
[11:01:55 EST(-0500)] <anastasiac> ok, right
[11:02:28 EST(-0500)] <colinclark> Bosmon: We'd actually need another name here for the creator function in this case.
[11:02:46 EST(-0500)] <colinclark> no, wait, now i'm being the idiot
[11:03:11 EST(-0500)] <fj4000> does anyone else think it odd that the UIOptions.html file contain all the js files for itself, as opposed to the host page containing those js files?
[11:03:32 EST(-0500)] <colinclark> fj4000: What host page?
[11:03:34 EST(-0500)] <colinclark>
[11:03:43 EST(-0500)] <fj4000> in my case, the sakai page
[11:03:56 EST(-0500)] <fj4000> shouldnt that page have all the js files? jquery and the like?
[11:04:20 EST(-0500)] <fj4000> and uioptions.html hold very little?
[11:04:43 EST(-0500)] <fj4000> *sorry - uioptions.html shouldnt include those files, right?
[11:05:21 EST(-0500)] <colinclark> fj4000: You're making a distinction that is slightly problematic, but understandable.
[11:05:29 EST(-0500)] <fj4000> thing is, Michelle said she could see a situation where its used standalone
[11:05:35 EST(-0500)] <colinclark> Right.
[11:05:39 EST(-0500)] <fj4000> whereas im using is as a peice of a bigger page
[11:05:45 EST(-0500)] <colinclark> I mean, you could make the same argument about any one of our template pages.
[11:05:52 EST(-0500)] <fj4000> thing is
[11:06:00 EST(-0500)] <fj4000> this is a MUCH biiger template
[11:06:15 EST(-0500)] <fj4000> sort of
[11:06:31 EST(-0500)] <colinclark> The point being that, today, we don't have a fully-prepped template renderer.
[11:06:39 EST(-0500)] <colinclark> This is exactly the case where it will help.
[11:06:52 EST(-0500)] <fj4000> so you think i should forget using an ajax call and just embed the template?
[11:08:31 EST(-0500)] <colinclark> fj4000: Here's what I did in the case the Uploader on the server.
[11:08:37 EST(-0500)] <colinclark> It wasn't ideal, but it made life a bit easier.
[11:08:45 EST(-0500)] <colinclark> Cutting and pasting markup really sucks horribly.
[11:08:59 EST(-0500)] <jessm> no cut n' paste!
[11:09:01 EST(-0500)] <colinclark> Back in the old days of the Uploader, we had three different HTML files, all with exactly the same markup.
[11:09:05 EST(-0500)] <colinclark> For roughly this reason.
[11:09:24 EST(-0500)] <colinclark> And we found that changes would get committed in one place, and people would naturally forget to do it in the other places.
[11:09:40 EST(-0500)] <colinclark> So, what I did with Uploader still sucked, but hopefully a bit less so.
[11:09:54 EST(-0500)] <colinclark> I loaded the contents of the template page via Ajax.
[11:10:07 EST(-0500)] <colinclark> So there was still a small amount of duplicated code: the JavaScript file imports in the head.
[11:10:22 EST(-0500)] <colinclark> But then at least I wasn't duplicating the markup wholesale.
[11:10:31 EST(-0500)] <colinclark> fj4000: Can you do that, perhaps?
[11:11:18 EST(-0500)] <colinclark> Again, all of this pain will go away when the renderer is done. There's still some work to be done in terms of determining how templates will be sourced, but it means you'll be able to easily ask for a particular component and have it rendered into your page without cutting and pasting all its markup.
[11:11:26 EST(-0500)] <Bosmon> We do so have a darn fully prepped renderer
[11:11:41 EST(-0500)] <colinclark> Not by my reckoning.
[11:11:48 EST(-0500)] <colinclark> It's a hot and very promising renderer.
[11:11:50 EST(-0500)] <fj4000> thats what im doing now
[11:11:54 EST(-0500)] <colinclark> But it's going to take a bit more time.
[11:12:00 EST(-0500)] <fj4000> ajax loading the body of the html file, not the head
[11:12:05 EST(-0500)] <fj4000> but for some reason
[11:12:20 EST(-0500)] <fj4000> there are 2 copies of most of the js files
[11:12:46 EST(-0500)] <fj4000> and I think it might be messing up the preview, i think
[11:13:02 EST(-0500)] <fj4000> or it could be something else im missing
[11:13:23 EST(-0500)] <colinclark> ?
[11:13:54 EST(-0500)] <colinclark> fj4000: If it helps any, I was using jQuery's very helpful .load() function.
[11:14:21 EST(-0500)] <colinclark> jQuery(elementToFill).load("url selector", ...);
[11:14:40 EST(-0500)] <fj4000> yes
[11:14:43 EST(-0500)] <fj4000> ^
[11:14:57 EST(-0500)] <fj4000> i was already doing that to load a div
[11:15:11 EST(-0500)] <fj4000> but i think it was firebug blinding me with science
[11:15:24 EST(-0500)] <fj4000> its showing duplicates, but i dont think they're really there
[11:15:56 EST(-0500)] <fj4000> since they're not loaded twice, just available in 2 different places in the script dropdown menu....argh!!
[11:16:36 EST(-0500)] * fj4000 hating firebug these days...but is still in love it....but wants to kill it...with love
[11:20:58 EST(-0500)] <fj4000> AHAH - I forgot to add the preview selector...
[11:21:15 EST(-0500)] * fj4000 feeling so stupid....
[11:23:42 EST(-0500)] <colinclark> fj4000: You're not stupid. It happens to everyone!
[11:29:20 EST(-0500)] * jessm routinely forgets the mute button
[11:30:57 EST(-0500)] <fj4000> ok, so now FLUID-1875 should be good to go, Justin_o
[11:31:07 EST(-0500)] <colinclark> Justin_o: How come my bug didn't get included in your "REVIEW" section in the bug parade? I feel left out.
[11:31:20 EST(-0500)] <Justin_o> fj4000: thanks
[11:31:32 EST(-0500)] <Justin_o> colinclark: sorry... oversite
[11:31:41 EST(-0500)] <colinclark> Just teasing you.
[11:31:52 EST(-0500)] <colinclark> I will ask Bosmon to review it, since it is a bit of a hairy fix.
[11:31:57 EST(-0500)] <anastasiac> fj4000, I've been confused by the duplicate files in the firebug menu
[11:32:06 EST(-0500)] <Justin_o> thanks
[11:33:26 EST(-0500)] <Justin_o> colinclark: your patch uses the swf file in the flash folder?
[11:34:00 EST(-0500)] <fj4000> anastasiac: yeah, it was redonkulous
[11:34:21 EST(-0500)] <fj4000> i dont know why it feels the need to show me the same file in the same place in 2 different ways
[11:36:24 EST(-0500)] <Justin_o> i'm updating the daily build site
[11:36:46 EST(-0500)] <colinclark> fj4000: Ah!
[11:36:58 EST(-0500)] <colinclark> You reminded me that this patch doesn't include the updated version of the .swf file.
[11:39:17 EST(-0500)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:40:27 EST(-0500)] <anastasiac> Bosmo1, question for you?
[11:40:41 EST(-0500)] <Bosmo1> Hi, sorry
[11:40:45 EST(-0500)] <Bosmo1> I got knocked off the net briefly
[11:40:54 EST(-0500)] <fj4000> colinclark: ?
[11:41:01 EST(-0500)] <anastasiac> the inline edit integrations, in the editModeRenderers, use that.options.TinyMCE and that.options.FCKEditor
[11:41:14 EST(-0500)] <colinclark> fj4000: Shoot
[11:41:23 EST(-0500)] <fj4000> your comment ^^
[11:41:26 EST(-0500)] <anastasiac> I'm not clear on what those refer to..
[11:43:26 EST(-0500)] <Bosmo1> Those are a set of "pass-through options"
[11:43:33 EST(-0500)] <Bosmo1> You can see some of them in the default options set
[11:43:54 EST(-0500)] <Bosmo1> But these are parcelled off unchanged (apart from merging) on to the "end component" in whatever proprietary way it accepts them
[11:44:04 EST(-0500)] <Bosmo1> For example, FCKEditor accepts them, mysteriously, in two places
[11:44:19 EST(-0500)] <colinclark> fj4000: Oh. Yes. My patch is slightly broken.
[11:44:46 EST(-0500)] <anastasiac> ah, ok - so they're options for the actual third-party objects, not for us
[11:44:58 EST(-0500)] <Bosmo1> yes
[11:45:10 EST(-0500)] <anastasiac> no, I don't see any in the defaults
[11:45:13 EST(-0500)] <Bosmo1> It means we can make each "instance" of the rich text control, or whatever, that we host, fully configurable
[11:45:16 EST(-0500)] <anastasiac> am I missing somethign??
[11:45:22 EST(-0500)] <Bosmo1> Oh wait, they are not in the defaults, but in the manual tests file
[11:45:42 EST(-0500)] <Bosmo1> Look at "richEditor2" for example
[11:45:48 EST(-0500)] <anastasiac> ah! right, got it
[11:45:51 EST(-0500)] <anastasiac> cool, thanks
[11:45:54 EST(-0500)] <Bosmo1> It merges in a specific width directive, targetted at the downstream TinyMCE control
[11:45:55 EST(-0500)] <anastasiac> much clearer now
[11:47:23 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[11:51:18 EST(-0500)] * fj4000 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[11:53:25 EST(-0500)] <anastasiac> Bosmo1, Justin_o: I've finished the review and associated changes to FLUID-1944.
[11:53:39 EST(-0500)] <anastasiac> It should undergo another review - Bosmo1, could you do that?
[11:53:44 EST(-0500)] <Bosmo1> OK, cool
[11:53:48 EST(-0500)] <Bosmo1> You want me to review your review?
[11:53:56 EST(-0500)] <anastasiac> yes, please
[11:54:09 EST(-0500)] <anastasiac> I've committed all the changes we've talked about
[11:54:12 EST(-0500)] <colinclark> Bosmo1, anastasiac: So I just did some API "user testing."
[11:54:13 EST(-0500)] <Bosmo1> OK, I will look
[11:54:25 EST(-0500)] <colinclark> The results were unanimous.
[11:54:32 EST(-0500)] <colinclark> Though you could argue with my Science.
[11:54:42 EST(-0500)] <anastasiac> what was your n?
[11:55:06 EST(-0500)] <Bosmo1> You mean, you asked some guys?
[11:55:09 EST(-0500)] <colinclark> hahaha
[11:55:15 EST(-0500)] <colinclark> That was my Science, yes.
[11:55:33 EST(-0500)] <anastasiac> and what was the unanimous verdict?
[11:55:56 EST(-0500)] <colinclark> I prefer to call it a Lightweight, Lowcost, Agile User Testing methodology recommended by Jared Spool (tm).
[11:55:57 EST(-0500)] <colinclark>
[11:56:03 EST(-0500)] <Bosmo1> SPOOL!
[11:56:03 EST(-0500)] <colinclark> Hence it is Science.
[11:56:27 EST(-0500)] * anastasiac is still waiting for the results
[11:56:46 EST(-0500)] <colinclark> I am keeping you in suspense by making riveting and witty methodology jokes.
[11:56:56 EST(-0500)] <Bosmo1> "I will not keep you in unnecessary suspense"
[11:56:59 EST(-0500)] <colinclark> So, anastasiac are you curious about the results?
[11:57:00 EST(-0500)] <anastasiac> oh, I didn't catch that
[11:57:02 EST(-0500)] <Bosmo1> So it says in your Book of Etiquette
[11:57:03 EST(-0500)] <colinclark>
[11:57:14 EST(-0500)] <colinclark> damn
[11:57:18 EST(-0500)] <colinclark> you guys are a tough crowd
[11:57:38 EST(-0500)] <colinclark> I flew all the way here from Toronto, and, boy, are my arms tired.
[11:57:59 EST(-0500)] <colinclark> Ok.
[11:58:06 EST(-0500)] * anastasiac is surprisingly amused by that
[11:58:23 EST(-0500)] <colinclark> Everyone felt that fluid.inlineEdit.tinyMCE() felt like a more natural instantiation, since it obviously conveys it as a "type" of inline editor.
[11:58:27 EST(-0500)] <Bosmo1> KENT, you are a nitwit
[11:58:34 EST(-0500)] <colinclark>
[11:58:34 EST(-0500)] <jessm> lol
[11:59:37 EST(-0500)] <colinclark> So anastasiac does this user research help you with your code?
[11:59:51 EST(-0500)] <anastasiac> yes, thanks
[11:59:59 EST(-0500)] <anastasiac> Bosmo1 is reviewing it now
[12:00:03 EST(-0500)] <Bosmo1> Well, if we are going with this depth, we can certainly clean up this
[12:00:04 EST(-0500)] <Bosmo1> fluid.inlineEdit.FCKEditor.inlineEditViewAccessor = function (editField) {
[12:00:16 EST(-0500)] <anastasiac> ack!
[12:00:20 EST(-0500)] <anastasiac> good catch, thanks
[12:00:44 EST(-0500)] <colinclark> ok
[12:00:47 EST(-0500)] * anastasiac loves pair programming
[12:01:11 EST(-0500)] <colinclark> So Bosmo1, when you are done review the review, I'm wondering if you'd grace my patch with your reviewing prowess.
[12:01:21 EST(-0500)] <colinclark> Except that I need to tweak it slightly, because it is broken.
[12:01:35 EST(-0500)] <Bosmo1> ok
[12:01:40 EST(-0500)] <Bosmo1> It will be a Graced Patch
[12:01:56 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[12:02:17 EST(-0500)] <anastasiac> Bosmo1, do you want to commit that fix, or shall I?
[12:02:26 EST(-0500)] <Bosmo1> Well, why don't you
[12:02:49 EST(-0500)] <anastasiac> was there anything else, or are you still looking?
[12:03:13 EST(-0500)] <Bosmo1> fluid.inlineEdit.dropdown = function (container, options) {
[12:03:14 EST(-0500)] <Bosmo1> return configureInlineEdit("fluid.inlineEdit.dropdown", container, options);
[12:03:14 EST(-0500)] <Bosmo1> };
[12:03:21 EST(-0500)] <Bosmo1> We could now economise on all these functions
[12:03:23 EST(-0500)] <Bosmo1>
[12:03:44 EST(-0500)] <anastasiac> go on...
[12:03:46 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[12:03:49 EST(-0500)] <Bosmo1> Well, you know
[12:03:51 EST(-0500)] <Bosmo1> The way JQuery does
[12:03:55 EST(-0500)] <Bosmo1> They all do the same thing
[12:04:31 EST(-0500)] <Bosmo1> We could just say, makeInlineEditConstructors("dropdown", "tinyMCE", "FCK")
[12:04:32 EST(-0500)] <Bosmo1>
[12:05:15 EST(-0500)] <anastasiac> I think there's economizing, and then there's economizing
[12:06:35 EST(-0500)] <Bosmo1> Yes, maybe
[12:06:45 EST(-0500)] <Bosmo1> We will wait for Renfro to criticise us
[12:06:49 EST(-0500)] <Bosmo1> And then we will do it
[12:08:16 EST(-0500)] <anastasiac> ok, I've committed the fix to the edit accessor name
[12:08:41 EST(-0500)] <anastasiac> I think we're good to hand this one over to Justin_o - would you concur, Bosmo1?
[12:08:59 EST(-0500)] <Bosmo1> Well, let me see if I can discover the missing TinyMCE icons first
[12:09:05 EST(-0500)] <anastasiac> ah, right
[12:09:47 EST(-0500)] <Bosmo1> You have not chosen the right name for these functions
[12:09:54 EST(-0500)] <Bosmo1> You have left the "edit" of "inlineEdit"
[12:10:07 EST(-0500)] <Bosmo1> Not noting that what they actually are are a "viewAccessor"
[12:10:12 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[12:12:06 EST(-0500)] <anastasiac> ah - I looked at the defaults, and it says editAccessor:
[12:12:09 EST(-0500)] <anastasiac> so...
[12:12:12 EST(-0500)] <anastasiac> is that wrong?
[12:12:48 EST(-0500)] <Bosmo1> Wel
[12:12:54 EST(-0500)] <Bosmo1> It is a thing of type "viewAccessor"
[12:13:00 EST(-0500)] <Bosmo1> The full name for it might be "editModeViewAccessor"
[12:13:52 EST(-0500)] <anastasiac> so the 'view' here is view as in MVC view?
[12:14:11 EST(-0500)] <Bosmo1> yes
[12:14:25 EST(-0500)] <anastasiac> hm
[12:14:31 EST(-0500)] * anastasiac ponders
[12:15:14 EST(-0500)] <anastasiac> if someone has a GidgetRichTextEditor, and wants to plug it in, they're have to write their own edit mode view accessor function, right?
[12:15:19 EST(-0500)] <Bosmo1> yes
[12:15:29 EST(-0500)] * anastasiac continues to ponder
[12:20:18 EST(-0500)] <anastasiac> ok, how about editViewAccessor?
[12:20:30 EST(-0500)] <anastasiac> for the actual function, not the name of the option
[12:25:01 EST(-0500)] <Bosmo1> What's wrong with "viewAccessor"
[12:25:08 EST(-0500)] <Bosmo1> It is entirely unambiguous
[12:25:16 EST(-0500)] <Bosmo1> Since you are dealing with something which is already implicitly an "editor"
[12:25:23 EST(-0500)] <Bosmo1> It could only possible be referring to the bloody edit view!
[12:25:24 EST(-0500)] <Bosmo1>
[12:26:58 EST(-0500)] <Bosmo1> ok
[12:27:04 EST(-0500)] <Bosmo1> I have located the elusive "icons"...
[12:27:09 EST(-0500)] <Bosmo1> I do wonder how I managed to detacth them...
[12:27:41 EST(-0500)] <Bosmo1> The "simple" configuration of TinyMCE is actually quite stylish
[12:28:02 EST(-0500)] <Bosmo1> Seems to work fine in Opera now
[12:28:37 EST(-0500)] <Justin_o> Bosmo1: that's good to hear
[12:29:25 EST(-0500)] <anastasiac> doesn't the inline editor also have a display view?
[12:29:53 EST(-0500)] <anastasiac> with its associated displayAccessor?
[12:30:04 EST(-0500)] <Bosmo1> EricDalquist: Sorry to miss your age-old query
[12:30:20 EST(-0500)] <Bosmo1> My first preference is for ISO-8601 dates
[12:30:26 EST(-0500)] <Bosmo1> For which I have a little library, that almost works
[12:30:27 EST(-0500)] <Bosmo1>
[12:30:51 EST(-0500)] <Bosmo1> anastasiac: Yes, but those can never be specfic to a particular editor technology
[12:31:23 EST(-0500)] <anastasiac> ok, yes, I can see that. I'm convinced
[12:31:33 EST(-0500)] <anastasiac> sorry if I'm being difficult, it's just my nature
[12:31:46 EST(-0500)] <Bosmo1> Yes, I'm sure it works well for you when you are carrying a sword
[12:32:24 EST(-0500)] <anastasiac> or wearing boxing gloves
[12:32:33 EST(-0500)] <Bosmo1> Yes
[12:32:40 EST(-0500)] <Bosmo1> But this time, THE ADVANTAGE IS MINE
[12:32:43 EST(-0500)] <Bosmo1> FOR YOU DO NOT HAVE A PLANE!
[12:33:05 EST(-0500)] <anastasiac> LOL
[12:33:44 EST(-0500)] <Bosmo1> Petro always flees when the Bullshot quotes start flying
[12:33:55 EST(-0500)] <anastasiac> ah, but I'm deathless, which lends a certain advantage
[12:34:31 EST(-0500)] <Bosmo1> Quite
[12:34:45 EST(-0500)] <Bosmo1> You would probably survive an assault by a giant octopus
[12:35:15 EST(-0500)] <Bosmo1> ICH BIN MIT PETRO NICHT VERMESSEN
[12:36:29 EST(-0500)] <Bosmo1> As a side-note to all, in my refactoring I also removed our older, "DOM-based" implementation of the InlineEditor "isEditing" function
[12:36:47 EST(-0500)] <Bosmo1> This is an example of the sort of thing of which these days we do "Not Approve" (TM)
[12:36:53 EST(-0500)] <anastasiac> ok, I think FLUID-1944 is finally ready for final QA now that I've committed the fix to the viewAccessor name
[12:37:03 EST(-0500)] <anastasiac> and Bosmo1 has restored the icons
[12:37:13 EST(-0500)] <anastasiac> and yes, it looks much nicer now
[12:37:24 EST(-0500)] <Bosmo1> It now has an implementation of this sort, based around a "micro-that"
[12:37:31 EST(-0500)] <Bosmo1> var makeIsEditing = function (that) {
[12:37:31 EST(-0500)] <Bosmo1> var isEditing = false;
[12:37:31 EST(-0500)]
[12:37:31 EST(-0500)]
[12:37:31 EST(-0500)]
[12:37:32 EST(-0500)] <Bosmo1> };
[12:37:38 EST(-0500)] <Bosmo1> I draw everyone's attention to it
[12:37:43 EST(-0500)] <Justin_o> have all the changes been committed?
[12:37:53 EST(-0500)] <Bosmo1> yes
[12:38:09 EST(-0500)] <Justin_o> okay... i'll start testing it
[12:40:52 EST(-0500)] <colinclark> Bosmo1: You and your need to Approve Things!
[12:40:59 EST(-0500)] <Bosmo1> Oh yes
[12:41:00 EST(-0500)] <colinclark> Anyway, that is very sensible and model-driven.
[12:41:04 EST(-0500)] <Bosmo1> Reminds me to do that blog posting
[12:41:11 EST(-0500)] <colinclark> Bosmo1: Please, yes.
[12:41:15 EST(-0500)] <Bosmo1> Which you can then Approve
[12:41:25 EST(-0500)] <colinclark>
[12:43:05 EST(-0500)] <Bosmo1> Wow
[12:43:11 EST(-0500)] <Bosmo1> Has really noone blogged since "Finding things quickly"
[12:43:17 EST(-0500)] <Bosmo1> We are really a paltry bunch of bloggers...
[12:44:30 EST(-0500)] <Bosmo1> Can someone give me the mega-hidden PHP url for the admin interface again?
[12:44:33 EST(-0500)] <Bosmo1> Privately, I guess
[12:44:35 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:44:51 EST(-0500)] <Bosmo1> MIT PETRO, PETRO...
[12:47:04 EST(-0500)] <colinclark> Bosmo1: I have been feeling very guilty about my lack of blogability recently.
[12:48:43 EST(-0500)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:53:26 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-73.LIPS.Berkeley.EDU) has joined #fluid-work
[12:55:32 EST(-0500)] <Justin_o> ecochran, fj4000: have you guys had a chance to look at Fluid-1935
[12:55:58 EST(-0500)] <fj4000> yes
[12:56:02 EST(-0500)] <fj4000> we were talking about it
[12:56:11 EST(-0500)] <fj4000> we're going to work on it after standup
[12:56:20 EST(-0500)] <Justin_o> perfect, thanks
[13:00:07 EST(-0500)] <anastasiac> Justin_o, I'll have take a stab at reviewing FLUID-1901, the FSS Springboards
[13:00:44 EST(-0500)] <Justin_o> thanks... also i'm not sure if anyone has reviewed colinclark's patch yet either... the one i forgot to mention on bug parade
[13:01:04 EST(-0500)] <colinclark> Justin_o: I am now fearing my patch is mangled.
[13:01:11 EST(-0500)] <colinclark> So review can be delayed.
[13:01:31 EST(-0500)] <colinclark> I guess it's time for standup, anyway.
[13:01:36 EST(-0500)] <Justin_o> okay...
[13:07:59 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[13:19:52 EST(-0500)] <colinclark> Justin_o: What are you seeing with my patch?
[13:20:14 EST(-0500)] <colinclark> It should be broken on Flash 10 installations, but work across all browsers with Flash 9.
[13:20:47 EST(-0500)] <Justin_o> in winxp on my vmware the browse button isn't working... i've tried doing the flash set for local files a dozen times and it still isn't working... i'm using flash 9 by the way
[13:20:55 EST(-0500)] <Justin_o> i'm testing it with the demo version
[13:21:05 EST(-0500)] <Justin_o> of uploader
[13:21:41 EST(-0500)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has left #fluid-work
[13:22:18 EST(-0500)] <Justin_o> i should probably get anastasiac to make sure i applied the patch correctly but thought i would see if it is the same issue you were having
[13:24:20 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[13:25:02 EST(-0500)] <colinclark> So it looks like it's working for ecochran.
[13:25:15 EST(-0500)] <colinclark> Cross your fingers it's just my environment
[13:25:19 EST(-0500)] <colinclark> I'm getting somewhere now.
[13:33:44 EST(-0500)] <colinclark> Justin_o: Ok, so there is a critical error in my patch.
[13:33:55 EST(-0500)] <Justin_o> okay...
[13:33:57 EST(-0500)] <colinclark> I didn't include the SWFUpload 2.2.0 Flash movie along with it.
[13:34:10 EST(-0500)] <colinclark> And when you add it in, everything blows up. I've got a clean fix for it, luckily.
[13:34:21 EST(-0500)] <colinclark> But then there are still layers to go to get Flash 10 support fully working.
[13:35:42 EST(-0500)] <Justin_o> glad you were able to find the problem
[13:35:49 EST(-0500)] <Justin_o> for this current problem
[13:36:05 EST(-0500)] <colinclark> I can't shake the feeling that this whole library is not ready for prime time, and it's a worrisome prospect to unleash it on our users.
[13:36:31 EST(-0500)] <Justin_o> it is still in beta
[13:36:33 EST(-0500)] <colinclark> The consequences of this upgrade to both a11y and configurability are just dismal.
[13:37:23 EST(-0500)] <colinclark> We've signed the SWFUpload mortgage papers just as the house of cards is collapsing.
[13:37:30 EST(-0500)] <colinclark> To mix my metaphors.
[13:38:32 EST(-0500)] <Justin_o> colinclark: does gears only work in IE and FF
[13:38:52 EST(-0500)] <colinclark> Justin_o: Fortunately it runs in Safari too. I don't know about Opera support. Maybe fj4000 knows.
[13:39:14 EST(-0500)] <fj4000> hmm
[13:39:32 EST(-0500)] <fj4000> chrome has it built in, thats for sure
[13:39:44 EST(-0500)] <fj4000> i dont know about opera though
[13:40:13 EST(-0500)] <fj4000> http://www.opera.com/press/releases/2008/05/29/
[13:40:17 EST(-0500)] <fj4000> looks like it though
[13:40:23 EST(-0500)] <anastasiac> colinclark, I'm trying to apply your flash patch on my system
[13:40:29 EST(-0500)] <anastasiac> not working at all, even in FF3 on Mac
[13:40:34 EST(-0500)] <anastasiac> what am I missing?
[13:40:51 EST(-0500)] <anastasiac> is there something I need to do other than just apply the patch?
[13:41:01 EST(-0500)] <colinclark> anastasiac: Nope
[13:41:13 EST(-0500)] <anastasiac> glarg
[13:41:41 EST(-0500)] <Justin_o> colinclark, fj4000: thanks
[13:44:35 EST(-0500)] <colinclark> ok, well I'm going to have take a break from this.
[13:44:52 EST(-0500)] <colinclark> Justin_o: I'm preparing myself for the prospect of just not shipping an Uploader at all in Infusion 0.6.
[13:45:32 EST(-0500)] <Justin_o> really.... would you be adverse to shipping it with only Flash 9 support
[13:45:56 EST(-0500)] <colinclark> I dunno. I guess it's something we'll have to consider.
[13:46:01 EST(-0500)] <anastasiac> hm... someone committed with a NOJIRA...
[13:46:03 EST(-0500)] <colinclark> The optics really aren't great.
[13:46:36 EST(-0500)] <Justin_o> I don't think i added NOJIRA to the bug parade
[13:46:42 EST(-0500)] <colinclark> lol
[13:46:42 EST(-0500)] <anastasiac> that's a no-no during bug parade, isn't it?
[13:46:48 EST(-0500)] <colinclark> anastasiac: Review it. If it's really a whitespace correction, its fine.
[13:46:57 EST(-0500)] <colinclark> Unless Justin_o filed a "general cleanup" JIRA issue.
[13:46:58 EST(-0500)] <anastasiac> it is only whitespace correction
[13:47:13 EST(-0500)] <Justin_o> i did not.... do you guys think one is needed
[13:47:15 EST(-0500)] <colinclark> We needn't be process nerds here.
[13:47:30 EST(-0500)] * anastasiac hides her nerd hat under her chair
[13:47:41 EST(-0500)] <colinclark> Justin_o: Inevitably whitespace cleanup, formatting, and minor tweaks will come up during the release process.
[13:47:58 EST(-0500)] <colinclark> If NOJIRAs make you nervous during parade-and they should-you should probably give people a legitimate ticket to file against.
[13:48:12 EST(-0500)] <Justin_o> colinclark: good idea...
[13:48:17 EST(-0500)] <Justin_o> safer that way
[13:50:13 EST(-0500)] <colinclark> ok, i'm going to retreat to the grant cave for some respite from the trials of wrestling with the Flash beast.
[13:50:27 EST(-0500)] <colinclark> anything else anyone needs before i go?
[13:50:28 EST(-0500)] <Bosmo1> Yes, you are nerds
[13:50:36 EST(-0500)] <Bosmo1> I removed two levels of spacing from 8 lines
[13:50:39 EST(-0500)] <colinclark> Bosmo1: Look who's talking!
[13:50:47 EST(-0500)] <colinclark>
[13:51:12 EST(-0500)] <colinclark> ok i'm off
[13:51:18 EST(-0500)] <colinclark> enjoy carbonara and bug parades and all that
[13:53:10 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[14:08:34 EST(-0500)] <fj4000> Anyone want to have a look at my commit for fluid-1924? Just some simple css changes
[14:20:03 EST(-0500)] <Justin_o> I have just sent out the latest version of the bug parade to the fluid-work mailing list
[14:20:45 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621564.dsl.bell.ca) has joined #fluid-work
[14:21:04 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621564.dsl.bell.ca) has left #fluid-work
[14:21:18 EST(-0500)] <anastasiac> fj4000, I'll have a look at FLUID-1924 and 1875
[14:21:38 EST(-0500)] <fj4000> thank you
[14:22:22 EST(-0500)] <Justin_o> anastasiac: when you are checking fluid-1875 there is an issue where the UIOptions doesn't contain the current style values... maybe you can look at that while you are doing the code review
[14:22:37 EST(-0500)] <anastasiac> k, Justin_o
[14:22:42 EST(-0500)] <Justin_o> thanks
[14:40:03 EST(-0500)] <Justin_o> anastasiac, Bosmo1: I'm making a jira for general code cleanup for the release.. i have linting, whitespace, comments, and readme files.... anything else that we might need
[14:40:37 EST(-0500)] <Justin_o> i also added versioning
[14:47:58 EST(-0500)] <anastasiac> Justin_o, regarding 1875: I just chatted with fj4000, he said you'd created a jira for this? is that the case?
[14:48:58 EST(-0500)] <Justin_o> sorry.. i'm lost... 1875 is a jira?
[14:49:31 EST(-0500)] <anastasiac> no, I'm talking about the political unrest in Poland at the end of the 19th century
[14:49:35 EST(-0500)] <anastasiac>
[14:50:01 EST(-0500)] <anastasiac> the issue with the preview in the sakai demo not showing the current settings
[14:50:05 EST(-0500)] <Justin_o> how about the political unrest in Canada in the 21st century
[14:50:07 EST(-0500)] <fj4000> well then, I believe the politics should take a nap, get their rest
[14:50:19 EST(-0500)] <fj4000> dont want any unrest around here, right?
[14:50:43 EST(-0500)] <Justin_o> anastasiac: oh no i didn't make a seperate jira for that... was it related to the change, in your opinion
[14:50:58 EST(-0500)] <Justin_o> colinclark has unrest because of swift
[14:50:58 EST(-0500)] <anastasiac> no, not related to the change
[14:51:04 EST(-0500)] <anastasiac> I think it's an existing issue
[14:51:15 EST(-0500)] <Justin_o> okay... i'll make a new jira it then
[14:51:40 EST(-0500)] <anastasiac> part of a larger task that I don't think will likely get done before 0.6, but Michelle would be the person to ask about that
[14:52:01 EST(-0500)] <anastasiac> she might check email this evening, so maybe once it's filed, you could email her about it?
[14:52:31 EST(-0500)] <Justin_o> good ide
[14:52:32 EST(-0500)] <Justin_o> idea
[15:09:00 EST(-0500)] <anastasiac> Jusin_o, I'll have a go at reviewing FLUID-1947 and 1948 (a single patch file)
[15:09:37 EST(-0500)] <Justin_o> thanks
[15:22:45 EST(-0500)] <anastasiac> Justin_o, ecochran: I've tried out the patch for FLUID-1947/48
[15:22:56 EST(-0500)] <ecochran> yes?
[15:23:04 EST(-0500)] <anastasiac> While it does seem to address 1948, 1947 is still reproducable
[15:23:19 EST(-0500)] <anastasiac> also, the delete buttons seem confused
[15:23:31 EST(-0500)] <anastasiac> (though that might have been a pre-existing issue, I haven't checked)
[15:23:57 EST(-0500)] <anastasiac> I can reproduce 1947 if I restart and restop it a second time
[15:24:32 EST(-0500)] <ecochran> 1947 is fixed on the server, but not on the local version... there is more work to be done there
[15:24:49 EST(-0500)] <ecochran> how are the delete buttons confused?
[15:24:55 EST(-0500)] <ecochran> anastasiac: ^
[15:25:29 EST(-0500)] <anastasiac> after 'pausing' an upload, the not-yet-uploaded items are dimmed, as though you can't delete them
[15:25:46 EST(-0500)] <ecochran> yep, that's a bug
[15:25:57 EST(-0500)] <ecochran> we didn't see it because we didn't have pausing
[15:25:58 EST(-0500)] <anastasiac> you can't delete them
[15:26:04 EST(-0500)] <anastasiac> though that was a pre-existing bug
[15:26:08 EST(-0500)] <anastasiac> it wasn't introduced by this patch
[15:26:16 EST(-0500)] <ecochran> you should be able to delete them
[15:26:16 EST(-0500)] <anastasiac> (I just reverted)
[15:26:17 EST(-0500)] <ecochran> hmm
[15:26:22 EST(-0500)] <anastasiac> actually, did you commit that patch, eli?
[15:26:25 EST(-0500)] <ecochran> no
[15:26:29 EST(-0500)] <anastasiac> ok, just checking
[15:26:38 EST(-0500)] <anastasiac> yes, so the delete button this was already there
[15:36:20 EST(-0500)] <anastasiac> ok, I'm going to start looking at FLUID-1821
[16:00:43 EST(-0500)] <ecochran> anastasiac: I'd like to commit that patch with the caveat that it does not fix FLUID-1948 but does fix FLUID-1947... clearly FLUID-1948 still needs some work, specifically with the demo code
[16:04:02 EST(-0500)] <Justin_o> ecochran, fj4000: I'm just looking at the remaining blockers, how is Fluid-1935 looking
[16:04:31 EST(-0500)] <fj4000> Eli was taking the reigns on that one
[16:04:56 EST(-0500)] <Justin_o> fj4000: okay... thanks
[16:05:15 EST(-0500)] <fj4000> Justin_o: werent you glad I was glad you were glad??
[16:05:16 EST(-0500)] <ecochran> We're starting with a fairly simple consolidation.
[16:05:33 EST(-0500)] <ecochran> and is going well... I expect to be done today
[16:05:47 EST(-0500)] <fj4000> ecochran: any issues?
[16:05:53 EST(-0500)] <Justin_o> ecochran: that's good, thanks
[16:06:01 EST(-0500)] <fj4000> specifically with the fss stuff?
[16:06:18 EST(-0500)] <ecochran> not so far, but I'm not that deep into it, got caught up in a discussion with Mara
[16:06:21 EST(-0500)] <ecochran> fss?
[16:06:35 EST(-0500)] <anastasiac> ecochran, is it possible to separate the changes for 1947 from the changes for 1948?
[16:06:37 EST(-0500)] <fj4000> yeah, its our acronym for the fluid skinning system
[16:06:37 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[16:06:48 EST(-0500)] <ecochran> fj4000: ah
[16:07:05 EST(-0500)] <fj4000> you'll see it scattered amongst the jira tickets
[16:07:56 EST(-0500)] <ecochran> anastasiac: yes
[16:08:22 EST(-0500)] <ecochran> although it does fix the 1948, but only on the server implementation
[16:08:33 EST(-0500)] <ecochran> I can separate the two
[16:09:06 EST(-0500)] <anastasiac> it's not a big deal, I guess
[16:09:13 EST(-0500)] <anastasiac> I get too finicky sometimes
[16:09:27 EST(-0500)] <anastasiac> and, am I getting 47 and 48 mixed up, or are you?
[16:09:50 EST(-0500)] <anastasiac> I thought the patch fixed 1948, but not 1947...
[16:11:47 EST(-0500)] <ecochran> anastasiac: sorry, yes... getting mixed up
[16:11:53 EST(-0500)] <ecochran> and low blood sugar
[16:11:56 EST(-0500)] <ecochran> need lunch
[16:11:56 EST(-0500)] <anastasiac> ok, no prob
[16:12:03 EST(-0500)] <anastasiac> indeed!
[16:12:48 EST(-0500)] <Justin_o> ecochran: are you going to be committing that now.. if so i'll test it quickly and then send out an update on the bug parade
[16:13:16 EST(-0500)] <ecochran> sure, if it is OK with anastasiac
[16:13:41 EST(-0500)] <anastasiac> yes, I'd say go ahead, but that 1947 is not resolved yet
[16:13:53 EST(-0500)] <Justin_o> okay
[16:18:56 EST(-0500)] <ecochran> Justin_o: Checked in
[16:19:11 EST(-0500)] <ecochran> updated FLUID-1948
[16:19:18 EST(-0500)] <Justin_o> thanks
[16:19:48 EST(-0500)] <ecochran> anastasiac & Justin_o & fj4000: off to get some food
[16:20:06 EST(-0500)] <Justin_o> ecochran: okay.. see you tomorrow
[16:20:11 EST(-0500)] <Justin_o> i'll be heading home soon
[16:21:46 EST(-0500)] * everettz (n=chatzill@fctnnbsc16w-156034216002.pppoe-dynamic.nb.aliant.net) has joined #fluid-work
[16:22:23 EST(-0500)] <ecochran> everettz: is that Chad Everett?
[16:22:33 EST(-0500)] <everettz> anastasiac: Just got your message about the reorder widget. Are you aware that Control + J opens the feed-reader in IE7?
[16:22:49 EST(-0500)] <anastasiac> feed-reader?
[16:23:00 EST(-0500)] <anastasiac> I don't even know what that is
[16:23:39 EST(-0500)] <everettz> ecochran: It's Everett Zufelt
[16:23:46 EST(-0500)] <ecochran> ah, np
[16:23:55 EST(-0500)] <everettz> anastasiac: Control + J opens the IE7 RSS reader.
[16:24:09 EST(-0500)] <Justin_o> everettz: do you have to set it to do that or is it automatic
[16:24:31 EST(-0500)] <everettz> Justin_o: Pretty sure that it's automatic.
[16:24:52 EST(-0500)] <ecochran> everettz: I have a developer friend in North Carolina named Chad Everett, who's company is Everettz Consulting
[16:24:55 EST(-0500)] <Justin_o> i'm pretty sure i've tested that with the reorderer but i'll give it a try again
[16:25:19 EST(-0500)] <anastasiac> yes, this is interesting
[16:25:33 EST(-0500)] <anastasiac> we did a lot of searching to find keys that weren't taken
[16:25:41 EST(-0500)] <anastasiac> I'm surprised we never noticed this
[16:26:28 EST(-0500)] <everettz> anastasiac: Is the most recent reorder found at: http://build.fluidproject.org/fluid/fluid-components/html/Reorderer.html
[16:26:31 EST(-0500)] <Justin_o> everettz: i just ran a quick test, at least with pc cursor mode off it seems to work
[16:27:44 EST(-0500)] <anastasiac> everettz, the link you pasted is one of our demo files
[16:27:54 EST(-0500)] <anastasiac> it shows a few different uses of the Reorderer
[16:28:02 EST(-0500)] <anastasiac> different use cases: lists, grids, tabs
[16:28:18 EST(-0500)] <everettz> anastasiac: Are those examples using the new keystrokes?
[16:28:36 EST(-0500)] <anastasiac> no: to try the different keystrokes, you can go here:
[16:28:46 EST(-0500)] <everettz> Justin_o: Interesting, I would still say that it will be a bit confusing and cause usability issues.
[16:28:50 EST(-0500)] * anastasiac searches
[16:28:59 EST(-0500)] <anastasiac> http://build.fluidproject.org/fluid/sample-code/reorderer/image-reorderer/image-reorderer.html
[16:29:32 EST(-0500)] <Justin_o> everettz: good news is that the keys are customizable, this may be something that we have to investigate more though
[16:30:35 EST(-0500)] <everettz> Justin_o: Glad it's not my job to find keystrokes that aren't taken
[16:31:03 EST(-0500)] <Justin_o> fj4000: the themed tabs example in the springboards is broken in ff2
[16:31:37 EST(-0500)] <fj4000> i dont have ff2....can you send me a screenshot?
[16:31:49 EST(-0500)] <Justin_o> everettz: i know... it's an up hill battle
[16:32:51 EST(-0500)] <Justin_o> I sent it on IM
[16:33:15 EST(-0500)] <everettz> anastasiac: Are the images on that example page arranged vertically, horizontally or in a grid?
[16:33:49 EST(-0500)] <everettz> Justin_o: FYI, I should be available Tue. Dec. 16 for informal meeting anytime after 11am
[16:33:50 EST(-0500)] <anastasiac> everettz, they're in a linear list in the mark-up, that flows around in a grid visually
[16:34:16 EST(-0500)] <anastasiac> so it looks like a grid, but if you move to the right of the rightmost item on a line, you end up on the first item of the next line
[16:34:27 EST(-0500)] <anastasiac> does that make sense?
[16:34:35 EST(-0500)] <everettz> anastasiac: And what do ijkm do?
[16:34:47 EST(-0500)] <Justin_o> everettz: sounds good... i'll be in the fluid room here at the atrc until about 4pm that day...
[16:35:01 EST(-0500)] <Justin_o> so i can meet with you whenever is convenient
[16:35:09 EST(-0500)] <anastasiac> the letters should map to the directions in which they are spatially arranged on the keyboard
[16:35:21 EST(-0500)] <anastasiac> so I is up, m is down, j is to the left, k is to the right
[16:36:56 EST(-0500)] <everettz> anastasiac: So if I understand correctly using the keys alone should navigate and using them with control should perform the reorder in the given direction?
[16:37:19 EST(-0500)] <anastasiac> right, everettz
[16:38:39 EST(-0500)] <everettz> anastasiac: This will be an interesting learning curve for most screenreader users. It appears that you are doing a 2 dimentional reorder here. Is there a 1D example?
[16:38:59 EST(-0500)] <anastasiac> yes, try this link:
[16:39:09 EST(-0500)] <anastasiac> http://build.fluidproject.org/fluid/sample-code/reorderer/todo-list/sortable-styled-todo-list.html
[16:39:13 EST(-0500)] <anastasiac> this is a vertical list
[16:39:38 EST(-0500)] <anastasiac> the i and m keys should work
[16:42:10 EST(-0500)] <everettz> anastasiac: Well in IE7 with JAWS10 the 2d example works really well. Looks like the widget grabs the keystroke for control + J before it gets to the handler for openning up the rss reader.
[16:42:43 EST(-0500)] <anastasiac> in the 2d example, I wouldn't expect control + j to do anything
[16:43:00 EST(-0500)] <everettz> anastasiac: It is a bit disorientating to a screen-reader user to be able to move past the beginning of the list to the end. It would be nice if there was a stop at each end.
[16:43:21 EST(-0500)] <anastasiac> that's good input.
[16:43:34 EST(-0500)] <anastasiac> we've had varying advice from varying groups
[16:45:07 EST(-0500)] <everettz> anastasiac: I'm thinking that this might be nice to use in an RSS reader I will be working on for Credibility2.0, to allow users to reorder categories and feeds. The stop at the beginning and end would be valuable there.
[16:45:32 EST(-0500)] <everettz> anastasiac: But, perhaps it's something that one could get accustomed to given time.
[16:45:54 EST(-0500)] <anastasiac> it's actually something that should probably be configurable
[16:46:34 EST(-0500)] <anastasiac> I think the reasoning behind the wrapping function was to avoid the annoyance of arrowing all the way down the list, and then having to arrow all the way back up
[16:48:32 EST(-0500)] <everettz> anastasiac: I agree that that is a benefit of the wrapping. Perhaps an option set by the person implementing the widget, not the end-user.
[16:48:46 EST(-0500)] <anastasiac> yes, that's what I was thinking of
[16:53:57 EST(-0500)] <everettz> anas: The Conference Planning example is not working in IE7 with J10. It is working in FF3.1b2 with J9. Should I be able to reorder the second level of the tree, or only the first level of tree items?
[16:55:04 EST(-0500)] <anastasiac> only the first level
[16:55:38 EST(-0500)] <anastasiac> sorry folks, I'm going to have to sign off for the evening
[16:55:47 EST(-0500)] <anastasiac> have a good night, all!
[16:56:08 EST(-0500)] * anastasiac (n=team@142.150.154.160) has left #fluid-work
[16:58:55 EST(-0500)] <Justin_o> i'm off too, good night
[16:59:03 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[17:01:55 EST(-0500)] * apetro_ (n=apetro@12.164.139.7) has joined #fluid-work
[17:45:06 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:53:08 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[19:04:31 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[19:29:23 EST(-0500)] * jessm_ (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[21:40:37 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined #fluid-work
[22:43:21 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
Unknown macro: { ... }
Unknown macro: {isEditing = true;}
Unknown macro: {isEditing = false;}
Unknown macro: {return isEditing;}
Manage space
Manage content
Integrations