D7595: Skip reload when another reload is already in progress

2017-08-30 Thread Albert Astals Cid 
aacid added a comment.


  Please abandon this revision, i commited 
https://commits.kde.org/okular/a6aea956081e8faac2484ab2283a5ab50f9e0bbe

REPOSITORY
  R223 Okular

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

To: rkflx, #okular
Cc: sander, aacid

D7495: Do not start reloading again if we're reloading

2017-08-30 Thread Albert Astals Cid 
aacid abandoned this revision.
aacid added a comment.


  Got in as 
https://commits.kde.org/okular/a6aea956081e8faac2484ab2283a5ab50f9e0bbe

REPOSITORY
  R223 Okular

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

To: aacid
Cc: rkflx, #okular, aacid

[okular] [Bug 384142] okular: seg at exit (For multiple input files)

2017-08-30 Thread Dave Gilbert 
https://bugs.kde.org/show_bug.cgi?id=384142

--- Comment #4 from Dave Gilbert  ---
Not tested, but Thanks!

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

[okular] [Bug 384185] Markdown backend does not reload automatically if the file has changed

2017-08-30 Thread Albert Astals Cid 
https://bugs.kde.org/show_bug.cgi?id=384185

--- Comment #3 from Albert Astals Cid  ---
Yes works for me.

HAvne't you destroyed this feature locally while testing patches D7595/D7495 ?

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

[okular] [Bug 380154] Please add "Rulers" option to Okular

2017-08-30 Thread bugzilla_noreply 
https://bugs.kde.org/show_bug.cgi?id=380154

--- Comment #3 from yousifjka...@yahoo.com ---
Hi.

It is a remainder about this issue. 

Dear due you will accept to add this feature or not ?

If yes, please allow me to add something I forgot in 1st post of this thread:

regarding rulers they should be 2: one vertical & 2nd horizontal.

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

D7241: Search for Kirigami

2017-08-30 Thread Heiko Becker 
heikobecker added a comment.


  Ping?

REPOSITORY
  R223 Okular

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

To: heikobecker, #okular, mart
Cc: aacid

[okular] [Bug 315552] Allow save annotations directly to original pdf file

2017-08-30 Thread Christoph Feck 
https://bugs.kde.org/show_bug.cgi?id=315552

--- Comment #17 from Christoph Feck  ---
Bug 151614?

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

[okular] [Bug 384185] Markdown backend does not reload automatically if the file has changed

2017-08-30 Thread Oliver Sander 
https://bugs.kde.org/show_bug.cgi?id=384185

--- Comment #2 from Oliver Sander  ---
Can you reproduce it?

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

[okular] [Bug 384185] Markdown backend does not reload automatically if the file has changed

2017-08-30 Thread Albert Astals Cid 
https://bugs.kde.org/show_bug.cgi?id=384185

Albert Astals Cid  changed:

   What|Removed |Added

   Severity|wishlist|normal
 CC||aa...@kde.org

--- Comment #1 from Albert Astals Cid  ---
this is a bug not a wish, i'm kind of surprised this doens't work, nothing pdf
sepcific in the reload path

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

[okular] [Bug 384185] New: Markdown backend does not reload automatically if the file has changed

2017-08-30 Thread Oliver Sander 
https://bugs.kde.org/show_bug.cgi?id=384185

Bug ID: 384185
   Summary: Markdown backend does not reload automatically if the
file has changed
   Product: okular
   Version: 1.3.70
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: okular-devel@kde.org
  Reporter: oliver.san...@tu-dresden.de
  Target Milestone: ---

Okular reloads pdf files automatically when they change on disk.  I would
expect the markdown backend to do the same. a) for consistency and b) because
it is convenient when writing markdown.

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

[okular] [Bug 288042] Option to reset forms (PDF)

2017-08-30 Thread Gilbert Assaf 
https://bugs.kde.org/show_bug.cgi?id=288042

Gilbert Assaf  changed:

   What|Removed |Added

 CC||gas...@gmx.de

