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