Subject: Re: Two toolbars; should enable/disable seperately
From: Paul Rohr (paul@abisource.com)
Date: Mon Feb 28 2000 - 20:28:20 CST
At 04:23 AM 2/27/00 +0000, Aaron Lehmann wrote:
>I notice that in the options dialog there is an option to disable or
>enable the toolbars. What if you want to be selective (like me) and wan't
>one but don't want the other?
That's exactly what the toggleable View / Toolbars menus are for. Just
pull-right and click and they should come and go as needed. (The behavior
would be comparable to the existing View / Rulers menu item.)
As for the Options dialog, since there are likely to be more toolbars over
time (rather than less), having one checkbox per toolbar here is likely to
get more and more cluttered over time. Instead, two alternative suggestions
would be to:
1. Cut the toolbar checkbox entirely. This would probably be my
preference.
2. Keep it there as a tri-state checkbox instead. That way, you could
easily turn all the toolbars on or off at once. However, I'm not sure this
is all that useful.
>Naturally, the next thing I want to try is to make them work.
Cool! I've been meaning to write that up as a POW for a while now, but
haven't gotten around to it.
>I looked a
>lot around the code, and it looks like the logical way to do it would be
>to create a prefs listener in all of the platform-specific frame classes
>(ugh) and make it destory or recreate the appropriate toolbar. I don't
>think this really belongs in platform-specific code though, and the
>creation of the toolbars seems to be in the af/ subdirectory, meaning it
>would be framework code. Where do you think the code to handle this should
>go?
Yep. This should definitely be implemented in AF code, and it would be nice
to do as little of it as possible in platform code.
Currently, the call chain to create toolbars looks something like the
following:
AP_<os>Frame::initialize(void)
XAP_<os>Frame::_createTopLevelWindow()
EV_<os>Toolbar::synthesize()
The call chain needs to touch platform code in most of those places because
we're packing and unpacking platform-specific widgets inside the frame.
Even if you add a remove() method to each toolbar, you'll still need to
replicate the platform-specific widget-packing logic currently implicit in
the _createTopLevelWindow() implementation.
I will admit that the class factoring could arguably be improved here --
surely not *all* of that cut&paste duplication of code is necessary -- but
to date, nobody's taken a serious whack at figuring out a better way to
improve the amount of XP code over on the XAP side of the fence.
Since multiple inheritance is *not* an option here, Jeff had to make a
choice about which inheritance path seemed most optimal at various points in
the framework, and what he wound up with was:
- AP_<os>Frame : XAP_<os>Frame : XAP_Frame
- AP_<os>App : XAP_<os>App : XAP_App
By all means, wherever you can find clean ways to move the implementations
"up" the class hierarchy, please do so. For example, if you discover that a
contiguous block of 90% of the functionality of each of the XAP_<os>Frame
implementations of method foo are identical, then feel free to move that
logic up a level -- to ::foo() or perhaps a protected _foo() -- and call it
from each of the child implementations. The less code we have to maintain,
the better. :-)
In any event, you certainly shouldn't have to do the work *all* the way down
in the AP_<os>Frame classes, because the ruler widgets are app-specific,
whereas *any* app will want to be able to toggle off its toolbars (and
status bar).
Does that make sense?
Paul
This archive was generated by hypermail 2b25 : Mon Feb 28 2000 - 20:22:48 CST