Plasma 5.18 bugs

Well, I am more confused now.
Switching to a newly created test user solve the issue (Thanks for the tip), but with my usual user I also have the same issue with FreeOffice (so it is not something in LibreOffice config) and I have the exact same behaviour on another machine also !!
Bottomline... I have no idea in which "config" to begin to search for. Any idea ?

I had also issues with localization after the upgrade to plasma-desktop 5.18 (there was a mix of languages in many applications). I then renamed the files in "~/.config" related to plasma (in dolphin filter for "plasma") such that they have to be regenerated anew.

This solved the problem for me (but clearly, you will also lose some setting that you have to restore, for instance, you may have to choose again the correct language for Firefox and Thunderbird).

You may try this without risk: If it doesn't help simply restore your original config-files.

1 Like

THANKS ! It worked for me. the ~/config/plasma-localerc file was corrupted and the locale fall back to a non UTF-8 one.
After deleting this file, log-out and log-in again the file was recreated with the right locale and now everything is working as it should. :+1:
And it was only this file, with only the locale settings. So I didn't loose any of my configurations.

1 Like

This can be temporarily fixed by setting the cursor size manually in System Settings. It is a bug in the "Resolution Dependent" cursor size option under Wayland.

2 Likes

Because my bug was reported as a duplicate, I commented on the other bug report that it seems to affect Plasma only on Qt 5.14 branch.

Yeah, I do the same when I get a duplicate, which is quite often. This is usually the only way to find the proper bug that is traced by developers.

I removed your bug from this list as this isn't Plasma 5.18 specific bug and it won't be quickly resolved. So for future reference I copy the data here:

Certain KDE/Plasma components don't respect touchpad scroll direction setting in Wayland with Qt 5.14.x
Submitted:
https://bugs.kde.org/show_bug.cgi?id=417686
Fixed: Not yet.

khotkeys is no longer a hard dependency of kmenuedit - and to my underastanding never was supposed to be. That's not a bug.
Generally with 'orphans' it's the user's decision to remove them or keep them as explicitly installed.
From ArchWiki:

Check for orphans and dropped packages

After upgrading you may now have packages that are no longer needed or that are no longer in the official repositories.

Use pacman -Qtd to check for packages that were installed as a dependency but now, no other packages depend on them. If an orphaned package is still needed, it is recommended to change the installation reason to explicit. Otherwise, if the package is no longer needed, it can be removed.

For that reason you will find the setting for auto-removal of orphans in pamac under this notice:

image :stuck_out_tongue_winking_eye:

In any case I have added khotkeys in the kde iso-profile to make sure it will be present in fresh installs.

3 Likes

Well we have to see if it is an issue. What is the connection of kmenuedit and khotkeys? When I search the code I don't see a dependency. However, Ubuntu Focal is listing it still as a dependency. Did we talk to the Arch Maintainer yet, why it got removed as dependency? @michaldybczak Also I don't see any bug opened at the Arch Bugtracker regarding that matter.


Also kmenuedit just compiles fine without khotkeys ...

Result without khotkeys:

-- The following OPTIONAL packages have been found:

 * Qt5Gui (required version >= 5.14.1)
 * KF5Service (required version >= 5.67.0)
 * KF5Bookmarks (required version >= 5.67.0)
 * KF5JobWidgets (required version >= 5.67.0)
 * KF5Solid (required version >= 5.67.0)
 * KF5CoreAddons (required version >= 5.67.0)
 * KF5Auth (required version >= 5.67.0)
 * KF5Codecs (required version >= 5.67.0)
 * KF5Config (required version >= 5.67.0)

-- The following REQUIRED packages have been found:

 * ECM (required version >= 5.66.0)
 * Qt5 (required version >= 5.12.0)
 * Gettext
 * KF5I18n (required version >= 5.66.0)
 * KF5DBusAddons (required version >= 5.66.0)
 * KF5IconThemes (required version >= 5.66.0)
 * Qt5Xml (required version >= 5.12.0)
 * KF5KIO (required version >= 5.66.0)
 * KF5ItemViews (required version >= 5.66.0)
 * KF5Sonnet (required version >= 5.66.0)
 * Qt5Core (required version >= 5.12.0)
 * KF5DocTools (required version >= 5.66.0)
 * KF5Init (required version >= 5.66.0)
 * Qt5DBus (required version >= 5.12.0)
 * KF5GlobalAccel (required version >= 5.66.0)
 * KF5 (required version >= 5.66.0)

-- Configuring done
-- Generating done

Result with khotkeys:

-- The following OPTIONAL packages have been found:

 * Qt5Gui (required version >= 5.14.1)
 * KF5Service (required version >= 5.67.0)
 * KF5Bookmarks (required version >= 5.67.0)
 * KF5JobWidgets (required version >= 5.67.0)
 * KF5Solid (required version >= 5.67.0)
 * KF5CoreAddons (required version >= 5.67.0)
 * KF5Auth (required version >= 5.67.0)
 * KF5Codecs (required version >= 5.67.0)
 * KF5Config (required version >= 5.67.0)

