Dialogs, KMessage box and job widgets

[Albert Astals Cid]

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 <kde at rusu.info
> >>> 
> >>> <mailto:kde at 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