/srv/irclogs.ubuntu.com/2019/11/14/#kubuntu-devel.txt

IrcsomeBot1<MichaelTunnell> is QtCurve still a thing . . . I know it gets minor updates here and there but is it really still a thing?03:47
IrcsomeBot1<MichaelTunnell> @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 shame03:49
valorie@MichaelTunnell as I understand it, KDE only set up the Hub so that we could get Discover working with everything.... snap, appimage and flatpak05:15
IrcsomeBot1<MichaelTunnell> does Discover work with AppImages though? and if it exists why not let people know that to use it?05:17
valoriehmmm, dunno 05:21
valorieI like good old-fashioned packages05:22
valorieeventually I'll have to accept the Future, I know05:22
IrcsomeBot1<MichaelTunnell> 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 nightmare05:24
valoriewell, I used to build some stuff from source05:24
valorieI'm not afraid of work05:24
valoriebut i don't want to run gentoo either05:25
valorieand my snap experiment didn't go well05:25
IrcsomeBot1<MichaelTunnell> 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 yea05:27
IrcsomeBot1its in the repos but it is 100% always out of date05:27
IrcsomeBot1<MichaelTunnell> 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 LTS05:28
valorieI live in hope that there will be ONE solution05:49
valoriealthough I know that's a pipe dream05:49
IrcsomeBot1<MichaelTunnell> 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 fixed06:04
valorieamen to that06:13
IrcsomeBot1<RikMills> @MichaelTunnell, Nope07:48
IrcsomeBot1<RikMills> @MichaelTunnell, "Discover doesn't export appimagehub without packaging and installing scratch/apol/xdgthing"09:14
IrcsomeBot1<RikMills> https://phabricator.kde.org/T1064809:14
IrcsomeBot1<RikMills> Even Neon decided, nope.09:15
IlgazI experienced a strange black screen with full ssd/hd activity for 2 days in a row, after long time idling11:17
Ilgazwayland was enabled11:17
BluesKajHowdy all12:13
IrcsomeBot1<MichaelTunnell> @RikMills, Neon makes many other wrong decisions as well :D16:16
IrcsomeBot1<MichaelTunnell> @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. :D16:18
IrcsomeBot1<MichaelTunnell> what are everyone's thoughts of change the default task manager to Icons Only Tasks?16:21
IrcsomeBot1<RikMills> @MichaelTunnell, But once it was in Neon, never bothered to do so for debian. … Besides, the launcher is not Discover integration.16:36
IrcsomeBot1<MichaelTunnell> @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. :D16:44
sitter*squint*17:41
sitterRikMills: to clarify that wasn't a neon decision; it's a matter of shipping the right knsrc which discover peeps opted to not do17:44
sitteralso debian wasn't forgetting, it's why the aforementioned task was bounced onto the Neon2Debian board17:45
sitter*forgotten even17:46
santa_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?21:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!