[okular] [Bug 396137] Okular hangs when scrolling fast on both pdf and djvu documents
https://bugs.kde.org/show_bug.cgi?id=396137 Elvis Angelaccio changed: What|Removed |Added CC||elvis.angelac...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 408818] Ark crashed when trying to open *.fb2 file
https://bugs.kde.org/show_bug.cgi?id=408818 Elvis Angelaccio changed: What|Removed |Added Product|ark |okular Component|general |general Assignee|elvis.angelac...@kde.org|okular-devel@kde.org --- Comment #3 from Elvis Angelaccio --- No need to, I changed the product of this one. :) -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 406713] Wrong PDF rendering
https://bugs.kde.org/show_bug.cgi?id=406713 --- Comment #3 from Elvis Angelaccio --- Interesting, I didn't know about stamps. Thanks for the workaround! -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 406713] Wrong PDF rendering
https://bugs.kde.org/show_bug.cgi?id=406713 --- Comment #1 from Elvis Angelaccio --- Created attachment 119533 --> https://bugs.kde.org/attachment.cgi?id=119533=edit Okular VS Firefox Comparison between Okular and Firefox opening the attached PDF file. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 406713] New: Wrong PDF rendering
https://bugs.kde.org/show_bug.cgi?id=406713 Bug ID: 406713 Summary: Wrong PDF rendering Product: okular Version: 1.7.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: elvis.angelac...@kde.org Target Milestone: --- Created attachment 119532 --> https://bugs.kde.org/attachment.cgi?id=119532=edit PDF file not rendered correctly by okular The attached PDF file is not rendered correctly in okular, while it works fine in firefox. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 404078] Full screen to normal back to full screen causes systematic crash
https://bugs.kde.org/show_bug.cgi?id=404078 Elvis Angelaccio changed: What|Removed |Added Version|17.12.3 |unspecified Assignee|elvis.angelac...@kde.org|okular-devel@kde.org Resolution|--- |BACKTRACE Component|general |PDF backend Product|ark |okular Status|REPORTED|NEEDSINFO --- Comment #1 from Elvis Angelaccio --- Seems to be a crash in the okular part. Please install debug symbols for okular and qt and post another backtrace. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 155563] Automatic text selection in Okular
https://bugs.kde.org/show_bug.cgi?id=155563 Elvis Angelaccio <elvis.angelac...@kde.org> changed: What|Removed |Added CC||elvis.angelac...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
D8704: Don't use exec() to open dialogs
This revision was automatically updated to reflect the committed changes. Closed by commit R223:40afb8292690: Dont use exec() to open dialogs (authored by elvisangelaccio). REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8704?vs=22046=22219 REVISION DETAIL https://phabricator.kde.org/D8704 AFFECTED FILES part.cpp To: elvisangelaccio, #okular, aacid Cc: ngraham, okular-devel, aacid
D8704: Don't use exec() to open dialogs
elvisangelaccio added a subscriber: okular-devel. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D8704 To: elvisangelaccio, #okular Cc: okular-devel, aacid
D8704: Don't use exec() to open dialogs
elvisangelaccio created this revision. elvisangelaccio added a reviewer: Okular. Restricted Application added a project: Okular. REVISION SUMMARY exec() is blocking and should not be used if possible. Currently it makes impossible to interact with a 2nd okular window if the first window has the Properties or Embedded Files dialog open. It also causes a double delete crash when closing okular via dbus while either of those dialogs is open. We can use open() instead which does not block the event loop and fixes both the problems. TEST PLAN 1. Open the Properties or Embedded Files dialog, then close okular via dbus. 2. Open two okular windows, then open the Properties or Embedded Files dialog in one of them and try to use the other window. REPOSITORY R223 Okular BRANCH master REVISION DETAIL https://phabricator.kde.org/D8704 AFFECTED FILES part.cpp To: elvisangelaccio, #okular Cc: aacid
D7996: Properly create KPixmapSequence
This revision was automatically updated to reflect the committed changes. Closed by commit R223:1364d0e97b22: Properly create KPixmapSequence (authored by elvisangelaccio). REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7996?vs=19947=19958 REVISION DETAIL https://phabricator.kde.org/D7996 AFFECTED FILES ui/searchlineedit.cpp To: elvisangelaccio, #okular, aacid Cc: aacid, #okular
D7996: Properly create KPixmapSequence
elvisangelaccio added a comment. In https://phabricator.kde.org/D7996#149307, @elvisangelaccio wrote: > The weird thing is that I can't find the change with git blame. Shouldn't we just restore the old implementation? Ah no, we can't since KIconLoader is tier3... REPOSITORY R223 Okular BRANCH Applications/17.08 REVISION DETAIL https://phabricator.kde.org/D7996 To: elvisangelaccio, #okular, aacid Cc: aacid, #okular
D7996: Properly create KPixmapSequence
elvisangelaccio added a comment.
In https://phabricator.kde.org/D7996#149273, @aacid wrote:
> Whoever decided to change from iconName to fullpath deserves some
punishment for having a class constructor that has exactly signature but
behaves totally different.
>
> every single instance is broken
>
https://lxr.kde.org/source/frameworks/kpeople/src/widgets/mergedialog.cpp#0082
> https://lxr.kde.org/source/frameworks/knewstuff/src/uploaddialog.cpp#0147
>
https://lxr.kde.org/source/calligra/krita/libs/ui/widgets/kis_cie_tongue_widget.cpp#0162
>
https://lxr.kde.org/source/extragear/base/nepomuk-webminer/src/lib/ui/fetcherdialog.cpp#0140
>
> meh, i'll forget this to make my life better.
I had a look, kdelibs has
KPixmapSequence::KPixmapSequence(const QString , int size)
: d(new Private)
{
d->loadSequence(QPixmap(KIconLoader::global()->iconPath(xdgIconName,
-size)), QSize(size, size));
}
while kwidgetaddons has
KPixmapSequence::KPixmapSequence(const QString , int size)
: d(new Private)
{
d->loadSequence(QPixmap(fullPath), QSize(size, size));
}
The weird thing is that I can't find the change with git blame. Shouldn't we
just restore the old implementation?
REPOSITORY
R223 Okular
BRANCH
Applications/17.08
REVISION DETAIL
https://phabricator.kde.org/D7996
To: elvisangelaccio, #okular, aacid
Cc: aacid, #okular
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- (Updated Sept. 26, 2017, 9:28 p.m.) Status -- This change has been marked as submitted. Review request for Okular, KDE Usability and Albert Astals Cid. 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 - core/document.cpp 91c623b58d1d98e11afdce73bc3f1f68becd657c ui/searchlineedit.cpp 74e6ef60c06c2d4e0b30be1eb6804545f58bd8eb Diff: https://git.reviewboard.kde.org/r/129893/diff/4/ 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
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- (Updated Sept. 26, 2017, 8:42 p.m.) Review request for Okular, KDE Usability and Albert Astals Cid. Changes --- Removed the roundtrip core->ui->core 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 91c623b58d1d98e11afdce73bc3f1f68becd657c ui/searchlineedit.cpp 74e6ef60c06c2d4e0b30be1eb6804545f58bd8eb Diff: https://git.reviewboard.kde.org/r/129893/diff/4/ Changes: https://git.reviewboard.kde.org/r/129893/diff/3-4/ 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
D7996: Properly create KPixmapSequence
elvisangelaccio created this revision. Restricted Application added a subscriber: Okular. Restricted Application added a project: Okular. REVISION SUMMARY The KPixmapSequence constructor needs the full path of the icon, so the current code doesn't work and generates a "Invalid pixmap specified" warning at runtime. By using KIconLoader we can fix this issue. TEST PLAN Search something and reach the end of document to make the animation start. REPOSITORY R223 Okular BRANCH Applications/17.08 REVISION DETAIL https://phabricator.kde.org/D7996 AFFECTED FILES ui/searchlineedit.cpp To: elvisangelaccio Cc: #okular, aacid
D7996: Properly create KPixmapSequence
elvisangelaccio added a reviewer: Okular. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D7996 To: elvisangelaccio, #okular Cc: #okular, aacid
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/#review103715 --- Ping? Or should I re-upload the patch on phabricator for better visibility? - Elvis Angelaccio On Aug. 30, 2017, 2:47 p.m., Elvis Angelaccio wrote: > > --- > 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. > > > 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 > - > > core/document.cpp b725ecfc7 > ui/searchlineedit.cpp 74e6ef60c > > > Diff: https://git.reviewboard.kde.org/r/129893/diff/3/ > > > 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 > >
Re: Review Request 129893: Implement continuous search
--- 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
Re: Review Request 129893: Implement continuous search
> On Feb. 2, 2017, 11:38 p.m., Albert Astals Cid wrote: > > i'm not sure i agree with this change, but this doesn't seem the proper way > > to do it, if we're going to continue searching anyways, don't send a > > Okular::Document::EndOfDocumentReached, just continue searching. > > Elvis Angelaccio wrote: > Should we ask input from the usability team maybe? I find the messagebox > annoying because it usually gets in the way. If I trigger Next it's because I > have not yet found what I was looking for, so I *always* click the Continue > button in the messagebox. > > Albert Astals Cid wrote: > You're reading a 20 page document, you've already read up to page 10, and > then you decide to search for "very important thing", why would you want to > wrap if you've already read the first 10 pages? > > Anyhow sure try to get someone from usability, but comparing okular to > kate is an apples to pineapples comparison imnsho. > > Elvis Angelaccio wrote: > Consider this use case: I open a pdf because I need to search something > in there. Not the first time I open this pdf, so it gets open somewhere after > the beginning of the document. Which means there is a good chance that I > reach the end of the document without finding what I was looking for. That's > why I think the "continue from beginning?" dialog can be annoying. @Albert: I tried to rework this patch to work without `EndOfDocumentReached`, but I can't figure it out. It seems to me that we cannot get rid of it (otherwise I don't know how to notify that we reached the first or last page). - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/#review102350 --- On March 11, 2017, 5:41 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129893/ > --- > > (Updated March 11, 2017, 5:41 p.m.) > > > Review request for Okular, KDE Usability and Albert Astals Cid. > > > 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 > - > > core/document.h 1fd86262 > core/document.cpp 41b9ddfe > ui/searchlineedit.cpp baac8be0 > > 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 > >
[okular] [Bug 381328] Okular crashes when editing forms in a PDF that's located inside an archive
https://bugs.kde.org/show_bug.cgi?id=381328 Elvis Angelaccio <elvis.angelac...@kde.org> changed: What|Removed |Added CC||elvis.angelac...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 130131: Initialize cursor in PageView scrollbars with ArrowCursor (fixes bug 334798)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/130131/#review103227 --- +1 - Elvis Angelaccio On May 15, 2017, 8:30 p.m., Tobias Deiminger wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/130131/ > --- > > (Updated May 15, 2017, 8:30 p.m.) > > > Review request for Okular. > > > Bugs: 334798 > http://bugs.kde.org/show_bug.cgi?id=334798 > > > Repository: okular > > > Description > --- > > QT Docs [say](http://doc.qt.io/qt-5/qwidget.html#cursor-prop): "If no cursor > has been set, or after a call to unsetCursor(), the parent's cursor is used." > For us this means, as long as PageView child scrollbars are not initialized, > their cursor will be whatever the PageView cursor is. I think it's reasonable > to let the scrollbar cursors always be an arrow, unconditionally. > > Furthermore, would you expect the cursor in selection mode to change from > cross back to arrow if it resides in the "empty grey space" in between the > page and the scrollbar? At the moment the patch doesn't change that > behaviour, cursor will stay a cross there. > > > Diffs > - > > ui/pageview.cpp 28cf77df9d92b92a33f427217a1438bc452c0eb0 > > Diff: https://git.reviewboard.kde.org/r/130131/diff/ > > > Testing > --- > > > Thanks, > > Tobias Deiminger > >
[okular] [Bug 334798] Mouse cursor appearence does not change when hovering
https://bugs.kde.org/show_bug.cgi?id=334798 Elvis Angelaccio <elvis.angelac...@kde.org> changed: What|Removed |Added CC||elvis.angelac...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 129893: Implement continuous search
> On March 19, 2017, 10:30 p.m., Thomas Pfeiffer wrote: > > Great idea! > > The only feedback I have is that currently the message is visually detached > > from the search bar (which the user is likely to focus on at this point > > because that's where they've just clicked a button). > > Could it be placed at the bottom, directly above the search bar instead? Not really, it seems that with the current architecture the message widget can only be placed to the top-left corner, or top-right if the layout is right-to-left. This could be changed but I'm afraid I don't know the codebase well enough to do it. - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/#review102908 --- On March 11, 2017, 5:41 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129893/ > --- > > (Updated March 11, 2017, 5:41 p.m.) > > > Review request for Okular, KDE Usability and Albert Astals Cid. > > > 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 > - > > core/document.h 1fd86262 > core/document.cpp 41b9ddfe > ui/searchlineedit.cpp baac8be0 > > 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 > >
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- (Updated March 11, 2017, 5:41 p.m.) Review request for Okular, KDE Usability and Albert Astals Cid. Changes --- Screenshots before/after to help the usability people. 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 - core/document.h 1fd86262 core/document.cpp 41b9ddfe ui/searchlineedit.cpp baac8be0 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 (updated) 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
Re: Review Request 129893: Implement continuous search
> On Feb. 2, 2017, 11:38 p.m., Albert Astals Cid wrote: > > i'm not sure i agree with this change, but this doesn't seem the proper way > > to do it, if we're going to continue searching anyways, don't send a > > Okular::Document::EndOfDocumentReached, just continue searching. > > Elvis Angelaccio wrote: > Should we ask input from the usability team maybe? I find the messagebox > annoying because it usually gets in the way. If I trigger Next it's because I > have not yet found what I was looking for, so I *always* click the Continue > button in the messagebox. > > Albert Astals Cid wrote: > You're reading a 20 page document, you've already read up to page 10, and > then you decide to search for "very important thing", why would you want to > wrap if you've already read the first 10 pages? > > Anyhow sure try to get someone from usability, but comparing okular to > kate is an apples to pineapples comparison imnsho. Consider this use case: I open a pdf because I need to search something in there. Not the first time I open this pdf, so it gets open somewhere after the beginning of the document. Which means there is a good chance that I reach the end of the document without finding what I was looking for. That's why I think the "continue from beginning?" dialog can be annoying. - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/#review102350 ------- On Feb. 9, 2017, 10:08 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129893/ > --- > > (Updated Feb. 9, 2017, 10:08 p.m.) > > > Review request for Okular, KDE Usability and Albert Astals Cid. > > > 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 > - > > core/document.h 1fd86262 > core/document.cpp 41b9ddfe > ui/searchlineedit.cpp baac8be0 > > 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. > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- (Updated Feb. 9, 2017, 10:08 p.m.) Review request for Okular, KDE Usability and Albert Astals Cid. 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 - core/document.h 1fd86262 core/document.cpp 41b9ddfe ui/searchlineedit.cpp baac8be0 Diff: https://git.reviewboard.kde.org/r/129893/diff/ Testing (updated) --- 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. Thanks, Elvis Angelaccio
Re: Review Request 129893: Implement continuous search
> On Feb. 2, 2017, 11:38 p.m., Albert Astals Cid wrote: > > i'm not sure i agree with this change, but this doesn't seem the proper way > > to do it, if we're going to continue searching anyways, don't send a > > Okular::Document::EndOfDocumentReached, just continue searching. Should we ask input from the usability team maybe? I find the messagebox annoying because it usually gets in the way. If I trigger Next it's because I have not yet found what I was looking for, so I *always* click the Continue button in the messagebox. - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/#review102350 --- On Feb. 1, 2017, 11:20 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129893/ > --- > > (Updated Feb. 1, 2017, 11:20 p.m.) > > > Review request for Okular and Albert Astals Cid. > > > 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 > - > > core/document.h 1fd86262 > core/document.cpp 41b9ddfe > ui/searchlineedit.cpp baac8be0 > > Diff: https://git.reviewboard.kde.org/r/129893/diff/ > > > Testing > --- > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- (Updated Feb. 1, 2017, 11:20 p.m.) Review request for Okular and Albert Astals Cid. Changes --- Rebased on current master 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.h 1fd86262 core/document.cpp 41b9ddfe ui/searchlineedit.cpp baac8be0 Diff: https://git.reviewboard.kde.org/r/129893/diff/ Testing --- Thanks, Elvis Angelaccio
Re: Review Request 129894: Fix wrong apidox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129894/ --- (Updated Jan. 29, 2017, 6:30 p.m.) Status -- This change has been marked as submitted. Review request for Okular and Albert Astals Cid. Changes --- Submitted with commit 3b610bd86a2393fca1f04e02e2b7d899835fe635 by Elvis Angelaccio to branch master. Repository: okular Description --- The `duration` argument is used as input of `QTimer::start()`, which requires milliseconds and not seconds. Diffs - core/document.h bac38f89 Diff: https://git.reviewboard.kde.org/r/129894/diff/ Testing --- Thanks, Elvis Angelaccio
Re: Review Request 129894: Fix wrong apidox
> On Jan. 26, 2017, 11:47 p.m., Elvis Angelaccio wrote: > > I don't understand https://bugs.kde.org/show_bug.cgi?id=354133 but this > > patch probably fixes it as side effect. Oh sorry, this comment was supposed to be for RR 129893 - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129894/#review102266 --- On Jan. 26, 2017, 11:37 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129894/ > --- > > (Updated Jan. 26, 2017, 11:37 p.m.) > > > Review request for Okular and Albert Astals Cid. > > > Repository: okular > > > Description > --- > > The `duration` argument is used as input of `QTimer::start()`, which requires > milliseconds and not seconds. > > > Diffs > - > > core/document.h bac38f89 > > Diff: https://git.reviewboard.kde.org/r/129894/diff/ > > > Testing > --- > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129894: Fix wrong apidox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129894/#review102266 --- I don't understand https://bugs.kde.org/show_bug.cgi?id=354133 but this patch probably fixes it as side effect. - Elvis Angelaccio On Jan. 26, 2017, 11:37 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129894/ > --- > > (Updated Jan. 26, 2017, 11:37 p.m.) > > > Review request for Okular and Albert Astals Cid. > > > Repository: okular > > > Description > --- > > The `duration` argument is used as input of `QTimer::start()`, which requires > milliseconds and not seconds. > > > Diffs > - > > core/document.h bac38f89 > > Diff: https://git.reviewboard.kde.org/r/129894/diff/ > > > Testing > --- > > > Thanks, > > Elvis Angelaccio > >
Review Request 129894: Fix wrong apidox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129894/ --- Review request for Okular and Albert Astals Cid. Repository: okular Description --- The `duration` argument is used as input of `QTimer::start()`, which requires milliseconds and not seconds. Diffs - core/document.h bac38f89 Diff: https://git.reviewboard.kde.org/r/129894/diff/ Testing --- Thanks, Elvis Angelaccio
Review Request 129893: Implement continuous search
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129893/ --- Review request for Okular and Albert Astals Cid. 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 - core/document.h bac38f89 core/document.cpp 468a8a9f ui/searchlineedit.cpp 85516efb Diff: https://git.reviewboard.kde.org/r/129893/diff/ Testing --- Thanks, Elvis Angelaccio