--- Comment #4 from Gilbert Assaf  ---
https://git.reviewboard.kde.org/r/130057/

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

Re: Review Request 129893: Implement continuous search

2017-08-30 Thread Elvis Angelaccio 

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

(Updated Aug. 30, 2017, 2:47 p.m.)


Review request for Okular, KDE Usability and Albert Astals Cid.


Changes
---

Simpler diff. It still uses EndOfDocumentReached but at least it doesn't add 
new values to SearchType.


Repository: okular


Description
---

Show non-intrusive info messages whenever the search start over from the 
beginning or the bottom of the document, instead of asking the user if s/he 
wants to continue the search. This is consistent with search in KWrite/Kate and 
with web browsers.


Diffs (updated)
-

  core/document.cpp b725ecfc7 
  ui/searchlineedit.cpp 74e6ef60c 

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


Testing
---

Search for something in a pdf, click Next until reaching the end of document. 
Click again Next and the search starts over from the beginning of the document, 
without the "Continue from the beginning?" dialog.


File Attachments


Before: dialog asks if the search should continue from the beginning.
  
https://git.reviewboard.kde.org/media/uploaded/files/2017/03/11/16eca574-0572-455d-babe-54f1087a403f__before.png
After: always continue search from beginning, with a non-intrusive notification.
  
https://git.reviewboard.kde.org/media/uploaded/files/2017/03/11/23b69d9a-6fbf-45a5-9595-d355dac26042__after.png


Thanks,

Elvis Angelaccio

D7595: Skip reload when another reload is already in progress

2017-08-30 Thread Oliver Sander 
sander added a comment.


  To be honest, I liked your first patch better.  Granted, that definition of 
reloadLock is elegant, but you need quite a bit of C++ experience to see its 
beauty.  People without that will be scared.
  
  But it is really Albert who decides.

REPOSITORY
  R223 Okular

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

To: rkflx, #okular
Cc: sander, aacid

[okular] [Bug 288042] Option to reset forms (PDF)

2017-08-30 Thread francisco navarro morales 
https://bugs.kde.org/show_bug.cgi?id=288042

francisco navarro morales  changed:

   What|Removed |Added

 CC||navarromorales...@gmail.com

--- Comment #3 from francisco navarro morales  ---
working on it

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

D7595: Skip reload when another reload is already in progress

2017-08-30 Thread Henrik Fehlauer 
rkflx updated this revision to Diff 18960.
rkflx edited the summary of this revision.
rkflx added a comment.


  Thanks Oliver, I like compromises. You inspired me to try another way: Out 
with the `unique_lock`, in with the `unique_ptr`. This way no 
custom RAII wrapper is needed.
  
  OTOH, I'm not really convinced there is no threading involved (or will be in 
the future). Anyway, I hope this is acceptable now.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7595?vs=18903=18960

BRANCH
  reload-mutex (branched from Applications/17.08)

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

AFFECTED FILES
  part.cpp
  part.h

To: rkflx, #okular
Cc: sander, aacid

D7595: Skip reload when another reload is already in progress

2017-08-30 Thread Oliver Sander 
sander added a comment.


  From merely looking at the patches, I like this one better than Albert's.  In 
Albert's patch, the fact that you have to set m_areWeReloading at every exit of 
the method slotDoFileDirty does feel like breakage waiting to happen.
  
  On the other hand, Albert's objection "Using a mutex when threads are not 
involved is wrong in my book" is not without reason either.  Casual readers of 
the code will see the mutex and expect there to be threading.  I therefore 
suggest to expand the comment in part.cpp:1773 to clearly state why the mutex 
is needed, and why it does not have anything to do with threading.
  
  Is that a reasonable compromise?

REPOSITORY
  R223 Okular

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

To: rkflx, #okular
Cc: sander, aacid

D7594: Update to synctex 1.19

2017-08-30 Thread Henrik Fehlauer 
rkflx added a reviewer: Kile.
rkflx added a subscriber: mludwig.
rkflx added a comment.


  @mludwig As Kile is also providing synctex functionality, maybe you are 
