Hi! I have this same problem and just making the call to QFileDialog::getSaveFileName (I am writing a general Qt program) gives the message as described in Bug 203205 but does also mess with my information structure. As it appears to make data loss I mark this bug as critical (following the guidelines on severity help). I have some QTextEdits open and all of them are emptied when I make the call to QFileDialog::getSaveFileName, which in turn is supposed to (and does) open the native (i.e. KDE) save-file-as dialog. It seems that the problem only occurs first time the dialog is called (nothing is disturbed on second call). The call to getSaveFileName() works fine in MS Windows, and if I use an instance of the QFileDialog instead the problem does not exist. I am currently using Qt 4.5.3 and KDE 4.3.2 on my Gentoo box. I have made a gentoo revdep-rebuild to look into this and I have updated my .la-files using the gentoo lafilefixer. Regards, Erik +++ This bug was initially created as a clone of Bug #203205 +++ Version: (using KDE 4.3.0) OS: Linux Installed from: Ubuntu Packages (7223) findLibraryInternal: plugins should not have a 'lib' prefix: "libkfilemodule.so" (7223) KPluginLoader::load: The plugin "libkfilemodule" doesn't contain a kde_plugin_verification_data structure This bug is present in most Qt programs when you open a OpenFileDialog. Example in Arora.
I didn't understand from your report what data you are losing and what information is being messed. Can you please clarify that?
Hi! In my main window there is a number of rich text editors (QTextEdit objects) dynamically created. It is a note-taking application similar to KDE Basket. This is what happens: * I enter some text into the texteditors (notes) * I make an operation to show the SaveAs dialog (export in my case). The moment the dialog is loaded and the error is printed on my trace, all TextEdit-objects are cleared. The text I wrote is vanished and if content is fetched using getHtml() and empty HTML-document is returned. The applicatin is called Basqet (it is a Pure Qt clone of KDE-Basket) and the project is hosted on google-code: http://code.google.com/p/basqet/ I have created a tag of the revision where I found this problem: tags/kde_bug_210904 ( http://code.google.com/p/basqet/source/browse/#svn/tags/kde_bug_210904 ) Look into file: mainwindow/mainwindow.cpp, method actionExport(), line 235. This is a slot where the file-dialog is shown that triggers the bug. In this version I use the file dialog on 3 places, the main window above in in mainwindow/settings.cpp twice. I have experienced craches after using the file-dialog to chose directories, I did not realize it could be related to this by the time and made no effort to document it (I use pointers, I blame those in first place :) ). Hope this makes things clearer // Erik
I can confirm it here with trunk and Qt's 4.6-stable branch. First of all, let's clarify some things: that warning _is_ harmless and is related to a deprecated way to create plugins for KDE. You seem to use Qt and KDE without debug symbols, so that's all you see when QFileDialog uses the environment's native file dialogs (in this case, KDE's). Digging through the code, it seems to be caused by a stat done by KFileWidget when the dialog is about to be shown -- more specifically, kdelibs/kfile/kfilewidget.cpp in lines 603 and 604 (svn rev 1036880).
I've also stumbled on this problem right after adding a file dialog to a pet application of mine which is written in Qt. I'm running Qt 4.5.2 and KDE 4.3.2.
The problem seems still present. I have the problem that a combobox is set to the first index if I try to open a file. Under Windows the problem doesnt exist. So it seems to be a KDE related problem. I attached a test application. System Gentoo Linux, Qt 4.6.2, KDE 4.3.5
Created attachment 42411 [details] Qt4 application test project
The problem is in the retranslateUi() call of the generated ui_mainwindow.h. For the comboBox in the attached test case (and probably also for the QTextEdit widgets mentioned in comment #2), Qt's uic generates a clear() call before filling the comboBox with new (translated strings). KDE generates the QEvent::LanguageChange event during its initialization of the KLocale object, so that the application is informed of KDE specific changes (date formats, number formats, etc.). If you want to make sure the comboBox does not change its currentIndex caused by the changeEvent, save its current index before calling retranslateUi() and restore it after the call. Please file a wish to Nokia, if you want the generated restranslateUi() function handle that for you.
I removed handling of the re-translate in the problematic widgets and the problem vanished. This will not make any loss in functionality, the widgets only contains user-entered inputs. Fellows, you have made an impressive amount of work! You did not solve the problem but found why and I can now make my part. From my point of view this is a matter of documentation rather than changing anything. You made my day! THANKS! // Erik