El Dijous, 15 de novembre de 2012, a les 20:51:30, Valentin Rusu va escriure: > On 11/15/2012 08:28 PM, Albert Astals Cid wrote: > > El Dijous, 15 de novembre de 2012, a les 19:59:54, Valentin Rusu va escriure: > >> On 11/15/2012 02:51 AM, Aleix Pol wrote: > >>> On Wed, Nov 14, 2012 at 8:37 PM, Valentin Rusu <k...@rusu.info > >>> > >>> <mailto:k...@rusu.info>> wrote: > >>> According to the epics page, kdeui/dialogs will go to tier3. > >>> On the other hand, kdeui/jobs will go to tier2, only the class > >>> KDialogJobUiDelegate is actually using KMessageBox. > >>> If KMessageBox will stay in "dialogs", then tier2 jobs will need > >>> to call tier3. I suppose that's not the desired situation. > >>> > >>> What would be the best solution in order to follow the defined > >>> policies? Where should KMessageBox > >>> go?<https://mail.kde.org/mailman/listinfo/kde-frameworks-devel> > >>> > >>> Maybe we can port from KMessageBox to QMessageBox? > >> > >> Well, I think I'll port it to QT then. I suppose it should go the the > >> inqt5 library in this case. > > > > Are we really losing all the integration? > > > > What's the point of having KMessageBox if we don't use it? If we are > > starting to use QMessageBox everywhere at least we could try to see what > > we can upstream to QMessabeBox? > > Well, that's what I mean - port interesting features to QMessageBox as > I'm surely not interested in losing the KMessageBox features. My fault > not stating more clearly: "well, I think I'll port KMessageBox features > to QMessageBox" - actually that's the trend with some other classes from > KDE.
Ahh, good then :-) Cheers, Albert _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel