Re: re Hiding controls and another question
Re: re Hiding controls and another question
- Subject: Re: re Hiding controls and another question
- From: Dietmar Planitzer <email@hidden>
- Date: Fri, 01 Mar 2002 13:25:41 +0100
>
From: Sam Goldman <email@hidden>
>
>
The Objective-C method of hiding controls is, from what I have heard, and
>
very object-oriented and sophisticated style of doing it. It may be more
>
difficult to adjust you perspective to that kind of mind frame than it is to
>
actually hide the control.
Well, the method of hiding and showing controls or arbitrary views in Cocoa
is neither very object-oriented nor sophisticated.
All we currently have is a choice between a number of hacks and workarounds.
The three most prominant examples being:
1) Leave the view which you want to hide in the view hierarchy but move it
to an invisible part of the superview (i.e. move it to 5.000, 5.000). Sure,
the view is now invisible but it's still in the responder chain. Thus a user
which has full keyboard navigation turned on will now start to wonder why
suddenly the keyboard focus indicator disappeared because he just hit the
tab key (because our supposedly hidden view is now in focus) and then, after
hitting tab a second time, reappears again out of nothing. The same is true
for controls with a command key shortcut (this functionality was enabled in
10.1). Quite confusing if you ask me. Also, it's not really clear how the
hidden view reacts to a change in the size of the superview.
2) Pull the view from the view hierarchy. While this solves the responder
chain problem it introduces another very annoying problem: what if the size
of the superview changes while our view is not in the view hierarchy. Our
view won't be automatically resized in this case so we will have to do it by
hand once we plug the view back into the view hierarchy. However, resizing
the view manually is not always a trival task because not only the size of
it may be affacted by the superview size change but also, depending on the
autoresize flags, its origin. It also requires us to track the size changes
of the superview manually so that we even know by how much the size of it
changed. While we're at it, you haven't forgotten to retain the view before
you pulled it from the superview, have you ? :)
3) Put the view inside another 'proxy' view. Now whenever you want to hide
your view pull it from the proxy view. Whenever you want to show it put it
back into the proxy view. This makes the resizing problem simpler because
the proxy view will participate in the resizing business of the view
machinery while your view is not part of it. Thus the proxy view will always
have the correct position and size. Now when you want to show your view, you
put it back into the proxy view but you still have to manually adjust its
size to that of the proxy view. This solution however, requires you to add
another view to the view hierarchy, which doesn't serve any real purpose. It
just makes the view hierarchy more complex and thus slower to draw
(especially annoying in connection with live window resizing).
Compare these 'solutions' to a really object-oriented and sophisticated
solution like the following:
[myView setVisible: YES] and [myView setVisible: NO].
Just one line of code to show and hide a view and it'll work correctly under
all circumstances. Best of all, its no more complicated than what you can
find in the Carbon API (ShowControl/HideControl) and what you can find in
every single, even most simplistic, C++ framework for the MacOS toolbox.
Many Mac OS applications have traditionally shown and hidden controls based
on the current application context. I.e. apps that have a mode for novice
and one for expert users. In such a situation it doesn't make sense to
display controls which are only supposed to be used by expert users to the
novice, especially not if they are always disabled. Such visisble but
disabled controls would just confuse the novice user and eat screen
real-estate for no good reason.
The probably best example for a control which should only be shown if
necessary, is the famous progress indicator. Why show this control if there
is no progress to show ? Doesn't make sense. In fact you can find an
instance of this example in your own copy of PB. It only shows the build
progress indicator in the lower left window corner if you're actually
building your app but not otherwise. Simply because otherwise it would be
confusing for the user (what's that control for, doesn't do anything while I
edit this source file ?) and distracting. This is such a natural and
expected behavior that i.e. the Carbon Chasing Arrows control has this
auto-hiding behavior even built in from the start (take a look at the Finder
some times).
Anyway, there is no way that you could ever prevent people from doing
certain things by not offering the necessary API. This is just one big
single fallacy. Its much better to offer API for these things so that at
least folks use methods that are guaranteed to work under all circumstances
and system versions. Otherwise, they are just going to use private API
anyway or come up with there own solution that surely might work with the
current system version and under all situations for which they explicitly
tested, but might break with just the next OS version or in more unusual
environments. Not to neglect the fact that by necessity thrid-party
solutions often are slower than a solution built into the framework (take
class-dump and check the live resize machinery in the AppKit out some time
if you don't belive this).
Further, I think it would be better to offer a show/hide view API and to
extend the Aqua Guildlines with a chapter about the One And Only True Way of
showing and hiding controls, rather than simply ignoring this problem.
Regards,
Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.