Bug 161020 - Okular deselection of yellow marker tool
Summary: Okular deselection of yellow marker tool
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.6.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
: 207657 233182 241007 264925 265578 268840 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-19 15:58 UTC by Bui Arantsson
Modified: 2017-03-18 13:01 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bui Arantsson 2008-04-19 15:58:13 UTC
Version:           0.6.3 (using KDE 4.0.3)
Installed from:    Ubuntu Packages
OS:                Linux

Possibly this belongs in the "wishlist" category. When using the yellow highlighter in okular 0.6.3, it is necessary to re-choose the marker to mark other lines after having marked something. In other words, the marker tool is deselected every time I have marked something. This is very annoying since I often mark several disjointed lines, and this have to re-choose the tool every time.
Comment 1 kde2eran 2008-04-30 23:04:13 UTC
I have the same issue: when highlighting parts of documents, I have to repeatedly choose the highlighter tool, which is inconvenient and error-prone.

Right now Okular has two notions of modal tools:
* Browse/zoom/select (in the toolbar)
* Highlight/line/etc. (in the review inset)

Can't the two notions of tools be merged into one simple mode?
Comment 2 Tiago Farani 2008-05-31 21:02:47 UTC
I'm new to linux and okular definetelly has made me switch from Windows to Linux, but i have to say that i have the same issue. It`s very annoiyng to have to select the review tools every time i want to use it.

Hope that it is solved soon.
Comment 3 utonto 2008-09-08 13:05:37 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 Christian Weickhmann 2008-11-15 11:49:53 UTC
Proposal: Some text processing programs let you double click or re-click  the tool on selection (the button is then sunken or in a grey shade) and the tool stays active until click on the same button or any other tool.

How about that?
Comment 5 Bram Schoenmakers 2009-11-21 17:06:29 UTC
*** Bug 207657 has been marked as a duplicate of this bug. ***
Comment 6 niburu1 2010-02-07 18:09:38 UTC
This behavior is quite annoying, and perhaps it is partly due to the fact that the review bar is not a "proper" toolbar like it *should* be (and there is a wishlist for its being so).
Comment 7 Johannes Simon 2010-02-07 18:34:31 UTC
The fact that it is not a "proper" toolbar has nothing to do with the fact that the buttons have an unintuitive behaviour. Also, there is a reason for it not being a "proper" toolbar because the current setup saves space. The review bar is drawn exactly where most documents have a border anyway, while only hovering over the document - thus not actually making the document's "canvas" smaller.
Comment 8 niburu1 2010-02-07 18:44:26 UTC
Saves space? I could add a single button to my toolbar that gives a drop down selection of review tools, and that saves much more space than having an thick review bar on the sides/top/bottom of my document. Also, given that Okular has a "trim margin" feature (which I happen to always use), there really are no borders or otherwise whitespace that could be best filled up by a hideous review bar. I just don't see any benefit of the review bar not being a proper toolbar except for the fact that one may hide/reveal it using a single key (or combination) without hiding the standard toolbar.
Comment 9 Johannes Simon 2010-02-07 18:50:09 UTC
There's two problems with having the review bar as a drop down menu:
1) You have to move your mouse farther to select a tool
2) You have to click more often

All in all I bet that this user interaction would take at least 3 times longer if the review bar was replaced by a drop down menu.

Also note that not everyone trims the borders of a document. They're there for a reason, and imo make the document more pleasant to the eye and therefore more readable.
Comment 10 niburu1 2010-02-09 11:58:20 UTC
(In reply to comment #9)
> There's two problems with having the review bar as a drop down menu:
> 1) You have to move your mouse farther to select a tool
> 2) You have to click more often

I don't understand (1). Depending on where one places their pointer (and review bar too), they may or may not have to move the mouse further. As for (2), you do not have to click more often. You click and hold once or, if each tool is assigned their own toolbar button, you just click once. To bring up the review bar, you have to either click a toolbar button or press F6, and *then* you need to select a tool. 

> All in all I bet that this user interaction would take at least 3 times longer
> if the review bar was replaced by a drop down menu.

Clicking and holding for a drop-down button would take insignificantly longer, but assigning each tool their own button wouldn't. Indeed it would be faster.

> Also note that not everyone trims the borders of a document. They're there for
> a reason, and imo make the document more pleasant to the eye and therefore more
> readable.

Typically margins exist out of printing concerns and have nothing to do with screen display. Whether margins make a document look more pleasant to the eye varies per reader. It doesn't for me or anyone else who trims margins.

I don't think either of us will convince the other about which implementation is better, nor do I think that this is the right forum to do so. There is another bug filed for this.
Comment 11 Pino Toscano 2010-04-07 22:06:36 UTC
*** Bug 233182 has been marked as a duplicate of this bug. ***
Comment 12 Pino Toscano 2011-01-31 15:14:50 UTC
*** Bug 264925 has been marked as a duplicate of this bug. ***
Comment 13 Dotan Cohen 2011-01-31 19:27:33 UTC
> There's two problems with having the review bar as a drop down menu:
> 1) You have to move your mouse farther to select a tool
> 2) You have to click more often
>

