> 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 b&w 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
