Arch Linux User Repository

@jghodd Glad to hear it! Took a while to get there, but the result is worth it I'd say. ^_^

@Thulinma - that did it. Works perfectly, and the icons look good - the gray one even looks like the gray version of the blue one now and not just a gray blob. I saw your code change. ;) Anyway, I do appreciate that this now complies with the SNI requirement, and I also appreciate that it now works as it did with xembed. There is no better tool for performing updates in a graphical Linux environment. Hands down. I won't push anything less to my users. I'll keep both kalu and kalu-kde in my repository for now. I check the repository status daily against the AUR, so whenever you merge the two, I'll know.

Frankly I don't anticipate finding anything else wrong. It seems to be working fully as expected now. I don't mind testing, and you're welcome. Thank you for fixing this.

@jghodd Okay, I spend a few hours debugging/tweaking and found the problem. (Actually tested from KDE, this time.) The new 4.7.1 should work fully as intended for you. I was also able to put in proper detection with automatic fallback to xembed for older systems, so the --enable-status-notifier flag no longer exists, and the kalu and kalu-kde packages are now equivalent and should work and look the same on all systems and all desktop environments. (Plus, bonus: the notifications now also use the SVG images instead of the pixelated old version.)

Just to be clear, this was never an X11/Wayland issue: KDE has required SNI since 2014 (Plasma 5) and stopped supporting xembed at the time. I merely refer to "SNI" as "Wayland" because on all of Wayland, SNI is the only way to get a taskbar icon (while KDE "trailblazed" to some degree by requiring it even under X11, something the other X11 desktop environments didn't follow them in). X11 support on non-KDE environments through xembed was never removed or broken, but KDE hasn't used that implementation for over a decade now. (This is also probably why this version of the package is/was called "kalu-kde", since it added SNI support, which was equivalent to KDE support at the time.)

I'm keeping kalu-kde around for a month or so and then plan to submit a merge request to automatically redirect people to the "plain" kalu package, since both support all environments now.

Thanks for the assist debugging this! Let me know if anything else still seems off, but I'm fairly confident everything is finally how it should be now.

@Thulinma - I'll test your v4.7.0, but at this point, I've already prepared my own local branch of kalu-kde-4.5.2 to create a version for my users. I'm prepared to keep watch on your commits for anything related to the package manager and apply those as needed. In its current form, I can't use it. Under xorg, it's just too flaky. Wayland has not yet reached the maturity of xorg, and although I understand your impulse, I won't let my X users deal with a partially functioning system updater. This has to work perfectly as before or it's useless to me and my users.

Why not, as I've suggested before, return kalu-kde to the 4.5.2 branch and keep that for xorg users, and modify kalu for wayland. Or vice verse. Or peel off the package management from the GUI and put them in separate shared libraries so you can more easily maintain both xorg and wayland while keeping the package management intact. Otherwise, you're messing with the updater for one group or the other.

Edit: just checked github and there have been no source code changes since the last time I pulled it and very fully tested it. I won;t be testing it further unless and until new fixes are made.

Edit2: you don't need to install KDE - run a KDE/Plasma distro in a virtual machine for testing. Given that it's called "kalu-kde", I'd have imagined it should always have been tested in a KDE/Plasma environment.

Given that all of the package management tasks are performed by kalu-dbus, the separation of functions is, for all intents and purposes, already there. It seems to me that maintaining just 2 separate versions of src/kalu, an xorg and a wayland version, shouldn;t be difficult. My understanding is that a majority of Linux users are still on X, not yet wayland. Although I understand your desire to extend the functionality of kalu to folks using wayland, to do that at the expense of the majority of users is simply not right. To provide it for Wayland, it's been hobbled for Xorg. That should absolutely never be the way it's done.

@jghodd I've gone ahead and updated the package for now, since we're almost there. The alternating between active/passive is very strange - we don't actually create two icons at all. It's merely the "one" icon that gets changed between the various states and icon styles. So... it should not be possible to have more than one (unless multiple versions of kalu are running simultaneously, somehow...?) I'd say try out the 4.7.0 build and see what happens - if the problem is still there I'll take another look at it by installing KDE myself and seeing how it behaves there.

@Thulinma - I have it running now - I don't test in my own desktop, I build an iso and test from a vm. I'm going to leave it up to wait for updates. I am going to let you know that when it came up, it still has a weird flicker. I'll leave an edit when I have a clearer picture of what's happening.

Edit: Ok. I actually went and put the icons into the icon theme I use to make sure they made their way into the icon cache. On startup, weird flashing of the blue icon in the active space and the correct passive/gray icon in the passive space. I'm waiting for updates again at this point to watch carefully what's happening during an update. I did one already, but only noticed the flashing blue icon in the active space. Should both icons be set either to passive or active depending on your conditional? On startup, both icons should be set to passive until it's determined that updates/etc are available. Is the issue that only one is getting set to active/passive when both should be getting set in lockstep? I'll know more after the next update - I'll look carefully at what's going on, but I think my observation of the startup condition is important.

In other words, on startup, kalu-gray is correctly appearing in the passive space, but kalu is flashing in the active space. If I'm right, both should be in the passive space at this point. I will post back here after an update. I want to see if it's the same situation with one icon in passive and one in active. What I'm seeing is that the kalu and kalu-gray icons must be set to active/passive in lockstep - both are active or both are passive.

Edit2: After adding the icons directly to the icon theme, updating works as expected. The icons are doing what they're supposed to be doing - blinking in the active space. The startup condition is still weird, with the blue icon (kalu.svg) flashing in the active space while the gray icon (kalu-gray.svg) is flashing in the passive space. Fix that and it's done.

@jghodd: Did you actually install the new icons? The original used in-memory bitmaps for the grey and paused icon, but in the new version I switch to using system icons, and the newest package installs vector art versions of these icons (which, yes, can absolutely be overridden by theme packs etc!). Most likely the disappeating icon is entirely you not having the new icons installed, so it can't load them. Easiest way to test this would be to install the latest kalu-kde package (which includes the icons and installs them in the right spot) and then run the newer code. That should work well. If it does, great! That means I can release this version.

@Thulinma - the more I watch exactly what happens during checking for updates, the more I'm convinced that the missing gray icon is what's causing the flicker. I'm pretty sure if you restore the gray icon (or feel free to change the color so it's not so ugly), the flicker will return to a blink.

