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)

x86
macOS
defect
Not set
normal

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.
(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.
Attached patch Patch v1.0Splinter Review
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 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 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.

Attachment

General

Creator:
Created:
Updated:
Size: