[okular] [Bug 391460] print dialogue does not show advanced options

[bugzilla_noreply]

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

--- Comment #2 from royla...@corplink.com.au ---
Created attachment 111212
  --> https://bugs.kde.org/attachment.cgi?id=111212=edit
Screenshot of advanced properties in Okular

no access to colour printing
this was available in Fedora 25

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

[okular] [Bug 391460] print dialogue does not show advanced options

[bugzilla_noreply]

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

--- Comment #1 from royla...@corplink.com.au ---
Created attachment 111211
  --> https://bugs.kde.org/attachment.cgi?id=111211=edit
Screenshot of advanced properties in Okular

Access to colour printing not an available option,

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

[okular] [Bug 391460] New: print dialogue does not show advanced options

[bugzilla_noreply]

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

Bug ID: 391460
   Summary: print dialogue does not show advanced options
   Product: okular
   Version: 1.3.1
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: printing
  Assignee: okular-devel@kde.org
  Reporter: royla...@corplink.com.au
  Target Milestone: ---

Created attachment 111210
  --> https://bugs.kde.org/attachment.cgi?id=111210=edit
Screenshot of advanced options in Firefox

This is a new problem in KDE-5 concurrent with upgrade to Fedora 27 in 2018.
Advanced options including printing in colour are not available in Okular, but
are available in Firefox

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

[okular] [Bug 391407] Okular cannot display next page with hand tool

[Zakhar]

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

--- Comment #3 from Zakhar  ---
Just enabled the consecutive feature and browse tool works as I would expect it
to, in consecutive mode. It was so not ovbious it was even there as an option,
perhaps it should be reconsidered.

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

[okular] [Bug 391407] Okular cannot display next page with hand tool

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 CC||aa...@kde.org
 Status|UNCONFIRMED |NEEDSINFO

--- Comment #2 from Albert Astals Cid  ---
are you using the consecutive view or the single page view?

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

D11074: Fix opening files via a file manager on Mac

[René J . V . Bertin]

rjvbb added a comment.


  >   One could try to reimplement this with Objective-C, I do not know whether 
it makes sense though.
  
  No, you'd be doing what Qt already does for you.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[René J . V . Bertin]

rjvbb added a comment.


  >   The legacy argc,argv is handled by QCommandLineParser.
  
  Only partly, the annoying bit where you loop over the array to see which 
options are there. For the rest it only handles Qt-specific arguments, and 
files to be opened end up in the `positionalArguments()` list.
  
  QApplication cannot know if your application can (or should be able to) open 
files, even less how to open them.
  All Qt can do is provide an integrated Qt'ish mechanism through which get 
informed when the user intends to open a document via LaunchServices. That 
mechanism encapsulates the ObjC implementation Sergio referred to, and such 
events can occur at any moment, also when the application is already running.
  
  And so yes, every Qt application that wants to be able to open files through 
the Finder and other LaunchServices mechanisms must implement a handler (event 
filter) for QFileOpenEvents.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Sergio Bragin]

sbragin added a comment.


  In D11074#219505 , @ltoscano wrote:
  
  > Does each and every macOS application which would like to open a file via a 
file manager need to implement the same macapplication.cpp (or so) again and 
again (which makes use of a QFileOpenEvent, yes, but that's not the point; the 
point is about the content of macapplication.cpp, which is not Okular-specific).
  
  
  This is the way offered by Qt:
  http://doc.qt.io/qt-5/qfileopenevent.html
  
  One could try to reimplement this with Objective-C, I do not know whether it 
makes sense though.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11075: Make Okular show the list of opened windows in the Dock menu

[Sergio Bragin]

sbragin added a dependency: D11074: Fix opening files via a file manager on Mac.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Sergio Bragin]

sbragin added a dependent revision: D11075: Make Okular show the list of opened 
windows in the Dock menu.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Luigi Toscano]

ltoscano added a comment.


  In D11074#219504 , @sbragin wrote:
  
  > In D11074#219502 , @ltoscano 
wrote:
  >
  > > Let me rephrase: each and every macOS application which needs to open 
file via a file manager needs to implement this same code?
  >
  >
  > File opening via a file manager is handled via QFileOpenEvent.
  
  
  This states that a QFileOpenEvent instance is used, but it is not an answer 
to my question.
  
  Does each and every macOS application which would like to open a file via a 
file manager need to implement the same macapplication.cpp (or so) again and 
again (which makes use of a QFileOpenEvent, yes, but that's not the point; the 
point is about the content of macapplication.cpp, which is not Okular-specific).

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Sergio Bragin]

sbragin added a comment.


  In D11074#219502 , @ltoscano wrote:
  
  > Let me rephrase: each and every macOS application which needs to open file 
via a file manager needs to implement this same code?
  
  
  File opening via a file manager is handled via QFileOpenEvent.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Luigi Toscano]

ltoscano added a comment.


  So each application
  
  In D11074#219501 , @rjvbb wrote:
  
  > >   Isn't this another case of "should be fixed in QApplication or another 
lower level library"?
  >
  > No, not anymore than opening files via the legacy argc,argv mechanism.
  
  
  The legacy argc,argv is handled by QCommandLineParser.
  
  Let me rephrase: each and every macOS application which needs to open file 
via a file manager needs to implement this same code?
  If it does need to do that, then this is not the right place to implement it.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[René J . V . Bertin]

rjvbb added a comment.


  >   Isn't this another case of "should be fixed in QApplication or another 
lower level library"?
  
  No, not anymore than opening files via the legacy argc,argv mechanism.

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Sergio Bragin]

sbragin added a comment.


  In D11074#219475 , @ltoscano wrote:
  
  > Isn't this another case of "should be fixed in QApplication or another 
lower level library"?
  
  
  I do not quite understand, what you mean. I guess dispatching QFileOpenEvent 
is how file opening is supposed to be treated on Mac:
  http://doc.qt.io/qt-5/qfileopenevent.html

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11075: Make Okular show the list of opened windows in the Dock menu

[Sergio Bragin]

sbragin created this revision.
Restricted Application added a project: Okular.
sbragin requested review of this revision.

REVISION SUMMARY
  Qt applications, running on Mac, do not show the list of opened windows in 
the 
  Dock menu. This patch fixes it by creating a custom menu with the list and 
  inserting it as the Dock menu.

REPOSITORY
  R223 Okular

BRANCH
  master

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

AFFECTED FILES
  shell/macapplication.cpp
  shell/macapplication.h

To: sbragin
Cc: rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Luigi Toscano]

ltoscano added a comment.


  Isn't this another case of "should be fixed in QApplication or another lower 
level library"?

REPOSITORY
  R223 Okular

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

To: sbragin
Cc: ltoscano, rjvbb, #okular, michaelweghorn, ngraham, aacid

D11074: Fix opening files via a file manager on Mac

[Sergio Bragin]

sbragin created this revision.
Restricted Application added a project: Okular.
sbragin requested review of this revision.

REVISION SUMMARY
  On Mac a file open event is sent to the QApplication instance if there is 
  a request from the operating system to open a file. This patch adds a new 
  class, derived from QApplication, which handles file open events.
  
  Thanks to: René J.V. Bertin

REPOSITORY
  R223 Okular

BRANCH
  master

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

AFFECTED FILES
  shell/CMakeLists.txt
  shell/macapplication.cpp
  shell/macapplication.h
  shell/main.cpp

To: sbragin
Cc: rjvbb, #okular, michaelweghorn, ngraham, aacid

[okular] [Bug 389953] okular ignores paper size when printing

[Michael Weghorn]

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

--- Comment #39 from Michael Weghorn  ---
Great to hear. Thanks for the update!

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

D10932: Bug 288042 - Option to reset forms (Implemented using FormFields)

[Ahmad Osama]

ahmadosama updated this revision to Diff 28717.
ahmadosama added a comment.


  I mistakenly replaced the code with the auto test.
  I edited the patch now.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10932?vs=28622=28717

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

AFFECTED FILES
  autotests/resetformstest.cpp
  part.cpp
  part.rc
  ui/pageview.cpp
  ui/pageview.h

To: ahmadosama
Cc: ngraham, aacid, #okular, michaelweghorn

D10869: [5/5] Add test for read only set and checkbox calculate

[Andre Heinecke]

aheinecke updated this revision to Diff 28711.
aheinecke added a comment.


  No changes, only updated for context.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10869?vs=28120=28711

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

AFFECTED FILES
  autotests/data/checkbox_ro.pdf
  autotests/parttest.cpp

To: aheinecke, #okular
Cc: michaelweghorn, ngraham, aacid

D10932: Bug 288042 - Option to reset forms (Implemented using FormFields)

[Ahmad Osama]

ahmadosama added a comment.


  I mistakenly replaced the code with the auto test.
  Here is the previous patch.
  
  F5741409: 0001-reimplementing-the-reset-option-using-formfields.patch 


REPOSITORY
  R223 Okular

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

To: ahmadosama
Cc: ngraham, aacid, #okular, michaelweghorn

D10868: [4/5] Fix CheckBox script usage

[Andre Heinecke]

aheinecke updated this revision to Diff 28710.
aheinecke added a comment.


  No changes, only updated to get context

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10868?vs=28119=28710

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

AFFECTED FILES
  core/script/kjs_field.cpp
  ui/formwidgets.cpp
  ui/formwidgets.h

To: aheinecke, #okular
Cc: michaelweghorn, ngraham, aacid

D10867: [3/5] Add support to set read only from scripts

[Andre Heinecke]

aheinecke marked an inline comment as done.

REPOSITORY
  R223 Okular

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

To: aheinecke, #okular
Cc: aacid, michaelweghorn, ngraham

D10867: [3/5] Add support to set read only from scripts

[Andre Heinecke]

aheinecke updated this revision to Diff 28708.
aheinecke added a comment.


  Added @since marker to setReadOnly

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10867?vs=28115=28708

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

AFFECTED FILES
  core/form.cpp
  core/form.h
  core/script/kjs_field.cpp
  generators/poppler/formfields.cpp
  generators/poppler/formfields.h