@Thulinma - given that my last post took its time coming to any conclusion, I'll summarize it in fewer words.

What I'm seeing no longer appears to have to do with active/passive icon state. I think you got that fixed. I believe entirely that the "blink" is not functioning correctly. When kalu is looking for updates/notifications, and when it is actually performing an update, the tray icon blinks. The blink is broken - it's trying to do something, but it's coming off as a flicker vs a blink. I have to wonder if that has something to do with the now missing gray kalu icon. I imagine a blink going back and forth from a blue to a gray icon would look different than a blink going back and forth from a blue icon to a blank background. I could be wrong, but given that the non-thinking kalu functions don't affect the icon state, that would suggest the blink is the likely issue. Would the easiest solution be to just remove the blink, or to fix it?

Edit: I'm sitting here looking at kalu-4.5.2 doing an update, and looking at the blinking icon, it's clearly obvious it's going back and forth displaying the gray and blue icons. If the gray icon were missing...the blink becomes a flicker.

Edit2: This is how it should work:

1. on startup, there are no upgrades and no notifications; the icon is in a passive state; it checks for upgrades/etc and the passive icon blinks in the hidden icons space only; the icon does not appear at all in the active space unless the check produces upgrades or other notifications.

2. if the icon is in passive mode and check for upgrades is selected from the menu or from the notification, the upgrade window pops up and the icon remains in the hidden space unless a notification is generated, at which point the icon appears in the active space. The check with blinking takes place entirely within the hidden space, where the icon remains if no upgrades/etc are found.

