updated to openSUSE 20150903 (Tumbleweed)

English Install/Boot/Login
21

I don’t think that could cause a missing icon though.

So you mean the icons for the windows? In the case of YaST too?
I thought you were talking about the application menu…

Well, there was a fix in KWin to ignore invalid window icons to prevent crashes. Maybe this might be related, or those are just “bugs” in the applications.

Yes, I’ll do that later today, against kwin?

Hard to say, might be a bug in plasmashell too, or in the startup-sequence.
I’d probably start with kwin though, the KWin developers should know better where to search for the problem.

You could try to look at KWin’s “Support information” though (you probably know how from earlier bug reports, I have to look it up myself…), when the problem occurs (i.e. right after login). Does it say that compositing is enabled and set to OpenGL?

en-GB - I don’t recall setting that anywhere apart from Country / Keyboard during the initial install of TW. Within KDE there is no alternate layout set. The only setting I’ve changed is to explicitly set the keyboard model. I did note that “Numlock On” is also set here, I don’t know if that is default or if I changed it.

The default should be “Don’t change”, the YaST option is used then.
Maybe try to change it, or set it to “on” and turn off NumLock in YaST (so the booting should not mess at all with NumLock).

This is rather odd in as much as it only happens on initial boot, if I log out/in the shift key does not change the NumLock state.
I have NumLock set to “On” in the BIOS, so the sequence is as follows:
Boot - NumLock On
Grub - NumLock remains On
Kernel Loading - NumLock Remains On

That’s strange, it’s always Off after the kernel is loaded here. AFAIK the kernel even explicitly turns it off normally.
Or did they change that in current Kernels meanwhile?

KDE start - NumLock Off then Immediately On

That’s strange too, yes, if it was on all the time before.

NumLock remains ON until the first press of the Shift Key whereupon it switches OFF
Curiously, it then requires the NumLock key to be pressed twice to switch back ON.

That’s not so curious.
It just switches off the LED apparently, not NumLock itself.
So if you press the NumLock key it is actually turned off, and the LED stays off.

Since the last update it no longer crashes at logout/shutdown… Further up the thread “nrickert” indicated that it happens still with “Leap 42.1 Milestone 2”.

Yes, but that still doesn’t say anything about whether it is a general problem or what causes it.

I cannot even test Leap here, as I can only run 32bit guests in VirtualBox (my 64bit CPU doesn’t support hardware virtualization).
And I don’t have enough space to install it on my real hard disk.
And there are no LiveCDs available either…

22

Sorry, the icons that are being shown as the generic “Gear” are the ones displayed in the Task Manager. Yes, in the case of YaST too. SUSE Paste

You could try to look at KWin’s “Support information” though (you probably know how from earlier bug reports, I have to look it up myself…), when the problem occurs (i.e. right after login). Does it say that compositing is enabled and set to OpenGL?

qdbus org.kde.KWin /KWin supportInformation

Immediately after boot with the white non translucent panel:

Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV84
OpenGL version string: 3.3 (Core Profile) Mesa 10.6.5
OpenGL platform interface: GLX
OpenGL shading language version string: 3.30

After toggling compositing off-on to restore the translucency the support information appears to be identical, albeit with a few items in slightly different order.

I’ll post a bug report later.

The default should be “Don’t change”, the YaST option is used then.
Maybe try to change it, or set it to “on” and turn off NumLock in YaST (so the booting should not mess at all with NumLock).

That’s strange, it’s always Off after the kernel is loaded here. AFAIK the kernel even explicitly turns it off normally.
Or did they change that in current Kernels meanwhile?

That’s strange too, yes, if it was on all the time before.

I think I’m getting myself confused… The information I gave was wrong :embarrassed: I’ve just checked again and indeed you are quite correct, during kernel loading NumLock is switched off. Reverting back to the on state at ssdm. I am however seeing a very brief Off-On during KDE loading. I don’t know if that’s new, or has always done it, occurs at around the start of the progress bar.

The NumLock settings in YaST (System Keyboard Configeration) currently have Start Up State - Num Lock On - “Bios Settings”. Is that the setting you are referring to? There is a note that: “Settings made here apply only to the console keyboard. Configure the keyboard for the graphical user interface with another tool.”

