Closed
Bug 479881
Opened 15 years ago
Closed 15 years ago
Double-clicking on location/search field splitter should collapse/uncollapse the search field
Categories
(Camino Graveyard :: Toolbars & Menus, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ishermandom+bugs, Assigned: ishermandom+bugs)
Details
Attachments
(1 file)
1.27 KB,
patch
|
bugzilla-graveyard
:
review+
stuart.morgan+bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
When the search field is hidden, double clicking on the splitter should restore it to its original size. When the search field is visible, double clicking the splitter should collapse it.
Comment 1•15 years ago
|
||
(In reply to comment #0) > When the search field is hidden, double clicking on the splitter should restore > it to its original size. When the search field is visible, double clicking the > splitter should collapse it. To elaborate a bit, I don't think double-clicking to collapse is a behaviour that always makes intuitive sense on *SplitViews, but I think double-clicking the splitter to collapse the search field makes sense because the search field is almost always secondary to the location field in a Web browser. I'd be OK with ignoring that half of this bug, though (and I was the one who suggested that part on IRC), if other people think it's not logical.
Assignee | ||
Comment 2•15 years ago
|
||
Hey, look, Apple wrote this for us -- how nice :) The reference prototype for the method [1] has |NSInteger| where I have |int|. I'm not sure where NSInteger is defined -- it seems to be only OS X 10.5+, but is a typedef to int or long, depending on the environment [2]. Is just using int fine for us; or is there something better we can do? [1] http://developer.apple.com/mac/library/documentation/cocoa/Reference/NSSplitViewDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/NSSplitViewDelegate/splitView:shouldCollapseSubview:forDoubleClickOnDividerAtIndex: [2] http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/Reference/reference.html#//apple_ref/doc/c_ref/NSInteger Also, I'm like 99% sure that this has no effect on Tiger, but it would be nice to check.
Attachment #419144 -
Flags: superreview?(stuart.morgan+bugzilla)
Attachment #419144 -
Flags: review?(cl-bugs-new2)
Comment 3•15 years ago
|
||
Comment on attachment 419144 [details] [diff] [review] Patch v1.0 I'm not really qualified to answer the int/NSInteger question, but I'll offer this: http://cocoadev.com/index.pl?NSUInteger r=me on the code and functionality, with the caveat that when I tested this using Troubleshoot Camino, I had to manually expand the search field first (I normally keep it collapsed) before double-clicking would work. Once I did that, every subsequent double-click event worked as expected. This may not have been an issue if I had tested on a different machine, or if I had tested by quitting my "main" Camino and doing it that way.
Attachment #419144 -
Flags: review?(cl-bugs-new2) → review+
Comment 4•15 years ago
|
||
Comment on attachment 419144 [details] [diff] [review] Patch v1.0 >+// TODO int should be NSInteger Remove this; it's true of basically every Apple API we use through the whole codebase, so there's no reason to call this case out specifically. Once Camino is 10.5+ (or once Camino starts using GTM, so we can snag the handy header of conditional definitions), the whole codebase will need to be scrubbed for this kind of thing to make it 64-bit clean. sr=smorgan otherwise (although I'm a bit surprised this works, since we override a bunch of splitview stuff).
Attachment #419144 -
Flags: superreview?(stuart.morgan+bugzilla) → superreview+
Eiichi, can you give this patch a quick test on 10.4 to make sure nothing bad happens? The expected outcome on 10.4 is that the splitview behaves exactly as it did before. (From update of attachment 419144 [details] [diff] [review]) >+// NB This only works for OS X at least 10.5, but is harmless on 10.4. Nit: since this is Mac-only code, I don't think we need "OS X" here, either; something like "This works on 10.5 and up but is harmless on 10.4." (or "10.5+"; I forget what our style is) seems more succinct.
(In reply to comment #5) > Eiichi, can you give this patch a quick test on 10.4 to make sure nothing bad > happens? The expected outcome on 10.4 is that the splitview behaves exactly as > it did before. I tested the patch on 10.4, and it seemed that nothing bad happened and Camino behaved as before.
(In reply to comment #6) > I tested the patch on 10.4, and it seemed that nothing bad happened and Camino > behaved as before. Thank you! Landed on cvs trunk with the comment fixes.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•