To: aheinecke, #okular
Cc: aacid, michaelweghorn, ngraham

D10866: [2/5] Implement generic version of Form Widgets refresh

[Andre Heinecke]

aheinecke updated this revision to Diff 28707.
aheinecke added a comment.


  Updated without setVisibility implicit handling of isReadOnly

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10866?vs=28114=28707

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

AFFECTED FILES
  ui/formwidgets.cpp
  ui/formwidgets.h

To: aheinecke, #okular
Cc: michaelweghorn, ngraham, aacid

D10865: [1/5] Access readOnly state of FormWidgets dynamically

[Andre Heinecke]

aheinecke updated this revision to Diff 28706.
aheinecke added a comment.


  Removed implicit readOnly handling in setVisiblitiy and updated
  callers instead.
  
  Also the differential is now published with arcanist ;-)

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10865?vs=28113=28706

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

AFFECTED FILES
  ui/formwidgets.cpp
  ui/formwidgets.h
  ui/pageview.cpp
  ui/pageviewutils.cpp

To: aheinecke, #okular
Cc: aacid, michaelweghorn, ngraham

D10865: [1/5] Access readOnly state of FormWidgets dynamically

[Andre Heinecke]

aheinecke added a comment.


  In D10865#217744 , @aacid wrote:
  
  > BTW next time  please use arc so phabricator shows the context of the diff.
  
  
  Apologies, I'll try. While I like phabricator I'm not very skilled with 
arcanist, yet. :-}

INLINE COMMENTS

> aacid wrote in formwidgets.cpp:304
> i would really prefer this to be moved to whoever calls setVisiblity, it's 
> kind of weird for setVisiblity to sometimes not do what you ask it to do.

Yes, Indeed. I'll update the Differential accordingly.

> aacid wrote in formwidgets.cpp:310
> Do we need this at all? the widget won't ge visible when it's readonly, so 
> what do we care if it's enabled or not?

As I understand it there is a case where Forms are bisible, but disabled.
This is if in "PageView::notifySetup" the check for:

  const bool allowfillforms = d->document->isAllowed( Okular::AllowFillForms );

Returns false.
Then Okular will show all FormWidgets which are not readOnly disabled. I'm not 
sure if that makes much sense but as there is the extra code with 
"setCanBeFilled" I thought I should better leave that behavior because someone 
intended it that way at some point ;-)

> aacid wrote in pageview.cpp:1002
> If we remove the use of visiblity as i commented already we can get this back 
> to how it was?

No, setCanBeFilled accesses isReadOnly. This crashes if the formWidgets are not 
yet updated with the new fields.

I also think that it is better to only modify the field here and not earlier to 
avoid working with formWidgets that have dangling pointers to deleted fields in 
them.

REPOSITORY
  R223 Okular

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

To: aheinecke, #okular
Cc: aacid, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 28694.
dileepsankhla added a comment.


  Updating: Remembering side navigation panel state
  Removed the extra whitespace.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11051?vs=28693=28694

BRANCH
  master

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

AFFECTED FILES
  conf/okular.kcfg
  part.cpp
  ui/sidebar.cpp

To: dileepsankhla, #okular
Cc: sander, #okular, michaelweghorn, ngraham, aacid

D11051: Remembering side navigation panel state

[Oliver Sander]

sander added inline comments.

INLINE COMMENTS

> sidebar.cpp:717
>  {
> +
>  if ( !item )

Please avoid such white-space changes.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular
Cc: sander, #okular, michaelweghorn, ngraham, aacid

[okular] [Bug 344599] Thumbnails sidebar always open when okular starts

[Dileep Sankhla]

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

Dileep Sankhla  changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #10 from Dileep Sankhla  ---
I have sent a patch here: https://phabricator.kde.org/D11051

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

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a reviewer: Okular.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular
Cc: #okular, michaelweghorn, ngraham, aacid

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla created this revision.
Restricted Application added a subscriber: Okular.
Restricted Application added a project: Okular.
dileepsankhla requested review of this revision.

REVISION SUMMARY
  Every time Okular starts, one of the items of the side navigation panel is 
open. There is no way to disable it globally. It would be convenient to the 
users to automatically save the state of the panel upon exit and restore it 
when the Okular is opened again.
  FEATURE: 344599

TEST PLAN
  1. Open a PDF with Okular
  2. You will find that one of the items of the side navigation panel is open
  3. Click on the item icon of the navigation panel to minimize item's panel
  4. Close Okular
  5. Reopen Okular with same or different file as in step 1
  6. One of the items of the side navigation panel is again open
  7. But after applying this patch, the side navigation panel should be remain 
collapsed in step 6 with none of the item is selected

REPOSITORY
  R223 Okular

BRANCH
  master

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

AFFECTED FILES
  conf/okular.kcfg
  part.cpp
  ui/sidebar.cpp

To: dileepsankhla
Cc: #okular, michaelweghorn, ngraham, aacid

[okular] [Bug 389953] okular ignores paper size when printing

[Attila]

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

--- Comment #38 from Attila  ---
The problem didn't reappear, everything is fine.
Thank you very much for your excellent support.

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