-- The following REQUIRED packages have been found:

 * ECM (required version >= 5.66.0)
 * Qt5 (required version >= 5.12.0)
 * Gettext
 * KF5I18n (required version >= 5.66.0)
 * KF5DBusAddons (required version >= 5.66.0)
 * KF5IconThemes (required version >= 5.66.0)
 * Qt5Xml (required version >= 5.12.0)
 * KF5KIO (required version >= 5.66.0)
 * KF5ItemViews (required version >= 5.66.0)
 * KF5Sonnet (required version >= 5.66.0)
 * Qt5Core (required version >= 5.12.0)
 * KF5DocTools (required version >= 5.66.0)
 * KF5Init (required version >= 5.66.0)
 * Qt5DBus (required version >= 5.12.0)
 * KF5GlobalAccel (required version >= 5.66.0)
 * KF5 (required version >= 5.66.0)

-- Configuring done
-- Generating done

That's one of the reasons why [K]ubuntu sucks...
That dependency hell thing. Recently they have a real mess with LibreOffice's dependencies. A headache I've never experienced on Manjaro/Arch.

1 Like

This is an unresolvable problem and difference between Arch and Manjaro. For Arch, this isn't a problem or bug at all, the user should be knowledgeable and smart enough to change the status of the package and not uninstall it blindly.

On the other hand, the average user that Manjaro aims for (not explicitly but still), has problem of recognizing what a certain package is doing. Sure, there are some descriptions available, but they are usually dry, vague and in overall often useless. It's hard to decide what a given package is doing.

You can't expect a regular user to know all ins and outs. Arch claims to make things simpler but it makes things more difficult where SYSTEM GETS IN THE WAY OF THE USER. In other words, users must constantly check and research things about packages, because if they are not (and most average users won't do this), they have a high chance to break their system unwillingly. So you can't just use the system, you have to maintain it and you have to constantly learn about the details to be able to maintain it. This is fine for Arch users, but it's problematic for Arch derivatives that aim for a different group.

So we have an absurd situation here. On one side khotkeys are not hard dependency, merely an optional one, on other hand, it provides important feature that is as a key component of the system.

I get it, that from Arch perspective, the fewer dependencies the better. You have more freedom and space to configure your system as you want, so tracking down unnecessary dependencies and getting rid of them may be a positive thing.

On the other side of spectrum, when an average user installs somethings, he/she may expect it will pull everything needed for it to work. If he/she find it doesn't work, he/she will not know which package is the one that is missing. Again, you can't expect from a user to know it.

So removing dependencies is OK from Arch perspective, from Manjaro one, it creates issues. So you may be right that it isn't a bug per se, but it is an issue for general usability.

Just look for an example. Most users want to ride a car, not build a car. If they are forced to build it, they would prefer to have a comprehensive and smaller number of functional chunks to assemble. So they take few categories, like wheels, engine, sits, lights, etc., put them together and voilà, you have a working car. Arch is trying to make things more basic, so you have to know each, small part.

The border between what is a really a dependency is fluid, because someone will say: those two parts must be together, because alone they may work but their functionality will be ridiculously small, so there is no point of tearing them apart, because together, they create a bigger and much nicer functional piece. Of course if you add too many pieces this creates a whole array of other issues.

The point is, what is a dependency IS SUBJECTIVE, that is why package maintainers of various Linux families approach it differently.

To end this rant, I will keep it on the list and treat it as bug/issue because it can create functionality lacks (like it did for some users already) and we have to inform others what is the cause and how to fix it. There is a reason I didn't provide any bug report, only information.

3 Likes

Applying GTK theme in systemsettings5 cause pulseeffects to show always English locale.

https://bbs.archlinux.org/viewtopic.php?id=252943

1 Like

I think I found a bug.

Steps:
1- Open the browser, put any song to play
2- Go to the application launcher, right-click and choose the option to configure application launcher
3- Mute the tab sound to edit the app launcher (don't ask me where this sound comes from)
4- All sounds currently playing are deactivated

1 Like

I'm afraid I don't understand step 3.

1 Like

I don't know if I can post a video here (if I'm not sorry), I recorded a video of the possible bug.
edit: one thing i forgot to mention was that i'm on the unstable branch, sorry.

https://youtu.be/vV4H1ZdEk30

1 Like

You are clicking on the new mute button on the top right corner of the panel icon.
It's a feature! (of which I am also not 100% convinced that I like it)
Firefox icon has it too.
Anyway, on the unstable branch you are using plasma 5.18 already, which will not be included in the 19.0 release.

See:
https://cgit.kde.org/plasma-desktop.git/commit/?id=da268696a6af1386870383c5d9a3fd9f2ca88ea4

I think now I know what you mean! :laughing:
Right, I agree that the mute button of launcher settings shouldn't affect other sources. It shouldn't even have one, since it isn't the source of the sound.
Lets move this to the 15.8 thread and report it upstream.

3 Likes

I am 100% sure I don't like it.

1 Like

It can be disabled in Task Manager Settings:

image

Weird. I can't duplicate the issue. The sound icon doesn't show for me on this settings window icon. It stays only on FF's or Spotifie's icon.

Are you on testing branch? There were already some singular updates on unstable so maybe they fixed it.

Forum kindly sponsored by