[okular] [Bug 394429] New: Okular crashed after reboot

[Dennis]

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

Bug ID: 394429
   Summary: Okular crashed after reboot
   Product: okular
   Version: 1.4.1
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: okular-devel@kde.org
  Reporter: m...@dennis-irrgang.com
  Target Milestone: ---

Application: okular (1.4.1)

Qt Version: 5.10.0
Frameworks Version: 5.45.0
Operating System: Linux 4.16.8-1-default x86_64
Distribution: "openSUSE Tumbleweed"

-- Information about the crash:
- What I was doing when the application crashed:
I updated TW the evening before. After booting this morning it said it couldn't
open a file and crashed.

-- Backtrace:
Application: Okular (okular), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f5a04570180 (LWP 3497))]

Thread 3 (Thread 0x7f59e91de700 (LWP 3523)):
#0  0x7f5a00299179 in poll () at /lib64/libc.so.6
#1  0x7f59fac78429 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x7f59fac7853c in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#3  0x7f5a00bd7a2b in
QEventDispatcherGlib::processEvents(QFlags)
(this=0x7f59e4000b20, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7f5a00b7e95a in
QEventLoop::exec(QFlags)
(this=this@entry=0x7f59e91ddd90, flags=..., flags@entry=...) at
kernel/qeventloop.cpp:212
#5  0x7f5a009a5baa in QThread::exec() (this=this@entry=0x7f5a0126bd60
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
thread/qthread.cpp:522
#6  0x7f5a00ffba35 in QDBusConnectionManager::run() (this=0x7f5a0126bd60
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
qdbusconnection.cpp:178
#7  0x7f5a009aaba0 in QThreadPrivate::start(void*) (arg=0x7f5a0126bd60
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
thread/qthread_unix.cpp:376
#8  0x7f59fd27a59b in start_thread () at /lib64/libpthread.so.0
#9  0x7f5a002a3a1f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7f59f254f700 (LWP 3508)):
#0  0x7f5a00299179 in poll () at /lib64/libc.so.6
#1  0x7f59fd6a2387 in  () at /usr/lib64/libxcb.so.1
#2  0x7f59fd6a3faa in xcb_wait_for_event () at /usr/lib64/libxcb.so.1
#3  0x7f59f551a0a9 in QXcbEventReader::run() (this=0x55a1e454e1c0) at
qxcbconnection.cpp:1370
#4  0x7f5a009aaba0 in QThreadPrivate::start(void*) (arg=0x55a1e454e1c0) at
thread/qthread_unix.cpp:376
#5  0x7f59fd27a59b in start_thread () at /lib64/libpthread.so.0
#6  0x7f5a002a3a1f in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7f5a04570180 (LWP 3497)):
[KCrash Handler]
#6  0x7f5a029aa6a0 in  () at /usr/lib64/libKF5ConfigCore.so.5
#7  0x7f5a029bf3a4 in KConfigGroup::readEntry(char const*, QVariant const&)
const () at /usr/lib64/libKF5ConfigCore.so.5
#8  0x55a1e39a7863 in KConfigGroup::readEntry(char const*, int const&)
const (defaultValue=@0x7fff0d4e499c: 0, key=0x55a1e39ae562 "ActiveTab",
this=0x7fff0d4e4a50) at /usr/include/KF5/KConfigCore/kconfiggroup.h:728
#9  0x55a1e39a7863 in Shell::readProperties(KConfigGroup const&)
(this=0x55a1e46f4d00, group=...) at
/usr/src/debug/okular-18.04.1-1.1.x86_64/shell/shell.cpp:392
#10 0x7f5a036e99f8 in KMainWindow::readPropertiesInternal(KConfig*, int) ()
at /usr/lib64/libKF5XmlGui.so.5
#11 0x7f5a036e9a42 in KMainWindow::restore(int, bool) () at
/usr/lib64/libKF5XmlGui.so.5
#12 0x55a1e39a2be3 in kRestoreMainWindows() () at
/usr/include/KF5/KXmlGui/kmainwindow.h:719
#13 0x55a1e39a0312 in main(int, char**) (argc=,
argv=) at
/usr/src/debug/okular-18.04.1-1.1.x86_64/shell/main.cpp:66

Reported using DrKonqi

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

D10974: PDF: Allow to ignore print margins

[Michael Weghorn]

michaelweghorn added a comment.


  In D10974#264672 , @aacid wrote:
  
  > [...]
  >  The feature it's not really "Fit to printable area", it's more "Take 
