fluid-work IRC Logs-2013-08-16

Owned by Fluid IRC Log Bot
Last updated: Aug 16, 2013
11 min read

[09:59:26 CDT(-0500)] <jhung> vjoanna: If the buttons in the discovery tool do not fit horizontally in the panel, what should happen?

[10:03:44 CDT(-0500)] <vjoanna> jhung: they scroll horizontally, similar to uio but without the next/previous buttons

[10:05:40 CDT(-0500)] <jhung> So a default horizontal scroller bar is acceptable?

[10:11:36 CDT(-0500)] <vjoanna> jhung: yes, and if it possible to have it styled to match the panel

[10:17:06 CDT(-0500)] <jhung> vjoanna: default scroll bars can't be styled. We'd have to use something else in that case. The easiest solution would be just to use default styling but it will lack theming. Justin_o what do you think?

[10:17:51 CDT(-0500)] <jhung> Justin_o: currently if you shrink the browser window and/or enlarge, the DT buttons can wrap at the edge of the panel. We want a horizontal scroll to appear instead.

[10:19:55 CDT(-0500)] <Justin_o> jhung: http://stackoverflow.com/questions/9251354/css-customized-scroll-bar-in-div/14150577#14150577

[10:20:24 CDT(-0500)] <Justin_o> jhung: agree that the default would be the easiest (smile)

[10:21:51 CDT(-0500)] <jhung> Justin_o: perhaps we'll go with default implementation and if there's time we'll try to theme webkit version for contrast modes?

[10:22:36 CDT(-0500)] <Justin_o> vjoanna: are you okay with that? we don't actually theme any of the scrollbars with UIO so this would be consistent.

[10:26:14 CDT(-0500)] <vjoanna> justin_o, jhung: sure, i'll bring it up again later (wink)

[10:33:32 CDT(-0500)] <jhung> vjoanna: I'll be sure to file 2 jira - one for implementation of a scroller, and one for styling. (smile)

[10:34:05 CDT(-0500)] <vjoanna> thanks, jhung!

[10:43:55 CDT(-0500)] <jhung> fluid-everyone: My mic wasn't working during our check-in meeting so I will give my update here. I've made 2 pull requests - GPII-157 (Simplify styling) and GPII-133 (IE icon fixes). Also filed new jiras for other IE related bugs and will put them on the iteration page. Been talking about horizontal scrollers for DT and will add those to the iteration page once jiras are in. Also my last day today before 1 week vacation - so I will likely do testing today

[11:12:15 CDT(-0500)] <Justin_o> anastasiac: would you like to pair up on fixing up this wiki page today or sometime next week? http://wiki.fluidproject.org/display/fluid/Proposal+-+New+UIO+API

[11:12:33 CDT(-0500)] <anastasiac> Justin_o, how about next week?

[11:12:38 CDT(-0500)] <anastasiac> Justin_o, while we're on the subject...

[11:12:39 CDT(-0500)] <Justin_o> anastasiac: sounds good

[11:13:06 CDT(-0500)] <anastasiac> I noticed while updating the video player to the latest Infusion that the implemented API for UIO has drifted away from our goals

[11:13:15 CDT(-0500)] <anastasiac> primarily, the goal of having all options at the top level

[11:13:32 CDT(-0500)] <anastasiac> currently, the integrator needs to know about different subcomponents, and which options to pass to which

[11:13:35 CDT(-0500)] <anastasiac> that makes it complicated

[11:13:56 CDT(-0500)] <anastasiac> Justin_o, do we still have a desire to implement a simpler API? Or is what we have now going to be it?

[11:14:07 CDT(-0500)] <Justin_o> anastasiac: are you trying with the latest from master, because we did make some changes just before it got merged?

[11:14:28 CDT(-0500)] <anastasiac> Justin_o, actually, I was trying it last week, so I'll have another look

[11:15:27 CDT(-0500)] <Justin_o> anastasiac: we were looking at the structure that chris needed to use to make changes and it was just too complicated. so we flattened it a bit..

[11:15:48 CDT(-0500)] <anastasiac> Justin_o, I'm looking at the current master gradesDemo, and yes, it does look simpler

