Okular: Should continuous view be an okular setting or a document setting?

In Okular:

 

Some settings are okular wide, if you change them, they will be changed in all the future okular instances, an easy example is if you change the shortcut for saving from Ctrl+S to Ctrl+Shift+E. 

 

Some other settings are document specific, for example zoom, if you change the zoom of a document it will only be restored when opening the same document again, but not if you open a different one. There's also a "default zoom value for documents you've never opened before" in the settings.

Some other settings like "Continuous View" are a bit of a mess and are both. "Continuous View" wants to be a global setting (i.e. so that if you hate continuous view you always get a non continous view) but it is also restored to the status it had when you closed the document you're just opening.

That's understandably a bit confusing for users :D

My suggestion for continuous view would be to make it work like Zoom, be purely document specific but also have a default option in the settings dialog for people that hate continous view.

 

I'm guessing this should cover all our bases?

 

Opinions? Anything i may have missed?

21.04 releases schedule finalized

It is available at the usual place https://community.kde.org/Schedules/release_service/21.04_Release_Schedule

Dependency freeze is in five weeks (March 11) and Feature Freeze a week after that, make sure you start finishing your stuff!

AVIF support for KImageFormats just landed

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

https://github.com/google/oss-fuzz/pull/4850

CMake: Use new style imported targets to link libraries

 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:

• You can't misspell it, since these are actual things cmake knows about not strings so if you write something like JPEG::JPG it will fail at cmake stage
  
• You won't forget to add the include (most of us did at some point) because you don't need to :)
• The include path is just for that particular target (the old method added it to "everyone")
• It's basically less lines so it's harder to do wrong

 

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

Planned obsolence for Android phones

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 :)

20.12 releases branches created

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

Make sure KDE software is usable in your language, join KDE translations!

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.

Akademy-es call for papers expanded to October 27

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.

20.12 releases schedule finalized

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!

Is okular-devel mailing list the correct way to reach the Okular developers? If not what do we use?

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

3 days to sends your talks to Linux App Summit 2020!

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)

Flathub stats for KDE applications [that are part of the release service]

I just discovered https://gitlab.gnome.org/Jehan/gimp-flathub-stats that tells you the download (including updates) stats for a given flathub application.

Ran it over the KDE applicatitions that are part of the release service that we have in flathub.

The results are somewhat surprising:

org.kde.kdenlive
Total:   22649 downloads in 8 days
org.kde.kalzium
Total:   16571 downloads in 9 days
org.kde.kgeography
Total:   16343 downloads in 9 days
org.kde.kbruch
Total:   15744 downloads in 9 days
org.kde.kapman
Total:   15473 downloads in 9 days
org.kde.kblocks
Total:   15426 downloads in 9 days
org.kde.katomic
Total:   15385 downloads in 9 days
org.kde.khangman
Total:   15370 downloads in 9 days
org.kde.kbounce
Total:   15280 downloads in 9 days
org.kde.kdiamond
Total:   15242 downloads in 9 days
org.kde.kwordquiz
Total:   15173 downloads in 9 days
org.kde.ksudoku
Total:   15155 downloads in 9 days
org.kde.kigo
Total:   15125 downloads in 9 days
org.kde.kgoldrunner
Total:   15062 downloads in 9 days
org.kde.knetwalk
Total:   15030 downloads in 9 days
org.kde.palapeli
Total:   14939 downloads in 9 days
org.kde.klickety
Total:   14917 downloads in 9 days
org.kde.klines
Total:   14866 downloads in 9 days
org.kde.knavalbattle
Total:   14848 downloads in 9 days
org.kde.kjumpingcube
Total:   14831 downloads in 9 days
org.kde.ksquares
Total:   14829 downloads in 9 days
org.kde.killbots
Total:   14772 downloads in 9 days
org.kde.kubrick
Total:   14696 downloads in 9 days
org.kde.ktuberling
Total:   14652 downloads in 9 days
org.kde.kontact
Total:   3728 downloads in 458 days
org.kde.kolourpaint
Total:   2542 downloads in 9 days
org.kde.okular
Total:   2304 downloads in 3 days
org.kde.kpat
Total:   1203 downloads in 8 days
org.kde.ktouch
Total:   880 downloads in 9 days
org.kde.kate
Total:   638 downloads in 9 days
org.kde.ark
Total:   571 downloads in 9 days
org.kde.dolphin
Total:   566 downloads in 3 days
org.kde.elisa
Total:   387 downloads in 3 days
org.kde.minuet
Total:   103 downloads in 9 days
org.kde.kwrite
Total:   84 downloads in 9 days
org.kde.kcachegrind
Total:   35 downloads in 9 days
org.kde.kcalc
Total:   23 downloads in 4 days
org.kde.lokalize
Total:   10 downloads in 3 days

