[Okular-devel] [okular] [Bug 317073] Request to add fade transition to presentation mode
https://bugs.kde.org/show_bug.cgi?id=317073 Prakhar Mohan prakhar.0...@gmail.com changed: What|Removed |Added CC||prakhar.0...@gmail.com --- Comment #1 from Prakhar Mohan prakhar.0...@gmail.com --- Hi. I would like to take up this bug. How to go about it (In reply to comment #0) HI, i whould like to to have fade transition for presentation mode. I think it's more suitable for presentations rather than all the transitions available currently in Okular. Reproducible: Always -- 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 317183] New: okular/poppler crashes when printing a deleted PDF file
https://bugs.kde.org/show_bug.cgi?id=317183 Bug ID: 317183 Summary: okular/poppler crashes when printing a deleted PDF file Classification: Unclassified Product: okular Version: 0.16.1 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: fa...@kde.org Application: okular (0.16.1) KDE Platform Version: 4.10.1 (Compiled from sources) Qt Version: 4.8.5 Operating System: Linux 3.7.10-1.1-desktop x86_64 Distribution: openSUSE 12.3 (x86_64) -- Information about the crash: - What I was doing when the application crashed: I opened a PDF that was attached to a mail, in kmail. I.e. okular was showing a temporary file. Then I switched to another email in kmail -- which deleted the temporary file. Then I tried to print the PDF - okular crashed. (I think it can also crash when just scrolling around the document, I had that before.) If the PDF is loaded on demand, I guess there's no way to actually make this work. But maybe it could detect this case, and show an error message rather than crash. -- Backtrace: Application: Okular (okular), signal: Segmentation fault Using host libthread_db library /lib64/libthread_db.so.1. [KCrash Handler] #6 _IO_new_fclose (fp=0x0) at iofclose.c:54 #7 0x7fd341a63e40 in UniqueFileStream::~UniqueFileStream (this=0x2650d50, __in_chrg=optimized out) at /d/kde/src/4/poppler/poppler/Stream.cc:764 #8 0x7fd341a63e59 in UniqueFileStream::~UniqueFileStream (this=0x2650d50, __in_chrg=optimized out) at /d/kde/src/4/poppler/poppler/Stream.cc:765 #9 0x7fd341a6be9e in XRef::~XRef (this=0x25647a0, __in_chrg=optimized out) at /d/kde/src/4/poppler/poppler/XRef.cc:403 #10 0x7fd341dc2cb3 in cleanup (pointer=0x25647a0) at /d/qt/4/qt-for-trunk/include/QtCore/../../src/corelib/tools/qscopedpointer.h:62 #11 ~QScopedPointer (this=synthetic pointer, __in_chrg=optimized out) at /d/qt/4/qt-for-trunk/include/QtCore/../../src/corelib/tools/qscopedpointer.h:100 #12 Poppler::Document::info (this=optimized out, type=...) at /d/kde/src/4/poppler/qt4/src/poppler-document.cc:291 #13 0x7fd342000c7c in PDFGenerator::metaData (this=0x1593530, key=..., option=...) at /d/kde/src/4/kde/kdegraphics/okular/generators/poppler/generator_pdf.cpp:1233 #14 0x7fd349349cc6 in Okular::Document::metaData (this=optimized out, key=..., option=...) at /d/kde/src/4/kde/kdegraphics/okular/core/document.cpp:2464 #15 0x7fd34960b998 in Okular::Part::setupPrint (this=this@entry=0x12fd320, printer=...) at /d/kde/src/4/kde/kdegraphics/okular/part.cpp:2512 #16 0x7fd349616de2 in Okular::Part::slotPrint (this=0x12fd320) at /d/kde/src/4/kde/kdegraphics/okular/part.cpp:2456 #17 0x7fd349617a2a in qt_static_metacall (_a=optimized out, _id=optimized out, _o=optimized out, _c=optimized out) at /d/kde/build/4/kde/kdegraphics/okular/part.moc:231 #18 Okular::Part::qt_static_metacall (_o=optimized out, _c=optimized out, _id=optimized out, _a=optimized out) at /d/kde/build/4/kde/kdegraphics/okular/part.moc:160 #19 0x7fd3584736df in QMetaObject::activate (sender=0x1698b50, m=0x7fd35a382760 QAction::staticMetaObject, local_signal_index=1, argv=0x7fffc6a0e4e0) at kernel/qobject.cpp:3548 #20 0x7fd359591b64 in QAction::triggered (this=0x1698b50, _t1=false) at .moc/debug-shared/moc_qaction.cpp:276 #21 0x7fd359590e16 in QAction::activate (this=0x1698b50, event=QAction::Trigger) at kernel/qaction.cpp:1257 #22 0x7fd359590b78 in QAction::event (this=0x1698b50, e=0x7fffc6a0ed50) at kernel/qaction.cpp:1183 #23 0x7fd35a55d4fe in KAction::event (this=0x1698b50, event=0x7fffc6a0ed50) at /d/kde/src/4/kde/kdelibs/kdeui/actions/kaction.cpp:131 #24 0x7fd3595a17d2 in QApplicationPrivate::notify_helper (this=0xff2070, receiver=0x1698b50, e=0x7fffc6a0ed50) at kernel/qapplication.cpp:4562 #25 0x7fd35959ecce in QApplication::notify (this=0x7fffc6a10610, receiver=0x1698b50, e=0x7fffc6a0ed50) at kernel/qapplication.cpp:3944 #26 0x7fd35a66c46a in KApplication::notify (this=0x7fffc6a10610, receiver=0x1698b50, event=0x7fffc6a0ed50) at /d/kde/src/4/kde/kdelibs/kdeui/kernel/kapplication.cpp:311 #27 0x7fd358454714 in QCoreApplication::notifyInternal (this=0x7fffc6a10610, receiver=0x1698b50, event=0x7fffc6a0ed50) at kernel/qcoreapplication.cpp:949 #28 0x7fd3595922b3 in QCoreApplication::sendEvent (receiver=0x1698b50, event=0x7fffc6a0ed50) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #29 0x7fd3595e2cc2 in QShortcutMap::dispatchEvent (this=0xff2190, e=0x7fffc6a0f6c0) at kernel/qshortcutmap.cpp:908 #30 0x7fd3595e0e2f in QShortcutMap::tryShortcutEvent (this=0xff2190, o=0x161e020, e=0x7fffc6a0f6c0) at kernel/qshortcutmap.cpp:364 #31 0x7fd35959ef6c in QApplication::notify (this=0x7fffc6a10610,
[Okular-devel] [okular] [Bug 317185] New: Okular takes a very long time to load chm and does not display it correctly
https://bugs.kde.org/show_bug.cgi?id=317185 Bug ID: 317185 Summary: Okular takes a very long time to load chm and does not display it correctly Classification: Unclassified Product: okular Version: 0.16.60 Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: CHM backend Assignee: okular-devel@kde.org Reporter: wh...@herr-der-mails.de Okular takes severel miutes lo load a larger chm file which is then displayed incorrectly, i.e. missing some content. CHMsee is much faster and displays the file correctly. Reproducible: Always Steps to Reproduce: 1. Open the file. 2. Wait until opened. 3. Compare displayed result with the same file opened in CHMsee. Actual Results: File takes a very long time to load and is missing whole sections. Expected Results: File loads quickly and shows all content. -- 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 317185] Okular takes a very long time to load chm and does not display it correctly
https://bugs.kde.org/show_bug.cgi?id=317185 --- Comment #1 from Jan Binder wh...@herr-der-mails.de --- Testcase is too big to attach and can be found at http://intern.sfz-bw.de/~jan.binder/LD.Api.chm -- 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 317185] Okular takes a very long time to load chm and does not display it correctly
https://bugs.kde.org/show_bug.cgi?id=317185 --- Comment #2 from Jan Binder wh...@herr-der-mails.de --- Created attachment 78290 -- https://bugs.kde.org/attachment.cgi?id=78290action=edit Screenshot showing the different display Okular on the left, CHMsee on the right showing the same file. CHMsee's rendering is much more useful. -- 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 317073] Request to add fade transition to presentation mode
https://bugs.kde.org/show_bug.cgi?id=317073 --- Comment #2 from Albert Astals Cid aa...@kde.org --- Download the code, try to look where/how the other transition effects are done, do the new one -- 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 109632: Annotation eraser
On March 21, 2013, 11:29 p.m., Albert Astals Cid wrote: It does indeed look cool, but is there a use case? I mean do you usually have so much complex Ink annotations that you need to cut them only partially? For example: 1. Correct a shoddily drawn shape 2. Remove an accidentally drawn line over something else without having to re-do what's below 3. Change an I to an i :) 4. ... Also, it much more directly mirrors what a user will probably expect from an eraser tool. FWIW, these review requests are a direct result of me trying to switch from Xournal to Okular for taking notes in class. I implemented this because I thought it would be a nice feature to use - not a nice one to implement. - Peter --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/#review29667 --- On March 21, 2013, 1:26 a.m., Peter Grasch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/ --- (Updated March 21, 2013, 1:26 a.m.) Review request for Okular. Description --- Prerequisites: Please read till the end! This introduces a new annotation tool: Eraser. The eraser primarily erases other annotations that it comes into contact with (shapes, lines, highlights, etc.). However, ink annotations are treated more like a real eraser: Existing paths are split and unaffected parts are preserved. This is what it looks like: http://bedahr.org/eraser.ogv Example tool configuration for your tools.xml (not included in patch): tool id=15 name=Eraser pixmap=tool-eraser-okular tooltipEraser/tooltip engine type=Eraser / shortcut7/shortcut /tool The eraser builds on the work for the outline selection proposed in review request #109627. Please apply that patch before this one. Diffs - ui/pageviewannotator.cpp 7bd7496 Diff: http://git.reviewboard.kde.org/r/109632/diff/ Testing --- While it worked fine for the few PDFs I threw at it on this relatively powerful machine, it was pointed out to me in #okular, that calls to modifyPageAnnotation are very expensive as poppler has to re-draw the pdf (with the annotations) for every change. I hope we can resume the discussion about possible improvements here. Thanks, Peter Grasch ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109632: Annotation eraser
On March 21, 2013, 11:29 p.m., Albert Astals Cid wrote: It does indeed look cool, but is there a use case? I mean do you usually have so much complex Ink annotations that you need to cut them only partially? Peter Grasch wrote: For example: 1. Correct a shoddily drawn shape 2. Remove an accidentally drawn line over something else without having to re-do what's below 3. Change an I to an i :) 4. ... Also, it much more directly mirrors what a user will probably expect from an eraser tool. FWIW, these review requests are a direct result of me trying to switch from Xournal to Okular for taking notes in class. I implemented this because I thought it would be a nice feature to use - not a nice one to implement. So *you* are the use case, that works for me. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/#review29667 --- On March 21, 2013, 1:26 a.m., Peter Grasch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/ --- (Updated March 21, 2013, 1:26 a.m.) Review request for Okular. Description --- Prerequisites: Please read till the end! This introduces a new annotation tool: Eraser. The eraser primarily erases other annotations that it comes into contact with (shapes, lines, highlights, etc.). However, ink annotations are treated more like a real eraser: Existing paths are split and unaffected parts are preserved. This is what it looks like: http://bedahr.org/eraser.ogv Example tool configuration for your tools.xml (not included in patch): tool id=15 name=Eraser pixmap=tool-eraser-okular tooltipEraser/tooltip engine type=Eraser / shortcut7/shortcut /tool The eraser builds on the work for the outline selection proposed in review request #109627. Please apply that patch before this one. Diffs - ui/pageviewannotator.cpp 7bd7496 Diff: http://git.reviewboard.kde.org/r/109632/diff/ Testing --- While it worked fine for the few PDFs I threw at it on this relatively powerful machine, it was pointed out to me in #okular, that calls to modifyPageAnnotation are very expensive as poppler has to re-draw the pdf (with the annotations) for every change. I hope we can resume the discussion about possible improvements here. Thanks, Peter Grasch ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109632: Annotation eraser
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/#review29738 --- So yeah, besides what Fabio comments on it may well be a bit slow (no way to speed it up unless you change poppler to do two pass rendering that might even be possible) code looks ok *but* it will stop working when the undo/redo annotations code gets merged. I'd suggest you have a look at it and try to find out how you'd apply your changes on top of it. ui/pageviewannotator.cpp http://git.reviewboard.kde.org/r/109632/#comment22135 const - Albert Astals Cid On March 21, 2013, 1:26 a.m., Peter Grasch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109632/ --- (Updated March 21, 2013, 1:26 a.m.) Review request for Okular. Description --- Prerequisites: Please read till the end! This introduces a new annotation tool: Eraser. The eraser primarily erases other annotations that it comes into contact with (shapes, lines, highlights, etc.). However, ink annotations are treated more like a real eraser: Existing paths are split and unaffected parts are preserved. This is what it looks like: http://bedahr.org/eraser.ogv Example tool configuration for your tools.xml (not included in patch): tool id=15 name=Eraser pixmap=tool-eraser-okular tooltipEraser/tooltip engine type=Eraser / shortcut7/shortcut /tool The eraser builds on the work for the outline selection proposed in review request #109627. Please apply that patch before this one. Diffs - ui/pageviewannotator.cpp 7bd7496 Diff: http://git.reviewboard.kde.org/r/109632/diff/ Testing --- While it worked fine for the few PDFs I threw at it on this relatively powerful machine, it was pointed out to me in #okular, that calls to modifyPageAnnotation are very expensive as poppler has to re-draw the pdf (with the annotations) for every change. I hope we can resume the discussion about possible improvements here. Thanks, Peter Grasch ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 315703] Zoom, Selection, Text Selection (and possibly other) tools not working in 0.16.0 KDE 4.10 Kubuntu 12.04
https://bugs.kde.org/show_bug.cgi?id=315703 --- Comment #17 from defectosco...@gmail.com --- Albert Astals Cid, as much as I appreciate your free time and effort put into helping me, please refrain from posting such comments in the future - some might find those offensive. Still, though, if those were my actions that caused the issue, would you be so kind as to explain what exactly may have resulted in *rc files being owned by root? I'm also curious as to why the version from the Kubuntu Backports PPA and the one from the standard repo handle said file differently. I'd very much like to avoid it from this point onward. Thanks! -- 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