[11:16:02 CDT(-0500)] <Justin_o> anastasiac: that's good. is it to the level you were expecting?

[11:16:28 CDT(-0500)] <anastasiac> well, you still have to know about those three subcomponents, but I'm not sure how much simpler you could get it.

[11:16:45 CDT(-0500)] <anastasiac> I'll have to give another pass at the VP, and see how that feels there

[11:16:50 CDT(-0500)] <anastasiac> next week (smile)

[11:17:09 CDT(-0500)] <anastasiac> I've got some more docs to work on for Chris first

[11:18:12 CDT(-0500)] <anastasiac> Justin_o, perhaps when we update the "proposed API" page next week, we can talk though some questions about how we might be able to simplify the API

[11:39:26 CDT(-0500)] <Justin_o> anastasiac: sounds like a good plan

[11:45:53 CDT(-0500)] <michelled> Justin_o: did we make a decision to rewrite the build scripts instead of fixing the existing building tests?

[11:46:22 CDT(-0500)] <michelled> builder, I mean

[11:47:51 CDT(-0500)] <Justin_o> michelled: um.. not really… i guess that just hasn't been done yet… the problem is that few people have the necessary setup to even work on it

[14:04:57 CDT(-0500)] <Justin_o> jhung: looking at your pull request for GPII-133

[14:05:08 CDT(-0500)] <Justin_o> jhung: how did you get it working in IE8?

[14:11:49 CDT(-0500)] <jhung> I should clarify Justin_o. It fixes IE10, but GPII-169 stops me from testing in IE8 and IE9.

[14:12:47 CDT(-0500)] <jhung> We're not supporting IE8 and IE9 correct?

[14:13:00 CDT(-0500)] <Justin_o> jhung: we're targeting latest browsers

[14:13:04 CDT(-0500)] <Justin_o> so not really

[14:13:28 CDT(-0500)] <Justin_o> jhung: it's working for me in IE9 though

[14:14:32 CDT(-0500)] <jhung> Justin_o: ok good to hear. I'll see if I'm missing an update on my branch.

[14:14:47 CDT(-0500)] <cindyli> hi Bosmon or Bosmon7

[14:14:48 CDT(-0500)] <Justin_o> jhung: okay.. some styling issues there with the checkmarks though

[14:14:59 CDT(-0500)] <Justin_o> jhung: i think i can merge your branch though

[14:15:13 CDT(-0500)] <Bosmon> Hi cindyli - thanks so much for FLUID-5117

[14:15:19 CDT(-0500)] <Justin_o> jhung: have you noticed that the discovery tool panel isn't all the way to the bottom of the page in any browser but firefox

[14:15:25 CDT(-0500)] <Bosmon> I'd seen something like this issue for a while, but had struggled to reproduce it

[14:15:33 CDT(-0500)] <cindyli> yay!

[14:15:52 CDT(-0500)] <jhung> Justin_o: yes. There's a slight gap at the very bottom.

[14:16:12 CDT(-0500)] <Justin_o> jhung: yes… has anyone filed a jira for that one yet?

[14:16:42 CDT(-0500)] <jhung> Not yet. I'll file one.

[14:16:57 CDT(-0500)] <cindyli> 5117 is what i wanted to chat with you about, Bosmon. since it seems making sense to you, … done ...

[14:17:11 CDT(-0500)] <Justin_o> jhung: thanks

[14:17:20 CDT(-0500)] <Bosmon> cindyli - yes, I had frequently seen these "mouse droppings" attached to the DOM binder

[14:17:29 CDT(-0500)] <Justin_o> jhung: anything you need to touch base on before your vacation?

[14:17:37 CDT(-0500)] <Bosmon> But in the couple of test cases I tried to make, I wasn't able to provoke it to happen

[14:18:03 CDT(-0500)] <Bosmon> I guess I will have a busy weekend with all these framework issues : P

[14:18:15 CDT(-0500)] <Bosmon> cindyli - what UIO things are you looking at today?

[14:18:25 CDT(-0500)] <cindyli> fluid-5116

[14:18:32 CDT(-0500)] <jhung> Justin_o: I don't think so. I'll just send heidiv an email before I go, but there's nothing really in progress on my end.

[14:18:39 CDT(-0500)] <Bosmon> cindyli oh yes, good