kdenlive is the clear winner.

After that there's a compact block of games/edu apps that i think were/are part of the Endless default install and that shows, since after that the next app has like 6 times less downloads.

"New" (in the flathub sense) apps like lokalize or kcalc are the ones with less downloads, i guess people haven't seen them there yet.

Book your BoF for Akademy 2020 now!

BoF sessions are an integral part of Akademy, it's the "let's discuss and plan how to make things happen" oriented part after the more "this is what we've done" oriented part of the talks.

So go to https://community.kde.org/Akademy/2020/AllBoF and book a session to discuss with the rest of the community about something you're passionate! :)

20.08 releases branches created

Make sure you commit anything you want to end up in the 20.08 releases to them

We're already past the dependency freeze.

The Feature Freeze and Beta is this Thursday 16 of July.

More interesting dates
    July 30, 2020: 20.08 RC (20.07.90) Tagging and Release
  August  6, 2020: 20.08 Tagging
  August 13, 2020: 20.08 Release

https://community.kde.org/Schedules/release_service/20.08_Release_Schedule

Cheers,
  Albert

20.08 releases schedule finalized

It is available at the usual place https://community.kde.org/Schedules/release_service/20.08_Release_Schedule

Dependency freeze is in four weeks (July 9) and Feature Freeze a week after that, make sure you start finishing your stuff!

Racism is bad - a Barcelona centered reflection

I hope most of people reading this will not find "Racism is bad" to be controversial.

