Dialogs, KMessage box and job widgets

[Valentin Rusu]

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.

-- 
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)