3. if the icon is in active mode and check for upgrades is selected from the menu or the notification, the upgrade window pops up and the icon remains in the active space unless no upgrades/etc are found, at which point the icon moves to the hidden space. If upgrades/etc are available, the icon remains in the active space.

What is actually happening:

1. on startup, the icon is passive and in the hidden icon space; when it performs its initial check for upgrades, the icon flickers aggressively in the active space, where it should not be. Also, it should not be flickering aggressively, it should be blinking slowly. Its ending location is correct, landing in the active position if upgrades/etc are found, and landing in the hidden space if no upgrades/etc are found.

2. if the icon is in passive mode, in the hidden icon space, and check for upgrades is selected, the icon will flicker aggressively in the active space where it should not be. It lands in the correct space when done - active for upgrades, passive for none.

3. if the icon is in active mode, in the active icon space, and check for upgrades is selected, the icon will flicker aggressively in the active space. It, too, lands in the correct space when done.

The fact that everything settles into where it should be tells me you've fixed the active/passive issue. Also, I checked your source code and your logic appears sound. The conditional for active/passive is correct, and keeping track of the current icon state also looks right. I'm not sure where or how exactly the blinking icon is implemented and grep'ing on key words isn't helping, but it has to be happening, for sure, wherever and while an upgrade is performed.

Edit4: I watched an update carefully and what I saw was that the icon appears to be switching back and forth with itself instead of kalu-gray. And not back and forth between preloaded buffers, either. The icon images seem to be getting loaded at each swap which I think is causing the flicker effect. This was what happened during an update and I'm still sure the initial startup check is producing a blue vs blank flicker, but it is very likely that fixing the more obvious one will fix the other.

@Thulinma - OK. Very close. Very obviously improved, but still something setting the state to active 1) on initial startup, but is obviously immediately corrected; and 2) when checking for updates, it's apparent that there is a loop in there of some sort (maybe an event being triggered over and over), and the state of the icon is being set first to active, then to passive, because I'm seeing it flicker in the active position in the tray as if its state is being set back and forth to active and passive.

Re the PKGBUILD - statusnotifier needs to be added to the depends array, and you probably want to add replaces to both (kalu: replaces=('kalu-kde') ; kalu-kde: replaces=('kalu')). That'll allow for DE-specific updates (e.g. for my xorg users, they'll have to change from kalu-kde to kalu, so a 'replaces' in kalu will allow an update and change of package).

Edit: is it possible that there's another instance of what you just fixed...?

Edit2: is there any chance that one event that's setting the icon state to active might be triggering another event that sets the icon state to passive which triggers the first event setting the icon state to active which triggers... you get the point. Just a thought.

Edit3: interesting... I set up a condition to test updates, and I found the icon behaving in the opposite way. When the icon was supposed to be solidly active, it was flickering as if something was setting it to passive. But what if what I'm seeing is the correct behavior, without the gray/inactive icon. If what I'm seeing is supposed to be the icon flashing while it's "thinking", the difference may well be that missing gray icon. The flashing is likely achieved by going back and forth between the active and passive icons. Any thoughts on that? If that's how it works and the gray icon is missing, it would appear to be flickering vs flashing.

Edit4: I assume then that it's kalu that requires enable-status-notifier? currActive is defined within an ifdef block for status notifier enabled. kalu's PKGBUILD will need the statusnotifier dependency then so pacman pulls it along for the ride.

Edit5: Just wanted to let you know that for operations where "thinking" is not required (like show last notification), where there would be no flashing, there is no flicker or sign of the icon misbehaving in any way. This further suggests that the issue has something to do with the flashing, not the logic. I suspect that another way of "solving" this issue now, is to turn off flashing. Not sure that was all that useful anyway.