Subject: Re: Two toolbars; should enable/disable seperately
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Mon Feb 28 2000 - 20:57:20 CST
On Mon, 28 Feb 2000, Paul Rohr wrote:
> 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.)
Seems like there are options for the same thing in two places. Sounds bad
to me.
> 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.
I'm not sure I understand what a tri-state checkbox is. Can you point me
to a screenshot? I probably have used them before, but just am not
familiar with the term.
As for toolbar selection, I remember the toolbar selection from Word was
adequate. I don't usually reccomend Microsoft as a user interface example,
but from memory they did a good job with selecting what toolbars you want.
I forget exactly how it was done in word. I think that this does merit
some UI thought. One approach would be to have two CLists (GTK term for
list box), one with the selection of available toolbars and one with the
selected toolbars.
I think the best solution, though, would be to have a list of available
toolbars with a toggle button next to each one to indicate if it is
enabled.
> >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,
Sorry to whine about your C++ standards, but I don't see any reason why
multiple inheritance is slow, complicated, or bad in any way. If the
reason for avoiding this is to attract C programmers, you might as well
use ANSI C. Multiple inheritance has lots of valid uses and as long as it
is not abused I think it is very useful. If someone can understand C++
single inheritance, they can understand multiple inheritance. I don't see
why it would be a barrier.
> 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. :-)
I'd like to work on the XP parts. I am very busy right now (homework :(),
but I'll look at these classes when I have a moment.
> 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).
Yes, I am very suprized that you went through the work of designing a
cross-platform framework but used so much platform-specific code! Simple
polymorphism can handle this very well, and I will look at the current
state of the code and see how I can improve it.
>
> Does that make sense?
Yes. Thank you.
> Paul
>
>
>
This archive was generated by hypermail 2b25 : Mon Feb 28 2000 - 20:57:26 CST