----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102188/#review5475 -----------------------------------------------------------
Ship it! fileModule() creates a componentData indirectly, because it loads a plugin, right? This makes me wonder if we shouldn't create a componentData in kfiledialog.cpp instead, to make this more robust long term (what if the file module wasn't a plugin). OTOH in the long term I hope we can remove these requirements for a componentdata... Anyway, feel free to commit. - David On Aug. 2, 2011, 8:42 p.m., Albert Astals Cid wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102188/ > ----------------------------------------------------------- > > (Updated Aug. 2, 2011, 8:42 p.m.) > > > Review request for kdelibs and David Faure. > > > Summary > ------- > > Pure Qt applications get KDE dialogs through the various > KFileDialogQtOverride members, these functions instantiate a KFileDialog that > inherits from KDialog so on KFileDialog construction we end up in > KDialogPrivate::init that calls KDialog::setButtons that uses > KStandardGuiItem::ok() that has a i18n call. Since there is no valid main > component at this stage yet once we get to the fileModule() call and it > creates a proper main component we will get the KGlobal::locale warning. > > By invoking fileModule() before creating the KFileDialog we avoid this issue. > > > Diffs > ----- > > kio/kfile/kfiledialog.cpp 4195a68 > > Diff: http://git.reviewboard.kde.org/r/102188/diff > > > Testing > ------- > > Warning is gone > > > Thanks, > > Albert > >
