fluid-work IRC Logs-2010-04-01

[19:25:31 EDT(-0400)] <colinclark> Instead, it just causes the current lifecycle phase to hang around indefinitely
[19:26:01 EDT(-0400)] <michelled> oh, so it finally works the way I had originally thought it worked
[19:26:13 EDT(-0400)] <colinclark> So, our canonical use case is Table of Contents, where we're calling stop() in setup, instantiating the component, then calling start() again in an afterRender listener
[19:26:15 EDT(-0400)] <colinclark> That seems to be the case
[19:26:25 EDT(-0400)] <colinclark> There is one possible explanation for this...
[19:26:48 EDT(-0400)] <colinclark> Awhile ago Jorn added support for "modules" with real lifecycle function, but I don't know that we actually use them
[19:26:50 EDT(-0400)] <colinclark> I'll have to check
[19:27:04 EDT(-0400)] <colinclark> no, indeed we do
[19:27:11 EDT(-0400)] <colinclark> So, yeah.
[19:27:18 EDT(-0400)] <colinclark> stop() doesn't stop across lifecycle phases
[19:27:28 EDT(-0400)] <colinclark> It's sort of interesting...
[19:27:44 EDT(-0400)] <colinclark> It means you have to really be testing asynchrony for it to be useful
[19:28:05 EDT(-0400)] <colinclark> If you're just testing that a template is loaded, it should be equally accurate to just set the global AJAX options to be synchronous
[19:28:16 EDT(-0400)] <colinclark> And if you're really testing asynchrony, you must have some sort of callback available to the test
[19:28:20 EDT(-0400)] <colinclark> I don't know if I'm being sane
[19:28:27 EDT(-0400)] <colinclark> Or just rationalizing a bug
[19:28:35 EDT(-0400)] <colinclark> thoughts, michelled?
[19:29:09 EDT(-0400)] <michelled> well, if I understand it, now you need to call stop after your ajax call and start in the success callback (or fail I guess) of the ajax call
[19:29:40 EDT(-0400)] <colinclark> michelled: Yeah, more or less
[19:29:54 EDT(-0400)] <michelled> but in all of our use of ajax in tests I think it makes sense to just be synchronous
[19:30:11 EDT(-0400)] <michelled> it's not really our business to be testing jQuery's ajax
[19:31:23 EDT(-0400)] <colinclark> yeah
[19:31:33 EDT(-0400)] <colinclark> I guess I'm just imagining some bit of behaviour that happens in a timeout
[19:31:35 EDT(-0400)] <colinclark> like an animation
[19:31:37 EDT(-0400)] <colinclark> still hard to test
[19:31:41 EDT(-0400)] <colinclark> but i guess it always was
[19:31:58 EDT(-0400)] <colinclark> hence my stupid subvertAnimations() utility
[20:00:31 EDT(-0400)] * jhung doing Decapod QA
[20:16:08 EDT(-0400)] <jhung> I vote that Decapod be changed to be Isopod: http://www.treehugger.com/files/2010/03/cthulhu-pet-giant-isopod-photos-sea-monster-reddit-attached-underwater-robot.php
[22:41:34 EDT(-0400)] * tmbdev (~tmb@c-24-23-181-27.hsd1.ca.comcast.net) has joined #fluid-work
[23:31:57 EDT(-0400)] * mpcutter (~michael@iupr-48-018.informatik.uni-kl.de) has joined #fluid-work
[23:33:23 EDT(-0400)] * jhung (~decapod@H253.C203.cci.switchworks.net) has left #fluid-work
[02:23:10 EDT(-0400)] * Bosmon7 (~a@cpc2-cmbg15-2-0-cust770.5-4.cable.virginmedia.com) has joined #fluid-work
[02:24:21 EDT(-0400)] * joost (~joost@dfki-113.dfki.uni-kl.de) has joined #fluid-work
[03:42:39 EDT(-0400)] * thomas____ (~thomasain@213.246.129.247) has joined #fluid-work
[08:04:28 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[08:21:01 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[08:30:21 EDT(-0400)] * colinclark (~colin@bas2-toronto09-1176131835.dsl.bell.ca) has joined #fluid-work
[08:37:28 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[08:39:39 EDT(-0400)] * jhung (~Jon@H253.C203.cci.switchworks.net) has joined #fluid-work
[09:16:54 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:21:33 EDT(-0400)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[09:33:08 EDT(-0400)] <jhung> jessm: ping
[09:33:28 EDT(-0400)] <jessm> jhung: pong
[09:34:03 EDT(-0400)] <jhung> Can you help take a look over the "Planned Improvements" section here: http://wiki.fluidproject.org/display/fluid/Decapod+0.3+Release#Decapod0.3Release-PlannedImprovements
[09:34:33 EDT(-0400)] <jhung> We can chat over some of them when Michelle is online too.
[09:34:51 EDT(-0400)] <jessm> jhung: sure
[09:54:03 EDT(-0400)] * clown (~clown@142.150.154.101) has joined #fluid-work
[09:54:29 EDT(-0400)] * jhung1 (~Jon@H110.C192.cci.switchworks.net) has joined #fluid-work
[09:55:15 EDT(-0400)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[09:58:09 EDT(-0400)] <jessm> jhung: looks good to me
[09:58:17 EDT(-0400)] <jessm> jhung: can we send it to list to get feedback?
[10:00:03 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[10:02:59 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[10:36:46 EDT(-0400)] * yura1 (~yura@142.150.154.101) has joined #fluid-work
[10:37:03 EDT(-0400)] * 14WAAGC97 (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[10:42:20 EDT(-0400)] * joost (~joost@dfki-113.dfki.uni-kl.de) has left #fluid-work
[10:42:42 EDT(-0400)] * 50UAAIAVI (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[10:47:44 EDT(-0400)] * michelled_ (~michelled@142.150.154.141) has joined #fluid-work
[11:05:45 EDT(-0400)] <anastasiac> jamon, have you seen today's xkcd.com?
[11:14:36 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[11:15:00 EDT(-0400)] <colinclark> 50UAAIAVI: Nice nick, Kasper!
[11:15:06 EDT(-0400)] <jhung> jessm: Yep. We can send it to the list for feedback.
[11:15:12 EDT(-0400)] <colinclark> jhung: michelled_ thinks she's tracked it down already
[11:15:18 EDT(-0400)] <jhung> yeah?
[11:15:37 EDT(-0400)] <colinclark> Looks like perhaps it crept in at r "14"
[11:15:43 EDT(-0400)] <colinclark> air quotes intentiona
[11:15:48 EDT(-0400)] <colinclark> I just don't speak hex so well yet
[11:15:54 EDT(-0400)] <colinclark>
[11:18:38 EDT(-0400)] <50UAAIAVI> colinclark:
[11:18:51 EDT(-0400)] <colinclark>
[11:21:09 EDT(-0400)] <colinclark> jhung: yep, she's got it
[11:21:13 EDT(-0400)] <colinclark> genius!
[11:21:15 EDT(-0400)] <colinclark>
[11:27:20 EDT(-0400)] <michelled_> ok, so the issue is two fold. it looks like the genpdf script expects us to pass the -t flag for the type of pdf to output. if it's not passed it throws and error
[11:27:36 EDT(-0400)] <jhung> okay...
[11:27:40 EDT(-0400)] <michelled_> the second issue is the integration between the server and the script - the server does not pass -t
[11:27:56 EDT(-0400)] <michelled_> so, jhung, as release manager - is this a blocker?
[11:28:01 EDT(-0400)] * michelled_ votes yes
[11:28:13 EDT(-0400)] * jhung votes aye.
[11:28:17 EDT(-0400)] * colinclark votes "wicked!"
[11:28:40 EDT(-0400)] <jhung> groovy. Let's file a blocker and get this fixed.
[11:28:47 EDT(-0400)] <jhung> mpcutter: you around?
[11:29:26 EDT(-0400)] <michelled_> jhung: do you mind filing it and giving me the number?
[11:29:34 EDT(-0400)] <jhung> k.
[11:31:40 EDT(-0400)] <jhung> michelled: is the documentation updated to reflect that -t is mandatory?
[11:32:00 EDT(-0400)] <jhung> re: RUNNING.TXT file
[11:32:24 EDT(-0400)] <colinclark> jhung: michelled_ mentioned to me that she thinks it shouldn't be mandatory, but instead the pdf gen script should provide a good default
[11:32:33 EDT(-0400)] <jhung> agreed.
[11:32:33 EDT(-0400)] <michelled_> yes, that's what it should be
[11:32:48 EDT(-0400)] <michelled_> I think I'll default it to 1 which is the image pdf
[11:33:19 EDT(-0400)] <jhung> I thought this was always the case? It was like that in version "11".
[11:33:39 EDT(-0400)] <jhung> I recall joost making a modification that defaulted to -t1 while it was t3 before.
[11:33:54 EDT(-0400)] <colinclark> jhung: Standup, btw
[11:39:04 EDT(-0400)] <jhung> michelled_ : DECA-92
[11:48:41 EDT(-0400)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[12:05:00 EDT(-0400)] <colinclark> michelled_, yura1: http://rue.caret.cam.ac.uk/cspace
[12:05:35 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[12:20:56 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[12:40:24 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[12:44:43 EDT(-0400)] <jhung> michelled_: any update on Deca 92?
[12:45:13 EDT(-0400)] <michelled_> jhung: I've been in meetings since standup
[12:45:27 EDT(-0400)] <michelled_> I'll let you know when I get working on it
[12:45:48 EDT(-0400)] <jhung> when will that be?
[12:47:35 EDT(-0400)] <michelled_> I'm not sure how long this meeting will be
[12:47:44 EDT(-0400)] <michelled_> I'm guessing 1:00
[12:47:54 EDT(-0400)] <jhung> ok.
[12:48:02 EDT(-0400)] <colinclark> hey justin_o:
[12:48:11 EDT(-0400)] <colinclark> we're gonna chat with athena at 1 pm if that works for you instead of 2 pm
[12:48:23 EDT(-0400)] <justin_o> colinclark: sure
[12:51:06 EDT(-0400)] <jhung> jessm: is it assumed we're supporting Orca screen reader for Decapod? It's not explicit in the grant.
[12:51:30 EDT(-0400)] <jessm> jhung: you're right, screen readers aren't even mentioned in the grant
[12:52:09 EDT(-0400)] <jessm> i'm not sure we have a commitment to anything explicitly, though we as a community certainly have a commitment to making it accessible
[12:52:28 EDT(-0400)] <jessm> jhung: i'm hoping you and jameswy can do some work together in that area?
[12:53:04 EDT(-0400)] <jhung> Absolutely. I actually tried to get Orca running for this release but couldn't get it running properly.
[13:01:25 EDT(-0400)] * athena waves to colinclark and justin_o
[13:01:34 EDT(-0400)] <colinclark> athena: hey
[13:01:38 EDT(-0400)] <colinclark> i'm still stuck in a meeting
[13:01:43 EDT(-0400)] <justin_o> hello
[13:01:46 EDT(-0400)] <athena> ok!
[13:01:47 EDT(-0400)] <colinclark> can you guys start and loop me in when it ends
[13:01:48 EDT(-0400)] <colinclark> ?
[13:01:56 EDT(-0400)] <athena> sounds fine to me
[13:01:58 EDT(-0400)] <justin_o> sure
[13:02:04 EDT(-0400)] <athena> do you still want to meet here or switch to skype?
[13:02:44 EDT(-0400)] <justin_o> athena: either works fine for me... but i guess we can try to start here and see how it goes
[13:02:50 EDT(-0400)] <athena> sure
[13:03:04 EDT(-0400)] <athena> so i think you've probably already heard the use case, but just for completeness
[13:03:35 EDT(-0400)] <athena> the basic issue is that we'd like users to be able to easily move a portlet to another "tab" (basically like a page in the portal)
[13:03:52 EDT(-0400)] <athena> users can happily drag content around on the page right now, and all that works wonderfully
[13:04:23 EDT(-0400)] <athena> but it'd be even cooler if they could drag the item over a tab, and if they let go the item would be moved to that tab
[13:04:50 EDT(-0400)] <athena> the backend of that is all pretty straightforward, but i wasn't quite sure how to do that w/ the reorderer
[13:04:58 EDT(-0400)] <justin_o> athena: oh that's interesting
[13:05:32 EDT(-0400)] <athena> it's a bit different than the general reordering case, because you're sort of putting an item into an element, at which point we strip it off the page, rather than putting it before or after an element
[13:05:51 EDT(-0400)] <justin_o> athena: yes...
[13:06:04 EDT(-0400)] <justin_o> i suppose this isn't quite reordering exactly
[13:06:12 EDT(-0400)] <athena> right
[13:06:24 EDT(-0400)] <athena> though i guess it shares some similar features
[13:06:31 EDT(-0400)] <justin_o> athena: yes
[13:06:40 EDT(-0400)] <athena> we could probably hack something in, but i'd hate to break the keyboard functionality, among other concerns
[13:07:04 EDT(-0400)] <justin_o> athena: yes... that's true... so you'd want to be able to use the keyboard to move it there as well...
[13:07:04 EDT(-0400)] <athena> it's been near the top of the cooperative development queue for a couple months now though, so we do need to do something
[13:07:15 EDT(-0400)] <athena> right
[13:07:27 EDT(-0400)] <justin_o> athena: are there wireframes for this interaction by any chance?
[13:07:37 EDT(-0400)] <athena> hm, no
[13:07:56 EDT(-0400)] <athena> i'm not even sure what a wireframe for such an interaction would look like
[13:08:00 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:08:05 EDT(-0400)] <justin_o>
[13:08:10 EDT(-0400)] * athena is not a wireframe person
[13:08:54 EDT(-0400)] <athena> in my head, to a user it'd look exactly the same as dragging content around to perform reordering
[13:09:19 EDT(-0400)] <justin_o> yes... and then when it is placed on a tab, you'd want them to be able to drop it inside of it
[13:09:27 EDT(-0400)] <athena> except if you dragged it over a tab and release it, instead of the item being moved it would just disappear in a poof of magic and then would be on the other page when you clicked on it
[13:09:30 EDT(-0400)] <justin_o> and then you'd pick some default location to place it in there yourself
[13:09:31 EDT(-0400)] <justin_o> ?
[13:09:35 EDT(-0400)] <athena> yep
[13:09:50 EDT(-0400)] <athena> we'd probably put it at the top-most allowed location, or something like that (like we do with new content)
[13:10:26 EDT(-0400)] <athena> one interesting question about the keyboard interaction, i guess:
[13:11:12 EDT(-0400)] <athena> is it currently the case that when you move an item w/ the keys the item moved callback is executed on each little move over one element, or is it only when the control key is released?
[13:12:31 EDT(-0400)] <justin_o> hmm... not exactly sure... i should be able to make a quick test to verify that, but i would imagine it would be on each movement
[13:12:54 EDT(-0400)] <athena> i think that's correct, which would be a little bit of an issue w/ this kind of interaction
[13:13:16 EDT(-0400)] <athena> since you wouldn't want it to be moved to another tab immediately, since that would mean it'd be hard to jump over to the tab you actually wanted
[13:13:19 EDT(-0400)] <athena> if that makes any sense
[13:13:52 EDT(-0400)] <colinclark> I think the Reorderer could probably do this as-is
[13:14:04 EDT(-0400)] <colinclark> So there's a separation of drop targets from things that can be moved
[13:14:17 EDT(-0400)] <colinclark> And so the tabs could effectively be a column filled with drop targets that aren't moveables
[13:14:29 EDT(-0400)] <athena> awesome, i was hoping something like that would make sense
[13:14:36 EDT(-0400)] <colinclark> I guess the biggest problem is, as athena says, the keyboard interaction might get odd
[13:14:48 EDT(-0400)] <colinclark> Since they'd all have to live in the same Reordererable container
[13:14:52 EDT(-0400)] <colinclark> Within that, there'd be columns
[13:15:00 EDT(-0400)] <athena> so it'll be ok that the targets are sort of things you drop into instead of drop before and after?
[13:15:11 EDT(-0400)] <colinclark> athena: hmm
[13:15:12 EDT(-0400)] <colinclark> good point
[13:15:26 EDT(-0400)] <colinclark> That'd involve some experimentation, I think
[13:15:51 EDT(-0400)] <athena> we'd of course need to suppress the preview of the item in the tabs bar as well - maybe do something to highlight the current tab, or something like that
[13:15:54 EDT(-0400)] <justin_o> athena: the onMove is called on each movement with the keyboard
[13:15:58 EDT(-0400)] <athena> but i'd hope that could be handled via some css magic
[13:16:06 EDT(-0400)] <colinclark> athena: I think it could
[13:16:20 EDT(-0400)] <athena> so i think the onMove w/ the keyboard sounds like the biggest issue
[13:16:26 EDT(-0400)] <colinclark> If it didn't I guess we could probably work on some extension to the Geometric Manager to support it all
[13:16:29 EDT(-0400)] <athena> is there some sort of "user is done moving stuff around" event?
[13:16:39 EDT(-0400)] <justin_o> colinclark, athena: I think we may end up running into a problem with the way the reorderer allows you to drop something anywhere on the screen... and it just picks what it thinks is best
[13:16:47 EDT(-0400)] <justin_o> we also have a bug if the columns overlap...
[13:16:52 EDT(-0400)] <justin_o> one going above the other
[13:16:52 EDT(-0400)] <colinclark> you might be right, yes
[13:17:07 EDT(-0400)] <athena> hm, interesting
[13:17:21 EDT(-0400)] <athena> so it might be an issue that the tabs bar is horizontal above the vertical columns?
[13:17:56 EDT(-0400)] <justin_o> athena: yes... if we were to think of the tabs being seperate columns
[13:18:09 EDT(-0400)] <athena> gotcha
[13:19:27 EDT(-0400)] <justin_o> i'm kind of wishing our designers weren't all out for lunch... i'm worried that we have an interaction that says in one case you are moving things between items, and then another where you are moving them into items
[13:20:36 EDT(-0400)] <athena> yeah, it is conceptually a bit different
[13:20:57 EDT(-0400)] <justin_o> yah.. i'm still trying to wrap my head around how a user would interact with this...
[13:21:07 EDT(-0400)] <jhung> jessm: I have rephrased the "Planned Improvements" bit to be less affirmative. Gives us wiggle room to change plans if needed.
[13:21:09 EDT(-0400)] <athena> and i suspect we could invent some convention wherein we declare that if you move something after an item, it really means that you're trying to move it into that item, specifically for the tabs column
[13:21:18 EDT(-0400)] <athena> but i'm not sure if that's actually a wise thing to do
[13:21:21 EDT(-0400)] <jessm> jhung: smart move
[13:21:35 EDT(-0400)] <justin_o> athena: agreed
[13:21:51 EDT(-0400)] <jessm> jhung: you're really talking mostly to the IUPRers with that list – it won't really be digestible to non-techies
[13:22:10 EDT(-0400)] <justin_o> athena: also for you as an integrator... i have a question
[13:22:21 EDT(-0400)] <justin_o> so currently all our components are constrained to a container
[13:22:21 EDT(-0400)] <athena> sure
[13:22:40 EDT(-0400)] <justin_o> how do you feel about having the reorderer wrapping the tabs and the portlets
[13:22:51 EDT(-0400)] <athena> i don't think that'll be a problem
[13:22:55 EDT(-0400)] <jhung> jessm: true. Everything about this release is very technical. Hoepfully that will change over releases.
[13:23:04 EDT(-0400)] <justin_o> athena: okay.. good... just wanted to check.. cause i wasn't sure
[13:23:18 EDT(-0400)] <athena> the current container w/ all the portlets is most of the page anyway
[13:23:34 EDT(-0400)] <justin_o> right..
[13:23:44 EDT(-0400)] <athena> and actually i think in the next release we're going to refactor all of our layout editing code to be a fluid component that has a bunch of subcomponent
[13:23:54 EDT(-0400)] <athena> rather than the current random collection of spagghetti methods
[13:24:05 EDT(-0400)] <athena> as tasty as spaghetti is
[13:24:18 EDT(-0400)] <justin_o>
[13:24:33 EDT(-0400)] <athena> javascript will likely get more interesting in general in the next release
[13:24:42 EDT(-0400)] <athena> Spring 3.0 includes a bunch of really cool REST stuff
[13:24:51 EDT(-0400)] <justin_o> athena: when is that next release scheduled for?
[13:24:55 EDT(-0400)] <athena> so we'll be moving our ad-hoc target services over to REST as well
[13:24:58 EDT(-0400)] <athena> not imminent?
[13:25:24 EDT(-0400)] <athena> though i think we're hoping for a milestone in the next month or so - something that can at least do basic rendering of a JSR-286 portlet
[13:25:31 EDT(-0400)] <justin_o> okay... kind of wondering when you'll need this reordering functionality for
[13:25:39 EDT(-0400)] <athena> not like tomorrow or anything
[13:26:04 EDT(-0400)] <justin_o> athena: so i can stop panicing
[13:26:08 EDT(-0400)] <athena> uportal users would probably be happiest if we found a way to make it work with existing fluid versions so that we can add it to the maintenance branches of portlets
[13:26:12 EDT(-0400)] <athena> but no, no panicking required
[13:26:27 EDT(-0400)] <athena> i generally don't recommend panicking anyway
[13:27:05 EDT(-0400)] <justin_o> athena: jessm has a rule for no bleeding and crying in fluid, not sure what her rules about panicing are
[13:27:30 EDT(-0400)] <athena> lol
[13:27:34 EDT(-0400)] <athena> those are good rules
[13:27:36 EDT(-0400)] <jessm> justin_o: it's a harder one, but yes, no panicking!
[13:28:02 EDT(-0400)] <justin_o> jessm: okay.. i'll make sure i stop doing that as well...
[13:28:06 EDT(-0400)] <athena> a former boss of mine was asked once "is it time to panic yet?" and he answered that "no, it is never time to panic"
[13:28:07 EDT(-0400)] <athena>
[13:28:21 EDT(-0400)] <justin_o>
[13:28:41 EDT(-0400)] <jessm> if it's not a baby in a hot car, then don't panic
[13:28:47 EDT(-0400)] <athena> i sort of hope the "no bleeding" rule doesn't actually come up that much
[13:29:04 EDT(-0400)] <justin_o> athena: so i guess the what we should try to do first is assess if it is possible to get this interaction without having to change any of our code...
[13:29:05 EDT(-0400)] <jessm> athena: it's cutting edge bleeding, mostly
[13:29:18 EDT(-0400)] <athena> lol
[13:29:21 EDT(-0400)] <athena> ok, that i get.
[13:29:33 EDT(-0400)] <justin_o> athena: colinclark once cut his finger when we were trying to open a wine bottle with a knife
[13:29:41 EDT(-0400)] <athena> oww
[13:29:57 EDT(-0400)] <justin_o> I think that was all the bleeding we've had here
[13:30:31 EDT(-0400)] <athena> i used to have a really nice waiter's knife / corkscrew, which i liked specifically because it had a tiny knife for opening foil that was unlikely to result in tradgedies
[13:31:11 EDT(-0400)] <athena> i'm more careful in the kitchen since an incident while making chowder
[13:31:15 EDT(-0400)] <colinclark> that hurt so much
[13:31:20 EDT(-0400)] <athena> i bet!
[13:31:37 EDT(-0400)] <justin_o> it actually took 3 of us to open that bottle
[13:31:44 EDT(-0400)] <athena> lol
[13:31:45 EDT(-0400)] <athena> wow.
[13:32:41 EDT(-0400)] <athena> so is the right thing to do here to just play w/ the strategy of pretending the tabs are a magical kind of column and see how bad it gets?
[13:35:42 EDT(-0400)] <justin_o> athena: to get an idea of what the issues might be like take a look at this demo
[13:35:43 EDT(-0400)] <justin_o> http://build.fluidproject.org/infusion/demos/reorderer/layoutReorderer/html/layoutReorderer.html
[13:35:53 EDT(-0400)] <justin_o> and make the screen small so that two columns overlap
[13:36:31 EDT(-0400)] <athena> ah, i see
[13:36:38 EDT(-0400)] <athena> so the keyboard reorderer gets trapped?
[13:36:43 EDT(-0400)] <justin_o> athena: yes
[13:36:46 EDT(-0400)] <athena> ok
[13:36:51 EDT(-0400)] <athena> yeah i guess that'd be an issue
[13:37:34 EDT(-0400)] <justin_o> and the mouse dropping is a bit of a problem too.. probably since one of the columns steals the drop zone from the other
[13:37:53 EDT(-0400)] <athena> interesting
[13:38:01 EDT(-0400)] <athena> ok, yeah, that all sounds like potential issues
[13:38:24 EDT(-0400)] <athena> is that anything you guys have planned to address, or are there reasons why it's really hard to fix?
[13:39:06 EDT(-0400)] <michelled_> jhung: so far not so good. I'm getting a different error in the script now. 'no such file or directory tmpdir' and if I create 'tmpdir' before running I get the error 'tmpdir already exists - please choose another directory'
[13:39:14 EDT(-0400)] <michelled_> any sign of mpcutter?
[13:39:25 EDT(-0400)] <justin_o> athena: it has come up in the past... i'm not sure how hard it is for fixing, but i'm guessing that it has mostly been a lower priority... since these cases weren't expected to happen too often
[13:39:30 EDT(-0400)] <athena> yeah
[13:39:31 EDT(-0400)] <athena> makes sense
[13:39:56 EDT(-0400)] <justin_o> however your use case would really expose that
[13:40:07 EDT(-0400)] <athena> does the reorderer have a concept of horizontal ordering rather than vertical?
[13:40:17 EDT(-0400)] <michelled_> jhung: I think I either need a lot more time or I need mpcutter to look at this bug
[13:40:25 EDT(-0400)] <justin_o> athena: yes
[13:40:30 EDT(-0400)] <justin_o> you can set the orientation
[13:40:37 EDT(-0400)] <athena> but it just needs to be one of hte other?
[13:40:38 EDT(-0400)] <justin_o> with grids it is both directions
[13:40:52 EDT(-0400)] <michelled_> jhung: unless you were able to run the pdf generator from the command line? maybe there is a different set of options that would work
[13:41:21 EDT(-0400)] <justin_o> athena: so from that example i sent you.. you can see that you can move within a column up and down and across columns horizontally
[13:41:40 EDT(-0400)] <athena> yeah
[13:42:05 EDT(-0400)] <athena> was just wondering if it could be configured for horizontal columns, which it sounds like it can
[13:42:35 EDT(-0400)] <justin_o> i guess... although do you mean to move horizontally within a single column... that i'm not sure of
[13:42:41 EDT(-0400)] <justin_o> at least we don't have an example of that
[13:43:08 EDT(-0400)] <athena> gotcha
[13:44:28 EDT(-0400)] <jhung> michelld_: sorry. My IRC isn't making noises.
[13:44:40 EDT(-0400)] <jhung> ok. I'll give it a try using command line
[13:48:58 EDT(-0400)] * jhung (~Jon@H110.C192.cci.switchworks.net) has left #fluid-work
[13:49:27 EDT(-0400)] * jhung (~Jon@H110.C192.cci.switchworks.net) has joined #fluid-work
[13:49:31 EDT(-0400)] <colinclark> athena: I wonder if a next step might be to see if Gary has a spare cycle or two to sketch out the interaction
[13:50:01 EDT(-0400)] <colinclark> I guess, ultimately, this might represent an opportunity to factor out a bit more of the Reorderer's core logic and to build something from the pieces
[13:50:14 EDT(-0400)] <colinclark> Is that roughly your impression, justin_o?
[13:50:35 EDT(-0400)] <justin_o> colinclark: yes... i think so
[13:51:00 EDT(-0400)] <athena> yeah, i'll check and see if he's got some time
[13:51:18 EDT(-0400)] <athena> though i think his time has a platinum equivalency
[13:51:45 EDT(-0400)] <athena> i think the interaction from the mouse should really be fairly straightforward
[13:51:57 EDT(-0400)] <athena> but maybe it's less so from the keyboard, especially when you take direction into account
[13:52:03 EDT(-0400)] * jhung1 (~decapod@H110.C192.cci.switchworks.net) has joined #fluid-work
[13:52:07 EDT(-0400)] * jhung (~Jon@H110.C192.cci.switchworks.net) has left #fluid-work
[13:53:13 EDT(-0400)] <jhung1> michelled_ works in command line "decapod-genpdf.py -t 1 -b multi-page.tiff -d ./temp -p mypdf.pdf"
[13:53:28 EDT(-0400)] <jhung1> output is not very pretty though. Will try a different book.
[13:54:27 EDT(-0400)] <colinclark> athena: I sort of wonder if it isn't a totally different interaction for the keyboard
[13:54:37 EDT(-0400)] <colinclark> Currently, we use a kind of "swapping" metaphor
[13:54:44 EDT(-0400)] <colinclark> whereas this is much more like traditional drag and drop
[13:55:03 EDT(-0400)] <jhung1> michelled_ I don't think we can fix this. The output looks worse than it was in v11.
[13:55:12 EDT(-0400)] <jhung1> It's not even legible.
[13:55:14 EDT(-0400)] <colinclark> Where you've got a thing and a target, and spatially they could have very distant relationships where everything in between is sort of irrelevant
[13:55:17 EDT(-0400)] <athena> yeah
[13:55:22 EDT(-0400)] <colinclark> This is pretty fascinating
[13:55:33 EDT(-0400)] <athena> this might have more in common w/ the standard dragging demo of dropping something into a container
[13:55:34 EDT(-0400)] <colinclark> I wonder if jameswy might also have some thouhts
[13:55:42 EDT(-0400)] <colinclark> yep
[13:56:39 EDT(-0400)] <colinclark> justin_o: Can I merge my working FLUID-3577 branch?
[13:57:05 EDT(-0400)] <justin_o> colinclark: yes please...
[13:57:31 EDT(-0400)] <jhung1> michelled_ I think we're going to have to cut a different tag.
[13:57:45 EDT(-0400)] <jhung1> go back to v11. We know that works.
[13:58:32 EDT(-0400)] <athena> ok colinclark and justin_o - i think i'm going to disappear for a bit
[13:58:39 EDT(-0400)] <athena> i'll be back later this afternoon though
[13:58:45 EDT(-0400)] <colinclark> cool
[13:58:52 EDT(-0400)] <athena> thanks for all the good conversation - we'll definitely have to follow up
[13:59:38 EDT(-0400)] <colinclark>
[14:01:05 EDT(-0400)] <michelled_> you know, I think you're right
[14:01:09 EDT(-0400)] <michelled_> jhung1 ^
[14:02:12 EDT(-0400)] <jhung1> let's skype.
[14:02:39 EDT(-0400)] <michelled_> k
[14:05:14 EDT(-0400)] <justin_o> athena: thanks
[14:06:56 EDT(-0400)] <michelled_> jessm: do you have time to talk to us?