[14:19:09 CDT(-0500)] <cindyli> i'm refactoring UIO to make resourceLoader a real loader at fetching resources, which is done at this point. my next step is to get rid of uiOptionsLoader, Bosmon

[14:19:18 CDT(-0500)] <Justin_o> jhung: thanks, have a fun trip

[14:19:29 CDT(-0500)] <Bosmon> cindyli - cool - how will you be able to remove uiOptionsLoader?

[14:21:14 CDT(-0500)] <cindyli> uiOptionsLoader is in charge of loading message files and templates. Since those tasks are done by resourceLoader, uiOptionsLoader can be removed, Bosmon. once it's gone, the inline would have 3 sub components: uiOptions, templateLoader, messageLoader

[14:21:53 CDT(-0500)] <cindyli> since fat panel or full pages are instances of the inline

[14:22:09 CDT(-0500)] <Bosmon> cindyli - sounds good - can you think why we couldn't do this before?

[14:22:17 CDT(-0500)] <cindyli> the sliding panel will become a sibling of all loaders where it makes it easy to control its creation

[14:22:17 CDT(-0500)] <Bosmon> Is there some aspect of the new gingerness that helps us do this now?

[14:22:34 CDT(-0500)] <cindyli> i think yes, Bosmon

[14:27:39 CDT(-0500)] <Bosmon> cindyli - can you think what it is?

[14:29:54 CDT(-0500)] <cindyli> i just feel with all these event boiling, aggregate events and the power to simplify the declaration of invokers and listeners, things become easier.

[14:31:17 CDT(-0500)] <Bosmon> cindyli - I guess our old "3-level design" really is very old

[14:31:35 CDT(-0500)] <cindyli> time to improve it

[14:32:18 CDT(-0500)] <Bosmon> I guess it was July 2011 when we drew it up

[14:33:25 CDT(-0500)] <cindyli> good memory. ya, long time ago

[14:33:40 CDT(-0500)] <Bosmon> Well, it can easily be dated by this JIRA which you entered (smile)

[14:33:40 CDT(-0500)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-4334

[14:34:13 CDT(-0500)] <cindyli> ah ha (smile)

[14:35:35 CDT(-0500)] <Bosmon> I remember that appallingly hot summer in Toronto

[14:38:16 CDT(-0500)] <cindyli> while i sat besides you staring how you played magic with coding UIO

[14:55:42 CDT(-0500)] <Bosmon> cindyli - hardly very magical in those days

[14:55:48 CDT(-0500)] <Bosmon> With our terrible stodgy framework : P

[14:56:20 CDT(-0500)] <yzen> Bosmon:

[14:56:31 CDT(-0500)] <Bosmon> yzen!

[14:56:36 CDT(-0500)] <Bosmon> ZENE'EVICH!

[14:57:02 CDT(-0500)] <yzen> Bosmon: https://github.com/GPII/universal/pull/131 (wink)

[14:57:23 CDT(-0500)] <Bosmon> yzen - yes - we should talk about this

[14:57:33 CDT(-0500)] <yzen> oh oh

[15:11:13 CDT(-0500)] <yzen> Bosmon: what was it that you wanted to talk about ?

[15:11:27 CDT(-0500)] <Bosmon> yzen, well we should get together with colinclark in a bit

[15:34:39 CDT(-0500)] <colinclark> hey yzen, osrry

[15:34:44 CDT(-0500)] <colinclark> meetings

[15:35:04 CDT(-0500)] <colinclark> So, I wanted to bring up the question of repository modularity

[15:35:24 CDT(-0500)] <colinclark> I saw the pull requests separating out the Canopy Matchmaker from universal

[15:35:27 CDT(-0500)] <yzen> colinclark: sure

[15:35:34 CDT(-0500)] <colinclark> and I want to hear your thoughts and motivations on the idea

[15:35:49 CDT(-0500)] <colinclark> I read the channel log from two days ago where you and Bosmon briefly discussed it

[15:37:00 CDT(-0500)] <yzen> colinclark: right, so we were chatting about whether it would be beneficial to split out a certain components

[15:37:06 CDT(-0500)] <yzen> colinclark: in particular

[15:37:19 CDT(-0500)] <yzen> matchmaker, component or a specific type of a match maker

[15:37:48 CDT(-0500)] <yzen> it truly depends on just a couple of modules: kettle, transformer and ?ontology

[15:38:27 CDT(-0500)] <yzen> yet right now we are required to depend on all of universal to deal with the inclusion of multiple dependencies from the universal submodules

[15:40:14 CDT(-0500)] <yzen> colinclark: ^

[15:43:20 CDT(-0500)] <colinclark> one sec, sorry

[15:49:50 CDT(-0500)] <colinclark> Yeah

[15:49:53 CDT(-0500)] <colinclark> I see the motivation

[15:50:04 CDT(-0500)] <colinclark> I'm not quite sure how to balance it with two other factors that occur to me:

[15:51:01 CDT(-0500)] <colinclark> 1. This may lead towards "hyper modularity," which in itself isn't a bad thing but we don't necessarily have the infrastructure to manage many different repositories easily

[15:51:25 CDT(-0500)] <colinclark> I often refer back to the old days of Sakai 2, where things were really extremely modular and it caused quite a learning curve for new developers

[15:52:58 CDT(-0500)] <colinclark> 2. I want to convey to implementers that the "reference Matchmakers" are essential services available as a) building blocks for making other Matchmakers and b) the core, default Matchmakers that are used by the system

