[Okular-devel] Consistency in user interface

Mon Feb 29 01:29:57 UTC 2016

On 29/02/16 10:08, Albert Astals Cid wrote:
> El Monday 29 February 2016, a les 09:13:10, Jonathan Schultz va escriure:
>>> 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,
>
> This feature doesn't exist

'Doesn't exist' is not the same thing as not "want[ing] to do" them, 
which is the statement I was responding to.

>> making a compound selection (eg by
>> selecting another area while holding the control key
>
> This feature doesn't exist
>
>> ), displaying properties of the selected area
> This feature doesn't exist
>
>> just to name a few. The fact that none
>> of these have been written yet is not a good reason to preclude them.
>
> Yes it is, why make you take an extra step to do the only thing you can do in
> spirit of adding features that may never exist?

As I mentioned, I am in the process of adding such a feature, and am 
working out how to integrate it into Okular.

>> 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.
>
> If there are new features that make sense adding an additional step in between
> selecting the area and showing the menu, it may make sense to add such step.

I'm happy to show this to you when I am ready. It's just that I'm going 
to have to modify in some way the UI in order to do so.

>> 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
>
> *every other GUI program ever written* is a very strong statement, you may
> want to reconsider it ;)

You misquote me. I said *just about* every other GUI program.

>> 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.
>
> As i said, there's a well known pattern for text selection out there, so we
> follow it. And it fact it *does* copy the text, you can just middle click
> somewhere and it will paste it.

Yes but in that case the text does not pass by the clipboard, so it 
isn't really the same thing.

>>
>>    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.
>
> Patches and ideas to improve the code are always welcome.

OK will keep that in mind.

>>    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.
>
> But the other modes are not "well known patterns" out there.

The table selection, I agree, is a bit special.. But when it comes to 
rectangular selections then I disagree. Look at KolourPaint (to stay 
within the KDE world), GIMP, Photoshop? And even then, to my sense, 
selecting is selecting, whether it is based on following lines of text 
or choosing a rectangle. In which case the pattern of 1. selecting, then 
2. doing stuff with the selection is certainly well established.

>
>> 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.
>
> As I said, if there's a need to change how the modes behave because new
> features are added, sure let's change them. And if there's ways to make some
> of the modes less confusing, let's do that too.
>
> Cheers,
>    Albert
>
>>
>>> 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
>>
>> _______________________________________________
>> Okular-devel mailing list
>> Okular-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/okular-devel
>