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@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel
_______________________________________________
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel
