Release Version 3.0.3 for Plasma 6

[blackadderkate]

An updated version of the Weather Widget for KDE Plasma 6.

Major Bugs/Features/Issues to be sorted

1. You can no longer access local FILE:/// urls using XMLHttpRequest. This breaks the MetNo Search. Two possible fixes:

   • host on a free web host - the downside is limited bandwidth allowances...
   • set QML_XHR_ALLOW_FILE_READ=1 - less secure and requires manual hacking by users

2. Lots of "Attribute value not found" error messages in .xsession-errors using Openweathermap sources (due to their API omitting rain data if none is expected).

As far as I am aware, this is pretty stable now and apart from the two issues above I have fixed all the major bugs. Unless someone finds a serious bug this week, I am aiming to release on the KDE store during the Easter weekend.

---

This discussion was created from the release Release Version 3.0.0 for Plasma 6.

[martin-ms]

I don't know if I'm the only one, but in the current version when I open the setup dialog and want to search for a location, the view is like this:

This is what it looked like in Beta 2:

What has been changed between the versions? I can no longer recognize or select a location.

[blackadderkate]

Oops, Slip of the keyboard.
I accidentally removed a line in commit 6127c89.

Should be fixed in this version.

[martin-ms]

The given link is dead, should be https://github.com/blackadderkate/weather-widget-2/releases/download/V3.0.1/weather-widget-3.0.1.plasmoid

[blackadderkate]

Fixed that link.
I'm going to log off for the day as my brain has clearly stopped working properly. 🥴

[martin-ms]

All good ;) I can confirm that the display works again in version 3.0.1.

But... can you please describe to us what exactly the function of the "OK" button (1) in the "Location Search" dialog is in connection with the "metno" search? If I have found a city and marked it in the list and then press "OK", the dialog closes without the city being adopted. The function is practically the same as the "Cancel" button. In order to adopt a city, I first have to double-click on the entry in the list, then a "Confirmation" dialog opens and only when I confirm the selection here (2) is the city adopted and both windows of the "Location Search" closed; here too, the “OK” button has no meaning.

I would have expected that after selecting a city in the list and pressing "OK", the city would be adopted. It is particularly unintuitive for a new user, as there is no indication that they need to double-click on a city's entry in order to adopt it.

Furthermore, I noticed that if the weather is only displayed for one city and expanded to include additional cities, the link to switch to the next or previous city is invisible in the display. The mouse pointer switches to a hand when you move over the (known) display in that area, but it only becomes visible once you click on it. An inexperienced user will not know this and will look for a way to display the other cities. It's OK that the links are invisible if there is only one city, but if additional cities have been configured, the links should be visible from the second city onwards.

[blackadderkate]

To be honest, I think I just copy-pasted the double-click code into the single-click handler during development and never got around to tweaking it's behaviour.
Should be a relatively simple fix when I get back to my computer...

And I was literally adding extra code to properly handle adding/removing places yesterday - making the links visible should also be a simple fix now I have the basic framework in place.

[cyqsimon]

Hi and thanks for the good work. I noticed that in the latest commit (bc7e20f, installed via AUR), the temperature and weather icon are incorrectly overlapping in horizontal layout:

You might want to take a look.

[blackadderkate]

Spent most of yesterday working on this.
Trying to write something that works as a desktop widget, in both horizontal and vertical panels, and in the system tray - and switches flawlessly between horizontal, vertical and compact mode - has had me tearing my hair out!

As a short term fix, you can simply reduce the font size in the widget settings (in the appearance pane).

[cyqsimon]

Spent most of yesterday working on this.
Trying to write something that works as a desktop widget, in both horizontal and vertical panels, and in the system tray - and switches flawlessly between horizontal, vertical and compact mode - has had me tearing my hair out!

I get it. UI is hard 😮‍💨

As a short term fix, you can simply reduce the font size in the widget settings (in the appearance pane).

Yep I tried that. But it seems like the situation only starts to improve when I set the font size to below 12, which is too small to be usable on my 4K laptop screen. I guess I'll revert back to an earlier commit for now.

[blackadderkate]

Easter has proved busier than I planned, so it's taken longer than expected but hopefully build 3.0.2 will fix the issue for you.

[blackadderkate]

