Thanks to Daniel Novomeský we will have support for AVIF images in KImageFormats starting in the next release.
We have (and by we I mean him) also added the avif code to be fuzzed under oss-fuzz so we'll be helping the upstream libavif/libaom to find potential memory issues in their code.
https://invent.kde.org/frameworks/kimageformats/-/merge_requests/8
What does that mean?
It means this https://invent.kde.org/graphics/okular/-/commit/3129b642f996589f1c7fcee513741e1993924241
That is, you add JPEG::JPEG to target_link_libraries, and that's it, no need to add the includes, the compile_definitions and whatnot.
This has multiple advantages to the old mode:
JPEG::JPG it will fail at cmake stage
To know if you can use that you'll need to use the cmake help, for example the imported target is described at https://cmake.org/cmake/help/latest/module/FindJPEG.html
Now we don't probably depend on cmake 3.19, do we? So we need to make sure the cmake we say we support has that, so use the combo on the top of that page to go and find which version introduced it, for JPEG we can see it was cmake 3.12
Four years ago I bought a OnePlus 2 for 319€, nowdays it still is good hardware, it's better or as good as most of the mid to low end phones in the market.
But it has a big-ish problem, it is stuck on Android 6, which not only is old and probably full of security holes, it is starting to not be supported by some apps.
Solution: LineageOS.
It provides Android 10 for my phone and works flawlessly (from what i can see, only been using it for 4 days), so the fact that "some randos" (with all my love, I'm a rando) can make it work, means that the manufacturer could have if they wanted, they just chose not to.
It's really sad because if i wasn't a geek that knew how to put LineageOS on the device i would have probably ended up buying a new phone, making the world be fill with more junk.
Let's hope the more open devices like the PinePhone KDE Community Edition put an end to this :)
Make sure you commit anything you want to end up in the 20.12 releases to them
We're already past the dependency freeze.
The Feature Freeze and Beta is this Thursday 12 of November.
More interesting dates
November 26, 2020: 20.12 RC (20.11.90) Tagging and Release
December 3, 2020: 20.12 Tagging
December 10, 2020: 20.12 Release
https://community.kde.org/Schedules/release_service/20.12_Release_Schedule
Cheers,
Albert
Translations are a vital part of software. More technical people often overlook it because they understand English well enough to use the software untranslated, but only 15% of the World understands English, so it's clear we need good translations to make our software more useful to the rest of the world.
Translations are a place that [almost] always needs help, so I would encourage you to me (aacid@kde.org) if you are interested in helping.
Sadly, some of our teams are not very active, so you may find yourself alone, it can be a bit daunting at the beginning, but the rest of us in kde-i18n-doc will help you along the way :)
This is a list of teams sorted by how many translation commits have happened in the last year, more commits doesn't mean better, even teams with lots of commits will probably welcome help, maybe it's not in pure translation but instead in reviewing, you can also check statistics at https://l10n.kde.org/stats/gui/trunk-kf5/team/
More than 250 commits
Azerbaijani
Basque
Brazilian Portuguese
Catalan
Estonian
French
Interlingua
Lithuanian
Dutch
Portuguese
Russian
Slovak
Slovenian
Swedish
Ukrainian
Between 100 and 250 commits
German
Greek
Italian
Norwegian Nynorsk
Spanish
Between 50 and 100 commits
Asturian
Catalan (Valencian)
Czech
Finnish
Hungarian
Indonesian
Korean
Norwegian Bokmal
Polish
Vietnamese
Chinese Traditional
Between 10 and 50 commits
British English
Danish
Galician
Hindi
Icelandic
Japanese
Malayalam
Northern Sami
Panjabi/Punjabi
Romanian
Tajik
Chinese Simplified
Between 0 and 10 commits
Albanian
Belarusian
Latvian
Serbian
Telugu
Turkish
No commits
Afrikaans
Arabic
Armenian
Assamese
Bengali
Bosnian
Bulgarian
Chhattisgarhi
Crimean Tatar
Croatian
Esperanto
Farsi
Frisian
Georgian
Gujarati
Hausa
Hebrew
Irish Gaelic
Kannada
Kashubian
Kazakh
Khmer
Kinyarwanda
Kurdish
Lao
Low Saxon
Luxembourgish
Macedonian
Maithili
Malay
Maltese
Marathi
Nepali
Northern Sotho
Occitan
Oriya
Pashto
Scottish Gaelic
Sinhala
Tamil
Tatar
Thai
Tswana
Upper Sorbian
Uyghur
Uzbek
Venda
Walloon
Welsh
Xhosa
P.S: Please don't mention web base translation workflows as comments to this blog, it's not the place to discuss that.
This year Akademy-es is a bit special since it is happening in the Internet so you don't need to travel to Spain to participate.
If you're interested in giving a talk please visit https://www.kde-espana.org/akademy-es-2020/presenta-tu-charla for more info.
It is available at the usual place https://community.kde.org/Schedules/release_service/20.12_Release_Schedule
Dependency freeze is in four weeks (November 5) and Feature Freeze a week after that, make sure you start finishing your stuff!
After my recent failure of gaining traction to get people to join a potential Okular Virtual Sprint i wondered, is the okular-devel mailing list representative of the current okular contributors?
Looking at the sheer number of subscribers one would think that probably. There's currently 128 people subscribed to the okular-devel mailing list, and we definitely don't have that many contributors, so it would seem the mailing list is a good place to reach all the contributors, but let's look at the actual numbers.
Okular git repo has had 46 people contributing code[*] in the last year.
Only 17% of those are subscribed to the okular-devel mailing list.
If we count commits instead of commiters, the number raises to 65% but that's just because I account for more than 50% of the commits, if you remove myself from the equation the number drops to 28%.
If we don't count people that only commited once (thinking that they may not be really interested in the project), the number is still at only 25% of commiters and 30% of commits (ignoring me again) subscribed to the mailing list.
So it would seem that the answer is leaning towards "no, i can't use okular-devel to contact the okular developers".
But if not the mailing list? What am i supposed to use? I don't see any other method that would be better.
Suggestions welcome!
[*] Yes I'm limiting contributors to git commiters at this point, it's the only thing i can easily count, i understand there's more contributions than code contributions
Head to https://linuxappsummit.org/cfp/ and talk about all those nice [Linux] Apps you're working on!
Call for paper ends in 3 days (September 15th)
