Unbug request: mailUA evaluation

[noseshimself]

Priority low.

I was wondering why mailUA = xdg-open was not working as expected (neither was mailUA = open) and found this

   if( KraftSettings::self()->mailUA().startsWith("xdg") ) {
        args.append( "--utf8");
        args.append( "--attach");
        args.append(fileName);
        if( !mailReceiver.isEmpty() ) {
            args.append( mailReceiver);
        }
        prog = QLatin1String("/usr/bin/xdg-email");
    } else {
        // Fallback to thunderbird

in portal.cpp. Would it be possible to use the contents of mailUA as the external program plus parameters to be called for sending mail?

In the case of ChromeOS it might be advisable to let the system's xdg-url handler take care of it which is not using xdg-email to get things done in order to avoid setting up yet another mail environment. Chrome might be complicating things in another unexpected way: The MUA might not be GMail/Chrome but any available PWA-like tool (including NextCloud Mail or NerxtCloud/Rainloop turned into PWAs) or even Android applications like K9 (the future Thunderbird/Android) or 9Mail (highly recommended as it is not storing your credentials on the manufacturer's servers). These programs have no common file storage and need to be handled differently.

Instead of calling the MUA directly I would vastly prefer calling an external shell script with all required (or known) parameters (recommended subject (e. g. Document ID and if there is one, project name, attachment name(s) and optionally recipient name(s)) and letting the flies handle the job.

[dragotin]

If you want to use a script to call the mail UA, wouldn't it be an option to hack yourself a script called xdg-email that uses the same parameters as the original Linux tool?

Actually the orginal xdg-email is a shell script. Maybe it is easily adoptable?

[noseshimself]

If you want to use a script to call the mail UA, wouldn't it be an option to hack yourself a script called xdg-email that uses the same parameters as the original Linux tool?

I am very careful regarding changes to xdg components because there is no real X Desktop Environment in the containers. Things may (and do) change radically between updates. And as xdg is a part of the OS provided by the hardware vendor local changes can and will be reverted. Even changing default actions in ChromeOS may influence the Linux environment (it is intended to be that way).

By using xdg-open the ChromeOS is free to choose anything on his system that can send mail (Android tools, ChromeOS "applications" or even a Linux tool inside another container. But the different mechanisms might not have access to (all of) each others' files so sending files from a Linux application might need some copying as preparation.