feat: Programmatically toggle containers

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

[petrsimon]

Enables:

• programmatically un/collapse containers using collapsed attribute
• collapsing containers on app start (see comment in directive uiLayoutLoaded)
• introduces concept of "central" container
• add animation for collapsing
• fixesCreate CONTRIBUTING.md #129, Window resize resets column sizes #100
• few formatting changes

[j--w]

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

[petrsimon]

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

[j--w]

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

[petrsimon]

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

[petrsimon]

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

[j--w]

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

[petrsimon]

Right. That naturally makes sense. Just not sure how to go about fixing this...

[petrsimon]

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

[j--w]

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

[petrsimon]

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

[SomeKittens]

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

[petrsimon]

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

[j--w]

I think adding the dangling pixel to the last auto sized element makes sense.

[BobbieBarker]

!== vs !=

[BobbieBarker]

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

[petrsimon]

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

[SomeKittens]

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

[petrsimon]

Will do my best! :)

[petrsimon]

Please have a look.

[SomeKittens]

Latest commit LGTM

[petrsimon]

My pleasure! Let's see if others find anything fishy...

[BobbieBarker]

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

[petrsimon]

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

[BobbieBarker]

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

[petrsimon]

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.