23

OK Bug reported against KWin: 352445 – Loss of panel translucency at initial login

24

YaST doesn’t set an icon for its module windows. That’s already the case in 13.2 with KDE4, definitely nothing new in this latest Tumbleweed snapshot. In 13.2/KDE4 I see the generic X11 icon, but that depends on the icon theme I suppose.
Although I do see a “wrench” icon for the main control center window here in 13.2.

The digital clock settings window does have an icon here, but in Plasma5 with the Breeze windeco and the default colours you cannot see it because it is grey on grey (different shades but similar). If I look close enough, or deactivate the window, I see it though.

For GIMP I cannot reproduce this in 13.2. All windows have the GIMP icon, except when I load a picture, that window has the picture as icon.

Immediately after boot with the white non translucent panel:

Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV84
OpenGL version string: 3.3 (Core Profile) Mesa 10.6.5
OpenGL platform interface: GLX
OpenGL shading language version string: 3.30

After toggling compositing off-on to restore the translucency the support information appears to be identical, albeit with a few items in slightly different order.

I’ll post a bug report later.

Ok, Compositing seems to be active. So it’s probably plasmashell that doesn’t detect it correctly, or tries to detect it too soon when it hasn’t been turned on already (at least that was the problem in KDE4 years ago), I suppose.

I think I’m getting myself confused… The information I gave was wrong :embarrassed: I’ve just checked again and indeed you are quite correct, during kernel loading NumLock is switched off. Reverting back to the on state at ssdm. I am however seeing a very brief Off-On during KDE loading. I don’t know if that’s new, or has always done it, occurs at around the start of the progress bar.

Well, maybe setting it to “Don’t change” in KDE’s setting should “fix” that, because KDE shouldn’t mess with it on startup then.

The NumLock settings in YaST (System Keyboard Configeration) currently have Start Up State - Num Lock On - “Bios Settings”. Is that the setting you are referring to?

Yes.

There is a note that: “Settings made here apply only to the console keyboard. Configure the keyboard for the graphical user interface with another tool.”

The Xorg startup script set the NumLock state to on if desired. And apparently that works, otherwise it would be off at the login screen.
SDDM does have its own setting regarding this, just like KDM has, but by default it doesn’t change the state.
If you set it in the KDM/SDDM configuration, the YaST setting doesn’t apply to the graphical session because the login manager overrides it.

For other DMs it might be similar, or they might set it to a defined state in any case, I guess that’s why that warning is there.

A side-note: “BIOS” might not always work as intended. On my system here I have set it to on in the BIOS, and this worked fine with my old PS/2 keyboard, i.e. NumLock was on in the BIOS, in GRUB(2), and later in X/KDM.
But not long ago I switched to an USB keyboard, and the BIOS is now unable to turn NumLock on (although it flashes briefly). So it’s off in the BIOS screen, off in GRUB2, and off at the login screen, unless I explicitly set it to “on” in YaST or /etc/sysconfig/keyboard. There’s no way to turn it on for the BIOS screen and GRUB2 though…

25

D’oh, I do see what you mean now.
Yes, in Plasma 5’s task bar they all show up with the filetype icon for executables (not a gear here, as I use the Breeze theme).
It’s not so obvious here though, as I use the standard task manager and are not so fixated on the icon…

Ok, seems to be a regression in Plasma. Plasma 5.4.1 has been released today though, I will try again when I installed it.

26

PS, I found the “problem”:
The task manager has a new option in 5.4, “Use launcher icons for running applications”, which is on by default. Disabling this option in the settings “fixes” the icons…

27

Simple… when you know how! :wink:

Just tried and all on the icon front is restored as before… almost.

There was something bugging me about the Gimp but I couldn’t quite get what. Now I’ve realised… There weren’t separate icons before, they were grouped under the one Icon. I don’t use Gimp that often, I may be recalling how it was with 4.x

Many thanks.

28

Yes, my thoughts about this issue:
Previously, the task manager just displayed the icons that the applications set for the window, i.e. the icon that is also shown in the top-left corner of the window.
This option is intended to show the icon from the application launcher entry instead, I think.