[15:53:23 CDT(-0500)] <colinclark> my concern about splitting out, say, the Canopy Matchmaker is that it moves into the territory of "exemplar" rather than core service, if that makes sense

[15:53:28 CDT(-0500)] <colinclark> similarly for the Transformer

[15:53:34 CDT(-0500)] <colinclark> I guess it's a thin line to walk

[15:53:45 CDT(-0500)] <colinclark> to decide when something is legitimately a module that should have its own repository

[15:53:51 CDT(-0500)] <colinclark> and I'm not sure I have fully clear answers

[15:58:47 CDT(-0500)] <colinclark> My temptation is to be a bit on the conservative side, yzen

[15:58:55 CDT(-0500)] <colinclark> and only modularize universal once we're feeling the pain

[15:59:49 CDT(-0500)] <yzen> colinclark: i got convinced a couple days ago as well

[16:00:03 CDT(-0500)] <colinclark> convinced of which approach?

[16:00:08 CDT(-0500)] <yzen> this is why the flat match maker and core matchmaker code is staying in the universal

[16:00:38 CDT(-0500)] <yzen> canopy "strategy" is what's getting its own repot similarly to what rule based and stats ones would get

[16:01:33 CDT(-0500)] <yzen> colinclark: you can see it in the pull request above

[16:01:54 CDT(-0500)] <yzen> as well as this branch : https://github.com/yzen/canopyMatchMaker/tree/GPII-155

[16:02:14 CDT(-0500)] <colinclark> but why the Canopy, in particular?

[16:02:57 CDT(-0500)] <yzen> colinclark: well simply because we use flat match maker in our default configuration

[16:03:13 CDT(-0500)] <Bosmon> The canopy strategy may well end up becoming more fundamental

[16:03:27 CDT(-0500)] <Bosmon> Especially given the observation yesterday that it is probably equivalent to the "inversion of presets operation"

[16:03:28 CDT(-0500)] <colinclark> My impression is that we may want to offer the Canopy Matchmaker more prominently as a Matchmaking solution in the coming months

[16:03:44 CDT(-0500)] <Bosmon> The algorithm may end up even more central rather than further out - that is, it may end up inside ModelTransformations itself

[16:04:06 CDT(-0500)] <yzen> Bosmon, colinclark that can be changed of course, that was something Bosmon had no objects to a couple of days ago

[16:04:13 CDT(-0500)] <colinclark> I'm hoping, in fact, that we can use it to offer a more flexible approach to matching than we currently have with any of the other strategies, and also as a technical benchmark for the rule-based matchmaker

[16:04:18 CDT(-0500)] <Bosmon> yzen, well I may have changed my mind too (smile)

[16:04:30 CDT(-0500)] <colinclark> I guess I'm the one raising the objection, in fact

[16:04:40 CDT(-0500)] <yzen> Bosmon: tsk tsk tsk