Released v 3.0.3 with fixes for:

• MetNo timezones should now work properly with Daylight Savings Time (I hope).
• Improved algorithm for Horizontal/Vertical/Compact layouts.
• You can now Single-Click a Location and click OK to add a new location in MetNo Search .

[martin-ms]

#!/bin/sh
export QML_XHR_ALLOW_FILE_READ=1

Thank you, works as expected

cache it locally in a SQL database

Prepared something for you ;)

[martin-ms]

Hi Kate, I have prepared a sqlite3 database for you. Since I can't attach binary files here, I made it available for download in a cloud:
https://c.gmx.net/@327748706747023899/hiuzWNduSE2ISxoKUWMIYg

Since sqlite3 is a dependency of QT (at least for me), it should be available on every KDE system. This is what the database schema looks like:

CREATE TABLE IF NOT EXISTS "Countries" (
        "shortCode"     TEXT,
        "displayName"   TEXT,
        PRIMARY KEY("shortCode")
);
CREATE TABLE IF NOT EXISTS "tzData" (
        "displayName"   TEXT,
        "id"    INTEGER,
        PRIMARY KEY("id")
);
CREATE TABLE IF NOT EXISTS "Locations" (
        "shortCode"     TEXT,
        "Area"  TEXT,
        "Location"      TEXT,
        "Latitude"      TEXT,
        "Longitude"     TEXT,
        "Altitude"      TEXT,
        "timezoneId"    TEXT
);

There are now 198,311 records in the "Locations" table. The XK.csv file differs from the format of the other files and therefore could not be imported.

Here are some examples of how to access the tables:
List all countries
SELECT displayName FROM Countries ;

List all locations from GB
SELECT * FROM Locations WHERE shortCode = 'GB' ;

Retrieve data for Leicester as used
SELECT * FROM Locations WHERE shortCode = 'GB' AND Location = 'Leicester';

Working full example when called from the command line: $COUNTRY is set to the selected item from the drop-down list. Set $CITY as the user entered it and change the separator to a comma. You can use the % sign to control the match for the beginning or part of the search, or without it must be an exact match.

COUNTRY="United Kingdom"
CITY="Leic"
sqlite3 --separator "," placesearch.db "SELECT Location, Area, Latitude, Longitude, Altitude, tzData.displayName  FROM Locations INNER JOIN tzData, Countries ON Countries.shortCode = Locations.shortCode WHERE id = timezoneID AND Location LIKE '$CITY%' AND Countries.displayName = '$COUNTRY';"

[evgeniy-harchenko]

Could you please explain to me for what you are going to use database? Why CVS is bad? Does the problem lie only in XMLHttpRequest?

[martin-ms]

Databases are structured in contrast to CSV, access is faster and easier, and if they are stored locally there is no need for an online connection to a service provider such as webhostapp. As mentioned, the download limit could also become a problem if half the world tries to set up their locations in the widget via search after publication.

[evgeniy-harchenko]

As for CSVs offline reading, we can store and read them locally: evgeniy-harchenko@5ed1cf6 (as temporary solution).

[blackadderkate]

V3.0.4 has just been uploaded.

The layout code has been completely rewritten by @evgeniy-harchenko and hopefully works the way it's supposed to now...
The "Last Reloaded" text no longer wraps onto multiple lines, and can be disabled altogether in the Configuration settings.

[jotapesse]

Hi! Something is not right and it doesn't work well for me:

• Previously I could add the weather widget via the UI: Panel (right click) > Add Widgets... > Get New Widgets > Install Widget from Local File... > <path_to_file> - this no longer works with the weather-widget-3.0.4.plasmoid file - it fails with an error. Screenshot:

• I did try and I was able to add it via the command line with:

$ kpackagetool6 -i Downloads/weather-widget-3.0.4.plasmoid 
Successfully installed /home/joao/.local/share/kpackage/generic/org.kde.weatherWidget-3/

• However, I can run it but I still get the exact same issues as before - regarding the compact layout and its smaller weather icon size and the "updated Xm ago" text note wrapped over 2 lines. Also the "about" page on the widget still shows version: 3.0.3. Screenshot:

• Trying to list the installed widgets with the command line shows:

$ kpackagetool6 -l
Listing KPackageType: KPackage/Generic in /home/joao/.local/share/kpackage/generic/
KPackageStructure of KPluginMetaData(pluginId:"org.kde.weatherWidget-3", fileName: "/home/joao/.local/share/kpackage/generic/org.kde.weatherWidget-3/metadata.json") does not match requested format "KPackage/Generic"

Perhaps the weather-widget-3.0.4.plasmoid file is not well constructed in some way? Or am I doing anything wrong?

[evgeniy-harchenko]

@jotapesse , you should use kpackagetool6 with this parameter: -t Plasma/Applet. So, in your case it looks like: kpackagetool6 -i Downloads/weather-widget-3.0.4.plasmoid -t Plasma/Applet

As for installing through Install Widget from Local File. You can go to ~/.local/share/plasma/plasmoids/ and remove manually previous version of the widget. After that you can try to install it again.

Also, don't forget to remove this: /home/joao/.local/share/kpackage/generic/org.kde.weatherWidget-3. It is wrong place for widgets.

[jotapesse]

@evgeniy-harchenko Thank you for the hint. I guess that the previous 3.0.3 version persisted for some reason and it didn't allow the 3.0.4 to install properly. I eventually resolved it by manually removing the org.kde.weatherWidget-3 install directory:

$ kpackagetool6 -i Downloads/weather-widget-3.0.4.plasmoid -t Plasma/Applet
Error: Installation of /home/joao/Downloads/weather-widget-3.0.4.plasmoid failed: /home/joao/.local/share/plasma/plasmoids/org.kde.weatherWidget-3 already exists

$ rm -R .local/share/plasma/plasmoids/org.kde.weatherWidget-3

$ kpackagetool6 -i Downloads/weather-widget-3.0.4.plasmoid -t Plasma/Applet
Successfully installed /home/joao/.local/share/plasma/plasmoids/org.kde.weatherWidget-3/

$ kpackagetool6 -l
Listing KPackageType: KPackage/Generic in /home/joao/.local/share/kpackage/generic/
KPackageStructure of KPluginMetaData(pluginId:"org.kde.weatherWidget-3", fileName: "/home/joao/.local/share/kpackage/generic/org.kde.weatherWidget-3/metadata.json") does not match requested format "KPackage/Generic"

By the way, following the manual removal of the .local/share/plasma/plasmoids/org.kde.weatherWidget-3 directory, I was then also able to install the 3.0.4 version via the UI: Panel (right click) > Add Widgets... > Get New Widgets > Install Widget from Local File... > <path_to_file>. Please do note that previously I did try to remove it also via the UI and restarted the plasmashell (instance replaced). So, not sure why it failed to install via the UI in the first place but I now understand that my install via the command line was not properly executed and installed it with the wrong type and consequently on the wrong location.

$ rm -R .local/share/kpackage/generic/org.kde.weatherWidget-3

[blackadderkate]

I had this issue myself during the early development phase.
I thought it was because the version number in the plasmoid hadn't changed - but maybe there's a bug in the update procedure. It's also possible omitting the -t Plasma/Applet parameter meant there were two installations interfering with each other.
I also remember someone reporting the install timed out on a very slow virtual machine...

Silly question (not on computer right now) isn't there a -u parameter for upgrades? Or is that just kpackagetool5?

[evgeniy-harchenko]

Yes, kpackagetool6 has -u parameter too.

[blackadderkate]

@jotapesse , you should use kpackagetool6 with this parameter: -t Plasma/Applet. So, in your case it looks like: kpackagetool6 -i Downloads/weather-widget-3.0.4.plasmoid -t Plasma/Applet

As for installing through Install Widget from Local File. You can go to ~/.local/share/plasma/plasmoids/ and remove manually previous version of the widget. After that you can try to install it again.

Also, don't forget to remove this: /home/joao/.local/share/kpackage/generic/org.kde.weatherWidget-3. It is wrong place for widgets.

Another thing to add to the TODO: update the installation instructions for Plasma6. 😒

[tankersss]

I installed and configured version 3.0.4, when I just hover over it it shows correctly the city I configured.

But when I open the panel and hover over it shows incorrect name (correct data).

Also is there a configuration box to not show on hover when clicked?