{"id":1894,"date":"2005-05-07T22:18:32","date_gmt":"2005-05-08T01:18:32","guid":{"rendered":"http:\/\/brockerhoff.net\/bb\/viewtopic.php?p=1158"},"modified":"2010-05-08T20:54:22","modified_gmt":"2010-05-08T23:54:22","slug":"rbsplitview-1-1-1","status":"publish","type":"post","link":"https:\/\/brockerhoff.net\/blog\/2005\/05\/07\/rbsplitview-1-1-1\/","title":{"rendered":"RBSplitView 1.1.1&#8230;"},"content":{"rendered":"<p><a href=\"\/src\/rbs.html\">Same place<\/a> as usual. I really hope this will be stable for some time, at least until after WWDC&#8230;<\/p>\n<p>An interesting thing happened while doing this version. (The following discussion will make no sense unless you&#8217;re familiar with RBSplitView.)<\/p>\n<p>I have an adjustSubviews method call which does all the heavy lifting, computing the new positions and sizes for all subviews. This worked fine until I saw the need to (sometimes) have a specific subview stay the same size whenever the window was resized. In other words, I needed an adjustSubviewsExcepting: method.<\/p>\n<p>At first I saw no easy way to do this, but then I hit upon a simple trick; I would temporarily set that subview&#8217;s minimum and maximum dimensions to the current dimension, call adjustSubviews, then put the original limits back. This was way back in version 1.0.2.<\/p>\n<p>All seemed to work fine until I received a bug report that this could cause the subview to be collapsed in certain circumstances. So this time I tried several ways to prevent this from happening; the code inside adjustSubviewsExcepting: grew ever more large and cumbersome, and nothing appeared to work in all cases.<\/p>\n<p>Then the solution appeared in my sleep (as often happens). The thing was to make adjustSubviewsExcepting: the general case, and adjustSubviews the exception! I already looped twice over the subviews; first, to try to accomodate them just by resizing and limiting some to their constraints, then again if that didn&#8217;t work, to collapse or expand some until all constraints were satisfied.<\/p>\n<p>So I added a few lines to double this double loop; once while holding the excepted subview constant (if there was any), then once again while allowing it to resize if a solution was not reached. This proved to work quite well, and I was already near to publishing until I again found a circumstance where it didn&#8217;t work.<\/p>\n<p>Turned out my initial implementation was faulty in that 3 passes (not 2!) were needed to find a viable solution. So the algorithm now loops 3 times if there is no excepted subview and 6 if there isn&#8217;t. By now, after refactoring the inner loop several times, no serious speed penalty is incurred and everything works much more smoothly.<\/p>\n<p>Moral: refactoring should also consider what is the rule and what the exception&#8230;<\/p>\n<p><a rel=\"tag\" href=\"http:\/\/www.technorati.com\/tag\/Cocoa\">Cocoa<\/a> <a rel=\"tag\" href=\"http:\/\/www.technorati.com\/tag\/Programming\">Programming<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Same place as usual. I really hope this will be stable for some time, at least until after WWDC&#8230; An interesting thing happened while doing this version. (The following discussion will make no sense unless you&#8217;re familiar with RBSplitView.) I have an adjustSubviews method call which does all the heavy lifting, computing the new positions [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4,19],"tags":[26,20],"class_list":["post-1894","post","type-post","status-publish","format-standard","hentry","category-dev","category-software","tag-cocoa","tag-rbsplitview"],"featured_image_src":null,"author_info":{"display_name":"Rainer Brockerhoff","author_link":"https:\/\/brockerhoff.net\/blog\/author\/rbrockerhoff\/"},"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1q3Zc-uy","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts\/1894","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/comments?post=1894"}],"version-history":[{"count":0,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts\/1894\/revisions"}],"wp:attachment":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/media?parent=1894"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/categories?post=1894"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/tags?post=1894"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}