The problem is even if most (i'd hope to say all) of us think racism is bad, some of us are still consciously or unconsciously racist.

I am not going to speak about the Black Lives Matters movement, because it's mostly USA centered (which is kind of far for me) and there's much better people to listen than me, so go and listen to them.

In this case I'm going to speak about the Romani/Roma/gypsies in Barcelona (and from what i can see in this Pew Research article, most of Europe).

Institutionalized hate against them is so deep that definition 2 of 6 in the Catalan dictionary for the Romani word (gitano) is "those that act egoistically and try deceive others" and definition 5 of 8 in the Spanish dictionary is "those that with wits and lies try to cheat someone in a particular matter"

Here it is "common" to hear people say "don't be a gitano" meaning to say "don't cheat/play me" and nobody bats an eye when hearing that phrase.

It's a fact that this "community" tends to live in ghettos and has a higher percent crime ratio. I've heard people that probably think themselves as non racist say "that's just the lifestyle they like".

SARCASM: Sure, people love living in unsafe neighbourhoods and crappy houses and risking going to jail just to be able to eat.

The thing is when 50% of the population has an unfavourable view of you just because of who your parents are, or your surname is, it's hard to get a [nice] job, a place to live outside the ghetto, etc.

So please, in addition to saying that you're not a racist (which is a good first step), try to actually not be racist too.

Send your talks for Akademy 2020 *now*

The Call for Participation is still open for two weeks more, but please make us a favour and send yours *now*.

This way we don't have to panic thinking if we are going to need to go chasing people or not, or if we're going to have too few or too many proposals.

Also if you ask the talks committee for review, we can review your talk early, give you feedback and improve it, so it's a win-win.

So head over to https://akademy.kde.org/2020/cfp, find the submit link in the middle of that wall of text and click it ;)

chmk a simple CHM viewer

Okular can view CHM files, to do so it uses KHTML, makes sense CHM is basically HTML with images all compressed into a single file.

This is somewhat problematic since KHTML is largely unmaintained and i doubt it'll get a Qt6 port.

The problem is that the only other Qt based HTML rendering engine is QtWebEngine and while great it doesn't support stuff we would need to use it in Okular, since Okular needs to access to the rendered image of the page and also to the text since it uses the same API for all formats, be it CHM, PDF, epub, wathever.

The easiest plan to move forward is probably drop CHM from Okular, but that means no more chm viewing in KDE software, which would be a bit sad.

So I thought, ok maybe I can do a quick CHM viewer just based in QtWebEngine without trying to fit it into the Okular backend to support different formats.

And ChmK was born https://invent.kde.org/aacid/chmk.

It's still very simple, but the basics work, if you give it a file in the command line, it'll open it and you'll be able to browse it.



As you can see it doesn't have *any* UI yet, so Merge Requests more than welcome.

kwallet-pam >= 5.18.4 and ecryptfs homes

If you are using kwallet-pam to unlock your kwallet wallets *and* have a encryptfs home, the automatic unlocking probably stopped working for you with Plasma 5.18.4 and you are getting a "Wallet failed to get opened by PAM, error code is -9" in the system log.

Why?

kwallet-pam uses something called a salt file.

Before Plasma 5.18.4 the salt file was read (or created if not existing) in the "authenticate" step of pam. Now that happens on the "open_session" step of pam.

This is very important because on the open_session the encrypted home is already mounted while in the authenticate step it is not.

What that means is that before Plasma 5.18.4 there was a /home/youruser/.local/share/kwalletd/kdewallet.salt *outside* your encrypted home (that was created/read on the "authenticate" step).

Now with Plasma >= 5.18.4 the /home/youruser/.local/share/kwalletd/kdewallet.salt is created/read correctly inside your encrypted home like the rest of your files.

This is all nice for new users, but if you have an existing user, the kwallet auto unlocking will stop to work.

Why?

Because your wallet was salted with the file that was outside your encrypted home folder, now since kwallet-pam can no longer read that, it fails.

How to fix it?

* Reboot your system
* Login as root (or as a different user)
* See that there is a /home/youruser/.local/share/kwalletd/kdewallet.salt (FILE_A)
* Copy that file somewhere safe
* Now login as the youruser user
* If you have a /home/youruser/.local/share/kwalletd/kdewallet.salt copy it somewhere else safe too (you shouldn't need it but just in case)
* Copy the FILE_A you stashed somewhere safe to /home/youruser/.local/share/kwalletd/kdewallet.salt
* Reboot your system and now everything should work

Should KDE fork CHMLib?

CHMLib is a library to handle CHM files.

It is used by Okular and other applications to show those files.

It hasn't had a release in 11 years.

It is packaged by all major distributions.

A few weeks ago I got annoyed because we need to carry a patch in Okular flathub because the code is not great and it defines it's own int types.

I tried contacting the upstream author, but unsurprisingly after 11 years he doesn't seem to care much and got no answer.

Then i looked saw that various distributions carry different random set of patches, not great.

So I said, OK, maybe we should just fork it, and emailed 14 people listed at repology as package maintainers for CHMLib saying how they would react to KDE forking CHMLib in an effort to do some basic maintenance, i.e. get it to compile without need for patches, make sure all the patches different distributions has are in the same place, etc.

1 packager answered saying "great"
1 packager answered "nah we want to follow upstream" (... which part of upstream is dead did they not understand?)
1 person answered saying "i haven't been packaging for $DISTRO for ages" (makes sense given how old the package is)
1 person answered saying "not a maintainer anymore but i think you should not break API/ABI of CHMLib" (which makes sense, never said that was planned)

And that's it, so only 4 out of 14 answers and only one of them encouraging.

So I'm asking *YOU*, should we push for a fork or I should stop this crazyness and do something more productive?