Re: GSoC Project: Verifying signatures of pdf files (Draft Proposal)
I edited my proposal after researching how Adobe Acrobat implements the UI and made some modifications to my plan. I would appreciate any feedback regarding my proposal. Regards, On Fri, Mar 9, 2018 at 6:55 PM, Ahmad Osama wrote: > Dear All; > > I am interested to participate with Okular in GSoC, I have written a draft > proposal about the project I am interested to join. > > Here is the link to my proposal: > > https://docs.google.com/document/d/1DIQBvzPjuw8HdqEB0qXt4nkQ05bF_ > AV9_6kyrRcdJW8/edit?usp=sharing > > I am still going through Okular and Poppler's source code to get a better > understanding and develop a better implementation plan. > > Any feedback or suggestions are highly appreciated. > > Regards, > Ahmad Osama >
D10932: [Okular] Option to reset forms
ahmadosama updated this revision to Diff 29771. ahmadosama added a comment. I have done the required changes. I created the EditWidgetsCommand class to undo/redo the reset action of all widgets by a single click, also I moved the core implementation of the reset function to the Document class, and I updated the reset auto test to include the undo/redo and the test is working fine on the created tests. REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D10932?vs=29396&id=29771 REVISION DETAIL https://phabricator.kde.org/D10932 AFFECTED FILES autotests/CMakeLists.txt autotests/resetformstest.cpp core/document.cpp core/document.h core/documentcommands.cpp core/documentcommands_p.h part.cpp part.h part.rc ui/pageview.cpp ui/pageview.h To: ahmadosama, #okular, aacid Cc: ngraham, aacid, #okular, michaelweghorn
[okular] [Bug 391972] New: okular slower than evince at rendering a pdf
https://bugs.kde.org/show_bug.cgi?id=391972 Bug ID: 391972 Summary: okular slower than evince at rendering a pdf Product: okular Version: 1.3.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: kjs...@gmail.com Target Milestone: --- Okular renders some pdfs much slower than Evince, even though both use Poppler for the pdf backend. Since the same backend is used, I would expect the pdf render time to be the same. For example, the second page of this pdf https://arxiv.org/pdf/1701.07837v2 takes over 3 seconds for Okular to render. However, Evince renders it almost instantly. Or when quickly scrolling through a large pdf, Evince seems to render the pages almost instantly, while Okular renders slower than I can (quickly) scroll. Here is an example large pdf: https://arxiv.org/pdf/1508.02595v4 I'm using Okular 1.3.3, Evince 3.26.0, and poppler 0.61.1 on Archlinux (with an Intel i7-3720QM @ 2.6GHz). -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 391972] okular slower than evince at rendering a pdf
https://bugs.kde.org/show_bug.cgi?id=391972 Kevin changed: What|Removed |Added CC||kjs...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.
D11250: Expose presentation via MPRIS to rich remote controllers
kossebau added a comment. So far got a few comments about this being a nice idea in general, and one already about something in the code. So far all positive. Now, where are the negative ones, there must be some :) If not or even then, I hope for some good people for some further detailed review of the code and/or feature in the next days, please :) I know this came late in as new feature for 18.04, but still would be glad if we could manage to decide about it just in time (5 days left still until feature freeze next Thursday). Some more motivational info about this patch: While the current state of this feature is yet missing a lot over e.g. what is possible with https://wiki.documentfoundation.org/Impress_Remote , it still already adds value for people wanting to remote control their presentation, but who do not have a special wireless remote control input device. Older projects like https://code.google.com/archive/p/remuco/ or (k)anyRemote also supporting Okular show there are at least some people who like to have such functionality for making use of their existing mobile device instead. Also having this now in Okular, next to Gwenview (which already got a similar feature a few days ago), allows to keep Okular presentation feature in the loop and getting feedback from users already when working on enhancing the MPRIS spec for a future version for improved support for non-music media (see also https://community.kde.org/MPRIS#Features_for_MPRIS_3.0 for planning). For your inspiration about the proposed feature, here another thing which gets possible this way: in a meeting everyone could have their mobile connected with KDE Connect to the presentation device running Okular, and in discussion then everybody could navigate through the current presentation thanks to KDE Connect & MPRIS :) No more need to having to tell the current presentation-doing person which slide you want to see again or pass the remote control around or stand up and take over position next to presentation device when it is your turn. Just keep leaned back in your chair with legs up and touch your mobile :) And some note: when testing with KDE Connect for Android, make sure to use latest version 1.8, there had been some glitches with previous/next action buttons before. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D11250 To: kossebau, #okular Cc: pino, rkflx, #kde_connect, michaelweghorn, ngraham, aacid
