UI inconsistences in email client

This has always been the case, if plaintext emails didn’t have a white background you were using a patch.

If that’s the case, then I totally forgot that I did. My point still stands though, as the email viewer doesn’t feel integrated to the overall UI at all. And the change from the pully menu to buttons makes it even worse.

I found a way to bring back the pulley menu in emails.


Edit /usr/share/jolla-email/pages/HtmlViewer.qml Add the following above the “MessageViewFooter” block:

    MessageViewPullDown {
        id: pulley

After that, restart the email application. I don’t know yet how to remove the buttons.



hidden buttons;

    MessageViewFooter {
        id: footer
        visible: false    < --------added here.

        x: landscapeInviteContainer.width
        // Don't move with the keyboard.

Not perfect, but does the job.


@wgs - Hi, i’m curious as to how you discovered the 2 lines of code to bring back the pulley menu?, very cool indeed.

My immediate approach was simply to add the whole pulley menu back, but your code does it in just 2 lines…how?, where?, why? :D…tell me more!

I discovered it by accident really.

I started from your solution to change the footer background color by editing MessageViewFooter.qml. In the folder /usr/share/jolla-email/pages I grep'd "MessageViewFooter, to see what comes up, and found that it’s used as a class in HtmlViewer.qml. I also noticed a file named MessageViewPullDown.qml, which I figured was the class for the pulley menu, rather than footer buttons. As it was not referenced anywhere else, I figured I would just add an empty block to see what happened. That’s all really :slight_smile:.

To be honest, I have no idea why it works haha !


Aaah, that’s much better. Thanks @wgs!

There were a couple UI related topics in today’s community meeting:

Consistency of SFOS UX/UI across apps

1 Like

Pulley Menu & Buttons are now patched:



Or, direct download;



In the latest meeting the subject was touched and jolla devs mentioned it was a change dictated by the new engine used in the email client. And that it would be difficult to patch and that it would create problems.

No idea what is going on with this. :no_mouth:

1 Like

Maybe it was due to this? :smiley:

how hard was it and did you encounter any problems yet?

Sledges also mentioned in the community meeting that text selection within emails might conflict with pull-down. Might be a good idea to check.

If a good fix is found, it would be a good idea to raise this issue again in next community meeting.

@peterleinchen says: How hard was it?
Me: Not hard at all, then made even easier with wgs’s slimline code.

@peterleinchen says: did you encounter any problems yet?
Me: Not as yet, but then i don’t rely on the email client, I use my PC for that.

@Sefriol says: text selection within emails might conflict with pull-down. Might be a good idea to check.
Me: I’ve just checked with both plain and HTML mail, I can copy (and paste contents into a text message, reliably) and pull down the menu. The selected text stays selected while the pulley menu is pulled down completely and clipboard does honour what was copied.
So far, so good.

UPDATE 19/10/2020
Well, one user already spotted a problem with my patch, deleting the mail when in mail view doesn’t delete the mail, so I returned to my original patch contents which fixes this problem in version 0.1-2
Please use version 0.1-2


Some more insight by jpetrell: About redesigning incoming call experience in 3.4.0