Am 06.06.2018 23:17 schrieb Albert Astals Cid:
El dimecres, 6 de juny de 2018, a les 15:43:01 CEST, Dileep Sankhla va
escriure:
PageViewAnnotator pageviewannotator(part.m_pageView, part.m_document);
pageviewannotator.setEnabled( true );
Why don't you just call PageView::slotToggleAnnotator ?
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?
PageViewAnnotator is not an exported class so you can't call functions
on it
because those functions are not part of the library. You'll have the
same
"problem" with PageView::slotToggleAnnotator.
Thanks for your explanation! I'm adding a few technical bits. If you
want to see which symbols from an ELF library like okularpart.so can
used by linking programs (like parttest), you can check for "g" (Global
Symbol) flags with objdump. Every class that was defined with "class
OKULARPART_EXPORT" should have become global.
$ objdump -tC okularpart.so | grep PageViewAnnotator::PageViewAnnotator
000000000011a10e l F .text 00000000000000db
PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)
000000000011a10e l F .text 00000000000000db
PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)
Here the flag in the second column is a "l", which stands for "Local
symbol". So PageViewAnnotator::PageViewAnnotator is only visible from
within okularpart.so, but not for another binary that wants to link to
okularpart.so (like parttest). See also
https://gcc.gnu.org/wiki/Visibility. Not that for other binary formats
and compilers it's a bit different.
In this case it can be workarounded since it's a slot and you can use
qobject
magic to call it. See the QMetaObject::invokeMethod calls in parttest
Cheers,
Albert
On Wed, Jun 6, 2018 at 3:08 PM, Dileep Sankhla
<sankhla.dilee...@gmail.com>
wrote:
> 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?"
The button check is maybe not the most important test case wrt
functionality. But it's a very good one to learn about testing. So go on
with 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?
If you only want to check the toolbar and its buttons, don't load a
document at all. Toolbar and buttons are instantiated independent from
having a document open. You want to keep out not needed functionality,
to make a potential failed test more spot on.
> Do I need to simulate <F6> keypress for showing the annotation toolbar and
You could, but Alberts suggestion of using PageView::slotToggleAnnotator
is better, because it's a more direct way to achieve what you want to
achieve.
> if yes, then how will I check for the specific tool in it?
You could probably use QToolBar* toolbar =
part.m_pageView->findChild<QToolBar*>(), and then use
QToolBar::widgetForAction to look for the button.
Or you do a subsequent toolbar->findChildren<QToolButton*>(), to get a
list of the inner buttons.
Finally you can access the icon with QAbstractButton::icon().
Cheers
Tobias
> Need help.
>
> Thanks and Regards
> Dileep
>
>
>
>
> On Mon, Jun 4, 2018 at 1:19 AM, Tobias Deiminger <haxti...@posteo.de>
>
> 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