[16:04:46 CDT(-0500)] <colinclark> though find myself not entirely certain of my position (tongue)

[16:04:51 CDT(-0500)] <colinclark> I dunno

[16:04:51 CDT(-0500)] <Bosmon> It seemed harmless, but now I see the Canopy repository, although I agree it looks very neat and attractive, I'm not quite sure that it really does serve as a useful example of something to our partners

[16:05:08 CDT(-0500)] <Bosmon> I mean, they should be perfectly capable of putting things into a repository by themselves : P

[16:05:19 CDT(-0500)] <colinclark> So, I guess I still feel like there's a risk that if we split it off, it could be interpreted as "separate and unmaintained"

[16:05:21 CDT(-0500)] <colinclark> as just an example

[16:06:01 CDT(-0500)] <Bosmon> I mean, we could certainly keep it there as an example of a repository.... but especially if its core algorithm ends up in infusion, it's going to seem pretty strange

[16:06:31 CDT(-0500)] <colinclark> yzen: I hope you don't think that Bosmon just deployed me as an instrument of complaint (tongue)

[16:06:51 CDT(-0500)] <yzen> (smile)

[16:06:54 CDT(-0500)] <yzen> never

[16:06:54 CDT(-0500)] <anastasiac> Bosmon, does the framework now have a declarative way to attach a listener to an applier's modelChanged event?

[16:07:07 CDT(-0500)] <Bosmon> anastasiac - it still does not

[16:07:41 CDT(-0500)] <anastasiac> Bosmon, what would you recommend as the least offensive workaround?

[16:07:51 CDT(-0500)] <anastasiac> do it in a finalInit?

[16:07:52 CDT(-0500)] <Bosmon> anastasiac - putting it in an old-style preInit function

[16:07:53 CDT(-0500)] <yzen> colinclark: Bosmon so what about keeping universal as is but taking one of the types as an example for contributors ?

[16:07:54 CDT(-0500)] <Bosmon> Yes

[16:08:03 CDT(-0500)] <anastasiac> ok, thanks

[16:08:07 CDT(-0500)] <colinclark> It's a pretty good point, yzen

[16:08:37 CDT(-0500)] <yzen> i can even make it a matchmaker template

[16:08:38 CDT(-0500)] <colinclark> it would be nice to point them at something and say "do this"

[16:08:42 CDT(-0500)] <yzen> rather than a specific type

[16:09:09 CDT(-0500)] <Bosmon> yzen - you mean by a template, a kind of "skeleton code"?

[16:09:14 CDT(-0500)] <yzen> ya

[16:09:21 CDT(-0500)] <Bosmon> ok

[16:09:41 CDT(-0500)] <Bosmon> anastasiac - you can subscribe to http://issues.fluidproject.org/browse/FLUID-4258 to see when it is done

[16:09:56 CDT(-0500)] <yzen> colinclark: is that ok with you as well >

[16:09:56 CDT(-0500)] <yzen> ?

[16:09:58 CDT(-0500)] <colinclark> I think it would be fine to make them a template, yes

[16:10:01 CDT(-0500)] <colinclark> it's a good idea

[16:10:10 CDT(-0500)] <colinclark> and to be clear, I'm not averse to further modularizing universal

[16:10:17 CDT(-0500)] <colinclark> I think I just want it to hurt a bit before we do so

[16:10:19 CDT(-0500)] <colinclark> (smile)

[16:10:23 CDT(-0500)] <anastasiac> Bosmon, done, and waiting eagerly

[16:10:35 CDT(-0500)] <Bosmon> Well, I'm not averse to it either, but I'd like to see us plan our toolset better that would help us to work with it

[16:10:51 CDT(-0500)] <yzen> Bosmon: colinclark ok

[16:10:52 CDT(-0500)] <Bosmon> Until we have our "magical grunt builder", it will be the modularization that causes us the pain, rather than the lack of it

[16:11:17 CDT(-0500)] <yzen> good point

[16:11:23 CDT(-0500)] <Bosmon> Right now the only thing which manages git checkouts for our developers is a set of half-assed shell scripts and CMD scripts in 2 different repositories

[16:14:40 CDT(-0500)] <colinclark> I would love a magical grunt builder