This revision was automatically updated to reflect the committed changes.
Closed by commit R223:3832a6522f3b: Update Okular developer documentation
(authored by yurchor).
CHANGED PRIOR TO COMMIT
https://phabricator.kde.org/D17801?vs=50309=51073#toc
REPOSITORY
R223 Okular
CHANGES SINCE LAST
joaonetto added a comment.
I don't know a lot about autotests, therefore I'm not so sure that it is
implemented correctly. I can implement it, but I would need some assistance.
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18144
To: joaonetto, #okular
Cc: ngraham,
joaonetto updated this revision to Diff 51070.
joaonetto added a comment.
Changed decrypt to shellUtils. Implemented a test
REPOSITORY
R223 Okular
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D18144?vs=50806=51070
BRANCH
arcpatch-D18144_2
REVISION DETAIL
https://bugs.kde.org/show_bug.cgi?id=403943
--- Comment #4 from David Hurka ---
(In reply to Albert Astals Cid from comment #3)
> Adobe Reader [...]
Ah, that is why PDFs are deployed with such excessive whitespace in the TOC.
Then Okular should probably not silently remove the whitespace, but
aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.
I have not carefully reviewed it, but it seems to be clearly better than what
we have, so i'd say go ahead and commit it (without the setPlaceHolder changes
that don't belong here i guess)
El divendres, 25 de gener de 2019, a les 23:51:25 CET, João Netto va escriure:
> Hi,
>
> As of now, January 2019, Okular doesn't provide some basic features in it's
> search feature, one of them, the ability of search for whole words is
> lacking, this can be a problem when I'm searching for the
https://bugs.kde.org/show_bug.cgi?id=403943
--- Comment #3 from Albert Astals Cid ---
On the other hand Adobe Reader shows this without lots of space, so needs some
investigation as to waht we could do
--
You are receiving this mail because:
You are the assignee for the bug.
aacid added a comment.
Do you think you could create an autotest for this? If not it's fine, but
would make sure things don't break in the future.
INLINE COMMENTS
> shell.cpp:684
> KDocumentViewer* const doc = qobject_cast(part);
> +const QString
>
shubham edited the summary of this revision.
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18744
To: shubham, aacid, #vdg
Cc: davidhurka, abetts, loh.tar, alexde, ngraham, okular-devel, tfella,
darcyshen, aacid
shubham edited the summary of this revision.
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18744
To: shubham, aacid, #vdg
Cc: davidhurka, abetts, loh.tar, alexde, ngraham, okular-devel, tfella,
darcyshen, aacid
loh.tar added a comment.
Here a link how it is done in Kate/KTextEditor
https://cgit.kde.org/ktexteditor.git/tree/src/view/kateviewinternal.cpp#n2710
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18744
To: shubham, aacid, #vdg
Cc: davidhurka, abetts, loh.tar,
shubham added a comment.
I'm unsure how mouse click events of degree n can be handled. Maybe handle
mouseDoubleClickEvent() nested inside another mouseDoubleClickEvent() ?
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18744
To: shubham, aacid, #vdg
Cc: davidhurka,
https://bugs.kde.org/show_bug.cgi?id=403486
--- Comment #12 from avlas ---
Sounds good to me. Talking about remembering, in addition to F7 status (ON/OFF
and expanded/collapsed), could Okular remember "F6" ON/OFF status as well?
--
You are receiving this mail because:
You are the assignee for
13 matches
Mail list logo
