-
Notifications
You must be signed in to change notification settings - Fork 16
appimaged
future plans #68
Description
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?
Pseudo code of the end result:
appimaged.c
def main(){
libappimage.watch_directories(directories_to_be_watched, onFileChanged());
}
def onFileChanged(file){
if file.was_added:
{
libappimage.integrate()
} else if file.was_added {
libappimage.unintegrate()
}
def usage(){
...
}
All the implementation can happen in libappimage
, almost no code is left in appimaged
.
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)