On Sun, 3 Jul 2022 20:54:51 +0100 Wawrzek Niewodniczanski <m...@wawrzek.name> said:
> Hi, > > I'm not sure if that's the right place to ask, but ... > > I have a bunch flatpak applications. The GTK one are all fine, the > QT(5) cannot open files. I was looking through the internet and notice > this bug report: > https://github.com/flatpak/qt-flatpak-demo/issues/16 > > In the related issue, someone was having a problem, because of using > i3 (https://github.com/flatpak/xdg-desktop-portal/issues/336) > > I use self build enlightenment in Crux, so I wonder if there is > anything I adjust in E to make it work, or maybe I should look in > another direction. Ideally, I would prefer not to pull half of KDE to > build a xdg-desktop-portal-kde. > > I have: > E: 0.25.3 > EFL: 1.26.2 > > Cheers, > Wawrzek No idea but... it seems the issue is either with Qt or flatpak itself. possibly expecting a specific dbus service. it affects everyone else too it seems (no de at all - as you mention i3 etc.). my guess is this is a bad implementation of something in Qt and/or flatpak assuming a big desktop env. solution: dont use that app. certainly not in flatpak form. if they like to break apps and assume only a major DE of some sort to work in then they are not interested in you as a user unless you use those. Everyone on i3, fvwm, e, lxde, whatever will also suffer. in general i would advise keeping away from snaps, flatpak etc. - they have issues with all sorts of things - especially themes. if you have a gtk (or qt) theme engine installed and config for this, then the qt/gtk in the snap/flatpak can't use this engine module as it's system installed... but the theme config the breaks. this has been going on for years and years now. you also pay a big price in both disk space and memory usage. the point of shared libraries is to SHARE them. the same library used by 20 processes has data paged in from disk only once in memory. that data for the vcode for that library exists only once in memory for all 20 processes. shared libraries save you memory. they save you I/O cost of loading code into memory because it's already there from a previous process. they improve security and bugfixes by having a security or bug fix installed once and updated once for all those 20 processes rather than 20 developers having to manually choose to upgrade/update. there are a lot of downsides to this whole way of working. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
