Thank you Tobias for making it landable. Please go ahead :)

Set flag HAVE_POPPLER_0_67 in generator/poppler

Updated generator/poppler for text color

Added font color in Okular

Updating tools.xml <annotation> elements color attributes to incorporate #AARRGGBB color formats

Adapt CloseDialogHelper for use with QInputDialog.
Close typewriter input dialog with ok button and test for expected typewriter annotation.

Adding tests for typewriter annotation tool

Diff changed after commiting to gsoc2018_typewriter branch. Updating it.

Updating annotation popup window background color

The revision is closed. I'm unable to update it. Maybe someone with admin privileges should reopen it?

Hell! Sorry for this mistake again. Whenever I update the revision, I push the commit to the gsoc2018_typewriter branch too and the revision landed in need review state by that commit (both have the same hash).
@ltoscano May you please reopen this revision?

Fixed initial typewriter border width to 0

I didn't mean to change anything in Poppler. I meant it's the way it works in Poppler right now. I assume if both 'rg' operator and 'ca' entry are applied, alpha gets multiplied. Probably also depending on >blend mode. I don't know how this works exactly, it's a longer read through AnnotFreeText::generateFreeTextAppearance and the spec (e.g. 11.6.3 Specifying Blending Colour and Blend Mode). Maybe you >can figure it out on your own?

Fixed typewriter transparency in PagePainter

How about changing ui/pagepainter.cpp L668 to

acolor.setAlpha( a->style().opacity() * a->style().color().alpha() );

It gives us transparent background for new typewriter annotations. It should be backwards/forwards compatible with *.okular documents from other Okular versions. And I believe it's more consistent to what happens in Poppler, because I assume in Poppler color[alpha] and opacity will also get multiplied to determine the final alpha of background color for FreeText, if both values are set. But haven't verified this assumption yet.

In D13203#270552, @tobiasdeiminger wrote:

If I use the new tool to typewrite onto a plain text file, I get opaque white background instead of transparent background. Transparency does work for PDF documents (i.e. rendered by poppler). In the former case the typewriter annotation is drawn in ui/pagepainter.cpp L.680. Can you checkout what's wrong there?

We should add something like "Transparent background working on any supported document type" to the testplan (or only test .pdf and .txt for a start, it's enough to test both generator and pagepainter drawing paths).

The gsoc* branches are meant to share and log small junks of GSoC progress frequently (even daily), prior to publishing a ready-to-review patch on phabricator. But there haven't been any intermediate GSoC commits during the past two weeks on gsoc2018_typewriter. D13203 on phabricator is just the same as c344c5e31b6a in the branch. So both diffs have the same hash and therefore got automatically linked.

If you don't push your work-in-progress frequently to gsoc2018_typewriter, I doubt there's a point in having that extra branch branch at all. You could equally work on a local branch only and submit a patch after few weeks to phabricator.

@ngraham This is the part of my GSoC project: https://summerofcode.withgoogle.com/projects/#6053164340477952

Currently I am working as a GSoC student and in discussion with my mentor, I have decided to pause the patch report during the GSoC period. BBL

The state can be saved whenever a sidebar item is clicked in Sidebar::itemClicked but again as discussed earlier, it will be asymmetrical as to save in sidebar.cpp. Should I implement a signal slot mechanism in part.cpp to achieve so or should I find another way?

I tried but it is still giving me the segfault. The interesting thing, in my opinion, is whenever you open Okular and close it down without changing the sidebar state, it doesn't give a segfault whereas changing the sidebar state and closing it gives the error.
Should we stick to it or should we consider saving the stats in the Sidebar::~Sidebar()?

The verbose output of valgrind is around 190,000 lines with the line numbers. Here is the output:

https://paste.kde.org/pepnfuzxq

Following is the log of running valgrind on okular:

Updating: Remembring side navigation panel state
Changing the state to the one being discussed here in comments.

Actually I am getting the segmentation fault whenever I close Okular with a changed state of the side navigation panel and the code causing it is Okular::Settings::setHideSideContainer( m_sidebar->isCollapsed() ) inside the Part destructor. m_sidebar is not causing this problem as I misunderstood the earlier; it gives the segfault for any value as the argument of setHideSideContainer except for the boolean values True and False. It works fine for the absolute boolean values.
Running it with gdb, I got segfault in QAbstractScrollArea::horizontalScrollBarPolicy() const () from /usr/lib/libQt5Widgets.so.5 that is confusing for me. I need an idea regarding what can be done in this case?

In D11051#222205, @aacid wrote:

Also i'm not convinced it's a good idea to save the settings in sidebar.cpp but read them in part.cpp, seems a bit asymmetrical, can you explain your reasoning for it?

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

Updating D10249: Option to exit after printing

Oops! As I was getting errors in the autotests/mainshelltest.cpp file while make okular, I assumed the autotest didn't compile and build successfully. I also assumed the make command runs the tests too. Now running with ./autotests/mainshelltest, I got the error. After rectifying and rebuilding, I run the autotest again and whenever the window opens for the showPrintDialogAndExit, it waits for the user input and exits on clicking either Print or Cancel button. The autotest also stops there without showing any information about the passed and failed tests.
I'm not getting what's going on and how to proceed from this point. I even don't whether it is some error or the std::exit function stops the running test too. Should I eliminate 'showPrintDialogAndExit' row along with externalProcessExpectPrintDialogAndExit column?

No I ran the tests too and it was a success.

Updating D10249: Option to exit after printing
Tried my best to edit the data driven tests by adding appropriate data to the table using QTest::newRow function.

@aacid I have talked about using std::exit instead of QCoreApplication::exit here : https://phabricator.kde.org/D10249#200260

Updating D10249: Option to exit after printing
renamed isError variable to success and changed the option with -print-and-exit.

Updating D10249: Option to exit after printing
Initialized "isError" with false at the time of declaration.

Updating D10249: Option to exit after printing

Updating D10249: Option to exit after printing

Updating D10249 : Option to exit after printing

@aacid Agree that only one exit call is required but what about the exit status - EXIT_SUCCESS or EXIT_FAILURE? The issue description talked about the command line batch processing. For that purpose, should I set a bool "isError" when failing condition is encountered like "printing is not allowed" and then based on the isError's status, should I call either exit (EXIT_SUCCESS) or exit (EXIT_FAILURE)?

Thank you so much. I'm checking it out.

Sure :)

In D10209#198608, @ngraham wrote:

Lovely. Tested it out and it works as expected. Fix the BUG: string and I'll land this.

In D10209#198568, @ngraham wrote:

Thanks for the patch! Can you indicate your testing, and perhaps provide a screenshot that shows this working?

Also, the title of the revision is really better suited to being in the summary. For the title, try to briefly explain the overall purpose. Maybe something like "Use correct arrow cursor for Annotations' close buttons"