-NSView setHidden: in 10.2
-
In testing a Cocoa app today, I discovered that it doesn't work
correctly in 10.2 because there's no -[NSView setHidden:] method in
10.2. Surely it was possible to hide a view in 10.2, wasn't it? What
do I need to do to make this work?
Thanks,
Darrin
--
Darrin Cardani - <dcardani...>
President, Buena Software, Inc.
<http://www.buena.com/>
Video, Image and Audio Processing Development -
I believe the only reasonable alternative is to retain it and remove
it from its superview, replacing it as needed.
- J
On Sep 20, 2004, at 10:31 AM, Darrin Cardani wrote:> In testing a Cocoa app today, I discovered that it doesn't work
> correctly in 10.2 because there's no -[NSView setHidden:] method in
> 10.2. Surely it was possible to hide a view in 10.2, wasn't it? What
> do I need to do to make this work? -
On 20.9.2004, at 16:33, J Nozzi wrote:> I believe the only reasonable alternative is to retain it and remove
> it from its superview, replacing it as needed.
... making sure there will be no problems with autosizing (consider a
view is hidden=taken out, the window gets resized, the view is
shown=put back). It was not exactly easy. There's a plethora of
solutions (and discussions) in the mail archives.
There was a reason, by the way: in NeXTStep, hiding views was
considered a pretty bad UI design: if something does not work in
current circumstances, it should be disabled, not hidden. The user
should see the complete UI. OTOH, if something in some circumstances
does not make sense at all, it belongs into another tab or into another
window. Myself, I can't help it, but the adage still sounds reasonably
to me.
---
Ondra Ãada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc -
I agree with this design philosophy and probably should have included
this caveat, however, if someone asks a question, I generally try to
just answer it the best I can. ;-)
There are plenty of discussions on the matter and it's up to you,
Darrin, to decide which way best fits your app's design. If it's not
something that is needed all the time, try a tab view, a sheet, or even
a drawer (though for some reason there's great hostility toward drawers
in some camps; I see no problem with them if they're used properly).
- J
On Sep 20, 2004, at 10:45 AM, Ondra Cada wrote:> There was a reason, by the way: in NeXTStep, hiding views was
> considered a pretty bad UI design: if something does not work in
> current circumstances, it should be disabled, not hidden. The user
> should see the complete UI. OTOH, if something in some circumstances
> does not make sense at all, it belongs into another tab or into
> another window. Myself, I can't help it, but the adage still sounds
> reasonably to me. -
At 10:52 AM -0400 9/20/04, J Nozzi wrote:> There are plenty of discussions on the matter and it's up to you,
> Darrin, to decide which way best fits your app's design. If it's not
> something that is needed all the time, try a tab view, a sheet, or
> even a drawer (though for some reason there's great hostility toward
> drawers in some camps; I see no problem with them if they're used
> properly).
This is an iMovie plugin. Or more accurately, it's 2 different iMovie
plugins that share a lot of code and have very similar UI's. When the
user chooses the first plugin, they get the window with all the
controls. When the user chooses the other plugin they get the window
without a couple of controls. It's not a situation where doing
something within the window shows or hides the UI elements. But it
makes the size of the code and resources smaller to do it this way. I
don't believe that breaks the design guidelines you speak of.
Thanks for all your help,
Darrin
--
Darrin Cardani - <dcardani...>
President, Buena Software, Inc.
<http://www.buena.com/>
Video, Image and Audio Processing Development -
I have to bow out here, then, as I've no experience whatsoever
writing plugins for *anything*. ;-) Are you able to have iMovie display
one "plugin bundle" as two distinct plugins? If so, you might try a
tabview without the tabs. Sub-plugin uses tab at index 0, sub-plugin 2
uses tab index 1, etc.
Of course, I'm totally pulling this out of my *** ... just
brainstorming here. ;-)
- J
On Sep 20, 2004, at 11:06 AM, Darrin Cardani wrote:> At 10:52 AM -0400 9/20/04, J Nozzi wrote:
>> There are plenty of discussions on the matter and it's up to you,
>> Darrin, to decide which way best fits your app's design. If it's not
>> something that is needed all the time, try a tab view, a sheet, or
>> even a drawer (though for some reason there's great hostility toward
>> drawers in some camps; I see no problem with them if they're used
>> properly).
>
> This is an iMovie plugin. Or more accurately, it's 2 different iMovie
> plugins that share a lot of code and have very similar UI's. When the
> user chooses the first plugin, they get the window with all the
> controls. When the user chooses the other plugin they get the window
> without a couple of controls. It's not a situation where doing
> something within the window shows or hides the UI elements. But it
> makes the size of the code and resources smaller to do it this way. I
> don't believe that breaks the design guidelines you speak of.
>
> Thanks for all your help,
> Darrin
> --
> Darrin Cardani - <dcardani...>
> President, Buena Software, Inc.
> <http://www.buena.com/>
> Video, Image and Audio Processing Development -
Darrin,
On 20.9.2004, at 17:06, Darrin Cardani wrote:> It's not a situation where doing something within the window shows or
> hides the UI elements...
In which case perhaps you may want just remove those unneeded widgets
in the initialization, if the plugin happens to run in its "dumb" mode?
Or even better, you may want to load in another NIB in case it finds it
is in the "smart" mode?
Nevertheless, of course, the design is *completely* up to you: the
non-technical historical digression of mine was actually meant as an
aswer to the "surely there was a way to hide a view in 10.2" part of
the original question. There was not (save those comparatively ugly and
complicated hacks), for the mentioned reason.
---
Ondra Ãada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc -
At 10:06 AM -0500 9/20/04, Darrin Cardani wrote:> At 10:52 AM -0400 9/20/04, J Nozzi wrote:
>> There are plenty of discussions on the matter and it's up to you,
>> Darrin, to decide which way best fits your app's design. If it's
>> not something that is needed all the time, try a tab view, a sheet,
>> or even a drawer (though for some reason there's great hostility
>> toward drawers in some camps; I see no problem with them if they're
>> used properly).
>
> This is an iMovie plugin. Or more accurately, it's 2 different
> iMovie plugins that share a lot of code and have very similar UI's.
> When the user chooses the first plugin, they get the window with all
> the controls. When the user chooses the other plugin they get the
> window without a couple of controls. It's not a situation where
> doing something within the window shows or hides the UI elements.
> But it makes the size of the code and resources smaller to do it
> this way. I don't believe that breaks the design guidelines you
> speak of.
>
> Thanks for all your help,
> Darrin
Can you just have two different nibs? That way you can also
re-layout the one without the extra elements and not have any ugly
"big missing gap space".
(Granted, this will require making sure that you keep the two in sync
when you make other changes, but I'd think that providing a different
nib name string is a whole lot easier than going through and hiding a
bunch of elements).
--
Glenn Andreas <gandreas...>
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know -
On Sep 20, 2004, at 7:45 AM, Ondra Cada wrote:> There was a reason, by the way: in NeXTStep, hiding views was
> considered a pretty bad UI design: if something does not work in
> current circumstances, it should be disabled, not hidden. The user
> should see the complete UI. OTOH, if something in some circumstances
> does not make sense at all, it belongs into another tab or into
> another window. Myself, I can't help it, but the adage still sounds
> reasonably to me.
It is reasonable. Willy nilly hiding things makes an app harder to
learn. Remember Micorsoft Word's short menus/long menus fiasco?
That said, not every view is a thing to be manipulated. For example,
progress indicators and status texts, icons next to controls that warn
you that something needs attention. These things can (should) be hidden
when they don't apply, without being considered "bad UI".
_murat
