Version: 1.1.5 (using KDE KDE 3.3.0) Installed from: SuSE RPMs OS: Linux I assume that both DIGIKAM and GWENVIEW use the same plugin to export HTML data when building galleries. The output is written to KIPI....../"gallery name"/ etc If the gallery names are unique then why must everything be deleted below the KIPI..... directory when building a further gallery???? This would save storing all but the last gallery temporally elsewhere before uploading them to the web. The next point concerns the inability to transport text descriptions of images across to the HTML files and display them there. Text entered before the exportation is really meant to be read by the web viewer. To elaborate on the above I wish to keep all text in a SQLite database using the image filename to retrieve the text and put it into the image on the screen. Is the EXIF area the correct place ? Is it possible to build a plugin allowing SQLite usage ? I have over 4000 digital images and the numbers increase daily. My last wish is to be able to place the FOREWARD and BACKWARD arrows where I would like them. eg on each side of the image. See <www.deskelly.com> to understand my logic.
I agree that Digikam (or any other app using this kipi plugin) mustn't remove a folder in KIPIHTMLExport if its name is different from the one being created. I've search in the code and it seems that the problem is in the "removeTargetGalleryFolder" (from the imagesgallery.cpp file) at the following line (in the 0.1-beta2 version): QString MainTPath = m_configDlg->getImageName() + "/KIPIHTMLExport"; I first thought that it will be as simple as adding the name of the gallery at the end of the string MainTPath but I've found that the plugin can export more than one gallery. So, I can not submit a patch because it's becoming a little bit to difficult for me but I hope it can help someone with better skills.
This bug is reported against 'imagesgallery'. This plugin has been replaced by a new plugin called 'HTMLExport', which is written completely from scratch. This bug report will now be closed.
Since that plugin is obsolete, is this still valid?