Hey folks, I'd like to get a conversation going on an implementation approach and get this progressing.
Just for reference this was Giulio's initial attempt https://git.reviewboard.kde.org/r/118030/ I agree with Jan that adding an additional submission manager class that basically is a wrapper around Submission, that enables it to be initialized with the settings from SmtpAccountSettings (Now MSA::Account) is probably not the way to go here. Ideally we should be finding a suitable way that we can use the relevant MSA API's in the same way for both the desktopgui and qml UI's. As we shouldn't be making these changes just to suite Ubuntu but keep in mind that this would lay the groundwork to add additional front ends, say for Android/iOS/Sailfish etc if the opportunity arrives (and Jan feels up to it :-D ). I had an initial idea on how to do this, but I hit a few road blocks when trying to have a quick go at it. So I want to see if it is worth making changes to what I hit or whether I am way off track and it's a non starter. Basically, I personally would 'like' to use the MSA parts directly from qml so it would mean registering Submission, MSAFactory, SMTPFactory, SendmailFactory etc as qml types I.e qmlRegisterType<Submission>(); qmlRegisterType<MSAFactory>(); And be able to use these types in the same way as how the desktop gui currently handles MSA and create a submission object on each new mail composition As a quick simple example from the qml side say only for Smtp submission, in ComposePage.qml it would look something like this property Submission submission property MSAFactory msaFactory Component { id: submissionComponent Submission {} } Component { id: smtpFactoryComponent SMTPFactory {} } Component.onCompleted: setupConnection() function setupConnection() { // here we now setup the connection in the same kind of way as the desktop var subMethod = smtpAccountSettings.msaSubmissionMethod switch (subMethod) { case MSAAccount.SMTP: case MSAAccount.SSMTP: case MSAAccount.SMTP_STARTTLS: // create a new SMTPFactory object initialized with our settings msaFactory = smtpFactoryComponent.createObject(smtpAccountSettings.server, smtpAccountSettings.port, subMethod == MSAAccount.SSMTP, subMethod == MSAAccount.SMTP_STARTTLS, smtpAccountSettings.authenticateEnabled, smtpAccountSettings.username ) break case MSAAccount.SENDAMAIL: case MSAAccount.IMAP_SENDMAIL: break // now create our submission object submission = submissionComponent.createObject(0, imapAccess.imapModel, msaFactory) } function buildMessage() { // generate message from UI here } function sendMessage() { buildMessage() // set options stored in smtpAccountSettings submission.setImapOptions() submission.setSmtpOptions() submission.send() } Although this makes the use of the API's in the same kind of way as the desktop gui, obviously you can probably already tell where I hit problems with this approach. Mainly the need to overload the factory constructors and be QObject derived in order to register them as qml types, since when registering them we will have nothing to initialize them with. And the big issue is the virtual inheritance of the MSA factories doesn't work with QObject and from what i've read it's not even supported. :-/ (hence my thoughts on it being a non starter) I haven't invested much time into looking at how much work would be needed to change the current MSA implementation to make this approach possible, Jan your probably the best person to say off the top of your head if it's a significant amount or not. I'm merely just proposing a possible approach to investigate in order to have a consistent approach from either the desktop gui or qml ui's and try and avoid creating wrappers/additional classes just to support one specific frontend. Anyway that's enough for now and conversation started :-) Cheers folks Dan
