Size of the resize indicator
-
I would like to be able to use the mini version of a NSScrollView and
have that scroll view extend into the bottom right corner of a
resizable NSPanel where the resize indicator for the window is drawn.
Unfortunately, the resize indicator only seems to fit the regular
sized version of a NSScrollView.
Now, I have seen palettes in other applications with a resize
indicator which would fit nicely with the small version of a
NSScrollView.
Does anyone know how to get a smaller resize indicator to
automatically appear?
Is this something I will have to draw myself?
Are NSScrollViews only meant to be the 'regular' size?
If you need to see an example of what I am talking about, the problem
can be easily reproduced using just interface builder. I have placed
an example at:
http://ericgorr.net/resizeindicator.zip
Thank you. -
I'm pretty sure this cannot be done in Cocoa windows. If you see it in
some panels, those are either using SPI or they aren's Cocoa windows.
Also drawing it yourself is not possible using API, as the resize
indicator is part of a private view class.
Christiaan
On 3 Dec 2008, at 4:29 PM, Eric Gorr wrote:> I would like to be able to use the mini version of a NSScrollView
> and have that scroll view extend into the bottom right corner of a
> resizable NSPanel where the resize indicator for the window is drawn.
>
> Unfortunately, the resize indicator only seems to fit the regular
> sized version of a NSScrollView.
>
> Now, I have seen palettes in other applications with a resize
> indicator which would fit nicely with the small version of a
> NSScrollView.
>
> Does anyone know how to get a smaller resize indicator to
> automatically appear?
>
> Is this something I will have to draw myself?
>
> Are NSScrollViews only meant to be the 'regular' size?
>
>
> If you need to see an example of what I am talking about, the
> problem can be easily reproduced using just interface builder. I
> have placed an example at:
>
> http://ericgorr.net/resizeindicator.zip
>
>
>
> Thank you. -
Well, that is annoying.
If anyone knows of a way around this problem, I would be very
interested.
On Dec 3, 2008, at 10:49 AM, Christiaan Hofman wrote:> I'm pretty sure this cannot be done in Cocoa windows. If you see it
> in some panels, those are either using SPI or they aren's Cocoa
> windows. Also drawing it yourself is not possible using API, as the
> resize indicator is part of a private view class.
>
> Christiaan
>
> On 3 Dec 2008, at 4:29 PM, Eric Gorr wrote:
>
>> I would like to be able to use the mini version of a NSScrollView
>> and have that scroll view extend into the bottom right corner of a
>> resizable NSPanel where the resize indicator for the window is drawn.
>>
>> Unfortunately, the resize indicator only seems to fit the regular
>> sized version of a NSScrollView.
>>
>> Now, I have seen palettes in other applications with a resize
>> indicator which would fit nicely with the small version of a
>> NSScrollView.
>>
>> Does anyone know how to get a smaller resize indicator to
>> automatically appear?
>>
>> Is this something I will have to draw myself?
>>
>> Are NSScrollViews only meant to be the 'regular' size?
>>
>>
>> If you need to see an example of what I am talking about, the
>> problem can be easily reproduced using just interface builder. I
>> have placed an example at:
>>
>> http://ericgorr.net/resizeindicator.zip
>>
>>
>>
>> Thank you.
>
> -
While this is an interesting answer, what concerns me is if an OS
revision alters the look of the resize indicator what I am drawing
will look wrong. I could not find a way to be sure that what I am
drawing as the resize indicator will be what Apple is drawing.
On Dec 3, 2008, at 11:06 AM, harry Emmanuel wrote:> Hello,
>
> This isn't a builtin functionality , but you can easily add it.
>
> An possibility is to subclass NSButton,
> use IB to create it and set the right icon for resize indicator.
>
> Next, in the -mouseDown: method of your subclass,
> you manage the click like a resize indicator.
>
> Harry.
>
> On 3 déc. 2008, at 16:56, Eric Gorr wrote:
>
>> Well, that is annoying.
>>
>> If anyone knows of a way around this problem, I would be very
>> interested.
> -
On 3 Dec 2008, at 07:49, Christiaan Hofman wrote:> I'm pretty sure this cannot be done in Cocoa windows. If you see it
> in some panels, those are either using SPI or they aren's Cocoa
> windows. Also drawing it yourself is not possible using API, as the
> resize indicator is part of a private view class.
I'm not sure about how much size control you have (though there is a
kHIThemeGrowBoxSizeSmall), but you can definitely use
HIThemeDrawGrowBox() in any window, Cocoa or Carbon.
David Dunham A Sharp, LLC
Voice/Fax: 206 783 7404 http://a-sharp.com
Efficiency is intelligent laziness. -
On 3 Dec 2008, at 21:00, David Dunham wrote:> I'm not sure about how much size control you have (though there is a
> kHIThemeGrowBoxSizeSmall), but you can definitely use
> HIThemeDrawGrowBox() in any window, Cocoa or Carbon.
Although I'm not sure if HITheme drawing works with 64 bit
frameworks... I sure hope it does, because it's the only way to do
certain drawing operations.
David Dunham A Sharp, LLC
Voice/Fax: 206 783 7404 http://a-sharp.com
"People seem to misinterpret complexity as sophistication" -- Niklaus
Wirth -
On 4 Dec 2008, at 6:09 AM, David Dunham wrote:> On 3 Dec 2008, at 21:00, David Dunham wrote:
>
>> I'm not sure about how much size control you have (though there is
>> a kHIThemeGrowBoxSizeSmall), but you can definitely use
>> HIThemeDrawGrowBox() in any window, Cocoa or Carbon.
>
>
> Although I'm not sure if HITheme drawing works with 64 bit
> frameworks... I sure hope it does, because it's the only way to do
> certain drawing operations.
>
> David Dunham A Sharp, LLC
> Voice/Fax: 206 783 7404 http://a-sharp.com
> "People seem to misinterpret complexity as sophistication" --
> Niklaus Wirth
The Carbon 64 bit guide explicitly says HITheme is 64 bit safe (as it
is based on Quartz rather than QuickDraw, in fact it was introduced in
10.3 precisely because of that).
However I don't really see how you can override the Cocoa behavior
using this. How do you remove the Cocoa grow box, which is drawn by
the private NSThemeFrame (and methods controlling it are scattered
throughout AppKit), and how do you change the offset the scroller
uses? AFAICS this cannot be done without the use of SPI.
Christiaan -
On Dec 3, 2008, at 10:29 AM, Eric Gorr wrote:> I would like to be able to use the mini version of a NSScrollView
> and have that scroll view extend into the bottom right corner of a
> resizable NSPanel where the resize indicator for the window is drawn.
>
> Unfortunately, the resize indicator only seems to fit the regular
> sized version of a NSScrollView.
>
> Now, I have seen palettes in other applications with a resize
> indicator which would fit nicely with the small version of a
> NSScrollView.
>
> Does anyone know how to get a smaller resize indicator to
> automatically appear?
>
> Is this something I will have to draw myself?
>
> Are NSScrollViews only meant to be the 'regular' size?
>
If you don't mind overriding a private method, you can subclass
NSWindow (or NSPanel) and implement -_growBoxRect. Whatever rect you
return from this method is the rect used by the window to draw the
grow box (well, within reason - if you make it larger than the grow
box would normally be, it draws a normal grow box, but the drag area
is whatever dimensions you gave it). Also, the method is only used
when a scroll view would intersect with the grow box.
The method has been around since 10.2 at least and still works in
10.5, though as with any private method Apple could change it at any
time if they wish to.
But, anyway, something like this should work:
- (NSRect)_growBoxRect
{
CGFloat width = [NSScroller
scrollerWidthForControlSize:NSSmallControlSize];
NSRect frame = [self frame];
return NSMakeRect( NSMaxX(frame) - width, 0, width, width );
}
(I'm guessing when you said 'mini' above, you meant 'small', since any
time I've ever tried making a scroller use the 'mini' size it just
uses the normal size.)
--------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net -
On Dec 5, 2008, at 1:57 AM, Michael Nickerson wrote:>
> On Dec 3, 2008, at 10:29 AM, Eric Gorr wrote:
>
>> I would like to be able to use the mini version of a NSScrollView
>> and have that scroll view extend into the bottom right corner of a
>> resizable NSPanel where the resize indicator for the window is drawn.
>>
>> Unfortunately, the resize indicator only seems to fit the regular
>> sized version of a NSScrollView.
>>
>> Now, I have seen palettes in other applications with a resize
>> indicator which would fit nicely with the small version of a
>> NSScrollView.
>>
>> Does anyone know how to get a smaller resize indicator to
>> automatically appear?
>>
>> Is this something I will have to draw myself?
>>
>> Are NSScrollViews only meant to be the 'regular' size?
>>
>
>
> If you don't mind overriding a private method, you can subclass
> NSWindow (or NSPanel) and implement -_growBoxRect. Whatever rect
> you return from this method is the rect used by the window to draw
> the grow box (well, within reason - if you make it larger than the
> grow box would normally be, it draws a normal grow box, but the drag
> area is whatever dimensions you gave it). Also, the method is only
> used when a scroll view would intersect with the grow box.
>
> The method has been around since 10.2 at least and still works in
> 10.5, though as with any private method Apple could change it at any
> time if they wish to.
>
> But, anyway, something like this should work:
>
> - (NSRect)_growBoxRect
> {
> CGFloat width = [NSScroller
> scrollerWidthForControlSize:NSSmallControlSize];
> NSRect frame = [self frame];
>
> return NSMakeRect( NSMaxX(frame) - width, 0, width, width );
> }
Unfortunately, this doesn't seem to work as expected. While I can set
a breakpoint and see that the method is being called, the grow box is
not actually drawn any smaller in 10.5 in my tests.> (I'm guessing when you said 'mini' above, you meant 'small', since
> any time I've ever tried making a scroller use the 'mini' size it
> just uses the normal size.)
Yes, I meant 'small'. -
On 5 Dec 2008, at 3:35 PM, Eric Gorr wrote:>
> On Dec 5, 2008, at 1:57 AM, Michael Nickerson wrote:
>
>>
>> On Dec 3, 2008, at 10:29 AM, Eric Gorr wrote:
>>
>>> I would like to be able to use the mini version of a NSScrollView
>>> and have that scroll view extend into the bottom right corner of a
>>> resizable NSPanel where the resize indicator for the window is
>>> drawn.
>>>
>>> Unfortunately, the resize indicator only seems to fit the regular
>>> sized version of a NSScrollView.
>>>
>>> Now, I have seen palettes in other applications with a resize
>>> indicator which would fit nicely with the small version of a
>>> NSScrollView.
>>>
>>> Does anyone know how to get a smaller resize indicator to
>>> automatically appear?
>>>
>>> Is this something I will have to draw myself?
>>>
>>> Are NSScrollViews only meant to be the 'regular' size?
>>>
>>
>>
>> If you don't mind overriding a private method, you can subclass
>> NSWindow (or NSPanel) and implement -_growBoxRect. Whatever rect
>> you return from this method is the rect used by the window to draw
>> the grow box (well, within reason - if you make it larger than the
>> grow box would normally be, it draws a normal grow box, but the
>> drag area is whatever dimensions you gave it). Also, the method is
>> only used when a scroll view would intersect with the grow box.
>>
>> The method has been around since 10.2 at least and still works in
>> 10.5, though as with any private method Apple could change it at
>> any time if they wish to.
>>
>> But, anyway, something like this should work:
>>
>> - (NSRect)_growBoxRect
>> {
>> CGFloat width = [NSScroller
>> scrollerWidthForControlSize:NSSmallControlSize];
>> NSRect frame = [self frame];
>>
>> return NSMakeRect( NSMaxX(frame) - width, 0, width, width );
>> }
>
> Unfortunately, this doesn't seem to work as expected. While I can
> set a breakpoint and see that the method is being called, the grow
> box is not actually drawn any smaller in 10.5 in my tests.
>
And that shows what's the problem with overriding private methods.
There are various classes that define this method, and there also is
something like a grow box owner, which may or may not be the scroll
view. How all the different private methods is far from obvious, and
even having it work in a particular instance would be no guarantee (it
could be different in other situations or other OS versions).
Christiaan>> (I'm guessing when you said 'mini' above, you meant 'small', since
>> any time I've ever tried making a scroller use the 'mini' size it
>> just uses the normal size.)
>
> Yes, I meant 'small'.
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev -
On Dec 5, 2008, at 9:35 AM, Eric Gorr wrote:>
> On Dec 5, 2008, at 1:57 AM, Michael Nickerson wrote:
>
>>
>>
>> If you don't mind overriding a private method, you can subclass
>> NSWindow (or NSPanel) and implement -_growBoxRect. Whatever rect
>> you return from this method is the rect used by the window to draw
>> the grow box (well, within reason - if you make it larger than the
>> grow box would normally be, it draws a normal grow box, but the
>> drag area is whatever dimensions you gave it). Also, the method is
>> only used when a scroll view would intersect with the grow box.
>>
>>
>
> Unfortunately, this doesn't seem to work as expected. While I can
> set a breakpoint and see that the method is being called, the grow
> box is not actually drawn any smaller in 10.5 in my tests.
>>
>
Hmm, really? I tried it out to make sure it still worked before I
posted.
Oh, I see, it only works correctly if you have both scrollbars
visible. Sorry, hadn't thought to test that one out.
On Dec 5, 2008, at 10:22 AM, Christiaan Hofman wrote:>
>>
> And that shows what's the problem with overriding private methods.
> There are various classes that define this method, and there also is
> something like a grow box owner, which may or may not be the scroll
> view. How all the different private methods is far from obvious, and
> even having it work in a particular instance would be no guarantee
> (it could be different in other situations or other OS versions).
>> Christiaan
Yeah, which is why I started with "If you don't mind overriding a
private method..." I try to avoid them like the plague - the only
reason I knew about this method was from a few years ago when I was
creating a resizable borderless window and was looking into how a
normal window got it drawn.
--------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net
