D21092: Okular Annotation: use the new signal-slot connect syntax

[Rajeesh K Nambiar]

knambiar added a comment.


  Review D21238  created for the line start 
style.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21092

To: knambiar, #okular, aacid
Cc: sander, tobiasdeiminger, aacid, okular-devel, joaonetto, tfella, ngraham, 
darcyshen

D21238: Okular Annotation: add support for line start style for Straight Line tool

[Rajeesh K Nambiar]

knambiar created this revision.
knambiar added a reviewer: Okular.
Herald added a project: Okular.
Herald added a subscriber: okular-devel.
knambiar requested review of this revision.

REVISION SUMMARY
  Similar to the line ending style, add support for line start style for the 
Straight Line annotation tool

TEST PLAN
  1. Go to Configure annotations
  2. Create (or edit existing) Straight Line tool
  3. Set the ‘Line Start’ option on Style and Apply
  4. Use the Straight Line tool to draw a line and check the line starting 
style.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21238

AFFECTED FILES
  conf/editannottooldialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/pageviewannotator.cpp

To: knambiar, #okular
Cc: okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid

[okular] [Bug 407579] New: Bad behavior of RadioButton groups in Optional Contents

[Édouard Canot]

https://bugs.kde.org/show_bug.cgi?id=407579

Bug ID: 407579
   Summary: Bad behavior of RadioButton groups in Optional
Contents
   Product: okular
   Version: 1.6.3
  Platform: Ubuntu Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-devel@kde.org
  Reporter: edouard.ca...@univ-rennes1.fr
  Target Milestone: ---

Created attachment 120100
  --> https://bugs.kde.org/attachment.cgi?id=120100&action=edit
PDF 1.5 Standard Compliant example using RBGroups

SUMMARY

When using RBGroups (RadioButton groups) of Optional Contents, we can switch
from one group to another one in the "layers" panel of okular, but the drawing
of the corresponding graphic objects is not updated.

STEPS TO REPRODUCE
1. open the attached file "Labels_and_Languages_3_OC.pdf"
2. open the "layers" panel
3. open the "Language" group
4. switch from one language to another

OBSERVED RESULT
The switching between languages in the user interface is correct (mutually
exclusive Optional Contents is implemented via the RadioButton group) but the
display is not updated: texts are overwritten on the display.

EXPECTED RESULT
Each language should lead to different text strings.


SOFTWARE/OS VERSIONS
Linux distro: Ubuntu-19.04 (and before)
Okular version: 1.6.3
PDF Backend: 0.6.5
KDE Framework: 5.56.0
Qt version: 5.12.2

