You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 3, 2020. It is now read-only.
appimaged is a key component of the AppImage experience (for me, anyways) and I am critically dependent on it. I will not be going away.
If we can improve appimaged by borrowing some code from appimagelauncherd then fine. But let's not "replace" appimaged by something else; instead improve it (and share code with the other tools under the hood).
I don't want yet another new repo, new name, new instructions and so on. Having moved appimaged out of the AppImageKit repo was already a hassle that I didn't really like. For me, appimaged (apart from the performance and stability issues) does exactly what it needs to do, and I don't want or need something else.
If we want to switch the code then please let's do it gradually, I am not keen on having two branches of appimaged in parallel. The way I envision the refactoring is that a new high-level functionality gets added in libappimage, then appimaged is changed to consume that instead of implementing the functionality in appimaged (and appimagelauncherd), and over time there will be almost no code left in appimaged anymore; most code will be coming from libappimage. Makes sense?
appimaged
is a key component of the AppImage experience (for me, anyways) and I am critically dependent on it. I will not be going away.If we can improve
appimaged
by borrowing some code fromappimagelauncherd
then fine. But let's not "replace"appimaged
by something else; instead improve it (and share code with the other tools under the hood).I don't want yet another new repo, new name, new instructions and so on. Having moved
appimaged
out of the AppImageKit repo was already a hassle that I didn't really like. For me,appimaged
(apart from the performance and stability issues) does exactly what it needs to do, and I don't want or need something else.If we want to switch the code then please let's do it gradually, I am not keen on having two branches of
appimaged
in parallel. The way I envision the refactoring is that a new high-level functionality gets added inlibappimage
, thenappimaged
is changed to consume that instead of implementing the functionality inappimaged
(andappimagelauncherd
), and over time there will be almost no code left inappimaged
anymore; most code will be coming fromlibappimage
. Makes sense?Pseudo code of the end result:
All the implementation can happen in
libappimage
, almost no code is left inappimaged
.But again, let's do it "step by step" in the master branch rather than having a "appimaged 0.2" in parallel for half a year or so.
Originally posted by @probonopd in #67 (comment)
The text was updated successfully, but these errors were encountered: