commit -- Win32 toolbars hideous, but functional

Paul Rohr (paul@abisource.com)
Sat, 14 Nov 1998 05:16:53 -0800


Checkpoint. Initial toolbar implementation using Win32 common controls.

M src/ev/win/ev_Win32Menu.cpp
M src/ev/win/ev_Win32Toolbar.cpp
M src/ev/win/ev_Win32Toolbar.h
M src/ev/win/ev_Win32Toolbar_ViewListener.cpp
M src/ev/xp/ev_Menu.cpp
M src/ev/xp/ev_Toolbar.cpp
M src/wp/ap/win/ap_Win32App.cpp
M src/wp/ap/win/ap_Win32Frame.cpp
M src/wp/ap/win/ap_Win32Frame.h
M src/wp/main/win/Makefile
M src/wp/main/win/Win32Main.cpp

CAVEAT -- There aren't a lot of changes here, but they're spread fairly
broadly across the tree, so Win32 folks should play it safe and do a full
rebuild.

The final effect is *incredibly* ugly (see #1 below), but enough work has
been done to prove that the following mechanisms all more or less work:

- toggling and disabling buttons in response to document state
- triggering edit methods from toolbar buttons
- button labels and tooltips
- and yes, there *are* multiple toolbars stacked there

It's enough of a start to prove the concept, but there's still a decent
amount of polishing to do, primarily:

1. Keep multiple toolbars from clobbering each other. As best I can tell,
the toolbar control resists attempts to move it down-screen, and glues
itself to the top of the screen. Since we've got two of them stacked on top
of each other, it gets gruesome. Fast.

(a) One solution would be to subclass the control just so that we could
position the beast where we want it. This seems like overkill.

(b) The cooler solution would be to work through the various build and
distribution headaches so that we can use the rebar control as a
container for all our toolbars.

2. Get real icons instead of that placeholder, by whipping up some code to
convert all those lovely XPMs to palette-friendly BMPs at runtime. Oh joy.
At least then we'll be able to turn off the icon labels (by default) to
conserve screen space.

3. Get matching artwork for the format toolbar.

4. Tidy things up by moving the long status messages down to the status bar
where they traditionally belong, use shorter prompts on the tooltips, and
perhaps even append the current keybinding to the tooltip.

5. Replace the font button (which raises the font dialog) with two combos
that allow you to see and change the font face and size.

Bottom line -- #1, 2 and 3 are probably showstoppers for M1, but #4 can
wait. #5 would be a really nice touch to round out the M1 user experience,
but it's not clear how much time it'll take to get the feature done right on
both platforms.

Once again, kudos to Jeff for doing such a great job with the shared
framework, which really simplified the required platform-specific work.

Paul



This archive was generated by hypermail 1.03b2.