[03:47] is QtCurve still a thing . . . I know it gets minor updates here and there but is it really still a thing? [03:49] @RikMills, this is not true … AppImageLauncher has always been a needed thing because it removes the need for having to set execution permissions. It also makes it easier to update AppImages. … plus there is the AppImageHub now (ran by KDE apparently) and the fact that no distros support it out of the box (without one weird esoteric AppImage only distro) is a shame [05:15] @MichaelTunnell as I understand it, KDE only set up the Hub so that we could get Discover working with everything.... snap, appimage and flatpak [05:17] does Discover work with AppImages though? and if it exists why not let people know that to use it? [05:21] hmmm, dunno [05:22] I like good old-fashioned packages [05:22] eventually I'll have to accept the Future, I know [05:24] it depends on the purpose of the app for me. if it is a core utility then traditional packages but otherwise if it is a top level app that gets frequent updates, then traditional packaging is a nightmare [05:24] well, I used to build some stuff from source [05:24] I'm not afraid of work [05:25] but i don't want to run gentoo either [05:25] and my snap experiment didn't go well [05:27] I think there is value in traditional packaging but there is also *massive* flaws that hold back the whole Linux desktop. The fact that versions are locked to distro releases with months in between and with LTS potentially ever seeing updates. That's a nightmare for users and app developers. For example, when the project I work on releases a new version we essentially ignore Ubuntu updates and just do a PPA because yea [05:27] its in the repos but it is 100% always out of date [05:28] snaps need work, flatpaks and appimages too. . . they all have issues but I think their benefits vastly outweight the negatives in comparison to the traditional style of waiting for months or waiting for years with LTS [05:49] I live in hope that there will be ONE solution [05:49] although I know that's a pipe dream [06:04] the 3 that exist are all compatible with each other so as long as Discover supports them all to the users then Discover is the ONE solution . . . provided Discover's issues can be fixed [06:13] amen to that [07:48] @MichaelTunnell, Nope [09:14] @MichaelTunnell, "Discover doesn't export appimagehub without packaging and installing scratch/apol/xdgthing" [09:14] https://phabricator.kde.org/T10648 [09:15] Even Neon decided, nope. [11:17] I experienced a strange black screen with full ssd/hd activity for 2 days in a row, after long time idling [11:17] wayland was enabled [12:13] Howdy all [16:16] @RikMills, Neon makes many other wrong decisions as well :D [16:18] @RikMills, selective quoting Rik lol :D … right after that, Riddell said in the same message. "But we should install appimagelauncher by default. scarlettmoore has said she can get that into Neon." … and that's what I said as well. :D [16:21] what are everyone's thoughts of change the default task manager to Icons Only Tasks? [16:36] @MichaelTunnell, But once it was in Neon, never bothered to do so for debian. … Besides, the launcher is not Discover integration. [16:44] @RikMills, yea but appimagelauncher is something that would be beneficial if the only thing that ever happens is it being added. … appimagelauncher removes the necessity to edit permissions of each appimage manually. This is easy to do sure but brand new users would benefit from it and probono would likely use Kubuntu as an example for distros implementing AppImages better. :D [17:41] *squint* [17:44] RikMills: to clarify that wasn't a neon decision; it's a matter of shipping the right knsrc which discover peeps opted to not do [17:45] also debian wasn't forgetting, it's why the aforementioned task was bounced onto the Neon2Debian board [17:46] *forgotten even [21:52] RikMills: hi, I have been busy but I'm still alive. I'm resuming my test rebuild routine, for fw 5.64 there's no git repo for kcalendarcore, that's intentional, isn't it?