Riffing on the idea a little, I thought that apps distributed as AppImages would work well with a Sparkle[0]-style update mechanism. The developer hosts an RSS feed that lists releases with links to the AppImage files, and the app periodically pulls it and offers to fetch the newer AppImage. From there, Grr could form the basis of an “app catalog” that shows known feeds and the latest app versions.
Cheers, Graham. [0] https://sparkle-project.org/ > On 26 May 2026, at 17:27, Joseph Maloney <[email protected]> wrote: > > Some of the other repos like libs-gui have GitHub workflows that use a script > to pull libobcj2, tools-make and all the needed things. I was thinking you > could do the same for the individual app repos. > > Joseph Maloney > > Sent from Proton Mail <https://proton.me/mail/home> for iOS. > > > -------- Original Message -------- > On Tuesday, 05/26/26 at 11:24 [email protected] <mailto:[email protected]> > wrote: > Yes that’s an option, but a lot of the requirements are the same (objc > runtime, base, gui, back, the helper tools, the config file etc) so there’s > also value in having a shared process that all apps can opt into. I don’t > know that gnustep-make is the right place for this, but it has some useful > attributes. Another option is to use one of the other “packaging” outputs > like deb and then a package converter to build the AppImage. > > Cheers, > Graham. > >> On 26 May 2026, at 17:18, Joseph Maloney <[email protected] >> <mailto:[email protected]>> wrote: >> >> That's really cool. I wonder if it would make more sense to make a reusable >> workflow that could apply to specific repos like apps-easydiff, >> apps-projectcenter, apps-gorm instead of tools-make though? That way you >> just go to those repos, get the appimages, etc. >> >> Joseph Maloney >> >> Sent with Proton Mail <https://proton.me/mail/home> secure email. >> >> On Tuesday, May 26th, 2026 at 11:12 AM, [email protected] >> <mailto:[email protected]> <[email protected] <mailto:[email protected]>> >> wrote: >>> HI all, >>> >>> I used some time today to prototype this in GNUstep make, and successfully >>> built a portable image of EasyDiff: >>> >>> https://github.com/gnustep/tools-make/pull/70 >>> >>> I think lots of caveats (documented in the PR description), but it >>> basically works. It would be nice to have CI that builds non-flattened >>> AppImages that work on multiple architectures, for example. >>> >>> Best wishes, >>> >>> Graham. >>> >>>> On 25 May 2026, at 12:37, [email protected] >>>> <mailto:[email protected]> via Discussion list for the >>>> GNUstep programming environment <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>>> Am 25.05.2026 um 10:41 schrieb Riccardo Mottola >>>>> <[email protected] <mailto:[email protected]>>: >>>>> >>>>> Hi, >>>>> >>>>> [email protected] >>>>> <mailto:[email protected]> via Discussion list for the >>>>> GNUstep programming environment wrote: >>>>>> I think, GNUstep needs lower hurdles for entering our ecosystem and so I >>>>>> had the thought „What if we distribute the GNUstep dev tools as >>>>>> AppImage?“, e.g. bundling everything needed (basic GNUstep installation; >>>>>> compiler, linker, make; Gorm.app and ProjectCenter.app; some example >>>>>> code) into an AppImage like PikoPixel did, so that our App can be run >>>>>> everywhere AppImages are supported. >>>>>> >>>>>> What do you think about the idea, would it help our cause? >>>>>> >>>>>> What would be the prerequisites for such an attempt? >>>>>> >>>>>> How much work would it be? >>>>>> >>>>> >>>>> I don't know about AppImages but GNUstep supports packing everything into >>>>> a single directory containing Application, frameworks, themes, >>>>> preferences into a single folder. >>>>> >>>>> It is useful to ship a single application with its environment, I use it >>>>> with success on windows and have scripts for that. Very convenient. >>>>> Theoretically it can also contain more than one app. >>>>> >>>>> It is instead not very smart having several directories for each app, >>>>> since that way you have multiple runtime installations and running them >>>>> in concurrency may cause issues (beyond space waste). I don't know how >>>>> AppImages would handle this. >>>> >>>> I mentioned AppImages because those are a recognized way to distribute >>>> apps für Linux (and BSD? I don’t know). Yeah, they somewhat reinvented the >>>> wheel after OpenSteps app bundle, but they still seem to be the way >>>> commonly used. Please correct me if I am wrong. >>>> >>>> Despite all this I am off course open to other but similar easy ways to >>>> distribute (binary) apps to users. >>>> >>>>> >>>>> -R >>>> >>>> kind regards, >>>> >>>> Lars >>> >> >
