Re: [Okular-devel] Building on Windows
Thank you both Albert and Thomas for helping with this. I'm neither an expert in Okular nor in KDE for Windows. But I am working on a project that involves adding functionality to Okular and is worthless if it can't be built for Windows, so I do have an interest in getting this to work. So I am happy to invest some time and energy both in learning and in building and testing various solutions. Cheers, Jonathan On 10/03/16 21:01, Thomas Friedrichsmeier wrote: Hi, On Thu, 10 Mar 2016 01:19:39 +0100 Albert Astals Cid wrote: El Wednesday 09 March 2016, a les 17:16:10, Thomas Friedrichsmeier va escriure: [...] The knowledgeable people here are not just sitting iddle, waiting for somethign to do either. Didn't mean to imply that. Just pointing out that currently, _if_ you care about your app being available on Windows, you should be prepared to invest some work on that, yourself. Well, "my" app can make good (optional) use of okularpart, and having a solid Windows port _is_ a priority to us. So I am willing to invest some time, and so I'm doing what I can, but also that still cannot substitute for somebody more familiar with okular to invest the effort it takes to get a Windows VM up and running. [visibility problem] If the problem is the mobile part, you may as well leave it out for now. Good to know. However, I think I have found out how to fix this part, meanwhile. Review request will follow. Part 3, name of the lib probably just needs some cmake setting, but actually, ui/shell.cpp has a code-comment wrt loading the plugin that might just point to a cleaner solution. Nice :) By which I meant, perhaps somebody from your team might be interested in re-reading that and implementing a cleaner solution for plugin loading. I'm not going to mess with that. I will offer a trivial patch to CMakeLists.txt, instead, though. Regards Thomas ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 360200] Wrong rendering of shadings
https://bugs.kde.org/show_bug.cgi?id=360200 --- Comment #2 from Martin Thoma --- See https://bugs.freedesktop.org/show_bug.cgi?id=94441 -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 Carsten Gräser changed: What|Removed |Added CC||grae...@math.fu-berlin.de --- Comment #39 from Carsten Gräser --- I also stumbled about the fact that it seems to be impossible to have multiple instances of the same filled in form under the same file name and got the impression that "Save as..." does not work. After some experimenting I found out the problem with "Save as...": There's two places where form data is stored: .kde/* and the pdf-file itself. Data is always saved to .kde/* (attached to filename?). If you use "Save as" it's also stored to the file. The problem is that this is not visible to the user and that .kde/* seems to have precedence. If you want to fill the same form twice you can easily run into problems: Case a: Since form data is visible after closing, reopening, or moving the file, the user assumes that it's stored inside of the pdf. To fill a form a second time he copies the filled in form into a new location and changes the necessary data. Everything seems to work, but if he reopens the original file all it's data is changed to what he entered in the new place. Case b: The user is aware that data is stored in the file only if he used "Save as". After filling the form the first time he uses "Save as". To fill the form a second time he copies the filled in form into a new location and changes the necessary data and uses "Save as" again. Now different data is saved in both versions of the file. But if he opens version 1 again, he sees the changes he did in version 2. The reason for this is that by changing version 2, the data in .kde/* is changed and this seems to have precedence when viewing version 1. If you delete th corresponding file in .kde/* you see what's stored in the file. In both cases the user seems to have lost data. In a) this is true, in b) his data is just not visible. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request 127328: Fix build on Windows (MinGW)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127328/ --- Review request for Okular and Albert Astals Cid. Repository: okular Description --- Three parts to this patch: 1) The plaform #ifdef in interfaces/viewerinterface.h is platform, not compiler-specific. 2) When compiling okularplugin, the existing definition of okularpart_EXPORTS on the generated settings.cpp does not work with MinGW, for reasons that I do not understand. Setting the definition on the whole target, instead, works. 3) The okularpart lib will automatically be named libokularpart, and subsequently not be found when trying to load it via KPluginLoader. Tell cmake to drop the "lib"-prefix. See also: - Discussion on list https://mail.kde.org/pipermail/okular-devel/2016-March/022480.html - A previous review request addressed issue 2 for MSVC https://git.reviewboard.kde.org/r/125742/ Diffs - CMakeLists.txt e17bc25 interfaces/viewerinterface.h e9e76a2 mobile/components/CMakeLists.txt e09326a Diff: https://git.reviewboard.kde.org/r/127328/diff/ Testing --- Builds on Windows with MinGW. Starts, and loads okularpart, successfully. Thanks, Thomas Friedrichsmeier ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Building on Windows
Hi, On Thu, 10 Mar 2016 01:19:39 +0100 Albert Astals Cid wrote: > El Wednesday 09 March 2016, a les 17:16:10, Thomas Friedrichsmeier va > escriure: [...] > The knowledgeable people here are not just sitting iddle, waiting for > somethign to do either. Didn't mean to imply that. Just pointing out that currently, _if_ you care about your app being available on Windows, you should be prepared to invest some work on that, yourself. Well, "my" app can make good (optional) use of okularpart, and having a solid Windows port _is_ a priority to us. So I am willing to invest some time, and so I'm doing what I can, but also that still cannot substitute for somebody more familiar with okular to invest the effort it takes to get a Windows VM up and running. [visibility problem] > If the problem is the mobile part, you may as well leave it out for > now. Good to know. However, I think I have found out how to fix this part, meanwhile. Review request will follow. > > Part 3, name of the lib probably just needs some cmake setting, but > > actually, ui/shell.cpp has a code-comment wrt loading the plugin > > that might just point to a cleaner solution. > > Nice :) By which I meant, perhaps somebody from your team might be interested in re-reading that and implementing a cleaner solution for plugin loading. I'm not going to mess with that. I will offer a trivial patch to CMakeLists.txt, instead, though. Regards Thomas pgpthNRtLnUJT.pgp Description: OpenPGP digital signature ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