If having to click too often is a concern, then why does the Highlight icon require a click after each line of highlighted text? Seriously, fix that first.
Comment 14 Albert Astals Cid 2011-01-31 19:39:38 UTC
You can highlight multiple lines in one go. Seriously.
Comment 15 Dotan Cohen 2011-01-31 20:02:45 UTC
> You can highlight multiple lines in one go. Seriously.
>

I'm not highlighting continuous blocks of test. Seriously.
Comment 16 Albert Astals Cid 2011-01-31 22:02:40 UTC
Then your description of the problem is incomplete ;-)
Comment 17 Dotan Cohen 2011-01-31 22:15:09 UTC
You're right. That should have read "each block of highlighted text". Sorry!
Comment 18 raffamaiden 2011-01-31 22:57:58 UTC
I think we should definitively fix this as it is very annoying and prevent
for using okular for regular use (well there is another thing which prevent
me, but i will submit a proposal afterwards).

@Dotan Cohen: I still would like to know why you cannot double click, if you
can tell us of course (maybe it's personal .... who knows?). So we can find
a solution .... fix your double clicking problem or work around it (a menu
checkbox?)


2011/1/31 Dotan Cohen <kde-51@dotancohen.com>

> https://bugs.kde.org/show_bug.cgi?id=161020
>
>
>
>
>
> --- Comment #17 from Dotan Cohen <kde-51 dotancohen com>  2011-01-31
> 22:15:09 ---
> You're right. That should have read "each block of highlighted text".
> Sorry!
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> Okular-devel mailing list
> Okular-devel@kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel
>
Comment 19 Albert Astals Cid 2011-02-01 00:53:10 UTC
SVN commit 1218185 by aacid:

Allow the "continuous" selection of a tool by double clicking on it
Patch by Raffaele Mancuso cleaned up by me
This will be in KDE 4.7.0
This fixes the original report of bug 161020 so i'm closing it
If there were any other different wish report in that bug, do the proper thing an open a new one
BUGS: 161020


 M  +31 -7     pageviewannotator.cpp  
 M  +4 -0      pageviewannotator.h  
 M  +6 -0      pageviewutils.cpp  
 M  +8 -0      pageviewutils.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1218185
Comment 20 Dotan Cohen 2011-02-01 09:00:45 UTC
@raffamaiden: I have a manual disability. I can double click but it is painful. One of the great things about KDE is the single-click mode that affects all KDE applications, from Dolphin (KDE SC) to Digikam (Independent release schedule). If this feature requires double click then it will be in violation of the Single Click accessibility mode. See:
System Settings -> Input Devices -> Mouse -> General (translated, but it should be something like that)

Interestingly, this option used to be under Accessibility, but I understand why it was moved to Mouse.
Comment 21 Albert Astals Cid 2011-02-01 09:53:12 UTC
Would "Shift+button Click" be an option for you to enable the "continuous mode"?
Comment 22 Dotan Cohen 2011-02-01 14:16:45 UTC
> Would "Shift+button Click" be an option for you to enable the "continuous
> mode"?

Yes, that would be great! Thanks!
Comment 23 Pino Toscano 2011-02-06 10:23:30 UTC
*** Bug 265578 has been marked as a duplicate of this bug. ***
Comment 24 h.i.m 2011-04-01 11:20:43 UTC
What do you think about the following behaviour:
click short -> onetime selection
click long -> constant selection

--> no double click, no extra key (shift)
Comment 25 Dotan Cohen 2011-04-01 13:49:03 UTC
"Click Long" does not currently exist as a known UI event. I think that introducing a new UI event would be terrible for usability. Why not right/middle click?
Comment 26 Fabio D'Urso 2012-08-18 18:53:37 UTC
*** Bug 241007 has been marked as a duplicate of this bug. ***
Comment 27 Fabio D'Urso 2012-08-18 18:56:58 UTC
*** Bug 268840 has been marked as a duplicate of this bug. ***
Comment 28 Mostafa Hussein 2012-09-29 19:47:00 UTC
Great to find this bug fixed. However, I only found out that by double-clicking the highlighter will change to continous operation from this bug report. It will be great if the user is notified about this feature somewhere.

For example, the bubble that appears in the upper left corner when you select the highlighter can contain a second line saying something like "Double-click for continous mode". Or perhaps the tool-tip.

Also, I wonder if it's possible to have undo, instead of right-clicking than choosing delete everytime I want to remove a highlight.

I'm using Okular 0.14.3.
Comment 29 Avinash Sonawane 2017-03-05 05:58:20 UTC
>It will be great if the user is notified about this feature somewhere.

I second this.

I can see that the bug has been resolved in 2012. And in 2016 I had to search the Intenet if it's possible to do that in Okular. And I ended up here via a mailing list maintaining bug summaries.

So yes. Please document this in UI.
Comment 30 Oliver Sander 2017-03-06 11:19:57 UTC
The okular documentation is at

   https://cgit.kde.org/okular.git/tree/doc

(in docbook format).  It would be easiest if you could simply add the missing information there, and submit this as a patch.
Comment 31 Avinash Sonawane 2017-03-06 18:05:16 UTC
>(in docbook format).  It would be easiest if you could simply add the missing information there.

No. You don't understand. I am suggesting to add this in *UI* exactly what comment #28 have said.
Comment 32 Albert Astals Cid 2017-03-06 21:03:27 UTC
If you want something different to what this bug was about, you should really open a new bug.