In those cases, the task manager seems to be unable to associate the window/application with any application launcher entry, i.e. .desktop file, therefore it shows a generic icon. It probably would be better if it would fall back to the window icon in that case.

So in hindsight, your error messages from kbuildsycoca5 (which basically are about the application menu) might seem to be related indeed.
After all it does complain about the kde-settings.menu (which probably should contain a hidden entry for the digital clock settings module), and the suse-yast.menu.
GIMP seems to be a “special” problem though.

There was something bugging me about the Gimp but I couldn’t quite get what. Now I’ve realised… There weren’t separate icons before, they were grouped under the one Icon. I don’t use Gimp that often, I may be recalling how it was with 4.x

Hm, they are shown separately here in KDE4 too.
Can’t really say how it was in previous versions though, I never use GIMP.

But that would rather have been a change in GIMP some time ago, I suppose.
GIMP has an option “Single window mode” in the Settings menu, if you enable this it opens only one window. I think in earlier times that was the default, or the only way to have GIMP work.

It is possible to “hide” specific windows in the task manager via window rules though.

Many thanks.

You’re welcome.
At least you have a “work around” for the icon issue… :wink:

29

Just checked those icons on a different PC which is still on Tumbleweed 20150508 and using:
GIMP 2.8.14
KDE Platform Version 4.14.7

The icons are, as I thought, combined. SUSE Paste

Thomas Lübking ( 352445 – Loss of panel translucency at initial login ) says the non-translucent panel is due to 348154 – Panel is sometimes transparent depending on compositor settings

30

Well, they are not grouped here (13.2, KDE Platform Version 4.14.9, kdebase4-workspace/Plasma 4.11.20, GIMP 2.8.14):
http://wstaw.org/m/2015/09/09/gimp.png

Not even if I disable the option “Only group when taskbar is full”…

Although I did notice that they sometimes are indeed grouped (or ungrouped again) when I open/close GIMP windows. The behaviour seems to be quite inconsistent…

You are right that the “Icons-only” taskmanager does group them, so it seems to do something special.
The new one in Plasma5 seems to behave just like the standard task manager in this regard.

Thomas Lübking ( 352445 – Loss of panel translucency at initial login ) says the non-translucent panel is due to 348154 – Panel is sometimes transparent depending on compositor settings

Yes, I am aware of that bug, that’s why I wrote that the panel is not supposed to be translucent with the Breeze theme. Due to this bug, it was displayed translucent on some systems, and is not any more because the bug is fixed…

But that bug shouldn’t change the behaviour when you turn off compositing and turn it on again.
And as you state in your bug report, you are using a translucent panel.
The bug has been reopened meanwhile anyway…

31

I guess the question now becomes - is that behaviour by design or is it a bug?

I’ve filed a bug report 352477 – Icons from same application not grouped. against the Icon Only Task manager and will await to see what the outcome is.

32

Well, I think the old KDE4 icons-only taskmanager was a completely separate plasmoid, whereas for Plasma5 it has been rewritten to share the code with the standard one to make maintenance easier.
So that it behaves like the standard one now (and different than before) is not a bug per se, I’d say.

But it probably would be a good idea to extend/improve the grouping feature in general, maybe to the state that the KDE4 icons-only taskmanager had.
At the moment it only groups by name (like the standard one in KDE4), whatever that means, and those windows do have completely different titles at least. I’m not completely sure about the details though, as Konsole windows also have different titles (the current directory, by default) but are grouped.

I’ve filed a bug report 352477 – Icons from same application not grouped. against the Icon Only Task manager and will await to see what the outcome is.

OK, let’s see…

But this does only happen with GIMP, or do you see it with other applications as well?
I just tried with Konsole, and the windows are grouped correctly (if the task bar is full, or I disable the option “Only group when taskbar is full” which is on by default).

33

Yeah, right… It does at the moment look as if GIMP is the only application behaving that way. I’ve just tried Thunderbird and LibreOffice (as they are both non native KDE applications) and icons for those do group.

In trying that I noticed that LibreOffice is now not displaying it’s own icon (it uses a stylized ‘X’)… unless I re-enable “Use launcher icons for running applications”… Arrgh… rotfl!

34

Hm. LibreOffice does show an icon here, in both 13.2 and Tumbleweed, KDE4 and Plasma5. And it is displayed by both task managers.

Are you using Tumbleweed’s version, or did you install the one from their homepage maybe?
Would sound like the icons are missing on your system.

35

libreoffice 5.0.1.2-1.1 from Tumbleweed-OSS

Now, for even more weirdness :.…

I just took a screen-shot of the “wrong” and “right” libre office icons depending upon the setting of “Use launcher icons for running applications”. Rather than post them as separate images I intended to use GIMP and combine them into one image. Here’s what happened…

Launch GIMP - Three separate GIMP icons.
Open the first image - still three icons
Open the second image - three icons immediately group into one. SUSE Paste

I think I’ll update the Icon Manager bug report… then maybe take a holiday :stuck_out_tongue:

36

Actually it’s now four icons of course…

37

Yes, that shows the icon here.
Maybe your icon theme?

For me (with the default Breeze icon theme) it shows the icon included in breeze5-icons.

Now, for even more weirdness :.…

I just took a screen-shot of the “wrong” and “right” libre office icons depending upon the setting of “Use launcher icons for running applications”. Rather than post them as separate images I intended to use GIMP and combine them into one image. Here’s what happened…

Yeah, that’s what I meant when I wrote this earlier:

Although I did notice that they sometimes are indeed grouped (or ungrouped again) when I open/close GIMP windows. The behaviour seems to be quite inconsistent…

I see the same in KDE4.

As I said, GIMP seems to do something “special” with its windows…
Doesn’t mean that there’s no bug in the taskmanager too though.

38

These are the icons in the theme I’m using: SUSE Paste

Wrong names (or sizes) maybe?? Do you know of any easy way to find the name of the icon it should display?

39

They look like the standard icons included in LibreOffice.

Wrong names (or sizes) maybe?? Do you know of any easy way to find the name of the icon it should display?

The task manager doesn’t load/display the icon, unless you activate “Use launcher icons for running applications”.

It’s the application (LibreOffice in this case) that sets the image data to be displayed as window icon.
This image data can be hard-coded into the application, or it might read it from a file, maybe from your icon theme where it doesn’t exist.
The standard icons are located in /usr/share/icons/hicolor/XxY/apps/ (files libreoffice-draw.png and so on) e.g. (LO also ships with icons for the locolor and gnome themes)
Maybe try to copy those to your icon theme.
Or try setting “Breeze” as a test (or “Oxygen”).

You could run LibreOffice through strace to see whether it tries to load an icon file (and which one exactly) and fails.

Does the icon appear when you run “OOO_FORCE_DESKTOP=gnome libreoffice”?
It should then ignore the KDE icon theme I think.

40

Which in this case I guess it’s not… or it would be correct?

or it might read it from a file, maybe from your icon theme where it doesn’t exist.
The standard icons are located in /usr/share/icons/hicolor/XxY/apps/ (files libreoffice-draw.png and so on) e.g. (LO also ships with icons for the locolor and gnome themes)
Maybe try to copy those to your icon theme.

Copying those to the relevant locations (X x Y/apps) in my icon theme, logging out, zapping the relevant ~/.cache entries, logging in … made no difference.

However what I have found is that it’s only writer that displays the ‘X’ icon, startcentre, calc, draw, etc all show the libre office icons. Watching more closely, so does writer, very briefly I’m able to see the writer icon - then it is getting replaced by the ‘X’ icon. This is not related to copying the icons, as I removed those again and the behaviour is still the same.

Or try setting “Breeze” as a test (or “Oxygen”).

I really should have tried that already… but even without doing so I suspect the icons will be present. I’ll try shortly.

edit: OK just tried that and all libreoffice icons are shown in the task manager…

You could run LibreOffice through strace to see whether it tries to load an icon file (and which one exactly) and fails.

That sounds “above my pay scale” :frowning:

Does the icon appear when you run “OOO_FORCE_DESKTOP=gnome libreoffice”?
It should then ignore the KDE icon theme I think.

Yes… but if I use “OOO_FORCE_DESKTOP=gnome libreoffice --writer” then No

I think this might be another one that I “just live with”, nonetheless, I am appreciative of your time and effort.