ADDITIONAL INFORMATION
The PDF has been generated by my own graphic library Muesli. You can open the
attached PDF file with any text editor since it uses only ASCII characters. To
my knowledge, it is standard compliant: 'mupdf' doesn't claim about any errors,
and the "PDF Tools Online" validator
(https://www.pdf-online.com/osa/validate.aspx) returns nothing special about
it:  
Validating file "Labels_and_Languages_3_OC.pdf" for conformance level
pdf1.5
The document does conform to the PDF 1.5 standard.
Done.

-- 
You are receiving this mail because:
You are the assignee for the bug.

D21202: Added basic JavaScript functions to support animated PDF

[Pino Toscano]

pino added inline comments.

INLINE COMMENTS

> kjs_document.cpp:275-286
> +for ( Page * pIt : doc->m_pagesVector )
> +{
> +const QLinkedList< Okular::FormField * > pageFields = 
> pIt->formFields();
> +for( Okular::FormField *ffIt : pageFields )
> +{
> +if(numField == 0)
> +{

This convoluted for loop basically get the i-th element of a QLinkedList, which 
is not designed for index accessing (and that is why there is no at(int) 
method).
IMHO a better way is:

- get the list of form fields
- compare the wanted index with the count of the form fields: if it is out of 
boundaries, return KJSUndefined directly
- otherwise, create an iterator fromthe begin, and increment it by the wanted 
index to get to the wanted element

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21202

To: joaonetto, aacid, #okular
Cc: pino, anthonyfieroni, sander, okular-devel, joaonetto, tfella, ngraham, 
darcyshen, aacid

D21202: Added basic JavaScript functions to support animated PDF

[Anthony Fieroni]

anthonyfieroni added inline comments.

INLINE COMMENTS

> kjs_display.cpp:19
> +
> +static KJSPrototype *g_displayProto;
> +

use unique_ptr

> kjs_display.cpp:35-38
> +static bool initialized = false;
> +if ( initialized )
> +return;
> +initialized = true;

if (g_displayProto)
  return;

> kjs_display.cpp:40
> +
> +g_displayProto = new KJSPrototype();
> +

g_displayProto.reset(new KJSPrototype);

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21202

To: joaonetto, aacid, #okular
Cc: anthonyfieroni, sander, okular-devel, joaonetto, tfella, ngraham, 
darcyshen, aacid

D21202: Added basic JavaScript functions to support animated PDF

[Oliver Sander]

sander added inline comments.

INLINE COMMENTS

> kjs_document.cpp:139
> +
> +for ( Page * pIt : doc->m_pagesVector )
> +{

As you were using const iterators before: Shouldn't this be 
`qAsConst(doc->m_pagesVector)`  to avoid unnecessary detaching?

> kjs_document.cpp:142
> +const QLinkedList< Okular::FormField * > pageFields = 
> pIt->formFields();
> +numFields += pageFields.size();
> +}

Why not simply `numFields += pIt->formFields()` ?

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21202

To: joaonetto, aacid, #okular
Cc: sander, okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid

D21202: Added basic JavaScript functions to support animated PDF

[Joao Oliveira]

joaonetto updated this revision to Diff 58154.
joaonetto edited the summary of this revision.
joaonetto added a comment.


  Removed useless iterator

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21202?vs=58077&id=58154

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D21202

AFFECTED FILES
  CMakeLists.txt
  core/script/builtin.js
  core/script/executor_kjs.cpp
  core/script/kjs_display.cpp
  core/script/kjs_display_p.h
  core/script/kjs_document.cpp
  core/script/kjs_field.cpp

To: joaonetto, aacid, #okular
Cc: sander, okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid

D21202: Added basic JavaScript functions to support animated PDF

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> kjs_document.cpp:137
> +
> +QVector< Page * >::const_iterator pIt = doc->m_pagesVector.constBegin(), 
> pEnd = doc->m_pagesVector.constEnd();
> +unsigned int numFields = 0;

you don't need this anymore?

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21202

To: joaonetto, aacid, #okular
Cc: sander, okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid

Re: Bug concerning PDF "Optional Content" feature...

[Albert Astals Cid]

El dimecres, 15 de maig de 2019, a les 9:40:41 CEST, Édouard Canot va escriure:
> Hi,
> 
> The attached PDF file, "Labels_and_Languages_3_OC.pdf", clearly reveals 
> a bug in okular: some graphic objects are not erased when switching 
> between mutually exclusive Optional Contents (implemented via the 
> RadioButton group).

Can you please open a bug in bugs.kde.org so we can keep proper track of this?

Cheers,
  Albert

> 
> This PDF demonstrates the "Optional Content" feature... When opening it 
> with any browser, you can open the layers and choose one language among 
> three available ones (there are mutually exclusive). Most of PDF 
> browsers (Adobe Acrobat Reader under Windows, Evince under linux, ...) 
> behave well. The problem comes when using okular: when switching from 
> one language to another, the old active PDF object is not erased, and 
> all texts are overwritten on the display.
> 
> This bug appeared for me since Ubuntu-17.10 (therefore for 
> okular-1.1.3). Previously (under Ubuntu-17.04, okular-1.0.3), it was 
> correct. The bug is still present in okular-1.6.3 under Ubuntu-19.04.
> 
> The PDF has been generated by my own graphic library Muesli. You can 
> open it with any text editor since it uses only ASCII characters. To my 
> knowledge, it is standard compliant: 'mupdf' doesn't claim about any 
> errors, and the "PDF Tools Online" validator 
> (https://www.pdf-online.com/osa/validate.aspx) returns nothing special 
> about it:
> /Validating file "Labels_and_Languages_3_OC.pdf" for conformance level 
> pdf1.5//
> //The document does conform to the PDF 1.5 standard.//
> //Done./
> 
> Regards,
> Édouard Canot
> 
> 

[okular] [Bug 395497] Menubar - No text

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=395497

Albert Astals Cid  changed:

   What|Removed |Added

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

--- Comment #19 from Albert Astals Cid  ---
(In reply to jimbo1qaz from comment #18)
> I found this bug independently, with a slightly different procedure.
> 
> 1. Open Okular, Configure Toolbars dialog.
> 2. Add "About KDE" to Main Toolbar .
> 3. Press Apply, which creates ~/.local/share/kxmlgui5/okular/shell.rc.

You mean this three steps gives you a "No text" menubar?

Can the rest of you reproduce this?

I can't, just works fine for me

-- 
You are receiving this mail because:
You are the assignee for the bug.

Bug concerning PDF "Optional Content" feature...

[Édouard Canot]

Hi,

The attached PDF file, "Labels_and_Languages_3_OC.pdf", clearly reveals 
a bug in okular: some graphic objects are not erased when switching 
between mutually exclusive Optional Contents (implemented via the 
RadioButton group).


This PDF demonstrates the "Optional Content" feature... When opening it 
with any browser, you can open the layers and choose one language among 
three available ones (there are mutually exclusive). Most of PDF 
browsers (Adobe Acrobat Reader under Windows, Evince under linux, ...) 
behave well. The problem comes when using okular: when switching from 
one language to another, the old active PDF object is not erased, and 
all texts are overwritten on the display.


This bug appeared for me since Ubuntu-17.10 (therefore for 
okular-1.1.3). Previously (under Ubuntu-17.04, okular-1.0.3), it was 
correct. The bug is still present in okular-1.6.3 under Ubuntu-19.04.


The PDF has been generated by my own graphic library Muesli. You can 
open it with any text editor since it uses only ASCII characters. To my 
knowledge, it is standard compliant: 'mupdf' doesn't claim about any 
errors, and the "PDF Tools Online" validator 
(https://www.pdf-online.com/osa/validate.aspx) returns nothing special 
about it:
/Validating file "Labels_and_Languages_3_OC.pdf" for conformance level 
pdf1.5//

//    The document does conform to the PDF 1.5 standard.//
//    Done./

Regards,
Édouard Canot

--
Édouard Canot
tél: +33 (0)2 23 23 53 77
Institut de Physique de Rennes
CNRS, Université de Rennes
Bât. 11A, bureau 129
Campus de Beaulieu, F-35000 Rennes


Labels_and_Languages_3_OC.pdf
Description: Adobe PDF document

[neon] [Bug 389576] Okular snap package cannot access files outside home directory

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=389576

Nate Graham  changed:

   What|Removed |Added

Version|1.7.0   |unspecified
   Assignee|okular-devel@kde.org|neon-b...@kde.org
Product|okular  |neon
 CC||neon-b...@kde.org
  Component|general |Snaps

-- 
You are receiving this mail because:
You are the assignee for the bug.

D21195: [RFC] Create a Change Colors menu (with toolbar button)

[David Hurka]

davidhurka marked an inline comment as done.
davidhurka added a comment.


  I have figured out, what was going on in the QToolButton.
  
  KActionMenu::createWidget() added itself as default action. Then, 
CheckableActionMenu::createWidget() adds another action as default action. 
Then, the QToolButton has two actions, and builds a menu of them, instead of 
using the given menu.
  
  Now I remove the KActionMenu in CheckableActionMenu::createWidget(), so there 
is only my default action left. Then, QToolButton::setMenu() apparently works.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21195

To: davidhurka, #okular, #vdg
Cc: GB_2, davidre, aacid, ngraham, okular-devel, joaonetto, tfella, darcyshen

D21195: [RFC] Create a Change Colors menu (with toolbar button)

[David Hurka]

davidhurka updated this revision to Diff 58133.
davidhurka marked an inline comment as done.
davidhurka added a comment.


  - Toolbar button finally shows the intended menu
  - Add icon for Configure... action
  - Corrected action-slot connections
  - Named enable/disable action "Change Colors" again, looks better in the 
toolbar

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21195?vs=58129&id=58133

BRANCH
  create-change-colors-menu (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D21195

AFFECTED FILES
  conf/preferencesdialog.cpp
  conf/preferencesdialog.h
  part.cpp
  part.h
  ui/pageview.cpp
  ui/pageview.h

To: davidhurka, #okular, #vdg
Cc: GB_2, davidre, aacid, ngraham, okular-devel, joaonetto, tfella, darcyshen

D21195: [RFC] Create a Change Colors menu (with toolbar button)

[David Hurka]

davidhurka marked 2 inline comments as done.
davidhurka added a comment.


  I have added CheckableActionMenu, which cuts the default action connection 
between the KActionMenu itself and the toolbar button. Now it is possible to 
make the toolbar button checkable, but not the submenu.
  
  But the toolbar button (QToolButton) pops up a menu which I don’t really 
understand. It is a menu consisting of the default action (ok so far) and the 
KActionMenu itself as submenu (not ok). F6824299: 
Screenshot_2019-05-15_15:03:40.png 
  
  I have one idea how this submenu gets there: KActionMenu::createWidget sets 
the KActionMenu as default action for the QToolButton.
  Now the popup menu works fine. As soon as CheckableActionMenu::createWidget 
sets a new default action, this menu becomes a submenu (?).
  
  QToolButton::setMenu() has no effect, and QToolButton::menu() always returns 
nullptr.
  
  So, default action of the toolbar button works, menu works not.
  
  Someone an idea how I can keep the correct menu?

INLINE COMMENTS

> pageview.cpp:761
> +a->setCheckable( true );
> +a->setData( int( id ) );
> +d->aColorModeMenu->addAction( a );

Can I use Okular::SettingsCore::EnumRenderMode::type somehow for the action 
data, without casting it to int?

> GB_2 wrote in pageview.cpp:672
> No, we always use three dots.
> This item should have the `configure` icon BTW.

Ok I’ll add that.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21195

To: davidhurka, #okular, #vdg
Cc: GB_2, davidre, aacid, ngraham, okular-devel, joaonetto, tfella, darcyshen

D21195: [RFC] Create a Change Colors menu (with toolbar button)

[Björn Feber]

GB_2 added inline comments.

INLINE COMMENTS

> davidhurka wrote in pageview.cpp:672
> Unicode ellipsis … instead of periods ... ?

No, we always use three dots.
This item should have the `configure` icon BTW.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D21195

To: davidhurka, #okular, #vdg
Cc: GB_2, davidre, aacid, ngraham, okular-devel, joaonetto, tfella, darcyshen

D21195: [RFC] Create a Change Colors menu (with toolbar button)

[David Hurka]

davidhurka updated this revision to Diff 58129.
davidhurka added a comment.


  Removed checkbox from submenu, but toolbar button invents other menu structure

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21195?vs=58102&id=58129

BRANCH
  create-change-colors-menu (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D21195

AFFECTED FILES
  conf/preferencesdialog.cpp
  conf/preferencesdialog.h
  part.cpp
  part.h
  ui/pageview.cpp
  ui/pageview.h

To: davidhurka, #okular, #vdg
Cc: davidre, aacid, ngraham, okular-devel, joaonetto, tfella, darcyshen

[okular] [Bug 389576] Okular snap package cannot access files outside home directory

[bark mallard]

https://bugs.kde.org/show_bug.cgi?id=389576

--- Comment #7 from bark mallard  ---
By the way, Okular will neither open a pdf if I navigate to it from my home
folder by way of symbolic link to another drive.

Neither will it open a direct symbolic link to a pdf in my /tmp directory, if i
put that symbolic link in my /home folder, and attempt to open it there with
Okular.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 389576] Okular snap package cannot access files outside home directory

[bark mallard]

https://bugs.kde.org/show_bug.cgi?id=389576

bark mallard  changed:

   What|Removed |Added

 Resolution|DOWNSTREAM  |---
   Platform|Ubuntu Packages |unspecified
 CC||markjball...@googlemail.com
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED
Version|1.0.0   |1.7.0

--- Comment #6 from bark mallard  ---
I also have this bug.

I installed Okular via snap just a few weeks ago. I am unable to open files
that are not under /home.

It is notable that, when I use the Okular > File > Open dialog, I cannot either
navigate to other folders or see pdfs in folders other than home.

In particular, the Okular file dialog refuses to enter the /mnt or /media
directories. It will go into /tmp, yet when it gets there it cannot see any
.pdf file I've put there. In fact, it cannot see any file there.

Nate's contribution implies the problem might be an upstream bug caused by snap
failing to manage dependencies. And indeed I did find it necessary to follow
the install steps given in Bug 378130 in order to install Okular properly. But
fixing the dependencies by the procedure suggested does not fix this particular
bug. Okular is still unable to open files that are not in my Home folder.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 401268] Freehand lines rendered ugly as you write and look good only after you finish

[Darek]

https://bugs.kde.org/show_bug.cgi?id=401268

--- Comment #8 from Darek  ---
My problem is similar to the one reported earlier. The annotations handwritten
with help of wacom look ugly. The lines written using the touchpad are smooth.
The problem does not occur in xurnal.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 401268] Freehand lines rendered ugly as you write and look good only after you finish

[Darek]

https://bugs.kde.org/show_bug.cgi?id=401268

Darek  changed:

   What|Removed |Added

 Attachment #120077|0   |1
is obsolete||
 Attachment #120078|0   |1
is obsolete||

--- Comment #7 from Darek  ---
Created attachment 120079
  --> https://bugs.kde.org/attachment.cgi?id=120079&action=edit
ugly handwriting annotations

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 401268] Freehand lines rendered ugly as you write and look good only after you finish

[Darek]

https://bugs.kde.org/show_bug.cgi?id=401268

--- Comment #6 from Darek  ---
Created attachment 120078
  --> https://bugs.kde.org/attachment.cgi?id=120078&action=edit
ugly handwriting annotations

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 401268] Freehand lines rendered ugly as you write and look good only after you finish

[Darek]

https://bugs.kde.org/show_bug.cgi?id=401268

Darek  changed:

   What|Removed |Added

 CC||d.pac...@gmail.com

--- Comment #5 from Darek  ---
Created attachment 120077
  --> https://bugs.kde.org/attachment.cgi?id=120077&action=edit
ugly handwriting annotations

-- 
You are receiving this mail because:
You are the assignee for the bug.