Great work. I had to fix a minor bug in the viewer.rcp.in file or
it wouldn't compile (the PUSHBUTTON had a NOFRAME option that can't
be used for these buttons --- maybe it should be DISABLED, too).
Whoops, forgot about that stray NOFRAME, thanks for catching that. DISABLED
is a good idea, I left it off just since that what the PalmOS time set popup
does, but there isn't any real need to be able to click on these ones.
Disabled it is.
Another thing (that I won't fix:) is that the new strings should
be added to a *all* language files.
Will do. For the translations of languages I don't know (almost all of
them), is it recommended that I just write the english in, for that language
maintainer to append? Or consult babelfish?
I don't think the narrow fixed font should be available in the
Preference form (it should only be used for the pre text).
That one wasn't really a conscious decision--just an artifact that this is
from an earlier version of the current version in the trunk that has pre
tag working instead of just a drop-down option. But just as a question, is
there a particular reason that you don't recommend a fixed width as an
option, since it's already been pretty well paid for in terms in terms of
the font resource? Most people I know prefer to read their email in constant
width text, even though could also read in a variable width font.
BTW, before this code is merged with the main trunk a description
of the autoscroll feature should be added to the documentation.
We might have to think about a way to remove the autoscroll control
(and also other controls) from the toolbar. As you can see the toolbar
is quite crowded at the moment, so it will not be possible to add any
other controls to it. Maybe it should be possible to configure the
toolbar, i.e. be able to choose what controls that should be included.
Some of the controls (e.g. back, home, forward) could always be
included while other controls would be optional.
Certainly a fair thing if there is many more buttons coming in that would be
tapped often enough to warrant not having to go to the menu each time. Right
now, I can testify first hand that there is no room left for a new button,
after many hours of both the bw and colour icons. If there is something new
that comes up that needs toolbar real estate, I would probably most
recommend sacking the +, - buttons and using those pixels for the incumbent
button. A toolbar selector option would be a handy feature (a list of
checkboxes of controls to display--this is the route that CSpotRun takes?).
I agree that a toolbar manager is probably a better solution than just
hiding the autoscroll since there is no net gain really of just hiding it
(leaves a hole in the middle of the toolbar that can't be used for anything
else), and if things are to slide over and replace it, on the way to a
toolbar manager already.
Best wishes,
Robert
