summarylogtreecommitdiffstats
path: root/.SRCINFO
AgeCommit message (Collapse)Author
2020-08-21upgpkg: 0.96.5Kevin Brodsky
2020-07-01upgpkg: 0.96.4Kevin Brodsky
2020-06-25upgpkg: 0.96.3Kevin Brodsky
2020-05-08upgpkg: 0.96.2Kevin Brodsky
THe SHA256 doesn't match the one given by https://newsgroup.xnview.com/viewtopic.php?f=82&t=40411&p=162833#p162797, for now I've put the actual sum.
2020-04-23upgpkg: 0.96.1 + switch to SHA256 from upstreamKevin Brodsky
2020-03-21upgpkg: 0.96Kevin Brodsky
2020-01-25Actually bump .SRCINFOKevin Brodsky
2020-01-15upgpkg: 0.94.3Kevin Brodsky
2020-01-11upgpkg: 0.94.2-2 (big refactor)Kevin Brodsky
The latest update to libwebp (1.1) broke XnView, because it tries to link against the system libwebpmux.so while using the packaged libwebp.so (in Plugins). Because of this, I realised that there is no point in using the packaged plugins, since they are all libraries available in standard Arch packages. This commit replaces them with symlinks to system libs (as XnView is still unhappy if it cannot find them in Plugins/), and adds the relevant dependencies. While at it, I also realised that a lot of files are junk and don't need to be installed, and that many permissions are wrong. Fix all that by specifying which files/directories to install (instead of removing some), and only making executable those that should be. Finally, it looks the bug that prevented me from getting rid of lib/ altogether is gone, so there's no need to symlink the Qt plugin directories any more. As a result, the only use we still have for xnview.sh is the LD_PRELOAD hack, and we don't need the one included in the archive any more.
2019-12-25upgpkg: 0.94.2Kevin Brodsky
2019-11-21upgpkg: 0.94.1Kevin Brodsky
The XnView binary in that release has wrong permissions, add some more permission cleanup.
2019-11-14upgpkg: 0.94Kevin Brodsky
2019-03-16updpkg: 0.93.1-2Kevin Brodsky
2019-03-10updpkg: 0.93.1 + cleanup + hackKevin Brodsky
I had the unpleasant surprise to find that something changed in the Qt5 libraries shipped in 0.93.1, in such a way that they're not quite compatible with the system ones on Arch. Fortunately I found a way around that, which is frankly horrifying, but as long as you don't look at it it's probably alright! On the plus side, I've made some cleanups: - Drop the 32-bit package (like in xnviewmp). - Drop the trash workaround, it's fixed in 0.93.1. - No need to special-case the "styles" folder any more, since it's now shipped as well.
2019-02-02updpkg: 0.93-2 (gvfs-trash workaround)Kevin Brodsky
As reported by fuan_k, the trash functionality is now quite broken because XnView relies on gvfs-trash, which no longer exists. Until it is properly fixed, use a wrapper that calls gio trash (gio is provided by glib2, so the optdepends has been updated). See also: https://newsgroup.xnview.com/viewtopic.php?t=37989
2019-01-31updpkg: 0.93Kevin Brodsky
2018-09-21updpkg: 0.92Kevin Brodsky
2018-09-19updpkg: 0.91-2Kevin Brodsky
2018-09-14updpkg: 0.91Kevin Brodsky
Pulled in qtav for libQtAVWidgets, see https://newsgroup.xnview.com/viewtopic.php?f=82&t=37907
2018-03-08updpkg: 0.90 + remove QT_QPA_PLATFORMTHEME overrideKevin Brodsky
Setting QT_QPA_PLATFORMTHEME to gtk2 doesn't work out of the box on Cinnamon (and probably other DEs). Using qt5ct works fine for me, so let's remove the override for now and see if anyone complains :-)
2018-01-17updpkg: 0.89Kevin Brodsky
2017-11-04updpkg: 0.88Kevin Brodsky
2017-10-04upgpkg: 0.87-2Kevin Brodsky
As pointed out by Marcouney (thanks for the tip!), it can be useful to symlink plugins/styles as well, so that theme engines such as qt5ct can be used for XnView as well without additional hacks. Note that xnview.sh would have to be modified for that purpose, as it overrides QT_QPA_PLATFORMTHEME.
2017-09-07upgpkg: 0.87Kevin Brodsky
2017-04-27updpkg: 0.86 + more library pruningKevin Brodsky
It turns out everything in lib/ should come from the system, so we can gain a bit more space by removing all the provided libraries (except those in Plugins/).
2017-04-05updpkg: 0.85Kevin Brodsky
2017-02-12updpkg: 0.84-3Kevin Brodsky
So apparently setting QT_QPA_PLATFORMTHEME was not enough to fix the font issue. I found out that using QT_PLUGIN_PATH=/usr/lib/qt/plugins didn't work for me because of an obscure issue in the OpenGL xcb integration. So my idea was to use the system Qt plugins, but not the whole directory as some stuff doesn't work. Symlinking just platforms and platformthemes seems to do the trick: no segfault and no font problem. Do keep in mind that this package is experimental and things may break as I am experimenting. But of course, when this happens, let me know and I'll try my best to make it work for everyone.
2017-02-08updpkg: 0.84-2 [new 0.84 release]Kevin Brodsky
2017-01-25Version source archivesKevin Brodsky
Add the version number to the downloaded source archives. This talks makepkg into redownloading the sources when there is a new release, instead of keeping the old archive and failing the checksum. This also has the nice side-effect of keeping previous source versions, should one want to downgrade the package. Since upstream does not always bump the version number when releasing new sources, I had to use a trick to make it work. "-rel$srcrel" is appended to the filename, and if new sources of the same version are released, srcrel is incremented (and then reset to 1 when a new version is released). Not beautiful, but it should do the job.
2017-01-21Initial version: 0.84Kevin Brodsky
Hopefully the QT_QPA_PLATFORMTHEME hack will work for most people.