[Okular-devel] [okular] [Bug 328576] Add keyboard shortcut for 'search previous' action: Shift+Enter

2013-12-30 Thread Saheb Preet Singh
https://bugs.kde.org/show_bug.cgi?id=328576

--- Comment #2 from Saheb Preet Singh saheb.pr...@gmail.com ---
Created attachment 84341
  -- https://bugs.kde.org/attachment.cgi?id=84341action=edit
proposed patch

The attached patch applies to the file ui/searchlineedit.cpp and
ui/searchlineedit.h

Added a key event listener to the SearchLineEdit for shift+return.

i am new to kde please guide me if something is wrong

-- 
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


[Okular-devel] [okular] [Bug 327376] Create straight freehand line by holding shift key

2013-12-30 Thread Saheb Preet Singh
https://bugs.kde.org/show_bug.cgi?id=327376

Saheb Preet Singh saheb.pr...@gmail.com changed:

   What|Removed |Added

 CC||saheb.pr...@gmail.com

--- Comment #1 from Saheb Preet Singh saheb.pr...@gmail.com ---
hi,

i am new to kde and want some help in solving this bug.

i am not clear about creating a freehand line by holding the shift key. I
tried in scribus and unable to create a freehand line by holding shift key.
Please guide me

-- 
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


[Okular-devel] [okular] [Bug 328576] Add keyboard shortcut for 'search previous' action: Shift+Enter

2013-12-30 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=328576

--- Comment #3 from Albert Astals Cid aa...@kde.org ---
Hi, can you please put the patch up at https://git.reviewboard.kde.org/, it
helps a lot with the reviewing

-- 
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


[Okular-devel] [okular] [Bug 327376] Create straight freehand line by holding shift key

2013-12-30 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=327376

Albert Astals Cid aa...@kde.org changed:

   What|Removed |Added

 Status|CONFIRMED   |NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #2 from Albert Astals Cid aa...@kde.org ---
He basically wants a way to create straight lines, I am confused though, since
we have a tool for creating straight lines. So maybe I was a bit too quick
setting this as confirmed.

Stephen, can you clarify why you need the straight line creation in the
freehand tool when we have a tool that creates straight lines?

-- 
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


Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved

2013-12-30 Thread Jon Mease

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114153/
---

(Updated Dec. 30, 2013, 12:53 p.m.)


Review request for Okular.


Changes
---

Added a status update to the description.


Repository: okular


Description (updated)
---

Update: The plan now is to only perform the internal rendering described below 
for Line, Ink, and Geometric annotations.  As I've worked with the internal 
rendering for these annotation types I've found several small bugs in the 
internal annotation rendering code that cause visual differences between 
Okular's rendering and Poppler's. My next steps are to open a series of bug 
reports and small review requests for these individual rendering bugs.  This 
review request can be considered to be on-hold until I've had time to document 
and fix these rendering bugs.


Unlike in other document formats, the annotations on PDF documents are rendered 
by the Poppler back-end along with the document itself.  Because this document 
rendering step is expensive we don't render annotations on PDF documents while 
the annotations are being moved (With Ctrl+Left click drag).  Instead of 
rendering the annotation itself during the move, we render a dashed outline of 
the annotation.  For non-PDF document types the annotations are rendered by 
Okular on top of the document, and so there is no large performance penalty in 
rendering the annotation smoothly as it is moved.  I find the aesthetic 
experience of moving annotations on non-PDF to be much more pleasing.

In this small patch updates the paintCroppedPageOnPainter() function draw 
external annotations using the internal annotation drawing logic while the 
annotation is being moved.  It also removes the dashed annotation outline 
during the move.  With this small change the experience of moving an annotation 
on a PDF now matches that of moving an annotation on the other document formats.

Two small oddities:  The rendering of the popup note icon differs between the 
Poppler back-end and Okular's internal rendering so the icon changes form while 
being moved and then changes back after being dropped.  The rendering of fonts 
on inline notes between the Poppler back-end and Okular's internal rendering 
seems to differ in some cases so as you move an inline note the font changes.

Thoughts?


Diffs
-

  ui/pagepainter.cpp d5d9c3e 

Diff: https://git.reviewboard.kde.org/r/114153/diff/


Testing
---

Tested drawing and moving each of the annotation types on a PDF document and on 
a DVI document. The behavior on the DVI document is unchanged. I find the 
behavior on the PDF document to be more natural.


Thanks,

Jon Mease

___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel