[Okular-devel] Layout of the toolbar

[Florian Graessle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pino Toscano wrote On 14.05.2007 22:25 Uhr:
> Alle 16:47, lunedì 14 maggio 2007, Florian Graessle ha scritto:
>> To make a long story short, I (once again ;) ) suggest to remove the
>> "Open/Open Recent..." toolbar entry.
> 
> Seems fine, although I'll readd it for me :P
> But yes, the average user will probably open more document directly from the 
> file manager/the Internet than from the application itself.

Fine :)

>>> || Previous page | Next page ||
>> The Oxygen icon survey showed that a lot of people mistake the
>> "Back/Forward" buttons for the "Previous Page/Next Page" buttons, so I
>> second your proposal. Do you plan to display the current page number
>> there too?
> 
> If I recall correctly, our guidelines say to not have/show informations in the 
> toolbars, but use the status bars.
> Nowadays, basically almost the most important document readers for GNU/Linux 
> out there have the page number in the toolbar, but of course this does not 
> mean it's really correct, isn't it? ;) So, I still think the new solution we 
> have (like a past version of acroread) might work as well.

Yes, taking into account that going directly to a given page number is -
compared to the other toolbar actions - a rare task I think the same.

Speaking of the status bar, there are more uses possible than just
displaying the page number. We could expand its functionality further
and use it as a means to display context sensitive information. E.g. if
we remove the zoom tool it can still live on as a key combination like
ctrl+shift+mouse selection. This would be similar to what is already
possible with ctrl+shift+mouse wheel. The status bar which currently is
pretty much empty anyways seems an apt place to display such context
sensitive interaction tips.

> (Btw, how does the Preview application of MacOsX behave in this sense?)

Preview behaves like most of the other readers out there and features
both an input and a status widget for the pages in the toolbar.

>>> Browse tool | Zoom tool | Select tool | Text Selection tool
>>> with the option of removing one of Zoom tool/Select tool.
>> We should probably consider putting an "Annotation tool" there as well,
>> since it is another exclusive tool mode.
> 
> Hmm, yes and no. The annotating mode is an "extra mode" of the normal mode, 
> and if you select it, it will automatically switch back to the normal mode 
> first. Aaron suggested me such a solution, that seems quite reasonable.

Hm, did Aaron mention anything why reviewing should be an extra mode
only of the normal mode? I have a feeling that the current solution
complicates things unnecessarily:

Enabling the "Review" pane switches from the non-Browse tools to the
Browse tool. So it is not possible to be in e.g. Selection tool mode and
at the same time have the review actions open. The Review entry in the
View menu however doesn't imply any connection between the Review mode
and the Browse tool mode. Also, disabling the review bar always leaves
the user in the Browse tool mode - no matter in which tool mode he has
been before. All this makes it difficult to build a mental model of how
the tool modes effect each other.

Wrapping up, in many regards the review bar already behaves just like
another tool. So I really think that actually making it another tool
mode would make things more comprehensible.

Florian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGUrwq3KoOvOZK8jYRAkjnAKCeVnto+UDErIqWOhT6I9kYEBpa0QCfYwXp
nDskBWVpjnA/CIssFtvAFPM=
=QEXx
-----END PGP SIGNATURE-----