D15279: Store all annotation color attributes as ARGB string

[Dileep Sankhla]

dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

BRANCH
  annotation_rgba

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

To: tobiasdeiminger, sander
Cc: dileepsankhla, sander, okular-devel, ngraham, aacid

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla abandoned this revision.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: sander, ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

Re: Contributing to Okular

[Dileep Sankhla]

Hi Kanchan,

Welcome to the project Okular! KDE Community greets you :)

1. You should have an intermediate programming experience in C++ ranging
from basic variables and iterations to class and objects. If you know about
the basic constructs in C++ including functions then you can begin to
contribute! You can learn about the classes and objects, templates etc by
going through the quick tutorials when required as on the way. I would
suggest you to follow a cpp tutorial online and learn by coding the samples
on the way. Compile and build your code from the terminal using g++ and/or
make. If you want to use an IDE, use eclipse.

2. Regarding Qt, the Qt docs are apt. You should only know the mechanism of
signals and slots which you can learn here [0]. This should be done after
gaining some experience in C++. Rest, you can search for the functions and
their signatures and return types on the docs.
Do some sample Qt programming in the latest Qt 5 using QtCreator IDE.

3. Use Linux with KDE desktop environment installed. Don't use windows. The
best OS, in my opinion, is kubuntu. Forget the mouse and the GUI and work
on the terminal. Use the commands frequently, don't memorize them and
eventually you will get used to them. You can google for the commands
anytime but also try to notice what and how it is doing.

4. Learn git. Install git into your system and learn the basics of commits,
branches, rebase etc. A quick overview of git is here [1]. You should read
the first 3 chapters of this book [2].

5. Learn a bit about cmake and how to build the projects using cmake. The
best tutorial is on its official website [2]. Build a sample Qt project
using cmake.

6. Now after going through all of them, which I think would take a couple
of weeks for the absolute beginner, it's your time to build Okular from the
source. This is your first task towards contributing to Okular. Follow [4].
If stuck, message on #okular channel on IRC freenode or send a quick mail
here.

7. After building okular from the source, your next task is to pick up a
junior job. Go to [5], create an account, search for the junior jobs in
Okular and begin with hacking into the codebase. Submit your first patch on
[6].

Hope it helps!

Cheers
Dileep


[0] http://doc.qt.io/qt-5/signalsandslots.html
[1] https://try.github.io/
[2] https://git-scm.com/book/en/v2
[3] https://cmake.org/cmake-tutorial
[4] https://okular.kde.org/download.php#okular
[5] bugs.kde.org
[6] http://phabricator.kde.org

On Sat, Aug 4, 2018 at 7:07 PM Kanchan K  wrote:

> Hi,
> My name is Kanchan.I have been using Okular for a while now.As I'm also a
> developer,I thought I would try my hand on contributing to Okular.
>
> I have mostly been a web developer so far,so I do not have much experience
> with C++ and I have never done any Qt development.
> It would be helpful if someone would suggest some other tasks which I
> could start with.
>
> Thanks,
> Kanchan K
>

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 38049.
dileepsankhla added a comment.


  Set flag HAVE_POPPLER_0_67 in generator/poppler

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=37378=38049

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  core/annotations.h
  generators/poppler/CMakeLists.txt
  generators/poppler/annots.cpp
  generators/poppler/config-okular-poppler.h.cmake
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: sander, ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla marked 7 inline comments as done.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: sander, ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added inline comments.

INLINE COMMENTS

> sander wrote in annots.cpp:182
> 1.) yes
> 
> 2. You need to write a test that sets the HAVE_POPPLER_0_67 flag. Have a look 
> at that CMakeLists.txt file.  It contains calls to check_cxx_source_compiles. 
> Each call contains a small C++ program and a HAVE_POPPLER_*** flag. The build 
> system tries to compile the program, and if that works, then the flag is set. 
>  You need to write a new call that tests for your setTextColor method, and 
> set the HAVE_POPPLER_0_67 flat.

