Support for Haiku in upcoming SyncTERM release

Hey, I’m the author of the SyncTERM BBS terminal software, and I’m getting ready to release a new version. Since one of you previously offered a Haiku package (Hi @arfonzo!) I figured I would make the support official and be sure it sucks the least amount possible for Haiku users.

Currently, I’ve got it building and running well on Haiku R1/beta5 installed in a VM, and am working on the .PackageInfo file, but there’s a couple issues I’m unsure of or unable to fix.

The first issue was that there isn’t a “Downloads” folder in Haiku, so I have SyncTERM defaulting to save downloaded files to the desktop, which feels messy to me.

The second (and bigger) issue is that I’m not an artist. I hacked together a simple and ugly icon as a .png file that’s served me well over the years, but Haiku doesn’t really want raster icons, and Haiku icons have a distinctive look that my hacked together icon doesn’t come close to matching. It was suggested in IRC that I ask in here for help, so if you are interested in helping improve SyncTERM on Haiku, and have the skills to design an icon, I would really appreciate the help!

7 Likes

I tracked down the icon @arfonzo created in 2012 and added it… it’s mostly the same as the PNG icon from the package, so it’s not ideal, but at least now the need isn’t as dire.

Welcome Deuce!

You may want to consider creating a haikuporter recipe . That would allow rebuilding when needed without you having to do it manually if anyone reported a problem that could be easily solved by a rebuild. If you submit it to haikuports, the package would also automatically appear in HaikuDepot.

Agreed. Best solution IMO is to provide the user a setting within your app to choose a download location.

My skills in that department are hit and miss… :slight_smile:
If you posted the icon, people (hopefully more skilled than me) could give it a try.

1 Like

You may want to consider creating a haikuporter recipe

I did, but it seems like it’s much more complicated than simply writing a script that shuffles the files into an appropriate directory then runs the package tool.

Generally speaking, I don’t submit port-like things to OSs that I don’t run… I figure that someone who actually runs the OS will do a much better job than me, and I don’t need to go chasing all the Linux distros down myself every time I do a release.

I have SyncTERM defaulting to save downloaded files to the desktop, which feels messy to me.

Agreed. Best solution IMO is to provide the user a setting within your app to choose a download location.

Yeah, that’s what it does, but the default location is the desktop.

If you posted the icon, people (hopefully more skilled than me) could give it a try.

I mean… I’m certainly not married to the current look of the icon, I’s just something I whipped up in five minutes because I needed one, but I’ll attach it here if I can figure out how.

syncterm

As I mentioned though, @arfonzo created one a long time ago, so I’ve managed to find it and keep using it (in the package now).

I’ve uploaded the .hpkg to SourceForge now, so you can see the package in all its glory.

Usually when I do releases, I only pre-build binaries for macOS and Windows with the assumption that every other OS will build from source and have their own packaging thing. I’ll likely leave Haiku to build from source for future releases, but since 1.2 will be the first one with official Haiku support, I figured could whip up a package.

Maybe @zuMi can help you with an icon?

If time permits I could have a look at this tomorrow or so, do you have a link to the source archive?

Fair. Also, from your package it should be a quite simple recipe. There’s only the binary and its dependence on sdl2. @Begasus should be able to whip one up while his dog crams for the next exam in doggie-sunday-school… :dog:

Good enough in my book. If the users get annoyed by files downloaded to the Desktop they’ll change it.

So interestingly, there is not stable a source archive for Haiku yet… the rc2 source archive on SourceForge does not have the latest CMake/code changes for Haiku, and rc3 won’t be released until this weekend.

The nightly source archive can be found here, but it changes every night so isn’t a good thing to use for a port, but maybe it’s enough to get the port written and ready for the release (likely two weeks from now, now that I need to do an RC3).

The git repo it lives in has a syncterm-1.2 branch which will become the release once it’s done, but there’s two issues with that… first, the tag doesn’t exist since 1.2 isn’t released yet, and second, the git repo has way too much extra stuff in it… the source tarball will be what you want to use for the port for sure because it only has what you need.

There’s only the binary and its dependence on sdl2.

It would maybe be nice to include the PDF manual as well if threre’s a place people would know to look for it, but the asciidoctor-pdf Ruby gem doesn’t seem to exist in ports, so it can’t be easily built on a Haiku system (didn’t look if Ruby has been ported).

It’s hard to take inspiration from a tiny flat icon, is there a bigger image?

First thing I do before even starting on a recipe is check a build in Terminal, thus so far:

  • source at sourceforge (archive) doesn’t work, needs too much patching (expected)
  • nightly source doesn’t work, can’t find packageinfo.in (seems a bit strange to me being used to work with haikuporter) :slight_smile:
  • source at gitlab works out fine and build completes, binary launches fine also

1 Like

@Deuce might be able to help you out here?

Sorry, I jsut got home from a conference, I’ll take a look in the morning.

Actually, just took a quick look, it appears I forgot to add PackageInfo.in to the source tarball. Added it and regenerated, it should work now.

Note that you shouldn’t feel like I insist on PackageInfo.in being used if that’s not how things are done.

Nope, that’s the biggest it’s every been. As I said, it’s terrible. There was a different thing made for the website…

image

Which at least doesn’t have the ‘H’.