Large progress indicators in Leopard

  • In Tiger, I could create a large progress indicator by setting its
    size to NSRegularControlSize:

    NSProgressIndicator *busyCursor = [[[NSProgressIndicator alloc]
    initWithFrame:rect] autorelease];
    [busyCursor setStyle:NSProgressIndicatorSpinningStyle];
    [busyCursor setControlSize:NSRegularControlSize];

    This would make the progress indicator fit nicely inside the rect. Now
    in Leopard, the size of the indicator seems non-adjustable. It's
    always small, whereas the rest of the rect draws white. Is it no
    longer possible to draw custom-sized progress indicators?
  • Am 23.11.2007 um 17:10 Uhr schrieb <slasktrattenator...>:

    > Is it no
    > longer possible to draw custom-sized progress indicators?

    I have no idea.

    In case it isn't:

    http://www.harmless.de/cocoa-code.php#progressindicator

    Andreas
  • How large are you setting the rectangle?
    I know there have been some changes in Leopard for better high-DPI
    support and this change might be another consequence of that.

    On Nov 23, 2007, at 8:10 AM, <slasktrattenator...> wrote:

    > In Tiger, I could create a large progress indicator by setting its
    > size to NSRegularControlSize:
    >
    > NSProgressIndicator *busyCursor = [[[NSProgressIndicator alloc]
    > initWithFrame:rect] autorelease];
    > [busyCursor setStyle:NSProgressIndicatorSpinningStyle];
    > [busyCursor setControlSize:NSRegularControlSize];
    >
    > This would make the progress indicator fit nicely inside the rect. Now
    > in Leopard, the size of the indicator seems non-adjustable. It's
    > always small, whereas the rest of the rect draws white. Is it no
    > longer possible to draw custom-sized progress indicators?
  • Both width and height is set to (screen width / 15).

    On Nov 23, 2007 7:53 PM, John Stiles <jstiles...> wrote:
    > How large are you setting the rectangle?
    > I know there have been some changes in Leopard for better high-DPI
    > support and this change might be another consequence of that.
    >
    >
    > On Nov 23, 2007, at 8:10 AM, <slasktrattenator...> wrote:
    >
    >> In Tiger, I could create a large progress indicator by setting its
    >> size to NSRegularControlSize:
    >>
    >> NSProgressIndicator *busyCursor = [[[NSProgressIndicator alloc]
    >> initWithFrame:rect] autorelease];
    >> [busyCursor setStyle:NSProgressIndicatorSpinningStyle];
    >> [busyCursor setControlSize:NSRegularControlSize];
    >>
    >> This would make the progress indicator fit nicely inside the rect. Now
    >> in Leopard, the size of the indicator seems non-adjustable. It's
    >> always small, whereas the rest of the rect draws white. Is it no
    >> longer possible to draw custom-sized progress indicators?
    >
    >
  • I tried downscaling but it didn't help. It seems the max size of the
    progress indicator is some 30x30 px. If the actual rect is larger,
    it's drawn in white. Yet NSProgressIndicator is a subclass of NSView
    so I figure I should be able to make it any size I want. Could this be
    a bug?

    On Nov 23, 2007 8:14 PM,  <slasktrattenator...> wrote:
    > Both width and height is set to (screen width / 15).
    >
    >
    > On Nov 23, 2007 7:53 PM, John Stiles <jstiles...> wrote:
    >> How large are you setting the rectangle?
    >> I know there have been some changes in Leopard for better high-DPI
    >> support and this change might be another consequence of that.
    >>
    >>
    >> On Nov 23, 2007, at 8:10 AM, <slasktrattenator...> wrote:
    >>
    >>> In Tiger, I could create a large progress indicator by setting its
    >>> size to NSRegularControlSize:
    >>>
    >>> NSProgressIndicator *busyCursor = [[[NSProgressIndicator alloc]
    >>> initWithFrame:rect] autorelease];
    >>> [busyCursor setStyle:NSProgressIndicatorSpinningStyle];
    >>> [busyCursor setControlSize:NSRegularControlSize];
    >>>
    >>> This would make the progress indicator fit nicely inside the rect. Now
    >>> in Leopard, the size of the indicator seems non-adjustable. It's
    >>> always small, whereas the rest of the rect draws white. Is it no
    >>> longer possible to draw custom-sized progress indicators?
    >>
    >>
    >
  • On Nov 23, 2007, at 3:11 PM, <slasktrattenator...> wrote:

    > I tried downscaling but it didn't help. It seems the max size of the
    > progress indicator is some 30x30 px. If the actual rect is larger,
    > it's drawn in white. Yet NSProgressIndicator is a subclass of NSView
    > so I figure I should be able to make it any size I want. Could this be
    > a bug?

    Perhaps not really a bug, but now a limitation.  Definitely file an
    enhancement request.  As John pointing out, the control could have
    been already modified to support Hi-DPI (aka resolution
    independence).  My guess is that Apple is using bitmapped images and
    are just providing multi-res flavors (72 dpi and 288 dpi).

    But, IMO, that's bad!  If I were implementing the control, I would
    allow any size and would either vector-based images (e.g. PDF) or
    drawing primitives for the content.

    Note that you'll see the same issues for most other controls as well.
    While they do support res-ind, their sizes are pretty much fixed point-
    wise.

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
  • Thanks, I'll file an enhancement request. In the meantime, I guess
    I'll have to design my own progress indicator {sigh}.

    On Nov 23, 2007 10:41 PM, Ricky Sharp <rsharp...> wrote:
    >
    > On Nov 23, 2007, at 3:11 PM, <slasktrattenator...> wrote:
    >
    >> I tried downscaling but it didn't help. It seems the max size of the
    >> progress indicator is some 30x30 px. If the actual rect is larger,
    >> it's drawn in white. Yet NSProgressIndicator is a subclass of NSView
    >> so I figure I should be able to make it any size I want. Could this be
    >> a bug?
    >
    > Perhaps not really a bug, but now a limitation.  Definitely file an
    > enhancement request.  As John pointing out, the control could have
    > been already modified to support Hi-DPI (aka resolution
    > independence).  My guess is that Apple is using bitmapped images and
    > are just providing multi-res flavors (72 dpi and 288 dpi).
    >
    > But, IMO, that's bad!  If I were implementing the control, I would
    > allow any size and would either vector-based images (e.g. PDF) or
    > drawing primitives for the content.
    >
    > Note that you'll see the same issues for most other controls as well.
    > While they do support res-ind, their sizes are pretty much fixed point-
    > wise.
    >
    > ___________________________________________________________
    > Ricky A. Sharp        mailto:<rsharp...>
    > Instant Interactive(tm)  http://www.instantinteractive.com
    >
    >
  • Thank you so much Andreas! Works great. Looks like I'm getting my
    Sunday's rest after all :-)

    On Nov 24, 2007 12:22 AM, Andreas Mayer <listen...> wrote:
    >
    > Am 23.11.2007 um 23:00 Uhr schrieb <slasktrattenator...>:
    >
    >> In the meantime, I guess
    >> I'll have to design my own progress indicator {sigh}.
    >
    > Hm. I did send this to the list, but I guess it didn't make it ...
    >
    > ----------
    >
    > Am 23.11.2007 um 17:10 Uhr schrieb <slasktrattenator...>:
    >
    >> Is it no
    >> longer possible to draw custom-sized progress indicators?
    >
    > I have no idea.
    >
    > In case it isn't:
    >
    > http://www.harmless.de/cocoa-code.php#progressindicator
    >
    >
    > Andreas
    >
  • On Nov 23, 2007, at 1:41 PM, Ricky Sharp wrote:

    > As John pointing out, the control could have been already modified
    > to support Hi-DPI (aka resolution independence).  My guess is that
    > Apple is using bitmapped images and are just providing multi-res
    > flavors (72 dpi and 288 dpi).
    >
    > But, IMO, that's bad!  If I were implementing the control, I would
    > allow any size and would either vector-based images (e.g. PDF) or
    > drawing primitives for the content.

    Really, whether a control supports high DPI and whether it is
    implemented using vectors/primitives or using bitmaps is largely
    irrelevant.  A bitmap sized for 72 DPI can serve just fine for higher
    resolutions, as if the *interface* is running at a higher resolution
    it will still be appropriately sized.

    One thing to think about is how newspapers and magazines do it.  In
    publishing, the "line work" plate files -- black & white text,
    typically -- are typically high-resolution, 1200 to 2400 DPI depending
    on the medium.  The "continuous tone" plate files -- photographs,
    charts, etc. -- are however typically 75 DPI to 300 DPI depending on
    the medium.

    This is partly because rasterizing color images in print involves
    halftone patterns, and you don't need a 2400 DPI color image to
    generate a 2400 DPI color halftone.  (In fact, you really don't want
    one.)  On the other hand, you also often don't need as high a
    resolution continuous-tone color image as you think you need to get
    the effect you're looking for.

    The reason some software doesn't look so great when run at 200%
    scaling is not because it uses bitmapped art, but because it's running
    at 200% scaling on a 72-110 DPI screen.  If it were running at 100% on
    a 144-220 DPI display, it would likely look pretty decent as the
    "chunkiness" wouldn't be any more apparent than it is on current
    displays.

    So, don't automatically assume that using bitmaps is bad for hi-DPI
    controls.  It's not always great, but it's not automatically a fail.
    Try printing your images at half scale on a high-resolution printer
    and see how they look first...

      -- Chris
  • On Nov 24, 2007, at 12:30 AM, Chris Hanson wrote:

    > On Nov 23, 2007, at 1:41 PM, Ricky Sharp wrote:
    >
    >> As John pointing out, the control could have been already modified
    >> to support Hi-DPI (aka resolution independence).  My guess is that
    >> Apple is using bitmapped images and are just providing multi-res
    >> flavors (72 dpi and 288 dpi).
    >>
    >> But, IMO, that's bad!  If I were implementing the control, I would
    >> allow any size and would either vector-based images (e.g. PDF) or
    >> drawing primitives for the content.
    >
    > Really, whether a control supports high DPI and whether it is
    > implemented using vectors/primitives or using bitmaps is largely
    > irrelevant.  A bitmap sized for 72 DPI can serve just fine for
    > higher resolutions, as if the *interface* is running at a higher
    > resolution it will still be appropriately sized.

    My point here about being bad was that due to the bitmapped graphics,
    the control can only be sized to a certain maximum.  To keep the math
    simple, let's say this maximum is 1/2 square inch.  On a 72 dpi
    display, that's 36 x 36 pixels.  On a 288 dpi display, that's 144 x
    144 pixels.  Thus, a multi-res TIFF with two images (36 x 36 and 144 x
    144) will indeed work, but it is still designed to only look right up
    to a maximum of 1/2 square inch.  In fact, this is what res-ind does
    for us; we design stuff based upon points and not pixels.

    If using vector-based artwork, the control has the advantage to
    infinitely scale its content.  In the specific case of the progress
    indicator, the content artwork need not be bitmapped based.  Thus,
    progress indicators of 1 sq inch, 2 sq inches, etc. will all have
    properly rendered content.

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today