I have added the following lines in generator/poppler/CMakeLists.txt:

  check_cxx_source_compiles("
  #include 
  #include 
  int main()
  {
  Poppler::TextAnnotation *annot = new Poppler::TextAnnotation( 
Poppler::TextAnnotation::InPlace );
  annot->setTextColor(Qt::blue);
  return 0;
  }
  " HAVE_POPPLER_0_67)

The typewriter text is created with the desired color but whenever I move the 
annotation, the text color falls back to "black". It means in 
```PopplerAnnotationProxy::notifyModification```,  ```ppl_txtann->setTextColor( 
okl_txtann->textColor() );``` is never get called. Why is this happening even 
after setting the flag in both CMakeLists.txt and annots.cpp?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: sander, ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added inline comments.

INLINE COMMENTS

> tobiasdeiminger wrote in annots.cpp:182
> Poppler::TextAnnotation::setTextFont is brand new poppler API (actually not 
> yet merged). We still want to support builds with older poppler versions. So 
> setTextFont needs to be surrounded by some
> 
>   #ifdef HAVE_POPPLER_0_xy
>   #endif
> 
> where 0_xy is the poppler release for which we assume the API to be released. 
> Maybe 0_67, to be optimistic.
> 
> To detect poppler version at build time, add a check_cxx_source_compiles for 
> Poppler::TextAnnotation::setTextFont and define HAVE_POPPLER_0_67 accordingly 
> in generators/poppler/CMakeLists.txt. Also add a cmakedefine to 
> generators/poppler/CMakeLists.txt. You'll find existing examples for other 
> versions if you look at these files.

1. Do I need to do something like this in okular/generators/poppler/annots.cpp:



  #ifdef HAVE_POPPLER_0_67
  
  ppl_txtann->setTextColor( okl_txtann->textColor() );
  
  #endif //HAVE_POPPLER_0_67



2. I didn't get what to do in generators/poppler/CMakeLists.txt. May you 
provide me an example?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 37378.
dileepsankhla added a comment.


  Updated generator/poppler for text color

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=37290=37378

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  core/annotations.h
  generators/poppler/annots.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 37290.
dileepsankhla added a comment.


  Added font color in Okular

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=36397=37290

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  core/annotations.h
  generators/poppler/annots.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 36397.
dileepsankhla marked an inline comment as done.
dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=36312=36397

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla marked 4 inline comments as done.
dileepsankhla added inline comments.

INLINE COMMENTS

> tobiasdeiminger wrote in editannottooldialog.cpp:128
> > So if we adopt the new color format in the default tools in tools.xml, do 
> > we need to alter all the color entries? Or is it okay to have two color 
> > formats?
> 
> I'm not sure if I understand this question. Of course not all color entries 
> that appear somewhere in okular source code  We shall just be consistent with
> 
>   const QString color = m_stubann->style().color().name(QColor::HexArgb);
> 
> So adapt everything to #AARRGGBB that will affect 
> Okular::Annotation::style()->color(). Afaikt this are the color=... 
> attributes of  elements in tools.xml. But not the color=... 
> attributes of  elements, because they don't affect 
> Okular::Annotation::style()->color(). Are there other places?

> Are there other places?

No, there are not. I'm updating the revision with tools.xml having  
elements color attributes incorporating #AARRGGBB color format.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla edited the test plan for this revision.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 36312.
dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35977=36312

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla marked 7 inline comments as done.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added inline comments.

INLINE COMMENTS

> tobiasdeiminger wrote in parttest.cpp:1582
> The QInputDialog is pure Qt functionality, just closing it is not that 
> interesting in a typewriter test case. The more interesting thing is to 
> verify if annotation is created correctly after closing.

First of all, in CloseDialogHelper, `m_clicked` is always false as 
`m_part->widget()->findChild();` returns NULL for the QInputDialog 
being the activeModalWidget. So I didn't use it.

Secondly, I agree that the low tests should be independent but I'm using 
`QTimer` technique in `testTypewriterAnnotTool` to grab the pointer to the 
active QInputDialog widget for which I need to connect the SIGNAL timeout() to 
the SLOT testDialogClosed which eventually becomes another test method. So I 
can't do it in only a single method instead need two different methods in which 
one of them becomes the slot of QTimer implementation. In this case. do you 
think I should do the same in the dedicated class like PartTestAnnotation?

Thirdly, to verify if the annotation is created correctly, what parameter(s) 
should I check?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 35977.
dileepsankhla added a comment.


  Adding tests for typewriter annotation tool

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35508=35977

BRANCH
  master

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

AFFECTED FILES
  autotests/annotationstest.cpp
  autotests/parttest.cpp
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

Re: Need help in getting started with writing the integration test

[Dileep Sankhla]

On Sat, Jun 9, 2018 at 1:43 AM Tobias Deiminger  wrote:

> Am 08.06.2018 18:57 schrieb Dileep Sankhla:
> > Hello Tobias,
> >
> > I have succeeded in getting the QInputDialog to write a new note:
> >
> > QMetaObject::invokeMethod(part.m_pageView, "slotToggleAnnotator",
> > Q_ARG( bool, true ));  // displayes the annotation toolbar
> > QList toolbuttonList =
> > part.m_pageView->findChildren(); // Get the list of all
> > 10 annotation toolbuttons
> >
> > QToolButton* typewriterButton = toolbuttonList.at(9); // Get's
> > typewriter toolbutton at 10th posiiton
> >
> > typewriterButton->click();  // clicks and selects the typewriter tool
> >
> > // Clicks on the viewport and a QInputDialog popups
> > QTest::mouseMove(part.m_pageView->viewport(), QPoint(width * 0.5,
> > height * 0.2));
> > QTest::mouseClick(part.m_pageView->viewport(), Qt::LeftButton,
> > Qt::NoModifier, QPoint(width * 0.5, height * 0.2));
> >
> > It popups a multiline QInputDialog annotation window and prompts for
> > the note. I write any content, press OK and the test ends.
> > My question is how to check if the popup window appears in the test as
> > it doesn't have any parent widget? So I can't do findChildren on
> > part.m_pageView to check for the QInputDialog.
>
> QApplication::activeModalWidget [0], QApplication::topLevelWidgets [1]
> and friends come to my mind to find the QInputDialog window. You can get
> the current QApplication with the qApp macro at any scope.
>
Actually as soon as the QInputDialog window shows up, it blocks the main
UI. Only after manually closing it, the next code to grab the pointer of
QInputDialog executes which then gives me the null QWidget. In this case,
is there any way to continue with the UI thread and grab the pointer to the
dialog without manually interacting with it?


>
> > And after checking for
> > the QInputDialog, how to CANCEL the dialog in the test so that my test
> > doesn't pause at user's input prompt? I just need an idea as I'm stuck
> > here.
>
> Once you've got a pointer to the dialog widget, I think you can invoke
> QDialog::done [2] to finish text input and continue annotation creation,
> or QWidget::close [3] to just close it.
>
> Had no time to look into the other issues in this thread yet, sorry.
> Will answer later unless someone other does.
>
> Cheers
> Tobias
>
> [0] http://doc.qt.io/qt-5/qapplication.html#activeModalWidget
> [1] http://doc.qt.io/qt-5/qapplication.html#topLevelWidgets
> [2] http://doc.qt.io/qt-5/qdialog.html#done
> [3] http://doc.qt.io/qt-5/qwidget.html#close
>

Re: Need help in getting started with writing the integration test

[Dileep Sankhla]

Hello Tobias,

I have succeeded in getting the QInputDialog to write a new note:

QMetaObject::invokeMethod(part.m_pageView, "slotToggleAnnotator", Q_ARG(
bool, true ));  // displayes the annotation toolbar
QList toolbuttonList =
part.m_pageView->findChildren(); // Get the list of all 10
annotation toolbuttons

QToolButton* typewriterButton = toolbuttonList.at(9); // Get's typewriter
toolbutton at 10th posiiton
typewriterButton->click();  // clicks and selects the typewriter tool

// Clicks on the viewport and a QInputDialog popups
QTest::mouseMove(part.m_pageView->viewport(), QPoint(width * 0.5, height *
0.2));
QTest::mouseClick(part.m_pageView->viewport(), Qt::LeftButton,
Qt::NoModifier, QPoint(width * 0.5, height * 0.2));

It popups a multiline QInputDialog annotation window and prompts for the
note. I write any content, press OK and the test ends.
My question is how to check if the popup window appears in the test as it
doesn't have any parent widget? So I can't do findChildren on
part.m_pageView to check for the QInputDialog. And after checking for the
QInputDialog, how to CANCEL the dialog in the test so that my test doesn't
pause at user's input prompt? I just need an idea as I'm stuck here.

Secondly, I'm doing like this to create and add a typewriter annotation to
page:

part.m_document->setViewportPage(0);

Okular::Annotation * annot = nullptr;
Okular::TextAnnotation * ta = new Okular::TextAnnotation();
annot = ta;
ta->setFlags( ta->flags() | Okular::Annotation::FixedRotation );
ta->setTextType( Okular::TextAnnotation::InPlace );
ta->setInplaceIntent( Okular::TextAnnotation::TypeWriter );
ta->style().setWidth( 0.0 );
ta->style().setColor( QColor(255,255,255,0) );

annot->setBoundingRectangle( Okular::NormalizedRect( 0.8, 0.1, 0.85, 0.15 )
);
annot->setContents( QStringLiteral("annot contents") );
// Add annotation to page
part.m_document->addPageAnnotation( 0, annot );

I'm sleeping the UI thread with QThread::sleep(5) for 5 seconds in order to
hold the output widget and I'm not getting any visual of the added
annotation. I want to compare different properties from
Okular::Annotation::getAnnotationPropertiesDomeNode. May you help me where
I'm wrong or what I'm missing?

Thanks and Regards
Dileep


On Fri, Jun 8, 2018 at 3:20 PM Dileep Sankhla 
wrote:

> Thank you. I have created a single test case for the typewriter
> toolbutton and have pushed it to the gsoc2018_typewriter branch.
>
> I have defined 3 test cases as follows:
> 1. Check if the toolbar buttons contain the "Typewriter" button - Done
> 2. Click the typewriter button, start PickPointEngine engine, click and
> drag on PDF page to create a block and check if a popup QInputDialog opens
> 3. Add typewriter to a Okular::Document with
> setTextType(Okular::TextAnnotation::InPlace) and
> setInplaceIntent(Okular::TextAnnotation::TypeWriter), and check
> Okular::Annotation::getAnnotationPropertiesDomNode for expected
> attributes.
>
> I'm only sticking to the simple test cases at the initial as I'm new to
> writing tests and having the limited time. I don't know how to write a test
> that checks painting results pixel-wise and there are already none so my
> test cases are simple. I will write more complicated tests after doing the
> font color in both Poppler and Okular.
>
> Thanks and Regards
> Dileep
>

Re: Need help in getting started with writing the integration test

[Dileep Sankhla]

Thank you. I have created a single test case for the typewriter
toolbutton and have pushed it to the gsoc2018_typewriter branch.

I have defined 3 test cases as follows:
1. Check if the toolbar buttons contain the "Typewriter" button - Done
2. Click the typewriter button, start PickPointEngine engine, click and
drag on PDF page to create a block and check if a popup QInputDialog opens
3. Add typewriter to a Okular::Document with
setTextType(Okular::TextAnnotation::InPlace) and
setInplaceIntent(Okular::TextAnnotation::TypeWriter), and check
Okular::Annotation::getAnnotationPropertiesDomNode for expected attributes.

I'm only sticking to the simple test cases at the initial as I'm new to
writing tests and having the limited time. I don't know how to write a test
that checks painting results pixel-wise and there are already none so my
test cases are simple. I will write more complicated tests after doing the
font color in both Poppler and Okular.

Thanks and Regards
Dileep

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added inline comments.

INLINE COMMENTS

> tobiasdeiminger wrote in editannottooldialog.cpp:128
> So from now on ALL annotations (even ink, highlight, inline note etc) that 
> are created by a user-defined tool will store color as #AARRGGBB in *.okular 
> document archive, right? Formerly it was #RRGGBB.
> 
> What will happen if user A with new Okular saves an inline note to 
> mydoc.okular and sends mydoc.okular to user B who has an older Okular 
> version. Will the older version be able to deal with #AARRGGBB? How is it 
> vice versa, user B sending something to user A?
> 
> If this change is indeed forwards and backwards compatible, I think it's good 
> to go this way. We prepare other annotations types for transparency without 
> destroying something. Then we should however also adapt the color=... 
> attributes of the default tools in tools.xml to the new #AARRGGBB format, for 
> the sake of consistency.

There is no any problem in the newer Okular version as what I have found is 
that it respects both #RRGGBB and #AARRGGBB formats. I don't know about the 
older version but it should be both forward and backward compatible. And I 
agree there should be consistency in the color formats.
So if we adopt the new color format in the default tools in tools.xml, do we 
need to alter all the color entries? Or is it okay to have two color formats?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

Re: Need help in getting started with writing the integration test

[Dileep Sankhla]

I'm adding my test to autotests/parttest.cpp with a test function
PartTest::testTypewriterAnnotTool.
For the annotation toolbar, I have #include "../ui/pageviewannotator.h" and
doing this in the test function:

PageViewAnnotator pageviewannotator(part.m_pageView, part.m_document);
pageviewannotator.setEnabled( true );

But on make, I'm getting linking error as the undefined reference to
PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)

How to resolve this and check for the typewriter tool button in the toolbar?




On Wed, Jun 6, 2018 at 3:08 PM, Dileep Sankhla 
wrote:

