D10792: Raise annotation window when clicking on annotation
simgunz updated this revision to Diff 32442. simgunz added a comment. - Propagate the event REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D10792?vs=31564&id=32442 BRANCH raise-annotation-window REVISION DETAIL https://phabricator.kde.org/D10792 AFFECTED FILES autotests/parttest.cpp ui/annotwindow.cpp ui/pageview.cpp To: simgunz, #okular, aacid Cc: ngraham, #okular, michaelweghorn, aacid
D12299: Android: include metadata for okular kirigami
apol created this revision. apol added reviewers: Okular, mart, aacid. Restricted Application added a project: Okular. apol requested review of this revision. REVISION SUMMARY Include an AndroidManifest.xml file so when it's installed it has a proper icon and name. Include appdata information so it can be listed REPOSITORY R223 Okular BRANCH okularkirigamiandroid REVISION DETAIL https://phabricator.kde.org/D12299 AFFECTED FILES CMakeLists.txt mobile/android/AndroidManifest.xml mobile/android/res/drawable/icon.png mobile/android/res/values/libs.xml mobile/android/res/values/strings.xml mobile/app/CMakeLists.txt mobile/app/main.cpp mobile/app/org.kde.okular.kirigami.appdata.xml To: apol, #okular, mart, aacid Cc: michaelweghorn, ngraham, aacid
D10932: [Okular] Option to reset forms
aacid added a comment. Sorry for the late answer. I've been thinking about this and as all the stuff random user ask for, it shows they have not really thought much about it, and it is probably my fault having set this as a junio job. What does "Reset" actually mean? Is clearing a field resetting it? What if the field had "BLA" as contents when you opened it? Wouldn't resetting mean going back to "BLA" instead of empty? Ok, so this could be solved by changing from "Reset Forms" to "Clear Forms". "Clear" has a more "make this empty" meaning. But how do you actually clear a Radio button? When one of the N buttons has to be selected by definition? One could say "ok, let's ignore radio buttons". But then the biggest problem shows up and is on change actions linked to forms. You can have javascript linked to changing contents on form fields, and for example you could have one that said "if text of field A is empty put text 'BLA' on field B". What would be the correct output of running "Clear Forms"? Should field B contain "BLA" or not? And i'm going to say probably, but how do you actually achieve that programatically? I don't see a way since you'll go "set field A to be empty" -> "this triggers its execute change action" -> "set field B to empty" So my current thinking is closing the feature request as won't fix giving a version of the explanation written above. What do you think? Do you think what i say makes sense or am i saying stupid things? And if we were to throw away this code, how sad would you be? Have you at least learnt a bit about how testing/undo commands in Qt work? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10932 To: ahmadosama, #okular, aacid Cc: cfeck, ngraham, aacid, #okular, michaelweghorn
[okular] [Bug 392860] Incorrect rendering of scanned document
https://bugs.kde.org/show_bug.cgi?id=392860 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from Albert Astals Cid --- This is a bug in poppler. Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=poppler under the splash backend component -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 307304] Javascript in forms not working correctly
https://bugs.kde.org/show_bug.cgi?id=307304 Albert Astals Cid changed: What|Removed |Added CC||okular-devel@kde.org --- Comment #8 from Albert Astals Cid --- Please add okular-devel to the CC if you assign a bug to yourself. -- You are receiving this mail because: You are on the CC list for the bug.
D12049: Obey umask rules when saving new file
chinmoyr added a comment. ping REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D12049 To: chinmoyr, #okular, aacid Cc: michaelweghorn, ngraham, aacid
D12098: Resize content area to correct dimensions after zooming to Auto Fit
chinmoyr added a comment. ping REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D12098 To: chinmoyr, #okular, aacid Cc: michaelweghorn, ngraham, aacid
[okular] [Bug 307304] Javascript in forms not working correctly
https://bugs.kde.org/show_bug.cgi?id=307304
Andre Heinecke changed:
What|Removed |Added
Assignee|okular-devel@kde.org|aheine...@intevation.de
--- Comment #7 from Andre Heinecke ---
The problem here is that the SUM fields start readOnly / invisible. The
calculation works and if you set the fields to visible by hand they are updated
correctly.
In the PDF itself I find such scriptlets:
{
var summe = this.getField("Summe Spalte 1").value;
if(summe <= "0")
{
this.getField("Summe Spalte 1").display = display.hidden;
}
else
this.getField("Summe Spalte 1").display = display.visible;
}
Currently there is no support for the display property and display object.
These scripts are also not executed. Poppler currently does not parse the
scriplets. pdfinfo -js does not show them.
Looking at them in Adobe shows that the visibility scriptlets should be
executed when a field is deactivated. I guess that means something like
"Editing finished". The trigger has the Key "Bl".
So:
1. Parse "Bl" Triggered actions in poppler.
2. Execute them in Okular.
3. Add basic support for the display object / property in Okulars JavaScript.
I'll look into it.
--
You are receiving this mail because:
You are the assignee for the bug.
D11609: Add support for chained / next actions
aacid added inline comments. INLINE COMMENTS > aheinecke wrote in generator_pdf.cpp:475 > @aacid When you commited the corresponding poppler patch you did not add this > API. > > The problem here is: > > - In the LinkPrivate dtor we delete the nextLinks list. > - createLinkFromPopplerLink deletes the parsed the link. > > My solution for this was to add API to change the nextLinks so that they can > be "taken" from a Link. > > Maybe in poppler we could add "Poppler::Link::takeNextLinks()" to have a more > explicit API for that? > > Alternatively changing "createLinkFromPopplerLink" to optionally not delete > the link it parses? I think that is a bit more error prone as we have to make > sure we catch everything. For example the movie and rendition actions have > their own deletion. We have some takeXX functions but i personally don't like them much because they "break" the object, it may be very well possible that at some point we need to do getNextLinks somewhere else and we wouldn't see "we're doing it wrong" easily, since it would just be returning an empty list. I think adding a parameter to createLinkFromPoppler is the way to go, and yes it already is not great that createLinkFromPoppler behaves "randomly" in whether it should delete or not the links it gets. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D11609 To: aheinecke, #okular Cc: aacid, michaelweghorn, ngraham
[okular] [Bug 393206] Form data saved by Okular isn't readable by Adobe Acrobat
https://bugs.kde.org/show_bug.cgi?id=393206 Albert Astals Cid changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #3 from Albert Astals Cid --- Most probably a poppler bug, i'll investigate -- You are receiving this mail because: You are the assignee for the bug.
