Re: automatic presentation mode



> and I've been pretty negative on it for a while.  I'd really, really
> like evince to be primarily a kick-ass document reader and I wasn't sure
> how well presentations fit into that.  It seemed that making a really
> good presentation program would be orthogonal to our primary goal.
> 
> After talking with Bryan today, we came up with the following proposal:
> 
>  * We should merge the separate 'Presentation' and 'Fulcrum' modes.
>    'Presentation' mode is just fullscreen without dual or continuous
>    set.  This kills a menu-option, and (more importantly), a series of
>    code-paths in ev-view.c.

I would be very sad to see fullscreen and presentation modes merged.  I
use both of these modes extensively and I think merging them will lead
to omission of important features and reduced usability for at least one
of these modes.

While evince is a document reader, I think anything pdf is intended to
do should be included in the definition of document.  Two important and
very different uses of pdf are presentations and books.  I use the
fullscreen mode for reading books and long articles and presentation
when I give a seminar or teach a class.  I don't want presentation type
features enabled when reading books or vice versa, and reducing the set
of available features to those common to both uses incurs a terrible
cost.  

Consider for a moment key bindings.  Under the proposed merger, will it
be possible to use left and right mouse buttons to move forward and
backward in a presentation, for example?  Assuming that pdf documents
will include enough hints to make evince work well for presentations
while in the same mode as one would read a book sounds like a problem to
me.  I forsee bug reports to which the resolution is "your document was
not created properly."  

Another example: at the end of a presentation, an excellent behavior is
for the presentation to end and to return to normal viewing mode.  Will
we need to omit this feature or hope that evince will be intelligent
enough to turn on a switch for this?  

And why would anyone want automatic movement through the document in any
mode besides presentation?  I, at least, don't see the need.

Fullscreen as it now stands is an excellent feature which can be turned
on by the user after startup in order to use screen real estate
efficiently; presentation mode is working very well for those documents
that were created to be presentations.  It is all working well, why try
to force oil and water to mix?

Simplicity of menus and code is an excellent goal, but in this case the
two modes are different and important enough that I think the merged
code will ultimately be more complicated, not less, and it will be more
difficult to get the key features (particularly in presentation mode)
that really make evince the all purpose document viewer we need.

Grant
________________________________________________________________________
Grant Verdell Farnsworth 
Ph.D. Candidate, Finance 
Kellogg School of Management
224-715-0463 (M)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]