> Hello Tobias,
>
> Thank you so much for the detailed explanation. I got the overview of how
> tests are written and how they are currently organized.
>
> I have just begun to write the test for typewriter annotation tool and my
> first test case is "checking if the annotation toolbar has the typewriter
> tool button in it?"
>
> Till now I have been succeeded in opening the document data/file1.pdf with
> the current page as 0 by using the object of Okular::Part and now I'm not
> getting the way of showing the annotation toolbar and how will I check for
> the typewriter tool in it?
>
> Do I need to simulate  keypress for showing the annotation toolbar and
> if yes, then how will I check for the specific tool in it?
>
> Need help.
>
> Thanks and Regards
> Dileep
>
>
>
>
> On Mon, Jun 4, 2018 at 1:19 AM, Tobias Deiminger 
> wrote:
>
>> Am 03.06.2018 21:39 schrieb Tobias Deiminger:
>>
>>> Am 03.06.2018 08:05 schrieb Dileep Sankhla:
>>>
>>
>> Ups, I misread the question
>>
>>> What will I compare here?
>>>>
>>>
>> as "what will compare here?"
>>
>> GUI tests compare with autotests/parttest.cpp.
>>> Core tests potentially compare with autotests/*annot*.cpp
>>> Afaikt there are no tests yet that check painting results pixel wise.
>>>
>>
>> New answer: You compare actual outcome with expected outcome. What actual
>> outcome and expected outcome means depends on your test case. You have to
>> define it.
>>
>> Tobias
>>
>
>

Re: Need help in getting started with writing the integration test

[Dileep Sankhla]

Hello Tobias,

Thank you so much for the detailed explanation. I got the overview of how
tests are written and how they are currently organized.

I have just begun to write the test for typewriter annotation tool and my
first test case is "checking if the annotation toolbar has the typewriter
tool button in it?"

Till now I have been succeeded in opening the document data/file1.pdf with
the current page as 0 by using the object of Okular::Part and now I'm not
getting the way of showing the annotation toolbar and how will I check for
the typewriter tool in it?

Do I need to simulate  keypress for showing the annotation toolbar and
if yes, then how will I check for the specific tool in it?

Need help.

Thanks and Regards
Dileep




On Mon, Jun 4, 2018 at 1:19 AM, Tobias Deiminger  wrote:

> Am 03.06.2018 21:39 schrieb Tobias Deiminger:
>
>> Am 03.06.2018 08:05 schrieb Dileep Sankhla:
>>
>
> Ups, I misread the question
>
>> What will I compare here?
>>>
>>
> as "what will compare here?"
>
> GUI tests compare with autotests/parttest.cpp.
>> Core tests potentially compare with autotests/*annot*.cpp
>> Afaikt there are no tests yet that check painting results pixel wise.
>>
>
> New answer: You compare actual outcome with expected outcome. What actual
> outcome and expected outcome means depends on your test case. You have to
> define it.
>
> Tobias
>

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 35508.
dileepsankhla added a comment.


  Diff changed after commiting to gsoc2018_typewriter branch. Updating it.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35507=35508

BRANCH
  master

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla reopened this revision.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
dileepsankhla marked an inline comment as done.
Closed by commit R223:66c70934b82c: popup window background color (authored by 
dileepsankhla).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13203?vs=35383=35507#toc

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35383=35507

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

AFFECTED FILES
  ui/annotwindow.cpp

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

Need help in getting started with writing the integration test

[Dileep Sankhla]

Hello everyone,

I have created a revision[0] for adding the typewriter annotation tool to
Okular and now I need to write the integration test for the same.

I'm not getting whether to make a new file
autotests/typewriterannotationtest.cpp
or to append the test in the existing autotests/annotationstest.cpp?

And the important thing, what do I need to test in it? Do I need to write a
test to create a typewriter annotation with some content and then delete
it? What will I compare here?

I'm sorry but I'm unable to start before getting these basics right. I need
a little help in getting started.

Thanks and Regards,
Dileep

[0] https://phabricator.kde.org/D13203

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a reviewer: tobiasdeiminger.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, tobiasdeiminger
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 35383.
dileepsankhla added a comment.


  Updating annotation popup window background color

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35333=35383

BRANCH
  master

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla reopened this revision.
dileepsankhla marked an inline comment as done.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla marked an inline comment as done.
dileepsankhla added a comment.


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

INLINE COMMENTS

> tobiasdeiminger wrote in annotwindow.cpp:262
> `QColor(m_annot->style().color().name())` is a bit arcane way of saying 
> "force alpha of the popup window background color to 1.0"  If that's what 
> you've actually intended?
> 
> How about removing const of newcolor (not bad, local scope only) and do 
> `newcolor.setAlpha(1.);`?
> Or something like
> 
>   const QColor newcolor = m_annot->style().color().isValid() ? 
> QColor(m_annot->style().color().red(), m_annot->style().color().green(), 
> m_annot->style().color().blue(), 255) : Qt::yellow;
> 
> if you want to keep const. That would be more explicit and obvious.
> 
> Btw., sorry for commenting on an older revision. But ui/annotwindow.cpp is 
> not included in the latest revision. Phabricator seems to be a bit too smart 
> for our intended workflow.

I agree. It should be straightforward without any latent meaning. Updating the 
revision.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  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?
  
  Should I push the commit to the gsoc branch or not? I usually update revision 
in this manner:
  
  1. `git branch`
  
  *gsoc2018_typewriter
  master
  
  2. `vim file.cpp`
  3. `git commit -m "msg"`
  4. `git checkout master`
  5. `git merge gsoc2018_typewriter`
  6. `arc diff --update D13203`
  
  It sends two new commit, one created in the gsoc branch and one at the point 
of merging to master branch
  
  7. `git reset --hard `
  
  Here  is the last commit before merging gsoc2018_typewriter branch
  
  8. `git checkout gsoc2018_typewriter`
  9. `git push origin gsoc2018_typewriter`
  
  And finally, pushing the commit to origin/gsoc2018_typewriter branch.
  
  Can you suggest me where I'm wrong?

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R223:f0063e548b1b: Fixed initial typewriter width to 0 
(authored by dileepsankhla).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13203?vs=35332=35333#toc

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35332=35333

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

AFFECTED FILES
  ui/data/tools.xml

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 35332.
dileepsankhla added a comment.


  Fixed initial typewriter border width to 0

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35240=35332

BRANCH
  master

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  > 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?
  
  It's also complicated for me to comprehend but there is a blending mode 
function B(Cb,Cs) that multiplies the source color with the backdrop color. If 
not necessary, I won't go into the details.
  
  Btw I have updated the revision to have typewriter background transparent in 
PagePainter.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 35240.
dileepsankhla added a comment.


  Fixed typewriter transparency in PagePainter

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35136=35240

BRANCH
  master

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pagepainter.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  > 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.
  
  I agree but why do we need to multiply alpha value and opacity to determine 
the final alpha of background color for FreeText in Poppler? It is already 
determined by alpha value solely. I mean isn't it enough to change the line to 
`acolor.setAlpha( a->style().opacity() * a->style().color().alpha() )` as you 
suggested? Why do we need to change the Poppler's one?
  
  Secondly, in my opinion, we should change L 628 to `unsigned int opacity = 
(unsigned int)( a->style().color().alpha() * a->style().opacity() )` and here 
the variable `opacity` will determine the background color of FreeText.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  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).
  
  
  In ui/pagepainter.cpp L 668, we can comment out `acolor.setAlpha( opacity )` 
as here the value of opacity is 255 but changing the L 659 or 668 should be 
consistent in the case of other annotations too. Is commenting out L 668 
accepted?

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  > 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.
  
  Thank you so much for the info. From now on, I will frequently push my work 
to gsoc2018_typewriter.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ltoscano, ngraham, tobiasdeiminger, aacid, okular-devel

[okular] [Bug 394834] Okular not release memory (ram) taken by closed documents

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=394834

Dileep Sankhla  changed:

   What|Removed |Added

  Latest Commit|https://commits.kde.org/oku |https://commits.kde.org/oku
   |lar/95bc29a76fc1f93eaabe538 |lar/30cf1951a676401591b50d2
   |3d934644067dfc884   |9abedcec6e0de7001

--- Comment #3 from Dileep Sankhla  ---
Git commit 30cf1951a676401591b50d29abedcec6e0de7001 by Dileep Sankhla, on
behalf of Albert Astals Cid.
Committed on 30/05/2018 at 15:56.
Pushed by dileepsankhla into branch 'gsoc2018_typewriter'.

Force release of free memory

This should not be needed, but i can totally reproduce that without it
top is still reporting lots of memory used by Okular when it's really
not (heaptrack reports memory freed correctly)

M  +4-0OkularConfigureChecks.cmake
M  +3-0config-okular.h.cmake
M  +11   -0core/document.cpp

https://commits.kde.org/okular/30cf1951a676401591b50d29abedcec6e0de7001

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

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added a comment.


  @ngraham This is the part of my GSoC project: 
https://summerofcode.withgoogle.com/projects/#6053164340477952
  
  I have committed the same to my separate branch: 
https://cgit.kde.org/okular.git/log/?h=gsoc2018_typewriter but don't know how 
it got landed! It needs to be reviewed first. Have I done something wrong?

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: ngraham, tobiasdeiminger, aacid, okular-devel

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R223:c344c5e31b6a: Added Typewriter annotation tool (authored 
by dileepsankhla).

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13203?vs=35135=35136

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla
Cc: tobiasdeiminger, aacid, okular-devel, ngraham

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla added subscribers: aacid, tobiasdeiminger.

REPOSITORY
  R223 Okular

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

To: dileepsankhla
Cc: tobiasdeiminger, aacid, okular-devel, ngraham

D13203: Add Typewriter annotation tool in Okular

[Dileep Sankhla]

dileepsankhla created this revision.
Restricted Application added a project: Okular.
Restricted Application added a subscriber: okular-devel.
dileepsankhla requested review of this revision.

REVISION SUMMARY
  This patch adds the typewriter annotation tool in Okular with a new 
typewriter icon and the settings dialogue to configure annotation's font and 
the text input UI is same as that of inline note. It sets the intent to 
TypeWriter and background color transparent.

REPOSITORY
  R223 Okular

BRANCH
  master

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

AFFECTED FILES
  conf/editannottooldialog.cpp
  conf/editannottooldialog.h
  core/annotations.cpp
  ui/annotationpropertiesdialog.cpp
  ui/annotationwidgets.cpp
  ui/annotationwidgets.h
  ui/annotwindow.cpp
  ui/data/CMakeLists.txt
  ui/data/sources/tool-typewriter-okular-colorizable.svgz
  ui/data/tool-typewriter-okular-colorizable.png
  ui/data/tool-typewriter-okular-coloriza...@2x.png
  ui/data/tools.xml
  ui/guiutils.cpp
  ui/pageviewannotator.cpp

To: dileepsankhla
Cc: okular-devel, ngraham, aacid

Re: Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Hello Albert,

> Are you speaking of not having that for the new tool or removing it
> altogether?

I'm just suggesting to not have the hover icon for the new typewriter tool.
We should not remove it for the inline note. What do you finally suggest?

Thanks and Regards,
Dileep

Re: Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Hello everyone,



> Basically, annotation color is set as a common attribute to all annotation
>> types at the end of the file and if we should bypass it with an if
>> condition that will set annotation color for type "typewriter" hardcoded
>> to
>> QColor(255,255,255,0).
>> I have tried harcoding it for inline note and in the appearance settings,
>> I
>> got a transparent color but as soon as I create a note, it's background
>> turns to white. and I find color: white in the appearance settings again.
>> Will it work for the typewriter then?
>>
>
> No, if it doesn't work for inline note it also won't work for typewriter.
> We have seen transparent background working in our Qt5 poppler demo
> https://cgit.kde.org/scratch/dileepsankhla/okular-gsoc2018-t
> ypewriter.git/tree/src/main.cpp#n24. So the alpha channel obviously gets
> lost somewhere inside Okular. Can you try to hunt the QColor down the stack
> and see where this happens?

The culprit is here: Okular::Annotation::store in core/annotations.cpp L753.

if ( d->m_style.color().isValid() )
e.setAttribute( QStringLiteral("color"), d->m_style.color().name()
);

Here QColor::name converts our QColor(255,255,255,0) to #ff (white) and
we loose the alpha value. We can thus use:

e.setAttribute( QStringLiteral("color"),
d->m_style.color().name(QColor::HexArgb) );

QColor::HexArgb gives color name in #AARRGGBB format and hence we get our
color hex value as #00ff which tells that alpha channel is 0.

This is consistent with all other color values too and I will implement it
in my patch.

Thanks and Regards
Dileep


‌

Re: Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Thank you so much Tobias. I'm using vim editor and I was unaware of ctags.
I have just installed eclipse to speed and ease up the development process.
Your explanations are so vivid that I got them easily.
For now, I will try demo font color selector dialog with saving the current
color in the settings. I can then paint the overlay icon with the same
color and it will imitate the font color behavior in the patch. Later on.
with the implementation of real font color in annotations, we can just
change a few lines in okular and make that happen.
Can you provide your suggestions for point 6, regarding engine color and
all? It will be helpful in the initial development phase.

Thanks and Regards,
Dileep



‌

On Sun, May 20, 2018 at 5:08 PM, Tobias Deiminger <haxti...@posteo.de>
wrote:

> Hi,
>
> this one is about saving the actual annotation (rather then the tool
> configuration).
>
> Am Freitag, 18. Mai 2018, 17:04:09 CEST schrieb Dileep Sankhla:
>
>> 4. In Okular::Annotation::Style::setColor(const QColor ), it sets
>> d->m_color = color (see tree/core/annotations.cpp. Here d is just a
>> pointer
>> to a class Private). Does it save color in some config/xml file as the
>> previously set annotation color is always there whenever you close and
>> open
>> okular?
>>
>
> Yes, it does. For quite some time, saving annotations to an external XML
> file (called "docdata") was the only option to persist annotations. Thanks
> to a major piece of work in an extra branch 
> "dont-use-docdata-for-annots-and-forms",
> we now have a second option where we can save the annotation into a PDF
> file as its native  PDF representation. Please see branch [0] and merge
> commit [1], and related bug reports / reviews [2], [3], [4], [5]. You'll
> learn a lot from it.
>
> If docdata is used instead of PDF, it looks like this:
>
> ~$ okular somerawtext.txt   # Create inline note, exit okular
>
> ~$ cat .local/share/okular/docdata/24.somerawtext.txt.xml
> 
> 
> 
>  
>   
>
> 
>   contents="This is a inline note with white background."
> modifyDate="2018-05-20T11:13:09" 
> uniqueName="okular-{2aa99524-e7a1-450d-b440-0b1821e42919}"
> flags="4" color="#ff">
>   
>   
>title="" width="0"/>
>  
>   icon="Comment"/>
> 
>
>   
>  
>  
>   
>
>   
>   
>
> 
>
>   
>  
> 
>
> I'm unable to find class Private.
>>
>
> class Annotation::Style has a "d-pointer" to it's implementation, that's a
> well known C++ idiom [6]. The d-pointer is initialized on construction of
> Annotation::Style with a new instance of a class
> Annotation::Style::Private. class Annotation::Style::Private is defined in
> annotations.cpp L177.
>
> Which IDE do you use? Doesn't it support source code navigation? I'm
> mostly using Eclipse, it takes me to the definition of "class Private" by
> pressing F3. But this should even be possible with vim + ctags.
>
> [0] https://cgit.kde.org/okular.git/log/?h=dont-use-docdata-for-
> annots-and-forms
> [1] https://cgit.kde.org/okular.git/commit/?id=3957683d7651494a7
> bc48b26e6b113161e9a888c
> [2] https://bugs.kde.org/show_bug.cgi?id=151614
> [3] https://bugs.kde.org/show_bug.cgi?id=315552
> [4] https://bugs.kde.org/show_bug.cgi?id=301774
> [5] https://git.reviewboard.kde.org/r/124069/
> [6] https://en.wikipedia.org/wiki/Opaque_pointer
>

Re: Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Hi Tobias,


On Sat, May 19, 2018 at 6:17 PM, Tobias Deiminger <haxti...@posteo.de>
wrote:

> Hi Dileep,
>
> that's quite a lot. I don't have enough continuous time to answer all at
> once, so I just start with the first two questions.
> @all: Everybody is very welcome to join discussion and answering:)
>
> Am 18.05.2018 17:04 schrieb Dileep Sankhla:
>
>> I have few things to ask before getting it done and it would be nice
>> if you can reply to any of the queries with your own suggestions.
>>
>> 1. In tree/ui/data/tools.xml, we have decided to append new
>> "typewriter" annotation tool at  without muddling
>> others. Now should I give 0 to this tool or
>> should I ommit the  tag completely for this one?
>> Giving shortcut 0 makes sense as 0 is the key next to 9 on the
>> keyboard but having shortcut 0 for the tool at the lowest end in the
>> annotation toolbar doesn't make sense.
>>
>
> Imho either 0 or none would both make sense. Users can configure the
> toolbar and shortcuts themselves anyway.
>
> 2. My mentor remarked that tools.xml doesn't solely determine the
>> order in the toolbar. It is just the initial default, but the
>> "okularpartrc" file, if present, takes precedence.
>> It is located at ~/.config/okularpartrc on my system containing the
>> content similar to tools.xml. I need to know when it is being created
>> and read by okular and how do I append typewriter tool entry in it for
>> every system installing okular? I have no idea.
>>
>
> When toolbar accesses Okular::Settings::annotationTools, values are
> already in memory. But you'll ask, how and when have they come there?
>
> class Okular::Settings is defined in /settings.cpp.
> You must know that settings.{cpp,h} is autogenerated during project build
> by kconfig_compiler_kf5 out of conf/okular.kcfg. Please read [0] to learn
> about this. The responsible macro is in okular/CMakeLists.txt
> kconfig_add_kcfg_files(okularpart_SRCS conf/settings.kcfgc).
>
> Data for Okular::Settings is initialized once in
> Okular::Settings::Settings Ctor. There the file tools.xml is read, as coded
> into the  type="StringList">...
> element from okular.kcfg.
>
> Data for Okular::Settings is also loaded and saved via a KSharedConfig
> config object. KSharedConfig derives from KConfig, and
> KConfig::reparseConfiguration [1] loads data from ~/.config/okularpartrc.
>
> Sadly there are several KSharedConfig instances in Okular, so if we want
> to watch it in gdb, we have to figure out during runtime which
> KSharedConfig is responsible for ~/.config/okularpartrc.
>
> Be sure to have libKF5ConfigCore debug symbols around (on Ubuntu: apt-get
> install libkf5configcore5-dbgsym).
>
> $ gdb okular
>
> (gdb) set breakpoint pending on
> (gdb) break Okular::Settings::Settings
>
> Next set a specific breakpoint to filter for the interesting KSharedConfig
> object. We know that if KSharedConfig Ctor is called inside
> Okular::Settings::instance, it is the one responsible for
> ~/.config/okularpartrc. So break only in this condition.
>
> (gdb) break Okular::Settings::instance
> command 1
>   tb KSharedConfig::KSharedConfig
>   c
> end
>
> Run the program.
>
> (gdb) r
>
> When hit, we know the KSharedConfig object of interest.
> #0  KSharedConfig::KSharedConfig (this=0x5588f310, fileName=...,
> flags=..., resType=QStandardPaths::GenericConfigLocation)
> at ./src/core/ksharedconfig.cpp:124
>
> It is at 0x5588f310. Now we can set another conditional breakpoint to
> catch the KConfig::reparseConfiguration calls of interest.
>
> (gdb) break KConfig::reparseConfiguration if this=0x5588f310
>
> That's it.
> Everytime you hit Okular::Settings::Settings, Okular reads from tools.xml.
> Everytime you hit this KConfig::reparseConfiguration, Okular reads from
> ~/.config/okularpartrc.
>
> Can you share your observations?
>
Yes, you were right. Everytime during application startup, the okularpartrc
file is read if present, and whenever a user alters the toolbar in some
way, okularpartrc file is either created or updated. Hence I just need to
alter tools.xml and no need to worry about okularpartrc.


> To gain even more convidence in your debugging it's sometimes good to
> observe the value of QStrings. KDE provides nice tools for this:
>
> $ git clone git://anongit.kde.org/kde-dev-scripts.git
> $ cp kde-dev-scripts/kde-devel-gdb ~/.gdbinit
> $ gdb okular
>
> Break somewhere. Now you can use the printq5string function to print the
> content of a QString:
>
> Thread 1 "okular" hit Breakpoint 2, Okular::Settings::instance
> (cfgfilename=...) at ./obj-x86_64-linux-gnu/settings.cpp:189
> 189 ./obj-x86_64-linux-gnu/settings.cpp: Datei oder Verzeichnis nicht
> gefunden.
>
> (gdb) printq5string cfgfilename
> /home/tobias/.config/okularpartrc
>
> Cheers
> Tobias
>
> [0] https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html
> [1] https://api.kde.org/frameworks/kconfig/html/classKConfig.
> html#a46f2e340c44261c2b58496bc64b31106
>

‌

Re: Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Hi Albert,
‌

On Sun, May 20, 2018 at 3:02 PM, Albert Astals Cid <aa...@kde.org> wrote:

> El divendres, 18 de maig de 2018, a les 17:04:09 CEST, Dileep Sankhla va
> escriure:
> > Hello everyone,
> >
> > I'm working on my GSoC project[0] with my mentor Tobias Deiminger
> > <haxtibal[at]posteo[dot]de> and I need to add a new 'typewriter' tool to
> > the annotation toolbar with a new icon and a setting dialogue to
> customize
> > its font [and font color].
> >
> > I have few things to ask before getting it done and it would be nice if
> you
> > can reply to any of the queries with your own suggestions.
> >
> > 3. Inline note has a "hover icon" (see tools.xml) which is shown when a
> > dashed line block is drawn while dragging the mouse to create a note. Do
> we
> > also need a different hover icon for typewriter or should we get rid of
> it?
> > In my opinion, we should get rid of it instead of creating a new hover
> icon
> > for typewriter. What do you say?
>
> Why do you think we should remove a feature we have? What is in your
> opinion
> the reason to get rid of it?
>
As discussed earlier in a private mail where Tobias CCed you, we are first
making the text input UI same as that of Inline note. Here you can argue
that we need the typewriter-hover-icon but when we are going to implement
the WYSIWYG live editing feature just after, do we still need it? I mean
yes we will drag the mouse to create a dashed line rectangular box for
creating annotation on page and it should show the typewriter-hover-icon
then, but I don't know what kind of hover icon should we design for the
typewriter? And what if the community selects another approach (see the
earlier mail in okular-devel with the subject, "FreeText typewriter
annotation WYSIWYG implementation ideas") where we can use KTextEdit widget
of fixed dimensions to directly draw a WYSIWYG editor on the page? Hence
out of this ambiguity, in my opinion, we should get rid of it. Waiting for
your suggestion.


> Cheers,
>   Albert
>

Thanks and Regards,
Dileep

Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Dileep Sankhla]

Hello everyone,

I'm working on my GSoC project[0] with my mentor Tobias Deiminger
 and I need to add a new 'typewriter' tool to
the annotation toolbar with a new icon and a setting dialogue to customize
its font [and font color].

I have few things to ask before getting it done and it would be nice if you
can reply to any of the queries with your own suggestions.

1. In tree/ui/data/tools.xml, we have decided to append new "typewriter"
annotation tool at  without muddling others. Now should I
give 0 to this tool or should I ommit the 
tag completely for this one?
Giving shortcut 0 makes sense as 0 is the key next to 9 on the keyboard but
having shortcut 0 for the tool at the lowest end in the annotation toolbar
doesn't make sense.

2. My mentor remarked that tools.xml doesn't solely determine the order in
the toolbar. It is just the initial default, but the "okularpartrc" file,
if present, takes precedence.
It is located at ~/.config/okularpartrc on my system containing the content
similar to tools.xml. I need to know when it is being created and read by
okular and how do I append typewriter tool entry in it for every system
installing okular? I have no idea.

3. Inline note has a "hover icon" (see tools.xml) which is shown when a
dashed line block is drawn while dragging the mouse to create a note. Do we
also need a different hover icon for typewriter or should we get rid of it?
In my opinion, we should get rid of it instead of creating a new hover icon
for typewriter. What do you say?

4. In Okular::Annotation::Style::setColor(const QColor ), it sets
d->m_color = color (see tree/core/annotations.cpp. Here d is just a pointer
to a class Private). Does it save color in some config/xml file as the
previously set annotation color is always there whenever you close and open
okular? I'm unable to find class Private.

5. Do I need to implement "font color" for the typewriter annotation
(didn't propose in my proposal) or we fine with the regular black font?
This follows the next query.

6. tools.xml has  and  tags. The engine
color is used -
i) to colorize the overlay icon with engine color that is drawn
on tool-base-okular icon for every annotation toolbar icon[1].
ii) to set annotation background color to engine color if  tag is absent[2].
It is clear that we should omit  tag and wherever it is
calling Okular::Annotation::Style::setColor() function, we should pass
QColor(255,255,255,0) //alpha is 0, so transparent
But we need engineColor to colorize our overlay icon. We can't omit it.

6.1 We want to set overlay icon's color as the current font color being set
for typewriter only if we implement font color. Else we will have a black
colored icon. So if the community agrees on implementing the font color
feature, do I need to first demo this with typewriter icon? Or should we
agree on black font and implement it only when the font color feature is
done?
I don't know how to make a demo. Maybe something like
Okular::Annotation::Style::setFontColor() which will save color in private
data without applying it to the annotation and set a demo by simply
choosing, saving, reading font color and set the same icon color? This is
how we do for annotation color but here not applying to the annotation at
all.

6.2 Now engineColor is also responsible for annotation color, which we want
transparent. I don't know if  will set it to
transparent or should we omit this tag?
Basically, annotation color is set as a common attribute to all annotation
types at the end of the file and if we should bypass it with an if
condition that will set annotation color for type "typewriter" hardcoded to
QColor(255,255,255,0).
I have tried harcoding it for inline note and in the appearance settings, I
got a transparent color but as soon as I create a note, it's background
turns to white. and I find color: white in the appearance settings again.
Will it work for the typewriter then?

7. Are you agree on simple 'T' icon with some thickness and border black
that will be either black or filled with the engine color? It will be drawn
in the middle of okular base icon.
If we copy the Adobe Reader typewriter icon, please note that it is not a
simple 'T'.  It has bents sideways and at the bottom. See image[3].

Thanks and Regards
Dileep

[0] https://summerofcode.withgoogle.com/projects/#6053164340477952
[1] https://cgit.kde.org/okular.git/tree/ui/pageviewannotator.cpp#n1180
[2] https://cgit.kde.org/okular.git/tree/ui/pageviewannotator.cpp#n280
[3]
http://data.answerbase.com/Adobe/answers.acrobatusers.com/UserFiles/Answers201403/answerImage91278-05020444.jpg

FreeText typewriter annotation WYSIWYG implementation ideas

[Dileep Sankhla]

Hello all,

I'm working with my mentor Tobias Deiminger on the GSoC
project[0] regarding implementing the FreeText annotation with
FreeTextTypewriter (WYSIWYG live editing) behavior.

I have written a blog post[1] where I have presented three of the ideas to
implement WYSIWYG editing in typewriter annotation thus writing directly on
PDF page.

I would like to invite the okular developers to go through the blog post
and help me in choosing the most appropriate approach in order to make this
project successful. Your suggestions and comments will be very valuable for
me.

Thanks and Regards
Dileep


[0] https://summerofcode.withgoogle.com/projects/#6053164340477952
[1]
https://dileepsankhla.com/blog/freetext-typewriter-annotation-wysiwyg-implementation-ideas/

Queries regarding terminologies used in Okular PDF annotation rendering

[Dileep Sankhla]

Hi there,

Please try to answer my following queries:

1. What is "viewport"?

2. What is "pageview"?

3. How does PDF save an annotation in the document?

4. What is "generator" and how does generator render the annotation in PDF
page? What is the meaning of "rendering" here?

5. Now how does poppler render the annotation on the PDF page? Is it same
as the working of the Okular generator?

6. What does "painting" actually mean? And so what does
"PageView::paintevent" do?

I have a messed up knowledge of these subjects and I want a clarity in my
mind so that I can understand my work and can continue to develop.

Thanks and Regards
Dileep



‌

[okular] [Bug 325119] Size of inline notes not adjusted to font size and does not respect drawn boundaries

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=325119

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

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

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  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

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: tobiasdeiminger, aacid, sander, #okular, ngraham

[okular] [Bug 353401] Feature requst: "typewriter" annotation tool

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=353401

--- Comment #28 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
I'm working on this feature request as a GSoC 2018 student and you can find my
project here: https://summerofcode.withgoogle.com/projects/#6053164340477952
and my proposal here:
https://docs.google.com/document/d/1STBOz7Qcw1Wj6qB7XBg9er-wbsVx3g7Sw945WcHJfWU/edit?usp=sharing
Comments are always welcome and this thread will be updated regularly.

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

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  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?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: tobiasdeiminger, aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  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()?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  The verbose output of valgrind is around 190,000 lines with the line numbers. 
Here is the output:
  
  https://dileepsankhla.com/valgrind.txt

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  https://paste.kde.org/pepnfuzxq 

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  Following is the log of running valgrind on okular:
  
  https://paste.kde.org/pmyjdscmw/ohzvag 

  
  I have no luck in understanding the verbose. May you please help me by 
checking it out?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 30742.
dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11051?vs=28694=30742

BRANCH
  master

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

AFFECTED FILES
  conf/okular.kcfg
  part.cpp

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a comment.


  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?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular, aacid
Cc: aacid, sander, #okular, michaelweghorn, ngraham

Re: GSoC Proposal: Implementing the FreeText annotation (Draft)

[Dileep Sankhla]

@Tobias: Thank you so much for pointing out the minute details. I have
changed the project title and the details accordingly. I am refining it
more before the final submission. It is now clearer to me than before and I
understood the confusing part.

@Oliver: This creates a great project and accordingly a great proposal for
GSoC as now it is more specific to what to do done and how to be done. The
only hassle it created is that this was pointed out so late. And talking to
the mentors regarding the project didn't make me realize the missing part.
Thank you so much for sharing this project.

Thank you all.

Thanks and Regards,
Dileep

On Thu, Mar 22, 2018 at 2:35 PM, Oliver Sander 
wrote:

> Hi all,
>
>> I don't know the original bug you're working on.
>>
>
> it is
>
>   https://bugs.kde.org/show_bug.cgi?id=353401
>
> I assume that what really is missing is the FreeTextTypeWriter behavior?
>> You can check the ISO 32000 PDF standard for FreeTextTypeWriter (IT entry
>> of the FreeText object).
>> @Oliver: Do you know?
>>
>
> not really, sorry.  I only read that bug report and figured that it would
> make a nice GSoC project, but I never entered into the details of the
> problem.  Sorry for the hassle this created.
>
> Oliver
>
>
>

[okular] [Bug 353401] Feature requst: "typewriter" annotation tool

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=353401

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #18 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
On Thu, Mar 22, 2018 at 4:13 AM, Tobias Deiminger <haxti...@posteo.de> wrote:

Okular already let's you create FreeText annotations. The confusing thing is
that they're called "inline notes" in Okulars manual, and they're represented
as class TextAnnotation (with m_textType == TextAnnotation::InPlace) in Okular
and Popplers QT5 frontend. Under the hood poppler generates a real FreeText
annotation:

# qt5/src/poppler-annotation.cc
Annot* TextAnnotationPrivate::createNativeAnnot(::Page *destPage, DocumentData
*doc)
{
// ...
PDFRectangle rect = boundaryToPdfRectangle(boundary, flags);
if (textType == TextAnnotation::Linked)
{
pdfAnnot = new AnnotText(destPage->getDoc(), );
}
else
{
GooString * da = toAppearanceString(textFont);
pdfAnnot = new AnnotFreeText(destPage->getDoc(), , da); // Here it
is :-)
delete da;
}
// ...
}

I assume that what really is missing is the FreeTextTypeWriter behavior. You
can check the ISO 32000 PDF standard for FreeTextTypeWriter (IT entry of the
FreeText object).

You can also fire up okular in gdb and convince yourself

$ gdb okular
(gdb) b AnnotFreeText::AnnotFreeText
(gdb) r

# load document, create inline note => we hit popplers
AnnotFreeText::AnnotFreeText constructor

Thread 1 "okular" hit Breakpoint 1, 0x7fffce304220 in
AnnotFreeText::AnnotFreeText(PDFDoc*, PDFRectangle*, GooString*)@plt () from
/tmp/usr/lib/libpoppler-qt5.so.1
(gdb) bt
#0  0x7fffce304220 in AnnotFreeText::AnnotFreeText(PDFDoc*, PDFRectangle*,
GooString*)@plt () from /tmp/usr/lib/libpoppler-qt5.so.1
#1  0x7fffce30d689 in Poppler::TextAnnotationPrivate::createNativeAnnot (
this=0x7fffdc00ccb0, destPage=, doc=)
at
/home/tobias/workspace/OSScontrib/poppler/qt5/src/poppler-annotation.cc:1880
... backtrace shortened ...

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

GSoC Proposal: Implementing the FreeText annotation (Draft)

[Dileep Sankhla]

Hello,

I am interested to participate with Okular in GSoC this year. I have
written a draft proposal for the project.

Here is the link to my proposal:

https://docs.google.com/document/d/1STBOz7Qcw1Wj6qB7XBg9er-wbsVx3g7Sw945WcHJfWU/edit?usp=sharing

Any feedback or suggestion will be highly appreciated.

Thanks and Regards,
Dileep Sankhla



‌

[Need immediate help for GSoC project] Implementing FreeText annotation

[Dileep Sankhla]

Hello,

I have some doubts to clear so that I can begin writing my pending GSoC
proposal parts as soon as possible. Please help me.

1.  The existing FreeText annotation in a pdf file can be moved and edited
in Okular. Is this partial support of FreeText because of the poppler-qt5
library extends the core poppler? The core poppler implements a SubType
enum with FreeText in Annot.h whereas not in poppler-qt5.

2. How does the poppler-qt5 library extend the core poppler? By including
the header files from the core poppler?

3. If the FreeText annotation needs to be implemented in poppler-qt5 then
should all the code go inside the poppler-qt5's source instead of the core
poppler one?
This means a new class called "poppler::FreeTextAnnotation" should be added
and implemented in "poppler-annotation.cc"? This means one should avoid
using the exisitng partial support for FreeText in core poppler and write
the new one as the existing also have some bugs? If writing the new code,
will it collide with the code from the core poppler? Need a basic idea.

4. A very genuine question, how does an annotation class is implemented in
poppler? This mean does all the code regarding editing, moving, resizing,
deleting, transparency of background, text color of the FreeText annotation
should go in poppler codebase? If so, then how does Okular use these
annotations and what basically goes in various annotation source files in
Okular codebase? Need a basic idea.

5. Regarding the GUI, is it wise to implement a Popup toolbox whenever the
FreeText annotation is used and the popup toolbox should have options of
text size, color, and font? Or should all these font settings should only
be in Settings -> Configure Okular -> Annotations?

6. Should unit tests be written when this annotation is implemented?

Thanks and Regards

Dileep Sankhla


‌

General doubts regarding annotations and its poppler support for GSoC project

[Dileep Sankhla]

Hello all,

I am writing my proposal for the GSoC project, "Implement FreeText
Annotation" and I have some doubts to clear before proceeding ahead. Kindly
help me:

1. What does Okular use - the core poppler or poppler Qt5 interface library?

2. There is partial FreeText (TypeWriter) annotation support in poppler but
not in poppler-qt5. With this information, should Okular have FreeText
annotation support too?

3. What is the role of source files in i) okular/generator/poppler and also
in ii) okular/core directories? Hence how does Okular use poppler?

4.  How is an annotation implemented in poppler? Does poppler provide any
backend or UI for the annotation?

5. If annotations are implemented in poppler and Okular uses it, so why
does Okular also contain "annotation" named source files in okular/core,
okular/generator/poppler and okular/ui directories?

Please clear my doubts as soon as possible so that I can write my proposal
very soon.

Thanks and Regards
Dileep

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla marked an inline comment as done.
dileepsankhla added a comment.


  In D11051#05 , @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?
  
  
  Initially, I thought of reading and saving the settings in `part.cpp` but I 
can't access `m_sidebar` as to save its last state inside the destructor 
`Part::~Part` and it gives me segfault. Hence I am saving them in 
`Sidebar::~Sidebar`.
  
  > Do you think you can give it a try at adding an auto test for this?
  
  Sure, let me know your thoughts on where to save the settings and then I will 
try to write the auto test for this.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular
Cc: aacid, sander, #okular, michaelweghorn, ngraham

[okular] [Bug 344599] Thumbnails sidebar always open when okular starts

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=344599

--- Comment #11 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
May someone please review my patch being sent?

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

[GSoC] Project Requirements: Implement the FreeText annotation

[Dileep Sankhla]

Hello,

I am excited to tell you that I am interested in the project of
implementing the FreeText annotation under GSoC this year. I have gone
through the feature request reports being mentioned in the project detail
and finding it quite interesting while motivated to implement it.

I am studying the PDF format and also going through the poppler library.

I would like to know if there are other requirements I need to fulfill in
order to get more familiar with the project?

Thanks and Regards,
Dileep Sankhla


‌

[GSoC]

[Dileep Sankhla]

Hello,

My name is Dileep Sankhla (IRC: robstat7) and I am eager to contribute to
Okular this year in GSoC. I am well versed in C++ and have been programming
in it for the past four years while using Qt for development for the past
three months. In addition to it, I have been contributing to the Okular
codebase and have submitted 3 patches in till date in which two of them got
merged.

I went through the GSoC project ideas list and I am excited to see five
project ideas in Okular. The annotation bugs and feature requests interest
me the most whereas as I tried to perceive, adding the feature to verify
the signature of pdf files is somewhat different among all of them.

I have a few questions wandering in my mind. Hope to get them please here.

1. What is important to Okular this summer; adding a completely new
category of annotations called FreeText (or TypeWriter) or improving the
existing stamp annotations' handling or showing and adding the replies to
the sticky notes?
Actually, all three annotation projects interest me and I think I meet the
requirements.

2. Will adding the support for verifying the signatures in pdf files bring
something totally different to Okular in comparison to all the annotation
support as this capability have never been seen in Okular although the
poppler support it?
Again it is quite interesting and I meet the requirements.

I am selective regarding choosing the right project for me because if my
proposal gets selected, I want to see myself working on a project that will
actually matter Okular the most.


Thanks and Regards,
Dileep Sankhla



‌

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 28694.
dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11051?vs=28693=28694

BRANCH
  master

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

AFFECTED FILES
  conf/okular.kcfg
  part.cpp
  ui/sidebar.cpp

To: dileepsankhla, #okular
Cc: sander, #okular, michaelweghorn, ngraham, aacid

[okular] [Bug 344599] Thumbnails sidebar always open when okular starts

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=344599

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #10 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
I have sent a patch here: https://phabricator.kde.org/D11051

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

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla added a reviewer: Okular.

REPOSITORY
  R223 Okular

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

To: dileepsankhla, #okular
Cc: #okular, michaelweghorn, ngraham, aacid

D11051: Remembering side navigation panel state

[Dileep Sankhla]

dileepsankhla created this revision.
Restricted Application added a subscriber: Okular.
Restricted Application added a project: Okular.
dileepsankhla requested review of this revision.

REVISION SUMMARY
  Every time Okular starts, one of the items of the side navigation panel is 
open. There is no way to disable it globally. It would be convenient to the 
users to automatically save the state of the panel upon exit and restore it 
when the Okular is opened again.
  FEATURE: 344599

TEST PLAN
  1. Open a PDF with Okular
  2. You will find that one of the items of the side navigation panel is open
  3. Click on the item icon of the navigation panel to minimize item's panel
  4. Close Okular
  5. Reopen Okular with same or different file as in step 1
  6. One of the items of the side navigation panel is again open
  7. But after applying this patch, the side navigation panel should be remain 
collapsed in step 6 with none of the item is selected

REPOSITORY
  R223 Okular

BRANCH
  master

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

AFFECTED FILES
  conf/okular.kcfg
  part.cpp
  ui/sidebar.cpp

To: dileepsankhla
Cc: #okular, michaelweghorn, ngraham, aacid

Which vim shortcuts should be currently implemented?

[Dileep Sankhla]

Hi,

I'm working on the feature request[0] 342927 that demands to introduce
other vim like shortcuts in okular but I think there is no any single
comment from the mentor itself and there are different suggestions. Hence I
want to know which keys should be implemented in the patch?
I need to work on the issue asap.

[0] https://bugs.kde.org/show_bug.cgi?id=342927

Thanks and Regards
Dileep


‌

[okular] [Bug 342927] More Vim-like shortcuts

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=342927

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

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

[okular] [Bug 342927] More Vim-like shortcuts

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=342927

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #4 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
I think this feature request must be marked "CONFIRMED" and regarding
submitting the patch, what vim shortcuts should be currently implemented?

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

[okular] [Bug 350366] Tree view search bar in left side bar is not searching root items of the tree view.

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=350366

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #1 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
It is not reproducible in okular version 1.3.2

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

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 28360.
dileepsankhla added a comment.


  Updating D10249 : Option to exit after 
printing
  
  Removed the autotest and just updated the `serializedOptions` parameters.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=27086=28360

BRANCH
  fixing

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla added a comment.


  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?

REPOSITORY
  R223 Okular

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

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

Re: Better way to make the annotation windows scrollable with the document

[Dileep Sankhla]

Thank you so much Albert.



‌

On Tue, Feb 27, 2018 at 3:44 AM, Albert Astals Cid <aa...@kde.org> wrote:

> El dilluns, 26 de febrer de 2018, a les 11:50:02 CET, Dileep Sankhla va
> escriure:
> > Thank you so much Oliver. Due to lack of insight about the bugs, I'm
> unable
> > to categorize them into intermediate and difficult jobs.
> > I will try my best to find and work on some easier issue.
>
> We have some bugs marked as junior jobs when they are easy so you don't
> have
> to categorize them yourself.
>
> Cheers,
>   Albert
>
> >
> > Thanks and Regards
> > Dileep
> >
> > On Feb 26, 2018 14:15, "Oliver Sander" <oliver.san...@tu-dresden.de>
> wrote:
> > > Hi Dileep,
> > >
> > > it is great to see you so motivated to fix Okular annotation bugs.  But
> > > reading your
> > > mails I am wondering whether you picked a good place to start.  On the
> one
> > > hand,
> > > these scrolling annotation windows seem to be quite difficult to
> > > implement.
> > > On the other hand, my original bug report is really about the fact that
> > > you can
> > > maneuver annotation windows into a situation where you cannot close
> them
> > > anymore.  I know that the bug report is not quite _written_ that way,
> but
> > > I think
> > > that is how it should be read today.  Scrolling annotation windows
> could
> > > be a nice
> > > thing to have, but nobody seems to need them urgently.  At least not
> me.
> > >
> > > So maybe you could pick an easier issue to get you started?
> > >
> > > Many thanks, and best regards,
> > > Oliver
> > >
> > > On 25.02.2018 06:27, Dileep Sankhla wrote:
> > > > Hello,
> > > > I'm heading into Okular feature request 388450 where the annotation
> > >
> > > windows should scroll along with the document to increase readability.
> > >
> > > > I'm not getting a way to achieve so. As annotation window is a
> QWidget,
> > >
> > > should there be a way to stick it to the pageview or should it move up
> or
> > > down while scrolling the document using signal and slot mechanism or ?
> > >
> > > > I need the quick guidance regarding how to start with this feature.
> Any
> > >
> > > help will be appreciated.
> > >
> > > > Thanks and Regards
> > > > Dileep
> > > >
> > > > ‌
>
>
>
>
>

Re: Better way to make the annotation windows scrollable with the document

[Dileep Sankhla]

Thank you so much Oliver. Due to lack of insight about the bugs, I'm unable
to categorize them into intermediate and difficult jobs.
I will try my best to find and work on some easier issue.

Thanks and Regards
Dileep

On Feb 26, 2018 14:15, "Oliver Sander" <oliver.san...@tu-dresden.de> wrote:

> Hi Dileep,
>
> it is great to see you so motivated to fix Okular annotation bugs.  But
> reading your
> mails I am wondering whether you picked a good place to start.  On the one
> hand,
> these scrolling annotation windows seem to be quite difficult to implement.
> On the other hand, my original bug report is really about the fact that
> you can
> maneuver annotation windows into a situation where you cannot close them
> anymore.  I know that the bug report is not quite _written_ that way, but
> I think
> that is how it should be read today.  Scrolling annotation windows could
> be a nice
> thing to have, but nobody seems to need them urgently.  At least not me.
>
> So maybe you could pick an easier issue to get you started?
>
> Many thanks, and best regards,
> Oliver
>
> On 25.02.2018 06:27, Dileep Sankhla wrote:
> > Hello,
> > I'm heading into Okular feature request 388450 where the annotation
> windows should scroll along with the document to increase readability.
> > I'm not getting a way to achieve so. As annotation window is a QWidget,
> should there be a way to stick it to the pageview or should it move up or
> down while scrolling the document using signal and slot mechanism or ?
> >
> > I need the quick guidance regarding how to start with this feature. Any
> help will be appreciated.
> >
> > Thanks and Regards
> > Dileep
> >
> > ‌
> >
>
>

Better way to make the annotation windows scrollable with the document

[Dileep Sankhla]

Hello,
I'm heading into Okular feature request 388450 where the annotation windows
should scroll along with the document to increase readability.
I'm not getting a way to achieve so. As annotation window is a QWidget,
should there be a way to stick it to the pageview or should it move up or
down while scrolling the document using signal and slot mechanism or ?

I need the quick guidance regarding how to start with this feature. Any
help will be appreciated.

Thanks and Regards
Dileep

‌

[okular] [Bug 388450] Popup-note annotations don't scroll with the document

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=388450

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC|sankhla.dilee...@gmail.com  |

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

[okular] [Bug 388532] Clicking a popup note icon should bring the popup note to the top

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=388532

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

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

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

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

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

Re: Need help regarding heading into the Okular Feature: 388450

[Dileep Sankhla]

Thank you so much. The information made me understand okular much better
and its internals too. I will try my best to form a solution and if any
problem, will contact the developers here or IRC.
Thank you once again.

Dileep





‌

On Sat, Feb 17, 2018 at 4:13 PM, Tobias Deiminger 
wrote:

> Hi Dileep!
>
> @all: Please check if the following is correct
>
> But now the problem is I'm confused inside the large codebase
>>
>
> Don't worry! I guess this has happened to almost everybody here a few
> times :)
>
> I'm trying to get an idea from the annotations that remains glued to
>> the pageview and do scroll with the scrollbar
>>
>
> There's an critical difference between your popup annotation windows and
> the "glued annotations": The popup windows are real, independent widgets
> (AnnotWindow<-QFrame<-QWidget). But the glued ones are just "dumb"
> pixmaps mostly rendered by the poppler generator, while all logic & drawing
> is done by the (too-)mighty PageView (a QAbstractScrollArea widget). Imho,
> this disqualifies them a bit as "similar code example".
>
> Most "glued annotations" are rendered by the poppler library along with
> text and other PDF objects into, simplest case, one big QImage per page
> (see PDFGenerator::image [0], rendering thread). The page QImage is
> converted to a QPixmap and gets painted at once in
> PagePainter::paintCroppedPageOnPainter [1]. Okular just knows the
> annotations position rectangles, so that the PageView widget can overlay
> some basic UI functionality like tooltips and selection rectangles.
>
> There are interesting exceptions, e.g. stamp annotations. Poppler can't
> render them, so as kind of workaround [2] Okular does that on its own.
> Stamps are drawn in the seciton "5 -- MIXED FLOW. Draw ANNOTATIONS [OPAQUE
> ONES] on ACTIVE PAINTER" - "draw StampAnnotation" [3]. So, rendered by
> okular, scrolling with the page - that's a bit closer to what you want. But
> otoh, those stamps are still only dumb QPixmaps, handled by the PageView
> widget.
>
> Your popup note input dialog is a real independent widget (good so!) with
> user input logic + state. See class AnnotWindow, and
> PageView::openAnnotationWindow. This widget implements the "open state"
> of annotations, which is a term from PDF standard ISO 32000 [4]. Chapter
> 12.5.1, "Annotations - General" describes the open and closed state in
> detail, I think that's a good reading for you.
>
> Btw., I found README.internals.png [5] to be a brief and good overview of
> Okulars design when I first touched Okular.
>
> Sorry for not providing concrete solution hints. Hopefully it helped to at
> least gain more insight into the problem.
>
> Cheers
> Tobias
>
> [0] https://cgit.kde.org/okular.git/tree/generators/poppler/gene
> rator_pdf.cpp?h=v17.12.2#n950
> [1] https://cgit.kde.org/okular.git/tree/ui/pagepainter.cpp?h=v1
> 7.12.2#n265
> [2] https://bugs.kde.org/show_bug.cgi?id=383651
> [3] https://cgit.kde.org/okular.git/tree/ui/pagepainter.cpp?h=v1
> 7.12.2#n741
> [4] https://wwwimages2.adobe.com/content/dam/acom/en/devnet/pdf/
> PDF32000_2008.pdf
> [5] https://cgit.kde.org/okular.git/tree/README.internals.png?h=v17.12.2
>
>

Need help regarding heading into the Okular Feature: 388450

[Dileep Sankhla]

Hello devs,

I have spent the past three days in heading into this feature request [1]
regarding scrolling the annotations along with the scrollbar and I have
been finding out how to unfix the position of the annotation window that
remains fixed to its position while scrolling the pageview.
I'm trying to get an idea from the annotations that remains glued to the
pageview and do scroll with the scrollbar and hence applying the same
approach ( and a bit of the similar code too) in order to achieve this on
the annotation window.
But now the problem is I'm confused inside the large codebase and I tried
to search for the keywords like "mouseMove", "scroll", "fixed"  but without
any success in finding the relevant section.
I also did minor tweaks and changes in order to understand the behavior but
until now, I'm nowhere.

I'm still searching but now I doubt my way of fixing a bug. Can you please
suggest me how to proceed to fix/implement the bug/feature and how to
search the code, inspect the Qt elements and all? What to do now?
I have read 'get started' guide but it doesn't emphasis on my own dilemma.

‌[1] https://bugs.kde.org/show_bug.cgi?id=388450

Thanks and Regards
Dileep

Re: Can I work on an issue that is the basis of a GSoC project?

[Dileep Sankhla]

Thank you so much. It really helped.



‌

On Wed, Feb 14, 2018 at 2:33 PM, Oliver Sander <oliver.san...@tu-dresden.de>
wrote:

> On 14.02.2018 03:22, Dileep Sankhla wrote:
> > Thank you so much. Do you also mean I can send the proposal to the same
> project while working on the same issue during this pre-application
> duration and may also have sent a patch for the review?
>
> Again, I'd say you can.  If you have completed too much of the project by
> the time it starts,
> will find additional stuff for you to do.
>
> I wouldn't mind a second opinion on this, though.
>
> >
> >
> >
> > ‌
> >
> > On Wed, Feb 14, 2018 at 2:42 AM, Oliver Sander <
> oliver.san...@tu-dresden.de <mailto:oliver.san...@tu-dresden.de>> wrote:
> >
> > Hi Dileep,
> >
> > > Can I work on the issue beforehand?
> >
> > I'd say: Sure you can!  If you are too quick and you solve the gsoc
> project way
> > before gsoc is over, then there are plenty of further interesting
> annotation-related
> > things to work on.  So start right away if you feel like it.
> >
> > Best,
> > Oliver
> >
> > >
> > > Thanks and Regards
> > > Dileep
> > >
> > > ‌
> >
> >
>
>

Re: Can I work on an issue that is the basis of a GSoC project?

[Dileep Sankhla]

Thank you so much. Do you also mean I can send the proposal to the same
project while working on the same issue during this pre-application
duration and may also have sent a patch for the review?



‌

On Wed, Feb 14, 2018 at 2:42 AM, Oliver Sander 
wrote:

> Hi Dileep,
>
> > Can I work on the issue beforehand?
>
> I'd say: Sure you can!  If you are too quick and you solve the gsoc
> project way
> before gsoc is over, then there are plenty of further interesting
> annotation-related
> things to work on.  So start right away if you feel like it.
>
> Best,
> Oliver
>
> >
> > Thanks and Regards
> > Dileep
> >
> > ‌
>
>

Can I work on an issue that is the basis of a GSoC project?

[Dileep Sankhla]

Hello Okular Developers,

I have been contributing to Okular for the last two weeks and this
application product and its key interesting issues intrigue me the most. I
love Okular from the very beginning of using KDE desktop on my Arch Linux
and realizing the missing key features made me selecting it as my
application of interest.

I was looking at the GSoC '18 Okular project ideas and found one of them on
which I'm willing to work but it also contains a link to the bug report
 and I'm thinking about
working on this bug before the application period starts. I think it will
also help me a lot in understanding the project idea.

Can I work on the issue beforehand?

Thanks and Regards
Dileep

‌

[okular] [Bug 387834] Okular does not display replies to "sticky notes"

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=387834

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

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

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 27086.
dileepsankhla added a comment.


  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.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=26778=27086

BRANCH
  master

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla marked an inline comment as done.
dileepsankhla added a comment.


  @aacid I have talked about using std::exit instead of QCoreApplication::exit 
here : https://phabricator.kde.org/D10249#200260
  
  With that, I want to add QCoreApplication::exit does nothing if the event 
loop is not running. You can find the info in the docs here: 
http://doc.qt.io/qt-5/qcoreapplication.html#exit

INLINE COMMENTS

> aacid wrote in part.cpp:3212
> What is the value of isError when
> 
>   if ( printDialog->exec() )
> 
> returns false?

Undefined behavior - isError can either be true or false, my bad. Submitting a 
new patch.

> aacid wrote in part.cpp:3217
> We discussed a bit on IRC but i don't remeber which your reason for not using 
> QCoreApplication::exit were, can you please remind me?

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

With that, I want to add that QCoreApplication::exit does nothing if the event 
loop is not running. You can find the info in the docs here: 
http://doc.qt.io/qt-5/qcoreapplication.html#exit

REPOSITORY
  R223 Okular

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

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

[okular] [Bug 388450] Popup-note annotations don't scroll with the document

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=388450

--- Comment #6 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
Should the annotation window allow to be dragged outside of the viewport by
using the mouse left button unless it is the border of the pdf view?

I have almost got the idea and I want to work on this feature request if no
other one is working on it.

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

[okular] [Bug 388450] Popup-note annotations don't scroll with the document

[Dileep Sankhla]

https://bugs.kde.org/show_bug.cgi?id=388450

Dileep Sankhla <sankhla.dilee...@gmail.com> changed:

   What|Removed |Added

 CC||sankhla.dilee...@gmail.com

--- Comment #4 from Dileep Sankhla <sankhla.dilee...@gmail.com> ---
Should be the patch related to avoid dragging of the annotation window outside
of the viewport?

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

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 26778.
dileepsankhla added a comment.


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

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=26608=26778

BRANCH
  master

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ltoscano, ngraham, aacid, #okular, michaelweghorn

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 26608.
dileepsankhla marked an inline comment as done.
dileepsankhla added a comment.


  Updating https://phabricator.kde.org/D10249: Option to exit after printing
  Initialized "isError" with false at the time of declaration.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=26550=26608

BRANCH
  master

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ngraham, aacid, #okular, michaelweghorn

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 26550.
dileepsankhla added a comment.


  Updating https://phabricator.kde.org/D10249: Option to exit after printing
  
  local variable to slotPrint function

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=26547=26550

BRANCH
  master

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ngraham, aacid, #okular, michaelweghorn

D10249: Option to exit after printing

[Dileep Sankhla]

dileepsankhla updated this revision to Diff 26547.
dileepsankhla added a comment.


  Updating https://phabricator.kde.org/D10249: Option to exit after printing
  
  I was trying to get rid of extern keyword while declaring "isError" inside 
the namespace of the header file. Hence I declared it as a class member, my bad.
  I have declared it inside the source file "part.cpp" in the namespace 
definition.

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10249?vs=26453=26547

BRANCH
  master

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

AFFECTED FILES
  autotests/mainshelltest.cpp
  part.cpp
  part.h
  shell/main.cpp
  shell/shell.cpp
  shell/shellutils.cpp
  shell/shellutils.h

To: dileepsankhla, aacid, #okular, ngraham
Cc: ngraham, aacid, #okular, michaelweghorn