3.4.0.22 UI inconsistences in email client

+1 I agree with Cryx regarding the new phone swipe. With the old phone swipe + phone in the pocket I had answered calls that I did not want to answer and also the other way around.

Surely, a separate thread for Phone UI would be a more logical approach?

1 Like

Has anyone already an idea how we can get rid of the white background of the html loader page.
Jolla must have really bad UI designers, always these white background pages :-(.
In addition, some mails are not zoomed correctly.

3 Likes

The latest update, 3.4.0.24 is obviously a regression regarding last version. We received a UI change that nobody asked for, which makes the app look like a draft:

  • Inconsistent UI (buttons ? Seriously ?!)
  • Ugly white backgrounds in emails, for the sake of HTML emails (even for text/plain mimetypes!)
  • Regarding HTML emails, they don’t even display correctly (bad zoom, issue when going from portrait to landscape, …)

I really hope Sailfish team is going to patch this and make a release soon, because it looks like they have no idea what they’re doing and are pushing “updates” without even considering their userbase.

The greatest strength of SFOS is to provide a gesture based approach, and nice looking ambiances. This was also their main selling point when I got my first Jolla 1 phone. Now it looks like they’re just trying to be closer and closer to android so they can take a bite in their market share.

7 Likes

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.

1 Like

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

THERE IS NO GARANTY THAT IT WON’T BREAK ANYTHING ! Use at your own risk

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.

10 Likes

@wgs

hidden buttons;

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

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

Not perfect, but does the job.

10 Likes

@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 !

8 Likes

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
UI

1 Like

Pulley Menu & Buttons are now patched:

Openrepos

https://openrepos.net/content/markkyboy/patch-returns-pulley-menu-email-view

Or, direct download;

https://openrepos.net/sites/default/files/packages/1290/sailfishos-patch-email-pulley-menu-0.1-3.noarch.rpm

7 Likes

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:

@edz
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.

1 Like

@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

5 Likes

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

To reduce the duration of the white flash a little bit when opening an email, I modified line 193 in:
/usr/lib/qt5/qml/Sailfish/WebView/WebView.qml
from “color: webview.bgcolor” to "color: “transparent”.

As far as I know, the css file for manipulating html pages can now be found under
/usr/share/jolla-email/chrome/content/content.css.
But the main problem remains that the browser or webview always opens a page with a white background first.
Unfortunately, with my limited abilities, I can’t get any further.

I think maybe, just maybe, the white background is baked into libsailfishwebviewplugin.so (I may have that file name a slightly wrong).

Also, the part of the file you edited it just for transition between portrait and landscape and so won’t affect the white background, hence the id: orientationDelayOverlay - I could be wrong.