Meecast / meecast

MeeCast - multiplatform highly customizable open source weather forecast client based on OMWeather code. Copyright (C) 2006-2024
https://meecast.org/
GNU Lesser General Public License v2.1
30 stars 18 forks source link

[Suggestion] Optimise layout of MeeCast's Event-View #75

Open FingusDE opened 1 week ago

FingusDE commented 1 week ago

Missing Column in Event-View on Jolla C2, Jolla Tablet, Redmi 5 Plus

bd9fcef7eabc9d25874fbc973c8b7be91328d365

My suggestion is to stretch it to full width or add another day as column to it. The same for the Landscape-Display.

Olf0 commented 1 week ago

@FingusDE, thank you very much for filing this issue here. I categorised this as a suggestion, because it aims at beautifying the look, but everything is already fully functional.

As already denoted, IMO there is no space left for another icon (mind, that some empty space to the right screen border must be kept): The number of icons is currently 4 in portrait and 8 in landscape orientation, as you can easily see when you turn your device from portrait to landscape orientation.

To stretch this row of icons should be technically possible (with QML / Qt), but this is an "expensive" operation, i.e. it is slow and battery consuming.

IMO the elements of MeeCast's Event-View should be arranged as follows to look better:

  1. Create a centred column with equal margins (free space) to the left and right, and the necessary margins to the top and below (the latter may be 0, IDK).
  2. Place the icon displaying the current weather in the top left corner (i.e. left- and top-aligned, with no extra margin) of this column.
  3. Place the location (here: Havixbeck) centred in the column, with no or very little margin at its top. Use the same text element for the textual representation of the current weather (here: Bedeckt) in a smaller font size (the current one is fine, IMO) and separated by a line break (it is likely already implemented this way).
  4. Centre the row of weather forecast icons in the box, with a little margin at its top. IMO, currently there is slightly too little margin between the textual representation of the current weather and the icon-row (which is more pronounced in my screenshots below). Maybe this can be implemented as part of the element described in 3.
  5. Right-align the status message for the last poll time: IMO there is nothing to do, it currently looks excellent. But I wonder, why the left and right margin (of the column) seem to differ: The right margin appears to be almost double as wide as the left margin.

Side note: I wrote down these considerations before looking at the QML code: Many aspects are already implemented this way, and my considerations are better adapted to the current code-base than the other way around. Main point of my considerations is: This is how I imagine a better look, I do not care how this is achieved.

Other ideas for optimising the layout of MeeCast's Event-View are welcome, even more so a Pull Request which performs these optimisations. The corresponding QML code is here: sailfishos/meecast/event-components/WeatherBanner.qml

P.S.: Screenshots of the current look of MeeCast's Event-View v1.11.7 on an Sony Xperia X with SailfishOS 3.2.1:

pagism commented 1 week ago

The old Jolla weather app was displaying 5 icons in portrait mode. Personally I think 5 icons makes more sense than 4, especially when on the right there is a noticeable gap. Also in horizontal view I would prefer to have 7 (week) instead of 8. Maybe having the size of icons smaller will fit a 5th icon?

In addition on 10iii the font size of the first line of the weather location does not match the rest of the event screen especially when the date is also displayed at the top.

Olf0 commented 1 week ago

Maybe having the size of icons smaller will fit a 5th icon?

It sure would, but I have not seen vector graphic sources (e.g. in SVG format) of these icons (maybe I missed them). Scaling bitmap icons (e.g. PNG format) results in either ugly or blurred results (no matter if they are already scaled embedded in MeeCast or if MeeCast lets Qt scale them).

But that is a different topic than rectifying the visual layout of MeeCast's Eventview: Making the left and right borders equally large, plus centring the city name, textual weather indicator and the icon row.

Also in horizontal view I would prefer to have 7 (week) instead of 8.

I do not concur, I want as many as possible with a given icon size.

pagism commented 6 days ago

I am not a GUI expert, the jolla weather app event view layout is good and simple imo.

The top line is centered, symbol size and location fonts are larger than other text lines around.

Then for the second line it looks like each day-cell is split vertically to 4 rows, i.e. day, temp max, symbol, temp min. This allows to reduce the width of that cell to the icon size only. It does not have a fixed number of days, depending or screen resolution/scale, it can range from 4-6, and I guess on landscape will fit as many days as that horizontal space allows.

I do not know much about the icon graphics, but I get the impression that some of those sets have too much detail that might not help with scaling.

Olf0 commented 5 days ago

I am not a GUI expert, the jolla weather app event view layout is good and simple imo.

965f3f3850a6973f6f8800166d258e6fa86f0a94_jolla-weather-app

