<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-11-06 10:46 GMT+01:00 jdd <span dir="ltr"><<a href="mailto:jdd@dodin.org" target="_blank">jdd@dodin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Le 06/11/2016 à 10:11, Gilles Caulier a écrit :<br>
<br>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- You can let's 5.2.0 from system wide installed. No conflict.<br>
</blockquote>
<br></span>
but if you plan to use both, you have to use the same database. I do this without problem, but either backup the base frequently or store the data in the images and be ready to rebuild the database (anyway you may have to do this, for example if you move the collections).<br>
<br>
also what about the system setup? do the appimage write to it?<br></blockquote><div><br></div><div>What do mean by system setup ? DK setup ? </div><div><br></div><div>DK AppImage can read and write to user account DK settings, and system wide application.</div><div><br></div><div>AppImage will run with user account, not root. It cannot write on system. In fact DK from wide system will not do it also.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
that said, very good option to use the last digikam. I don't remember having ever lost anything important with digikam :-))<br></blockquote><div><br></div><div>There are again some improvements to do with AppImage :</div><div><br></div><div>1: use last JPEG lib. For the moment, due to time missing, i use CentOs 6 version (jpeg 6b), which is very old. Stable, but old. Some specifc code for JPEG support will be disabled. I needs i least to use JPEG 8 in the bundle.</div><div><br></div><div>2: it's the same for libtiff. CentOs provide a 3.9, and not last 4.x version.</div><div><br></div><div>3: libgphoto2 is an older version from CentOs. I need to update this to last one in the bundle to offer the last camera drivers.</div><div><br></div><div>4: libsane is an older one too. If you is interested by image scanner, you will not see all last drivers. This need to be updated in the bundle. </div><div><br></div><div>For the rest all is the last version :</div><div><br></div><div>- OpenCV 3.1 with all unwanted options disabled. Just what we need fro DK. I'm sure that some crash appears in DK because OpenCV is compiled with experiment options on some Linux system. OpenCV is a giant project, too much, too complex, and finally unstable when you enable all.</div><div><br></div><div>- Qt5 is the last one : 5.7.0</div><div>- KF5 is the last one : 5.27.0</div><div><br></div><div>- Exiv2 : is the last one, but i would to use current code from svn where more than 200 bugs are currently fixed. Exiv2 is a core dependencies to DK. I'm sure that DK can crash a lots with a non stabilized Exiv2. Exiv2 + OpenCV = the most important core libs. At least, with AppImage i use 0.25 and i disabled all unstable options, as video metadata support.</div><div>I already ask to Exiv2 team to release more frequently the library, but without success.  The 0.26 release is planed before Christmas as i know, but nothing is sure with Exiv2...</div><div><br></div><div>- Libraw : I update code to last 0.18 beta 1 and reported some compilation problem to the team. patches have been integrated as upstream. The 0.18 final release is planed before Christmas, as libraw coordinator said to me by private mail.</div><div><br></div><div>Some words now about the others bundles : Windows and OSX. Currently, OSX and Windows use different manners to bundle, and i need to factorize my scripts to have the same versions/compilation options everywhere. AppImage bundle project give me some good ideas/ways to implement a common frameworks for deployment everywhere. I will do it for 5.4.0.</div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier</div></div></div></div>