Margins into account" or if we negate it "Ignore printer margins", because 
"printable area" is the area of the page where the printer can print, but what 
we're doing here is ignore the printer margins, that default to the printable 
area but the user can change at will.
  >
  > What do you think?
  
  
  I agree. I personally like "Ignore printer margins" best.
  Thanks also for your suggestion on how to make it available for all 
generators.! I'll try to have a closer look sometime next week, since I'm away 
for this weekend.

REPOSITORY
  R223 Okular

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

To: michaelweghorn, #okular
Cc: okular-devel, aacid, ngraham

KDE CI: Applications okular kf5-qt5 FreeBSDQt5.10 - Build # 13 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Applications%20okular%20kf5-qt5%20FreeBSDQt5.10/13/
 Project:
Applications okular kf5-qt5 FreeBSDQt5.10
 Date of build:
Fri, 18 May 2018 15:28:05 +
 Build duration:
48 min and counting
   JUnit Tests
  Name: (root) Failed: 16 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 17 test(s)Failed: TestSuite.addremoveannotationtestFailed: TestSuite.annotationstestFailed: TestSuite.calculatetexttestFailed: TestSuite.documenttestFailed: TestSuite.editannotationcontentstestFailed: TestSuite.editdrawingtooldialogtestFailed: TestSuite.editformstestFailed: TestSuite.generatorstestFailed: TestSuite.kimgiotestFailed: TestSuite.mainshelltestFailed: TestSuite.modifyannotationpropertiestestFailed: TestSuite.parttestFailed: TestSuite.searchtestFailed: TestSuite.translateannotationtestFailed: TestSuite.urldetecttestFailed: TestSuite.visibilitytest

