[Okular-devel] Consistency in user interface

[Jonathan Schultz]

> They operate differently because they do different things, after drawing the
> rectange there's nothing else you want to do so the menu is triggered
> immediately.

I differ with this interpretation in several ways:

1. On what basis do we know 'there is nothing else you want to do'? Some 
useful examples of things you might want do do include adjusting the 
boundaries of the selected area, making a compound selection (eg by 
selecting another area while holding the control key), displaying 
properties of the selected area, just to name a few. The fact that none 
of these have been written yet is not a good reason to preclude them. 
Moreover, my current project (more on this below) will need some of 
these functions (at the least adjustment of the selection boundaries), 
and I believe that such a change would be an improvement of Okular as well.

2. It means that Okular is unlike just about every other GUI program 
ever written. I tried to find a reference to UI standards in the KDE 
Usability standards, and it is a bit unclear, but I think that the 
'correct' (ie standard) way is implicit in the description of context 
menus: https://techbase.kde.org/Projects/Usability/HIG/ContextMenu

3. The same logic of 'there is nothing else you want to do' would also 
apply to text selections, yet Okular uses a more standard approach with 
those. In this sense Okular's behaviour is clearly inconsistent.

  On the table selection mode, you need to "draw" the table in
> multiple strokes, so you need a way to get out of it (i.e. escape).

4. I don't have such a big problem with this aspect (ie it is less 
disruptive to my personal project). However in the context of this 
discussion I would point out that the first time I saw table selection 
mode I thought that Okular had hung, because it stopped responding to 
mouse presses outside the selected area. Yes, there was a message 
telling me that I had to press escape, but that was not immediately 
obvious as it blended a bit too easily with the contents of my document. 
I do feel that a more friendly and intuitive approach would let the user 
get out of the table 'drawing' mode via right-clicking.

  The text
> selection mode works like other text selection modes.

Exactly - this is why I suggested that the same behaviour should guide 
the other modes.

The whole reason I am getting involved in this discussion is that I am 
working on code that does offer the user other things to do (ie 
'tagging' the region with various codes) with a rectangular selection. 
If I have to modify the behaviour of Okular to do this, then I will just 
go down that path. However, given that the Okular UI seems to me to have 
clear room for improvement here, I thought I would like to raise this as 
a topic for discussion.
>
> I find they are quite consistent in how you want to use them.
>
> Cheers,
>    Albert

Best,
Jonathan

>
>>
>> I would like to suggest that the operation be standardised around the
>> current behaviour in text selection mode, as this is standard GUI
>> behaviour. In addition to eliminating the current inconsistency, this
>> would permit a wider range of context-dependent options to be made
>> available via right-click. We could also (eventually) do more fancy
>> things like allow compound selections, even of different kinds and get
>> rid of the zoom tool entirely, by making 'zoom to selection' and 'zoom
>> out' as right-click options, depending on whether or not there is an
>> active selection. None of this seems very difficult to do at all - the
>> code is all in ui/pageview.cpp and it would simply be a question of
>> rearranging the functions that handle mouse button presses and releases.
>>
>> FYI the reason why I am interested in this is that I am working on using
>> Okular as the basis for a mark-up/tagging tool for qualitative research,
>> as a part of which I need to extend the range of functions that can be
>> applied to selections. See a brief discussion here:
>> https://mail.kde.org/pipermail/okular-devel/2015-November/021920.html
>> and the code itself here: https://github.com/jschultz/okular-tagging
>>
>> Cheers,
>> Jonathan
>>
>>
>> _______________________________________________
>> Okular-devel mailing list
>> Okular-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/okular-devel
>