This is definitely looking good. (Side note: I never used Foreca's proprietary weather app due to privacy; AFAIR it transmits the device's location to Foreca, Foreca is the only weather data provider available and Foreca's forcast data is in my experience less reliable than weather.com.) But as MeeCast has only a single maintainer who has very little time (I am merely supporting him with infrastructure work), any major redesign is out of scope, unless someone (you?) contributes it.

Hence, lets us focus on slightly rearranging the extant icons and look (which I actually like a bit better than Foreca's), so it does not look awkward any longer. Even that might require a contribution, as I do not have any time for that this year and I doubt @vasvlad can spare any either for this; ultimately it is just a beautification, the functionality is there (i.e. nothing is broken: it is a feature-request, not a bug).

panositi commented 5 days ago

@Olf0 yes it's an improvement not a bug. I have no experience in QML but I will give it a try when I get more time to setup the dev environment and will let you know.

Olf0 commented 5 days ago

I have no experience in QML but I will give it a try when I get more time to setup the dev environment and will let you know.

The nice and convenient thing about QML / QtQuick is that it is just JavaScript using Qt functions, and the excellent documentation by the Qt company and also third parties.

The inconvenient thing about QML is that it is JavaScript using Qt functions, for me: I hate to code in JavaScript, never became accustomed to it and I am not proficient in using Qt.

pagism commented 4 days ago

I am almost ignorant in QML and I never liked javaScript either lol. Anyway, it's really slow trial and error process here. I managed to fix the top line, the second one is more complicated as requires a very fine placement and alignment of items which I do not understand yet.

The reason we have that gap on the right is that alignment starts from left and for portrait and landscape mode the number of days is fixed to 4 and 8 respectively. For higher resolution screens (?) that is not enough to fill the entire line hence the gap.

Olf0 commented 4 days ago

I am almost ignorant in QML and I never liked javaScript either lol. Anyway, it's really slow trial and error process here. I managed to fix the top line, the second one is more complicated as requires a very fine placement and alignment of items which I do not understand yet.

I feel with you: That reflects exactly my experiences with QML. It should be "so easy" (maybe it is for web-page programmers accustomed to JavaScript), the Qt documentation is really well done, but I always struggle hard. Some "quick wins" are indeed easy to achieve, but in order to obtain a QML page layout as I imagined it, I ultimately struggle.

The reason we have that gap on the right is that alignment starts from left and for portrait and landscape mode the number of days is fixed to 4 and 8 respectively. For higher resolution screens (?) that is not enough to fill the entire line hence the gap.

Yes, exactly. I always wondered if this effect is really (or "really only") dependent on the screen-resolution, especially as QML should (just as HTML) be resolution-independent.

Hence I believe it is a wrong approach trying to adjust the layout depending on the screen resolution. Thus my suggestion to keep it simple and just centre the row with the (4 or 8) weather forecast icons horizontally in order to rectify the look.

vasvlad commented 4 days ago

Hi. I'm glad to see this discussion. My code (QML-part) for Event-View is not optimal (and most likely ugly). I coded it very quickly when Jolla had only one device(and one display resolution) I hope I'll find time to refactor it. @pagism please send patch or pull request of your current work.

pagism commented 2 days ago

I am struggling with the second line margins, slow process on that, I will send you my patch once it looks ok.

Is three anyway to find out whats in silica.weather lib tho? That would be useful, silica seems to provide customised blocks for weather apps including icons too, but it's hard to find more on that.

Olf0 commented 2 days ago

I am struggling with the second line margins, slow process on that, I will send you my patch once it looks ok.

Take your time, it has been like this for a decade. Hence, even if you pause and finish this next year, it will have been a quick action. :smiley:

Is three anyway to find out whats in silica.weather lib tho? That would be useful, silica seems to provide customised blocks for weather apps including icons too, but it's hard to find more on that.

Foreca Weather is proprietary software from Foreca, licensed by Jolla (as Jolla's Weather app), and IIRC Silica is proprietary software from Jolla. But if any of the parts relevant for your task are written in QML, we can take a look at them. I have some phones with old SailfishOS releases (Jolla1@SFOS2.2.1, XperiaX@SFOS3.2.1) around, if you can provide me with paths where to look, I can share the relevant code lines in a Gist at GitHub this weekend.

Olf0 commented 2 days ago

BTW, I found some interesting documentation for Silica in the WWW, but on first sight nothing addresses these page-layout issues.

But when searching for them you can find many postings on e.g. stackexchange.com etc. where people discuss their issues in achieving a specific page-layout in QML.

pagism commented 1 day ago

Thanks, I've seen some of the links, I will try to centre the second line and then start thinking about more improvements. With current format I do not think it can accommodate more than 4 days on the second line. On C2 there is horizontal space for 5 days.

The original Weather app has more optimisations, like updates on screen unlock, or visiting the events page, etc.

Olf0 commented 1 day ago

I will try to centre the second line

Please take a break when you have achieved that, and submit your achievements by a PR, because (as you stated to already have achieved a better layout of the first line) that should fully rectify the distorted looking, current layout.

and then start thinking about more improvements.

Sure, one can always pose another PR. Though it might make sense to discuss specific changes here to obtain a second, third etc., opinion, before implementing them.

Actually I would appreciate much, when you accompany your PR with a screenshot how it looks on your device (naming device and OS release) in a second comment for that PR (mind that the first comment of a PR will be used as commit details message when the PR is being merged).

With current format I do not think it can accommodate more than 4 days on the second line. On C2 there is horizontal space for 5 days.

I am not sure about this impression from the screenshots above: While it looks so on first sight, there may be a few pixels less space than required for an additional icon (fifth / ninth) while maintaining the current horizontal margins to the left and right. When looking at my Xperia X screenshots, I am quite sure that there is no space for a fifth icon in portrait orientation, but it looks like there is plenty of space for an ninth icon in landscape orientation; but I have no idea how it is rendered on other devices.

Hence, as stated: Things should not (I am actually inclined to state "must not") be optimised for a specific device or screen resolution. Mind that MeeCast still fully supports a Jolla1@SFOS3.4.0, even older SailfishOS releases, AuroraOS and all devices these two OSes run on, including community ports (many of which are stuck on older SailfishOS releaseas, as the Jolla 1 is): I will strongly oppose anything which may break this feat, and I am deliberately using "may", because nobody can possibly test all these combinations. OTOH, all use the long outdated Qt 5.6, so this is a common denominator.

Also as already stated: Please let Qt take care of correct rendering, do not try to override it (just as with classic, static, CSS-less HTML pages). Any hyper-optimisation will likely fail grossly on some device or some SailfishOS / AuroraOS release (including future ones). Thus hyper-optimisations almost always result in a large maintenance burden, due to the corresponding code becoming complex and fragile.

The original Weather app has more optimisations, like updates on screen unlock, or visiting the events page, etc.

Oh, that is completely new territory: Nice to have, but implementing this might be hard, tedious and frustrating.


P.S.: While in QML one usually anchors elements further down in a column on (width, position etc.) of a element further up in a column or on an element one level up, I remember that one can reverse that (but it is tricky in syntax, semantics and limitations), i.e. anchor a higher (level) element on what QML/Qt has chosen for a lower element. E.g. one should be able to render the icon row as centred and then anchor other elements on the left or right border Qt has chosen for the icon row; here it might make sense to anchor the "weather now" icon in the first row to the left border of the icon row and the "Last updated:"-line to the right border of it.

pagism commented 10 hours ago

meecast

Here is a preview of my changes, horizontal spaces seem to be fixed now, I managed to fit 7 days on C2 but on xperias that should be reduced to 5 days.

I tried to resemble the Jolla weather display, but mainly it's my preferable weather view, it can be adapt it if necessary, I do not have strong opinions on that.

There are several things that need to be fixed:

PS I tried to create a branch for this issue but I am not sure I have enough permissions to do so.

Olf0 commented 8 hours ago

[…]

Here is a preview of my changes, horizontal spaces seem to be fixed now,

This is looking really good, thank you! But I see that you already went far beyond fixing the (formerly off) horizontal alignment(s). Though I am repeating myself: Please do let us finish this first, without addressing any other improvements.

Things I notice:

I managed to fit 7 days on C2 but on xperias that should be reduced to 5 days.

Be assured I will also test on a Jolla 1, just to take as many devices into account as possible. We will see, how many icons can be practically used on all devices, I would assume 6 in portrait an 12 in landscape orientation.

I tried to resemble the Jolla weather display, but mainly it's my preferable weather view, it can be adapt it if necessary, I do not have strong opinions on that.

Me neither, but I do prefer basic layout of the icons MeeCast currently has, because that is what I looked at every day for more than 10 years. But as rearranging the temperature values was crucial to display more icons in the forecast row, this is fine; as this breaks the original style, mimicking the style of Jolla / Foreca Weather makes sense.

There are several things that need to be fixed:

No, definitely not in your upcoming PR: Please don't, defer researching and implementing these points to later and hence another PR.

  • the top line should display hourly temperature, which I do not know how to get it from the app
  • the number of days fit in the 2nd line should be adjusted automatically, the key element here is to work out how many days will fit in the row.
  • the row elements for days are statically coded, that should be converted to a ListView like

While the three points above should be addressed in later PR(s), IMO the next one should not:

  • the update mechanism needs revisiting, the Jolla weather QML code seems to update on several events including turn on the screen, etc.

IMO that is superfluous or even bad:

* ideally would be nice to include a graph for day temperatures (optional)

Another completely different topic, another separate PR when you get to that. May I suggest to implement this as a separate element, which also becomes embedded in MeeCast proper.

* the icon set does not have the same height for all icons, personally i would prefer to use the existing silica weather icon set, but that might require changes to the actual app code.

No way:

PS I tried to create a branch for this issue but I am not sure I have enough permissions to do so.

You can always create a branch in your clone of this repository (either at GitHub or locally) and pose a PR to origin:master from that.