D7662: Draw a dark rectangle around highlighted search results

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R223:004efa70e4a7: Draw a dark rectangle around highlighted 
search results (authored by sander, committed by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D7662?vs=21180=34440#toc

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7662?vs=21180=34440

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

AFFECTED FILES
  ui/pagepainter.cpp

To: sander, #okular, aacid
Cc: okular-devel, simgunz, cfeck, aacid, ngraham

[okular] [Bug 355043] Cannot differentiate between review and search highlights

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://commits.kde.org/oku
   ||lar/004efa70e4a764bbd780d4f
   ||3e5bcaf40de70a1a6
 Resolution|--- |FIXED

--- Comment #8 from Albert Astals Cid  ---
Git commit 004efa70e4a764bbd780d4f3e5bcaf40de70a1a6 by Albert Astals Cid, on
behalf of Oliver Sander.
Committed on 18/05/2018 at 15:27.
Pushed by aacid into branch 'master'.

Draw a dark rectangle around highlighted search results

Summary:

Makes it easier to distinguish search results from text with a 'highlight'
annotation.

Reviewers: #okular

Subscribers: okular-devel, simgunz, cfeck, aacid, ngraham

Tags: #okular

Differential Revision: https://phabricator.kde.org/D7662

M  +5-0ui/pagepainter.cpp

https://commits.kde.org/okular/004efa70e4a764bbd780d4f3e5bcaf40de70a1a6

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

D7662: Draw a dark rectangle around highlighted search results

[Albert Astals Cid]

aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  That is a fix, not the ideal fix, now that i've had time to look at the 
problem, the problem is.
  
  Basically that we're writting in the "buffered" area of the painter, which 
means we reuse it from paint to paint unless something big has happened, since 
we reuse it from paint to paint and if we're intersecting with limits it means 
that when a highlight it is cut by border "of the screen" we'll only paint part 
of the highlight, which means that when we scroll to show all the higlight we 
only paint the "new" area of the highlight, reusing the old one, that was fine 
before since it's just a colored rectangle, but now that it has borders it 
means that the old border that was "in the middle" of the highlight is kept.
  
  Ideally one would move the border painting to the non buffered area (i.e. the 
area that is not reused from paint to paint), but that'd be quite a lot of job 
so what i've made is partially use the suggestion from @simgunz but only 
applied to the hightlight rects.
  
  I'll commit in a minute

REPOSITORY
  R223 Okular

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

To: sander, #okular, aacid
Cc: okular-devel, simgunz, cfeck, aacid, ngraham

D11725: [RFC] Show signature status as a popup

[Chinmoy Ranjan Pradhan]

chinmoyr added a comment.


  In D11725#264703 , @aacid wrote:
  
  > This doesn't work anymore right? signValidationInfoList doesn't exist in  
D11723 
  
  
  It requires revision 30645 to work.

REPOSITORY
  R223 Okular

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

To: chinmoyr, #okular
Cc: okular-devel, aacid, sander, ngraham

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

D11725: [RFC] Show signature status as a popup

[Albert Astals Cid]

aacid added a comment.
Restricted Application added a subscriber: okular-devel.


  This doesn't work anymore right? signValidationInfoList doesn't exist in  
D11723 

REPOSITORY
  R223 Okular

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

To: chinmoyr, #okular
Cc: okular-devel, aacid, sander, ngraham

D10974: PDF: Allow to ignore print margins

[Albert Astals Cid]

aacid added a comment.


  Actually on a second read of the texts i'm not sure i like them.
  
  The feature it's not really "Fit to printable area", it's more "Take Margins 
into account" or if we negate it "Ignore printer margins", because "printable 
area" is the area of the page where the printer can print, but what we're doing 
here is ignore the printer margins, that default to the printable area but the 
user can change at will.
  
  What do you think?

REPOSITORY
  R223 Okular

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

To: michaelweghorn, #okular
Cc: okular-devel, aacid, ngraham

D10974: PDF: Allow to ignore print margins

[Albert Astals Cid]

aacid added a comment.
Restricted Application added a subscriber: okular-devel.


  Looks good, i'm going to try to make the PrintScalingOptionWidget be shown 
for all the formats and not only for PDF before commiting, should "hopefully" 
not be very hard.

REPOSITORY
  R223 Okular

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

To: michaelweghorn, #okular
Cc: okular-devel, aacid, ngraham

KDE CI: Applications okular kf5-qt5 FreeBSDQt5.10 - Build # 12 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Applications%20okular%20kf5-qt5%20FreeBSDQt5.10/12/
 Project:
Applications okular kf5-qt5 FreeBSDQt5.10
 Date of build:
Fri, 18 May 2018 13:18:28 +
 Build duration:
26 min and counting
   JUnit Tests
  Name: (root) Failed: 16 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 17 test(s)Failed: TestSuite.addremoveannotationtestFailed: TestSuite.annotationstestFailed: TestSuite.calculatetexttestFailed: TestSuite.documenttestFailed: TestSuite.editannotationcontentstestFailed: TestSuite.editdrawingtooldialogtestFailed: TestSuite.editformstestFailed: TestSuite.generatorstestFailed: TestSuite.kimgiotestFailed: TestSuite.mainshelltestFailed: TestSuite.modifyannotationpropertiestestFailed: TestSuite.parttestFailed: TestSuite.searchtestFailed: TestSuite.translateannotationtestFailed: TestSuite.urldetecttestFailed: TestSuite.visibilitytest

D11723: Add FormFieldSignature to Okular namespace

[Albert Astals Cid]

aacid added a comment.


  I understand you're mimicing the poppler API at some points but that doesn't 
always makes sense since poppler is a multi-purpose library and okular is a 
document viewer.

INLINE COMMENTS

> form.cpp:284
> +
> +void setValue( const QString& v ) override
> +{

What's this used for?

> form.h:390
> +ValidateVerifyCertificate = 1, ///< Validate the certificate.
> +ValidateForceRevalidation = 2, ///< Force revalidation of the 
> certificate.
> +};

What would be the usecase for this force?

> form.h:405
> + */
> +virtual QMap validate( ValidateOptions opt ) 
> const = 0;
> +

a map of strings to variants is not very good API since basically it can have 
any random things in there. So as a consumer of that API you're blind. Wouldn't 
a class/structure make sense here?

> form.h:412
> + */
> +virtual QMap validate( int opt, const QString& 
> validationTime ) const = 0;
> +

As a viewer when would we need to have a different validation time than now?

> formfields.cpp:389
> +case PopplerSignatureValidationInfo::SignatureValid:
> +signStat =  QStringLiteral( "Signature is Valid." );
> +break;

Are these strings supposed to be user visible? If so you need i18n around them

> formfields.h:140
> +
> +enum SignatureStatus {
> +SignatureValid,  ///< The signature is cryptographically 
> valid.

Why do we need all these enums can't we use the ones in poppler¿

REPOSITORY
  R223 Okular

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

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

D10792: Raise annotation window when clicking on annotation

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R223:48b9ca66a6fd: Raise annotation window when clicking on 
annotation (authored by simgunz, committed by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D10792?vs=33907=34434#toc

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10792?vs=33907=34434

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

AFFECTED FILES
  autotests/parttest.cpp
  ui/annotwindow.cpp
  ui/pageview.cpp

To: simgunz, #okular, aacid
Cc: okular-devel, ngraham, #okular, aacid

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

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Latest Commit||https://commits.kde.org/oku
   ||lar/48b9ca66a6fd8892c2f62b3
   ||4ad56ce66c817e45c
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Albert Astals Cid  ---
Git commit 48b9ca66a6fd8892c2f62b34ad56ce66c817e45c by Albert Astals Cid, on
behalf of Simone Gaiarin.
Committed on 18/05/2018 at 13:17.
Pushed by aacid into branch 'master'.

Raise annotation window when clicking on annotation

Summary:
Raise annotation window when clicking on the window title, window text edit, or
the associated annotation.

Reviewers: #okular, aacid

Subscribers: okular-devel, ngraham, #okular

Tags: #okular

Differential Revision: https://phabricator.kde.org/D10792

M  +89   -3autotests/parttest.cpp
M  +6-0ui/annotwindow.cpp
M  +4-1ui/pageview.cpp

https://commits.kde.org/okular/48b9ca66a6fd8892c2f62b34ad56ce66c817e45c

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

D10792: Raise annotation window when clicking on annotation

[Albert Astals Cid]

aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  Nice!

REPOSITORY
  R223 Okular

BRANCH
  raise-annotation-window

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

To: simgunz, #okular, aacid
Cc: okular-devel, ngraham, #okular, aacid

KDE CI: Applications okular kf5-qt5 FreeBSDQt5.10 - Build # 11 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Applications%20okular%20kf5-qt5%20FreeBSDQt5.10/11/
 Project:
Applications okular kf5-qt5 FreeBSDQt5.10
 Date of build:
Fri, 18 May 2018 12:42:38 +
 Build duration:
2 min 16 sec and counting
   JUnit Tests
  Name: (root) Failed: 16 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 17 test(s)Failed: TestSuite.addremoveannotationtestFailed: TestSuite.annotationstestFailed: TestSuite.calculatetexttestFailed: TestSuite.documenttestFailed: TestSuite.editannotationcontentstestFailed: TestSuite.editdrawingtooldialogtestFailed: TestSuite.editformstestFailed: TestSuite.generatorstestFailed: TestSuite.kimgiotestFailed: TestSuite.mainshelltestFailed: TestSuite.modifyannotationpropertiestestFailed: TestSuite.parttestFailed: TestSuite.searchtestFailed: TestSuite.translateannotationtestFailed: TestSuite.urldetecttestFailed: TestSuite.visibilitytest

D12825: Fix recalculating forms twice

[Albert Astals Cid]

aacid added a comment.


  Will you upload an updated patch or should i just do it ?

REPOSITORY
  R223 Okular

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

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

D12665: Support additional widget actions in PDF Forms

[Albert Astals Cid]

aacid added inline comments.
Restricted Application added a subscriber: okular-devel.

INLINE COMMENTS

> CMakeLists.txt:86
>l->nextLinks();
> +  f->additionalAction(Poppler::Annotation::CursorEnteringAction);
>  }

You need to move this to a whole new block since it has to be in a check for 
0.65 not for 0.64

> formfields.cpp:20
>  extern Okular::Action* createLinkFromPopplerLink(const Poppler::Link 
> *popplerLink, bool deletePopplerLink = true);
> +#ifdef HAVE_POPPLER_0_64
> +# define SET_ANNOT_ACTIONS \

This should be 65

> formwidgets.cpp:1073
> +{ \
> +Okular::Action *act = m_ff->additionalAction( 
> Okular::Annotation::MouseReleased ); \
> +if ( act ) \

This still triggers if you press the button inside a form, move the mouse 
outside the form and release, not sure this is "according to spec", it says "An 
action to be performed when the mouse button is released inside the 
annotation’s active area."

> formwidgets.cpp:1078
> +} \
> +else if ( !qobject_cast< CheckBoxEdit* > ( this ) ) \
> +{\

Are you sure this should be an else? Why should activation action only be 
signaled if there's no mouse release action?

Also, before we only did activation action for buttons, but now we do for lots 
of other forms, is that on purpose?

REPOSITORY
  R223 Okular

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

To: aheinecke, #okular
Cc: okular-devel, aacid, ngraham

D12825: Fix recalculating forms twice

[Andre Heinecke]

aheinecke added a comment.


  Ugh, Sorry for overlooking these.
  
  Yes. They also call notifyFormChanges in their redo.

REPOSITORY
  R223 Okular

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

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

D12825: Fix recalculating forms twice

[Albert Astals Cid]

aacid added a comment.


  Should we remove the recalculateForms from editFormList and editFormCombo too 
then?

REPOSITORY
  R223 Okular

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

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