Hi,
Here is the log of the chatroom at http://farsides.com/chat/ (or
irc://irc.freenode.net/#farsides) for the 2011-08-07.
2011-08-07 07:29:39+0000 mtyaka (mtyaka) is now online
2011-08-07 08:17:35+0000 <mtyaka> antoviaque, dachary: good morning!
2011-08-07 09:43:34+0000 arbrandes (arbrandes) is now online
2011-08-07 10:26:22+0000 <mtyaka> hi arbrandes, thanks for the pointers on #316!
2011-08-07 10:27:53+0000 <arbrandes> mtyaka, np, I was starting to investigate
them again now. For #316 you really only need the notification (i.e., the fact
that there are players present), but for #303 I'm going to need a working
placement of players, which dachary started implementing on vote_owner.
2011-08-07 10:28:22+0000 <mtyaka> yes
2011-08-07 10:28:25+0000 <arbrandes> did you understand that the information is
already there when you get to invitation_owner?
2011-08-07 10:28:58+0000 <mtyaka> yup, it's in the game param
2011-08-07 10:29:07+0000 <mtyaka> but there's a problem...
2011-08-07 10:29:13+0000 <arbrandes> when the poll returns, as you pointed out,
game_or_lobby is called, which subsequently calls game(), which makes another
ajax call to discover the game state, which then calls invitation(), and then
invitation_owner().
2011-08-07 10:29:23+0000 <mtyaka> right
2011-08-07 10:29:37+0000 <mtyaka> the problem is that this happens every time a
new player joins
2011-08-07 10:29:49+0000 <arbrandes> mtyaka, exactly :)
2011-08-07 10:29:50+0000 <mtyaka> and currently invitation_owner() is not
idempotent
2011-08-07 10:30:00+0000 <mtyaka> bad things happen if you call it twice in a
row :)
2011-08-07 10:30:25+0000 <blanchard> hi guys
2011-08-07 10:30:29+0000 <arbrandes> haven't tried yet, I'll take your word for
it
2011-08-07 10:30:31+0000 <mtyaka> we will need to adjust it
2011-08-07 10:30:31+0000 <arbrandes> hey blanchard !
2011-08-07 10:30:38+0000 <mtyaka> hi blanchard!
2011-08-07 10:30:43+0000 <blanchard> :)
2011-08-07 10:31:38+0000 <arbrandes> mtyaka, I would have had to tackle that
anyway regarding player joining animations: we can't play them twice if the
author hasn't left the page.
2011-08-07 10:32:14+0000 <mtyaka> arbrandes: yes, there's a lot of things
happening on that page...
2011-08-07 10:32:24+0000 <mtyaka> animations, joining players, popup dialogs...
2011-08-07 10:32:48+0000 <arbrandes> mtyaka, but correct me if I'm wrong, the
DOM is *not* destroyed when the poll returns
2011-08-07 10:33:09+0000 <mtyaka> no, it isn't
2011-08-07 10:33:19+0000 <arbrandes> So it's state should be where it was left
before, making it simpler for us to know what's going on.
2011-08-07 10:33:23+0000 <arbrandes> *its
2011-08-07 10:33:38+0000 <mtyaka> yes
2011-08-07 10:34:02+0000 <mtyaka> right now the problem is that every time
invitation_owner is called, another set of player slots gets created
2011-08-07 10:34:08+0000 <arbrandes> if $('.suchandsuch').css('display') ==
'block', etc
2011-08-07 10:34:12+0000 <mtyaka> and the modal dialog pops up
2011-08-07 10:34:50+0000 <arbrandes> mtyaka, yup, that's very bad :)
2011-08-07 10:35:01+0000 <mtyaka> i thought we could split the invitation_owner
function into two parts - the part that only needs to run once and the part
that runs every time a new player joins
2011-08-07 10:35:40+0000 <mtyaka> (actually every time the poll returns, i
think it is not only when new players join, also when they pick cards, etc)
2011-08-07 10:35:59+0000 <arbrandes> mtyaka, yup, the poll returns for any and
all state changes
2011-08-07 10:36:18+0000 <arbrandes> it's up to the state function to do
something about it, if needed
2011-08-07 10:36:19+0000 <mtyaka> so there'd be something like
invitation_owner_initialize() that would only be called when transitioning from
the previous (write_sentence) state
2011-08-07 10:37:07+0000 <mtyaka> but i'm not sure if that would be easy to do
or not
2011-08-07 10:37:12+0000 <arbrandes> mtyaka, I think that's exactly what
dachary did with vote_owner, but in the other direction:
2011-08-07 10:37:24+0000 <arbrandes> He added a new function for displaying the
board
2011-08-07 10:37:32+0000 <arbrandes> I think it's called results_board
(checking)
2011-08-07 10:38:14+0000 <arbrandes> yup, results_board
2011-08-07 10:38:26+0000 <arbrandes> we might even make use of it, if it's not
too vote-exclusive
2011-08-07 10:40:06+0000 <arbrandes> yeah, too vote-exclusive
2011-08-07 10:40:29+0000 <arbrandes> we'll need a new "invite_board", or
something like it
2011-08-07 10:40:58+0000 <mtyaka> i'm not sure i follow you...
2011-08-07 10:41:02+0000 <mtyaka> what would invite_board do?
2011-08-07 10:41:38+0000 <arbrandes> exactly what you suggested: it would
display the state after initialization.
2011-08-07 10:42:32+0000 <mtyaka> aha, so invite_board would be called only
once? and invite_owner would be called multiple times as it is now?
2011-08-07 10:43:09+0000 <arbrandes> possibly, not sure yet, just brainstorming
2011-08-07 10:43:35+0000 <arbrandes> let me look closer at what's going on in
vote_owner
2011-08-07 10:46:48+0000 <arbrandes> lol, there's already an invitation_board()
2011-08-07 10:47:01+0000 <arbrandes> but it's not used for invitation_owner()
2011-08-07 10:53:40+0000 <mtyaka> haha
2011-08-07 10:56:24+0000 <arbrandes> I'm looking through the git log, and this
is really a new problem. Up until ccc0282d1e7e34367a15d056086c5ac7156ecf0d the
poll always called reload() when it returned.
2011-08-07 10:57:36+0000 <arbrandes> It was at that precise revision that
this[id] was introduced as a way of saving state
2011-08-07 10:57:50+0000 <arbrandes> And apparently it triggered some problems
in tests, which you fixed
2011-08-07 10:59:54+0000 <mtyaka> arbrandes: yes
2011-08-07 11:01:11+0000 <mtyaka> Did my "fix" break something else?
2011-08-07 11:01:45+0000 <arbrandes> I don't think so, haven't met with any
issues
2011-08-07 11:01:56+0000 <arbrandes> I'm looking through your 272 branch now,
out of curiosity
2011-08-07 11:02:00+0000 <arbrandes> good work, btw
2011-08-07 11:02:49+0000 <mtyaka> thanks :) it took a long time, hopefully it
was worth it
2011-08-07 11:04:03+0000 <arbrandes> I'm just reading the diffs, and IMHO the
added clarity is definitely worth it (in addition to the fixes, of course)
2011-08-07 11:06:02+0000 <arbrandes> ah, so we save stuff in root now
2011-08-07 11:06:25+0000 <mtyaka> yes
2011-08-07 11:09:52+0000 <arbrandes> I love the $.fx.off bit, nice one :)
2011-08-07 11:12:10+0000 <mtyaka> yeah, that was a nice surprise i discovered
by accident :)
2011-08-07 11:12:35+0000 <arbrandes> too bad about the jquery bug, but I think
it's worth it in terms of code clarity
2011-08-07 11:13:03+0000 dachary (dachary) is now online
2011-08-07 11:13:24+0000 <mtyaka> it's horrible to see how many typos i make in
commit messages... i really should proofread before pushing :(
2011-08-07 11:13:42+0000 <arbrandes> pfft, no worries there, as long as there's
no typos in the code, heheheh
2011-08-07 11:14:25+0000 <dachary> mtyaka: hi
2011-08-07 11:15:46+0000 <mtyaka> hi dachary
2011-08-07 11:15:55+0000 <mtyaka> arbrandes: lol
2011-08-07 11:16:15+0000 <arbrandes> hey dachary!
2011-08-07 11:16:44+0000 <dachary> :-) typos in the code are ok as long as they
are consistent.
2011-08-07 11:17:04+0000 <arbrandes> hehehe
2011-08-07 11:17:06+0000 <mtyaka> hehe :)
2011-08-07 11:19:18+0000 <antoviaque> hi all : )
2011-08-07 11:19:27+0000 <arbrandes> dachary, if you have a few minutes, me and
mtyaka were discussing how to best make invitation_owner, as he puts it,
idempotent. The idea is to prevent stuff from happening twice, when not
desired, such as showing the modal info box twice, etc.
2011-08-07 11:19:31+0000 <arbrandes> hey antoviaque! :)
2011-08-07 11:19:32+0000 <mtyaka> hi antoviaque
2011-08-07 11:19:39+0000 <antoviaque> :)
2011-08-07 11:20:55+0000 <dachary> arbrandes: I'll be back in 30 minutes and
happy to discuss it
2011-08-07 11:21:10+0000 <arbrandes> dachary, ok, thanks :)
2011-08-07 11:21:13+0000 <dachary> antoviaque: bonjour ;-)
2011-08-07 11:21:20+0000 <antoviaque> hey sir : )
2011-08-07 11:23:03+0000 <mtyaka> antoviaque, arbrandes: i ran into an
interesting problem i'd like to discuss
2011-08-07 11:23:13+0000 <antoviaque> sure!
2011-08-07 11:24:22+0000 <mtyaka> in the invitation_owner state, a dialog
should pop up when the first player joins the game with the "go to vote" button
2011-08-07 11:24:34+0000 <arbrandes> go ahead
2011-08-07 11:24:38+0000 <mtyaka> (the button is actually disabled until the
second player joins the game)
2011-08-07 11:25:13+0000 <mtyaka> the problem is the "invite players" dialog,
which is not modal and has to be explicitly closed by clicking on the little 'X'
2011-08-07 11:26:03+0000 <mtyaka> so my problem is, if the invite players
dialog is opened, and the first player joins... should the "go to vote" dialog
be shown over the "invite players" dialog?
2011-08-07 11:26:10+0000 <mtyaka> or should it be behind it?
2011-08-07 11:27:14+0000 <mtyaka> if it is shown above the "invite players"
dialog, that means that the "invite players" dialog gets useless after the
first player joins (it is hidden behing the "go to vote" dialog)
2011-08-07 11:27:57+0000 <mtyaka> if "go to vote" is shown behind "invite
players" dialog, then the user might not even see it until he manually closes
"invite players" dialog by clicking on the 'X' button
2011-08-07 11:29:12+0000 <mtyaka> the only solution i see is making the "invite
players" dialog modal - it gets automatically closed after clicking "send
invitations"
2011-08-07 11:29:17+0000 <mtyaka> do i make sense?
2011-08-07 11:29:22+0000 <arbrandes> you do
2011-08-07 11:29:34+0000 <arbrandes> and I agree
2011-08-07 11:30:02+0000 <arbrandes> but that is something for antoviaque to
decide, though
2011-08-07 11:30:11+0000 * antoviaque reading
2011-08-07 11:32:28+0000 <antoviaque> mtyaka: agreed, the best option is
definitely to make "invite players" modal, appearing on top of the "go to vote"
box
2011-08-07 11:33:16+0000 <antoviaque> for closing automatically, I'm less sure
about what is best, but I'd go for your solution and see what it gives
2011-08-07 11:36:15+0000 <mtyaka> antoviaque: ok, thanks
2011-08-07 11:36:44+0000 <mtyaka> antoviaque: can we put an estimate on #316?
2011-08-07 11:36:46+0000 <antoviaque> yw!
2011-08-07 11:36:51+0000 <antoviaque> yup - how much?
2011-08-07 11:36:58+0000 <mtyaka> 2 hours?
2011-08-07 11:37:08+0000 * antoviaque looking
2011-08-07 11:37:44+0000 <antoviaque> yup, ok!
2011-08-07 11:37:53+0000 <antoviaque> thanks mtyaka
2011-08-07 11:37:57+0000 <mtyaka> thanks again!
2011-08-07 11:38:00+0000 <antoviaque> :)
2011-08-07 11:38:41+0000 <mtyaka> antoviaque: i will have to wait with #317 a
bit, because it will require some bigger changes that we'll need to discuss
with arbrandes and dachary
2011-08-07 11:39:01+0000 <mtyaka> but i found another thing that needs to be
done
2011-08-07 11:39:13+0000 <antoviaque> ok, cool
2011-08-07 11:39:36+0000 <antoviaque> thanks for sorting it out : )
2011-08-07 11:39:37+0000 <mtyaka> in invitation_owner wrong card is shown (it
is not the card that was picked)
2011-08-07 11:39:57+0000 <mtyaka> fixing this shouldn't take more than 30
minutes
2011-08-07 11:40:08+0000 <mtyaka> may i open a ticket for it?
2011-08-07 11:40:26+0000 <antoviaque> yep - unless it fits well in another
ticket, would be good yep
2011-08-07 11:40:53+0000 <mtyaka> ok!
2011-08-07 11:49:25+0000 <dachary> back
2011-08-07 11:49:42+0000 <dachary> arbrandes: mtyaka what would you like to
discuss ?
2011-08-07 11:50:38+0000 <arbrandes> dachary, put simply, we want your opinion
on the best way to avoid modals, animations, etc. from happening at each game
state change in invitation_owner (but elsewhere too).
2011-08-07 11:51:02+0000 <dachary> hum
2011-08-07 11:51:21+0000 <arbrandes> dachary, currently, at each return from
poll, modals are shown again, animations are played again, etc.
2011-08-07 11:51:23+0000 <dachary> I see what you mean
2011-08-07 11:51:50+0000 <dachary> arbrandes: what's your advice (I know you
enough by now to figure you have an opinion already ;-) ?
2011-08-07 11:53:24+0000 <arbrandes> for invitation_owner() specifically,
mtyaka suggested creating an "init" function that is only called once. But in
any case, we'll need to depend on the DOM to know what has already happened
before. The first question is, is that ok? I see you already had to do this
with this[id] anyway.
2011-08-07 11:54:11+0000 <arbrandes> (and mtyaka changed to
root.data("saved_elements") in issue 272)
2011-08-07 11:54:44+0000 <dachary> my first thought was to have something like
if(this.set_active(root, element)) {
do_animations_that_need_to_be_done_when_entering_state() } and have set_active
return true if the state actually changes and false if it's a redisplay of the
same state
2011-08-07 11:55:39+0000 <arbrandes> dachary, sounds good to me. mtyaka, what
do you think?
2011-08-07 11:56:05+0000 <dachary> storing the previous state in the dom also
works
2011-08-07 11:56:30+0000 * dachary thinking
2011-08-07 11:56:31+0000 <mtyaka> i like the idea
2011-08-07 11:57:32+0000 <mtyaka> we'll still need to do some checking on every
invocation of invitation_owner funtion (like is this player new or was he here
before...)
2011-08-07 11:57:54+0000 <arbrandes> mtyaka, I like dachary's way specifically
because I don't think just one init() function will solve all problems. There
might be multiple different "inits" needed per state (as you just said), and
that being the case, better to handle stuff inside the state function itself.
2011-08-07 11:58:13+0000 <mtyaka> arbrandes: agreed
2011-08-07 11:58:41+0000 <dachary> mtyaka: the game() function server side was
designed to provide all the informations needed for display so that the client
can be stateless
2011-08-07 11:59:17+0000 <dachary> if you think you need to remember something
client side, it's most probably best to change the server game() function to
resolve the problem for you
2011-08-07 11:59:55+0000 <arbrandes> dachary, take one specific case (which is
what I'm working on #303): I can only play the animation of a player joining
"once".
2011-08-07 11:59:55+0000 <mtyaka> dachary: here's an example: when a new player
enters the game, an animation of him being dealt the cards should be run
2011-08-07 12:00:09+0000 <arbrandes> mtyaka, heheehehe, hive mind
2011-08-07 12:00:12+0000 <mtyaka> when the next player joins the game, the
first one shouldn't be dealt the cards again
2011-08-07 12:00:15+0000 <mtyaka> arbrandes: :)
2011-08-07 12:01:01+0000 <arbrandes> additional info on this case: if the
author refreshes the page, we *should* play all the animations again.
2011-08-07 12:01:11+0000 <arbrandes> (it's in the spec)
2011-08-07 12:01:23+0000 <dachary> mtyaka: I see
2011-08-07 12:01:43+0000 <dachary> arbrandes: yes but not when a new player
joins and the user does not Control-R
2011-08-07 12:02:11+0000 <arbrandes> dachary, precisely
2011-08-07 12:02:22+0000 * dachary thinking
2011-08-07 12:07:04+0000 <dachary> it's a tough spot
2011-08-07 12:11:03+0000 <dachary> let say the client stores the game
information and makes a diff to figure out what to do
2011-08-07 12:12:21+0000 <arbrandes> I see, store the whole array, and each
state function takes care of it's own diff logic
2011-08-07 12:12:24+0000 <dachary> the complexity of the code will grow
2011-08-07 12:12:31+0000 <dachary> significantly
2011-08-07 12:12:39+0000 <dachary> arbrandes: exactly
2011-08-07 12:14:45+0000 <dachary> what I don't like is that instead of a
simple situation (state changes means play exit state animation when it's
complete enter state new state and play animation and when the animation is
complete display the new state), deciding when to play what animation will be
based on the previous state
2011-08-07 12:15:05+0000 <dachary> it won't be long before there are complaints
about overlapping animations
2011-08-07 12:15:27+0000 <arbrandes> To minimize complexity, a state function
could just skip doing the diff if not needed, and just behave as before. The
problem would be knowing when to depend on the diff, and when not to (i.e.,
when it would be best to alter server-side code to fit the client).
2011-08-07 12:15:29+0000 <dachary> and that blocking an animation or the user
interaction is required
2011-08-07 12:15:37+0000 <dachary> that's a bag of trick we don't want to open
2011-08-07 12:15:53+0000 <arbrandes> dachary, yes, that situation is scary
2011-08-07 12:16:03+0000 <mtyaka> it sure scares me
2011-08-07 12:16:09+0000 <dachary> :-) and it should
2011-08-07 12:16:59+0000 <dachary> but what troubles me is that I don't see a
simple way to solve the "display the player cards animation when (s)he arrives"
in a simpler way
2011-08-07 12:17:04+0000 <arbrandes> But is there a way around this complexity?
2011-08-07 12:17:07+0000 <arbrandes> yes, exactly
2011-08-07 12:17:10+0000 <dachary> although I sense there should be a solution
2011-08-07 12:17:20+0000 <dachary> because it looks simple
2011-08-07 12:22:10+0000 <mtyaka> we could decorate the DOM elements
representing the players (player slots) with metadata, or a special CSS class
(ie. ".cardstories_cards_dealt") when running the animation for the first time.
And then check for the presence of this data/class on every invocation to
decide whether to run the animations or not. Although this also feels a bit
hacky, it would be simpler in this particular case.
2011-08-07 12:22:23+0000 <dachary> let's go back to mtyaka original idea in a
maybe simpler way: play deal card animations on .player_1 when (s)he arrives
and at the end of the animation remove the .player_1 class. When player_2
arrives $('.player_1').animate() is run but match nothing and therefore is a
noop. When it redisplays the original HTML is loaded with player_1 class and
all are run.
2011-08-07 12:22:48+0000 <dachary> mtyaka: :-D I see we're on the same page.
2011-08-07 12:23:03+0000 <mtyaka> yes :)
2011-08-07 12:23:06+0000 <dachary> It feels a bit hacky I agree, but let's try
to glorify it a bit.
2011-08-07 12:24:12+0000 <arbrandes> It's simple, I like it.
2011-08-07 12:26:33+0000 <arbrandes> It'll work for the modals and slots, too,
although the class juggling will make the CSS a bit more confusing to newcomers.
2011-08-07 12:27:46+0000 <dachary> The state logic is to always call functions
that are in charge of displaying the game state. Each time the game state
changes, all the functions are called regardless. This keeps the logic simple.
If a given function in charge of displaying a specific game aspect (for
instance the player seat) wants to run differently the second time it is called
(for instance to animate dealt cards the first time around but not when another
player joins), it is i
2011-08-07 12:28:20+0000 tartarugafeliz (tartarugafeliz) is now online
2011-08-07 12:28:24+0000 <dachary> arbrandes: I think it will be less confusing
if we are carefull to isolate the logic in a separate function.
2011-08-07 12:28:38+0000 <arbrandes> it is...? your last line got cut off,
dachary
2011-08-07 12:28:47+0000 <dachary> it is its responsibility to do whatever it
needs to achieve this. It must not rely on the state function nor on the data
returned from the server to support its behavior. More importantly, it must be
carefull to not alter the DOM in a way that would have undesired side effects
on other functions.
2011-08-07 12:30:41+0000 <arbrandes> Ok, so far so good, the responsibility is
on the shoulders of the state function. And to start, our "best practice"
will be juggling css classes. Sounds about right?
2011-08-07 12:31:17+0000 <dachary> yes
2011-08-07 12:31:28+0000 <dachary> responsibility is on state function helpers
though
2011-08-07 12:32:00+0000 <arbrandes> Ah, ok, separate functions.
2011-08-07 12:32:08+0000 <dachary> I think it would clarify things if the class
jugling is in a separate function that is a helper of the state function
2011-08-07 12:32:23+0000 <dachary> maybe it will be two or three lines at the
beginning
2011-08-07 12:32:34+0000 <dachary> but animated related code tend to inflate
spontaneously ;-)
2011-08-07 12:32:44+0000 <arbrandes> hehehehe, it certainly does
2011-08-07 12:33:08+0000 <dachary> q.queue('chain', function(next) {
2011-08-07 12:33:08+0000 <dachary>
$this.create_pick_card_animate(cards, element, root, function() {next();});
2011-08-07 12:33:08+0000 <dachary> });
2011-08-07 12:33:20+0000 <dachary> would be (hypotheticaly):
2011-08-07 12:34:10+0000 <dachary> q.queue('chain', function(next) {
2011-08-07 12:34:10+0000 <dachary>
$this.create_pick_card_helper(cards, element, root, next);
2011-08-07 12:34:11+0000 <dachary> });
2011-08-07 12:34:33+0000 <dachary> where create_pick_card_helper would call
create_pick_card_animate if the class jugling allows
2011-08-07 12:34:46+0000 <dachary> (bad example but just to make it extra clear
what I mean by helper ;-)
2011-08-07 12:34:55+0000 <arbrandes> understood
2011-08-07 12:34:59+0000 <arbrandes> thanks for the example
2011-08-07 12:35:37+0000 <arbrandes> I see the idea is to minimize alterations
to the state function code flow.
2011-08-07 12:36:38+0000 <dachary> yes
2011-08-07 12:36:42+0000 <dachary> exactly
2011-08-07 12:36:58+0000 <dachary> let's hear what mtyaka has to say about it
2011-08-07 12:40:23+0000 <mtyaka> i like the idea
2011-08-07 12:40:54+0000 <dachary> arbrandes: I merged your master branch
2011-08-07 12:44:06+0000 <arbrandes> cool, thanks
2011-08-07 12:45:10+0000 <arbrandes> dachary, you might also look into merging
mtyaka's #292, it includes a lot of changes to the tests.
2011-08-07 12:46:00+0000 <arbrandes> I pulled into my issue303 branch, which
I'll merge later into master
2011-08-07 12:49:47+0000 <arbrandes> mtyaka, fyi, I'm getting started on the
idea we just discussed for #303. I don't know exactly which issue you're
working on now, but it will make for easier merging later on if we keep in
sync. I'll try to commit early and often.
2011-08-07 12:51:21+0000 <arbrandes> be back in 10 minutes
2011-08-07 12:51:36+0000 <mtyaka> dachary, arbrandes: while we're discussing
growing code complexity, there's something that has been bothering me lately
2011-08-07 12:53:38+0000 <mtyaka> here:
https://gitorious.org/cardstories-mtyaka/cardstories/blobs/issue293/static/js/jquery.cardstories.js#line723
2011-08-07 12:55:17+0000 <mtyaka> we aren't using background-images for buttons
inside dialogs, because background images don't animate well (well, i think it
should be possible using CSS3, but hello IE8). So we are using actual img
elements instead
2011-08-07 12:56:05+0000 <mtyaka> that means we can't use CSS :hover and
:active pseudo classes anymore to switch images, but have to do it in JS code.
2011-08-07 12:58:49+0000 arbrandes (arbrandes) is now online
2011-08-07 12:59:01+0000 <mtyaka> since the code that does this is pretty
repetitive, and inflates code size, I thought we could use a class to represent
these kind of image buttons (let's say ".cardstories_img_button") and use some
kind of metadata convention for hover and active images
2011-08-07 13:00:11+0000 <mtyaka> let's say {hover:'...path/to/hover-img.png',
active:'...path/to/active-img.png'}
2011-08-07 13:01:15+0000 <dachary> mtyaka: +
2011-08-07 13:01:18+0000 <dachary> mtyaka: +1
2011-08-07 13:01:23+0000 <mtyaka> then we could
$('.cardstories_img_button').live(...) bind those hover/mousedown/mouseup in
one place?
2011-08-07 13:02:23+0000 <mtyaka> hover/mousedown/mouseup *handlers* in one
place
2011-08-07 13:03:37+0000 <mtyaka> dachary: may i create a ticket for this?
2011-08-07 13:19:03+0000 <mtyaka> arbrandes: i finished #316, but i think i
will wait for you to finish #303 before i start working on #317
2011-08-07 13:20:54+0000 <mtyaka> otherwise we'd probably be doing double work
2011-08-07 13:25:06+0000 <arbrandes> mtyaka, possibly, yes
2011-08-07 13:25:32+0000 mtyaka` (mtyaka`) is now online
2011-08-07 13:25:52+0000 <arbrandes> mtyaka, possibly, yes. What was your idea
about the buttons, again? I missed the first messages
2011-08-07 13:26:51+0000 <mtyaka`>
2011-08-07 13:26:51+0000 <mtyaka`> <mtyaka> dachary, arbrandes: while we're
discussing growing code complexity,
2011-08-07 13:26:51+0000 <mtyaka`> there's something that has been
bothering me lately
2011-08-07 13:26:51+0000 <mtyaka`> <mtyaka> here:
2011-08-07 13:26:54+0000 <mtyaka`>
https://gitorious.org/cardstories-mtyaka/cardstories/blobs/issue293/static/js/jquery.cardstories.js#line723
2011-08-07 13:26:57+0000 <mtyaka`>
[14:53]
2011-08-07 13:27:00+0000 <mtyaka`> <mtyaka> we aren't using background-images
for buttons inside dialogs, because
2011-08-07 13:27:03+0000 <mtyaka`> background images don't animate
well (well, i think it should be
2011-08-07 13:27:07+0000 <mtyaka`> possible using CSS3, but hello
IE8). So we are using actual img
2011-08-07 13:27:09+0000 <mtyaka`> elements instead
[14:55]
2011-08-07 13:27:12+0000 <dachary> mtyaka please do
2011-08-07 13:27:13+0000 <mtyaka`> <mtyaka> that means we can't use CSS :hover
and :active pseudo classes anymore
2011-08-07 13:27:16+0000 <mtyaka`> to switch images, but have to do it
in JS code. [14:56]
2011-08-07 13:27:19+0000 <mtyaka`> *** arbrandes ([email protected])
has joined channel #farsides [14:58]
2011-08-07 13:27:19+0000 <dachary> mtyaka please do create a ticket
2011-08-07 13:27:22+0000 <mtyaka`> <mtyaka> since the code that does this is
pretty repetitive, and inflates code
2011-08-07 13:27:25+0000 <mtyaka`> size, I thought we could use a
class to represent these kind of image
2011-08-07 13:27:29+0000 <mtyaka`> buttons (let's say
".cardstories_img_button") and use some kind of
2011-08-07 13:27:32+0000 <mtyaka`> metadata convention for hover and
active images [14:59]
2011-08-07 13:27:33+0000 <mtyaka`> <mtyaka> let's say
{hover:'...path/to/hover-img.png',
2011-08-07 13:27:36+0000 <mtyaka`> active:'...path/to/active-img.png'}
[15:00]
2011-08-07 13:27:39+0000 <mtyaka`> <dachary> mtyaka: +
[15:01]
2011-08-07 13:27:43+0000 <mtyaka`> <dachary> mtyaka: +1
2011-08-07 13:27:47+0000 <mtyaka`> <mtyaka> then we could
$('.cardstories_img_button').live(...) bind those
2011-08-07 13:27:49+0000 <arbrandes> mtyaka, agreed, completely
2011-08-07 13:27:50+0000 <mtyaka`> hover/mousedown/mouseup in one
place?
2011-08-07 13:27:53+0000 <mtyaka`> <mtyaka> hover/mousedown/mouseup *handlers*
in one place [15:02]
2011-08-07 13:27:56+0000 <mtyaka`> <mtyaka> dachary: may i create a ticket for
this? [15:03]
2011-08-07 13:27:59+0000 <mtyaka`> <mtyaka> arbrandes: i finished #316, but i
think i will wait for you to finish
2011-08-07 13:28:00+0000 <mtyaka`> #303 before i start working on #317
[15:19]
2011-08-07 13:28:03+0000 <mtyaka`> <mtyaka> otherwise we'd probably be doing
double work [15:20]
2011-08-07 13:28:06+0000 <mtyaka`>
2011-08-07 13:28:16+0000 <mtyaka`> dachary: ok, will do, thanks
2011-08-07 13:28:48+0000 <arbrandes> mtyaka, as far as I'm concerned, you could
work on that now, just check with antoviaque first
2011-08-07 13:29:14+0000 <arbrandes> (on the button thing, I mean)
2011-08-07 13:29:43+0000 <mtyaka`> ok
2011-08-07 13:35:30+0000 <antoviaque> mtyaka: good for me yep - let me just
know the estimate
2011-08-07 13:38:07+0000 <arbrandes> mtyaka, dachary, I'm going to go with
adding a class to mark that element as previously animated, instead of removing
one. Why? Because 1) this will always be free of visual repercussions
(imagine the headaches of removing a class that actually defines style), and 2)
said class need not be in the stylesheet at all, and thus is only known by the
state function.
2011-08-07 13:38:34+0000 <dachary> arbrandes: +1
2011-08-07 13:38:57+0000 <arbrandes> cool
2011-08-07 14:00:48+0000 <mtyaka> antoviaque: I created #329 for the img button
handlers. Does 2 hours sound ok?
2011-08-07 14:12:18+0000 <mtyaka> arbrandes: i did a silly thing when pushing
commit for #316 - i can overwrite it, you didn't pull it yet, right?
2011-08-07 14:12:33+0000 <arbrandes> mtyaka, nope, didn't pull, go ahead :)
2011-08-07 14:12:47+0000 <arbrandes> So far I've only pulled #292 (which
includes the test changes)
2011-08-07 14:12:47+0000 <mtyaka> cool
2011-08-07 14:12:55+0000 <mtyaka> ok, great
2011-08-07 14:43:13+0000 <antoviaque> mtyaka: ok for the 2 hours
2011-08-07 14:49:49+0000 <mtyaka> antoviaque: thanks
2011-08-07 14:49:54+0000 <antoviaque> :)
2011-08-07 14:54:48+0000 dachary (dachary) is now online
2011-08-07 16:11:24+0000 <arbrandes> bbl
2011-08-07 17:08:56+0000 mtyaka (mtyaka) is now offline
2011-08-07 18:01:51+0000 blanchard (blanchard) is now online
2011-08-07 18:48:03+0000 arbrandes (arbrandes) is now online
2011-08-07 22:22:36+0000 dachary (dachary) is now online
2011-08-07 22:26:20+0000 dachary1 (dachary1) is now online
_______________________________________________
Farsides mailing list - [email protected]
Wiki: http://farsides.com/
List: http://farsides.com/ml/
Forum: http://farsides.com/forum/
Ideas: http://farsides.com/ideas/
Chat: http://farsides.com/chat/
