Re: discussion: GNUstep developer tools as AppImage?
James Carthew <[email protected]> Mon, 25 May 2026 20:25:50 +1000
| Newsgroups | gmane.comp.lib.gnustep.general |
|---|---|
| Message-ID | <CAK1+2aryLOZKz=K-h-9Pv0=azh7TWh2Ce96CnM0T0=J6zfR51g@mail.gmail.com> |
--000000000000222b440652a1ceb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Has anyone looked into shipping a linux equivalent to a DMG image for GNUstep applications? On Mon, 25 May 2026 at 18:42, Riccardo Mottola <[email protected]> wrote: > Hi, > > [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 =E2=80=9EWhat if we distribute the GNUstep dev tools as A= ppImage?=E2=80=9C, > 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. > > -R > > --000000000000222b440652a1ceb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Has anyone looked into shipping a linux equivalent to a DM= G image for GNUstep applications?</div><br><div class=3D"gmail_quote gmail_= quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 25 May 2026 = at 18:42, Riccardo Mottola <<a href=3D"mailto:[email protected]= ">[email protected]</a>> wrote:<br></div><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">Hi,<br> <br> <a href=3D"mailto:[email protected]" target=3D"_blank">lar= [email protected]</a> via Discussion list for the GNUstep <br= > programming environment wrote:<br> > I think, GNUstep needs lower hurdles for entering our ecosystem and so= I had the thought =E2=80=9EWhat if we distribute the GNUstep dev tools as = AppImage?=E2=80=9C, e.g. bundling everything needed (basic GNUstep installa= tion; compiler, linker, make; Gorm.app and ProjectCenter.app; some example = code) into an AppImage like PikoPixel did, so that our App can be run every= where AppImages are supported.<br> ><br> > What do you think about the idea, would it help our cause?<br> ><br> > What would be the prerequisites for such an attempt?<br> ><br> > How much work would it be?<br> ><br> <br> I don't know about AppImages but GNUstep supports packing everything <b= r> into a single directory containing Application, frameworks, themes, <br> preferences into a single folder.<br> <br> It is useful to ship a single application with its environment, I use it <b= r> with success on windows and have scripts for that. Very convenient.<br> Theoretically it can also contain more than one app.<br> <br> It is instead not very smart having several directories for each app, <br> since that way you have multiple runtime installations and running them <br= > in concurrency may cause issues (beyond space waste). I don't know how = <br> AppImages would handle this.<br> <br> -R<br> <br> </blockquote></div> --000000000000222b440652a1ceb5--