interested in looking at this patch, too. In my rather simple tests Kile worked 
fine, but you might be more familiar how it is supposed to work.

REPOSITORY
  R223 Okular

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

To: rkflx, #okular, sander, #kile
Cc: mludwig, aacid

D7495: Do not start reloading again if we're reloading

2017-08-30 Thread Henrik Fehlauer 
rkflx added a comment.


  Yay for reviews finding problems before users do \o/
  
  > majorly unchanged for years, and if someone breaks it, well it'll break and 
we'll fix it.
  
  If we can choose between a good and an improved solution, I'd say we should 
always pick the latter. Maybe I should have added a comment only instead of 
implementing it myself, but I wanted to check how it would work out and spare 
you some work. You have seen 384142 
 coming in only yesterday, please 
don't risk more crashes unnecessarily.
  
  > `SetBoolToFalseOnScopeExit` [...] should be less than 10 lines of code.
  
  That's both harder to understand and longer than the additional 0 lines of 
code for the RAII-mutex solution, as well as less compact in terms of the 
number of separate code fragments.
  
  I'm all for fixing the original issue, but let's do it properly.

REPOSITORY
  R223 Okular

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

To: aacid
Cc: rkflx, #okular, aacid

D7595: Skip reload when another reload is already in progress

2017-08-30 Thread Henrik Fehlauer 
rkflx added a comment.


  I guess someone else should judge which is easier to read considering the 
full picture (I got confused by your `areWeReloading` naming, actually). I 
admit someone not familiar with `std::mutex` semantics would need to read the 
comment, but understanding a custom RAII wrapper is even harder.
  
  Could you suggest another reviewer?

REPOSITORY
  R223 Okular

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

To: rkflx, #okular
Cc: aacid

[okular] [Bug 382011] SyncTeX 2017 upgrade

2017-08-30 Thread Henrik Fehlauer 
https://bugs.kde.org/show_bug.cgi?id=382011

Henrik Fehlauer  changed:

   What|Removed |Added

 CC||rk...@lab12.net

--- Comment #2 from Henrik Fehlauer  ---
Hi Jérôme,

thanks for the heads-up. We now have a review request ready at
https://phabricator.kde.org/D7594. Feel free to have a look and comment here
(or over in Phabricator if you have a KDE identity account) with any questions,
concerns or suggestions you have.

In terms of testing your pre-release code, I can report that I could integrate
it in Okular without major problems (we still carry some patches to make it
compile without errors and with less warnings, though). Superficial testing of
the functionality seems fine, but I am not able to do any thorough tests (we
will see what happens once we ship to our userbase).

For Okular, the only recent type of synctex-related problem is bug 383915. It
seems like recent TeXLive generates backwards-incompatible synctex files which
crash the very old synctex 1.16 parser in Okular.

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

D7594: Update to synctex 1.19

2017-08-30 Thread Henrik Fehlauer 
rkflx added a comment.


  Only used bugzilla's quicksearch which omits NEEDSINFO bugs, so I missed this 
(sorry). There doesn't seem do be any new information though. I'll add a link 
to this review.
  
  When implementing the patch, I had to decide between the version in the 
texlive svn and several branches of the github repo. Both are roughly 
equivalent to the github state if you look at bugfixes and ignore new feature 
development after TeXLive 2017 (in terms of code, as the actual commit history 
is totally different). I like that development is opening up, but there is also 
confusion about branches (see issue #3) and synchronisation with the svn. In 
the end, distros are shipping from svn, so I used that.
  
  As mentioned in the summary, we could think about our options for the 
longterm future. For 17.12 I would suggest to go with the pragmatic approach as 
outlined in this review request, except you are able to invest much time in a 
better solution right now. The work of going through the old patches and local 
commits without patches was needed anyway.

REPOSITORY
  R223 Okular

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

To: rkflx, #okular, sander
Cc: aacid