On Sat, 26 Jul 2003, Michael Nordstrom wrote:
> Well, I thought the "scroll past the bottom" was a different feature,
> but that was just a change from compile time to run time selection.
> However, I don't think that was a "good" change. I'm already a bit
> "worried" about the size of the viewer and to avoid turning it into
> bloatware it is necessary to be a bit "restrictive" about what options
> are included in the viewer.
>
> Unless you can provide a very good reason for why it should be
> selectable at run time I guess this feature will be moved back to
> a compile time switch.
I think it's a nuisance to be distributing thirty different binary
versions (15 languages x 2) just so users can choose whether they want
scroll to bottom. I think the vast majority of users are quite incapable
of recompiling the source. The more feature combinations we have, the
more binaries...
But perhaps it would not be too bad just to have one light and one full
version, each in the 15 languages, as long as there isn't any further
multiplication.
I also think we can reduce much of the file-size bloat just by deleting
the unnecessary fonts. The viewer_en.prc I now build is 235475 bytes.
Removing all nfnt resources gets us down to 214531. And I assume that the
hi-res users are more likely to have more memory, so a light version
wouldn't need them. There is 12K in bitmap resources. A lot of that is
in multiple versions. Again, users more likely to be short of memory
aren't going to need most of them--the b&w ones will be enough. One can
also remove the help tSTR resources, but I would be reluctant to do that.
In fact, for OS2 use, one doesn't need any custom font resources at
all--they're not supported. That's another 14K less.
> > You may have noticed that PyPlucker now has a new option
> > that lets you control whether you want the links to still show up
>
> Wouldn't it be possible to just not draw the links in the viewer
> when you connect the "parts"?
That would take a lot of special-casing whenever one draws paragraphs,
whereas there really is no reason now that the viewer supports seamless
fragments for PyPlucker to be producing the links except for the benefit
of users of older versions.
> Things I'm considering to remove,
>
> - The Read/Unread status indicator in Details.
> - Click sound for links (could be made the default action
> and then it is up to the user to turn off the sound if
> they find it "annoying".)
I find it annoying, but then I have the sound off anyway. :-)
> None of these would decrease the size that much, though.
>
> Things that could be made into compile time options,
>
> - Enable image caching.
> - Keyboard/graffiti.
I'd like to keep this and move hard-key and page up/down support out of
Prefs() and into the keyboard mapping databse. This would make things
simpler.
> I'm still not convinced about the "Force default text colors"; as I
> said in the bug report I don't think it is a viewer "problem" (the
> parser should create readable documents)
True, but it is a convenient little thing for users to have. One might
find the colors in the text annoying, too.
> "Enable dynamic scrollbar" should be moved to General (i.e. together
> with the scrollbar option) or maybe it should be the default action
> and removed from the preferences.
I have the dynamic scrollbar disabled myself, as this way I can scroll to
the end faster. I don't think it should be a default unless we make
Plucker fast enough that one can drag to the middle of a 1mb file in
dynamic mode.
* * *
I don't want to have multiple binary versions floating around. But I also
understand memory limitations. I don't mind your suggestion of a single
light version. We would need to settle on just what features to throw
into it (rotation, user fonts, nfnt resources, vfs, jogdial,
keyboardform (but keep keyboard.c stuff and use to implement hard keys and
paging keys), multiimage, tables, etc., are natural things to omit from
it). What I do not think we should have is multiple light versions.
The scroll-to-bottom thing is a special case. There are two main kinds of
users. There are those who are using Plucker for web-type viewing and
there are those who are using for ebook-type viewing. My guess is that
the web-type users might like scroll-to-bottom but it does make
ebook reading confusing (even with the little black dot marker). So it
would be quite a toss-up as to which one should be in the light version,
and I don't think we want to distribute: 45 versions:
full (x 15 langs)
light with scroll-to-bottom (x 15 langs)
light without scroll-to-bottom (x 15 langs)
And we certainly don't want to distribute 60 versions:
full without scroll-to-bottom (x15)
full with scroll-to-bottom (x 15 langs)
light with scroll-to-bottom (x 15 langs)
light without scroll-to-bottom (x 15 langs)
Alex
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department || online papers and home page:
Georgetown University || www.georgetown.edu/faculty/ap85
Washington, DC 20057 ||
U.S.A. ||
-----------------------------------------------------------------------------
"Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
- Paul of Worczyn (1424)
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
