1. Retro Fireworks Mac Os X
2. Retro Fireworks Mac Os Update
3. Retro Fireworks Mac Os Update

Fireworks MX is part of the companyis new Studio MX product suite, also announced today. More importantly, Fireworks MX is the first version of that product to run on Mac OS X. If you're planning on running the treasures of the past you'll find here on real old Macintosh hardware from the 90's, you sir/madame, deserve to win an Internet! For others, there's SheepShaver, a PowerPC emulator capable of running Mac OS 9.0.4 down to Mac OS 7.5.2 and there's Basilisk II, a 68k emulator, capable of running Mac OS (8.1 to 7.0).

A couple of weeks ago RetroShare has released version 0.6.6. But while download page offers quite a variety of pre-built packages for different operating systems, there is no 0.6.6 build for Mac OS (only 0.6.5 is available).

I found this peculiar, so I decided to try to build it from sources myself. It also seemed like a good opportunity to finally try RetroShare, as it has been available for more than 15 years, and I’ve heard many good things about it.

At the moment Mac OS section on download page looks like this:

Let’s take a cheeky look into the building process then.

James and John discuss eBay Finds: Test Drive a Mac brochure, Microloop 1100 Spirometer, Braun/Apple calculator. They look back at Macworld April 1991, and news includes upcoming Apple event rumors, faux Mac BBS, and chimes of death. Join our Facebook page, watch us on YouTube, and visit us at RetroMacCast.

RetroShare is based on Qt and currently it uses qmake. So as the very minimum, aside from cloning the repository, you need to have Qt installed in your system. If anything, I built mine from sources, but it will most likely just as well work if you’ll get it using official installer.

Just in case, here’s my environment:

The base application is extendable with plugins, and there is a qmake configuration option for building those too. I’ll describe the process for both variants: with and without plugins.

Building without plugins is easier, because it has less 3rd-party dependencies. And I would say, 3rd-party dependencies is the main difficulty of building RetroShare from sources.

Without plugins

There is some documentation on the matter (more about that later), from which I got to know that I need to install the following dependencies:

SDK resolving issue

Let’s try to configure it now:

So right from the very beginning you are getting this fantastic error in your face. Smells like something is hardcoded somewhere.

And indeed, if you open /path/to/retroshare/src/retroshare.pri, there is this weird block at the line 129:

This hardcoded list of versions doesn’t look good at all. And no matter what values I provided to CONFIG, the configuration was always failing with the same error. Certainly can’t tell what grand plan original developer had behind it, but it definitely does not make sense to me. So I ended up editing this block manually like this:

Why 11.1? Because that’s what xcrun reports in my system, and apparently that’s what is getting checked against during configuration.

Now the project configures fine, so we can build:

Missing OpenSSL headers paths

But during the build I got these errors:

That can be solved by explicitly providing paths to OpenSSL headers:

By the way, Homebrew had a warning about something similar:

and I tried to do so in my ~/.bash_profile:

but that didn’t help. And providing paths via qmake CLI parameters did help, so that’s what I will be doing going forward.

Missing dependencies

Next error I got was this:

That is solved by installing RapidJSON:

Then there was this error:

That is solved by installing SQLCipher:

Missing paths to linked libraries

After that everything finally built, but failed on linking stage:

That is because providing just include paths is not enough, you also need to provide paths to linked libraries binaries. So, the final sequence of commands to configure and build RetroShare (without plugins) is this:

Features

You might want to enable/disable certain application features:

• by default autologin is disabled, so you’ll need to enter your password every time you launch RetroShare, which is certainly more secure but also rather annoying
• another example is retroshare_service, which, if I understood correctly, allows RetroShare to run “headless” (without GUI). It is enabled by default, and I don’t need it
• not sure what use_native_dialogs does, but it is disabled by default, and having enabled it I seem to get more responsive GUI dialogs in the application

So my configuration looks like this:

Building takes about 8 minutes on my Mac, and as a result I get a working RetroShare application in /path/to/retroshare/src/build/retroshare-gui/src/RetroShare.app.

With plugins

RetroShare has some plugins as part of the main repository, and there are also plugins in separate repositories (for example, RetroChess).

To enable building RetroShare with plugins, you need to set this:

If you want to build more plugins than just the ones from main repository, clone their repositories and copy sources to /path/to/retroshare/src/plugins folder and add them in plugins.pro:

Retro Fireworks Mac Os X

Before building you need to install required dependencies:

The last one, OpenCV, is one crazy package. It drags a whole bunch of dependencies of its own, which in turn drag a lot more on their own, including by the way Qt. You can see the full list for yourself:

Anyway, having installed all the dependencies, you can now build the project. Needless to say, you’ll face errors about missing headers and linked libraries, so to save you some time, here are all of them:

…Yet, you will still get errors, though different ones this time. Here’s the first one:

This one is happening because RetroShare doesn’t link to one of the libraries from OpenCV. To find out which one, you can google for cv::VideoCapture and discover that it’s part of videoio, so you need to add that missing link with LIBS+=-lopencv_videoio.

Next error was more difficult to figure out:

Luckily, I’ve encountered something similar (not exactly) before, so soon enough I suspected that it’s yet again Mac OS providing an obsolete version of a library. And indeed, after I installed and used the latest XSLT library:

the problem was gone. So, here’s the final configuration command (with the features I’ve enabled):

Having built such a configuration, aside from RetroShare.app you will also get plugins built in /path/to/retroshare/src/build/plugins/**/lib/*.dylib. These files needs to be either bundled into RetroShare.app/Contents/Resources/ or copied to /Users/YOURNAME/.retroshare/extensions6/ (or whichever path is set in Preferences). Having done that, when you launch RetroShare next time, it should discover the plugins:

What about building from Qt Creator

You might ask, why building with bare qmake from CLI, why not building from Qt Creator?

Well, first of all, building from CLI is just faster and actually more convenient. But also here’s what I get when I try to build the RetroShare project from Qt Creator:

And I’ve no idea what this is about. I have CMake discoverable in my PATH, and also it is added in Qt Creator settings, and also I can build other CMake projects from Qt Creator just fine. Yeah, no idea.

Bundling resources

There are certain styles files which need to be bundled in the application bundle. Not sure why those are not added to resources.

So, if you won’t bundle those, the application will still work, but you will be missing some skins/styles in the list of available style options, for example Bubble style for chats:

Bundling stuff into application bundle on Mac OS with qmake is done via QMAKE_BUNDLE_DATA. In /path/to/retroshare/src/retroshare-gui/src/retroshare-gui.pro on line 275 there is a block for macxscope - that’s where the application icon is getting bundled, by the way. To bundle styles (or other resources) too, add the following lines:

Having configured and built the application, you should get the following contents in your RetroShare application bundle:

Making a DMG

If you’d like to distribute your build to other people, you’ll need to bundle required libraries and frameworks and also make a DMG.

Why DMG? No particular reason, really. It can just as well be a ZIP archive, but DMG seem to be more common for distributing applications on Mac OS.

In order to find and copy all the required libraries and frameworks, I would recommend to use macdeployqt. Actually, I would not recommend it, as it seem to bundle some redundant things as well, for example Virtual Keyboard, which I don’t think is used in RetroShare. But still - it does the job, so it’s easier to copy all the dependencies with macdeployqt than to find and copy them manually. Though RetroShare plugins do need to be copied manually.

Conveniently enough, macdeployqt can also make a DMG. So here’s the entire chain of commands for deployment:

Homebrew is awesome

I must say, Homebrew is an absolute life savior. Getting (and building) all the dependencies without it would take dramatically more time. Or maybe I would have just given up halfway.

About RetroShare

I’ve never used RetroShare before, and here’s what I can tell after using it for a week.

Documentation isn’t great

Documentation, and namely Mac OS build instructions, is scattered across several places. I could count at least five:

1. Three documents (and a patch) in the main repository:
   • MacOS.10.6_RS_Compilation_Instructions.txt
   • MacOS_X_InstallGuide.md
   • OSX_RS_Compilation_Instructions.txt
   • retroshare-mac-build.patch

The manual for building is not very helpful, which is why I created this very article. I would even say, the instructions from manual are half-baked and written in a negligent manner, there are a lot of typos and it even contains nonsense like:

In QtCreator Option Git add its path:

That is from the section about building RetroShare on Mac OS.

General documentation content also seems to be outdated. There are screenshots of menus and settings that no longer exist, and some instructions refer to no longer existing things as well.

Surely, I would be happy to make my contribution and update the documentation with my instructions, and also to fix typos and to make it look better. But given its current state, it just feels like my efforts would go into a void. At the very least documentation should be concentrated in one place first.

Inconsistent connectivity

RetroShare requires you to have “friends” - other people’s nodes who added you as their “friend”. There are no servers: basically everyone is a server, and together they form a network.

That is the first difficulty you will encounter, but that is not an issue, and actually that is one of the main features of RetroShare. It’s even awesome. Also, luckily enough, I’ve got invites from several people, so I had at least something to connect to.

The real issues started to appear later: I tried running RetroShare on Windows, Mac OS and Linux, and I had different experience on all three.

Retro Fireworks Mac Os Update

Windows

On Windows I seemed to get connected at first, and I was even getting forums, chats and so on, but the very next day it just stopped: I am no longer able to see any forums, and all the chats I entered the day before now have no people in them.

The NAT and DHT indicators show the following:

And neither of them ever got green.

Mac OS

Then I tried it on Mac OS, as by that moment I’ve managed to build it. There it was better, and I get forum posts, chats and so on.

The NAT and DHT indicators, however, are all red:

Plus Network settings seem to have some troubles getting external IP, though I am not sure if it matters:

Linux

Finally, I tried RetroShare in a virtual machine running Linux, and would you look at that:

Everything is green!

No idea, how come the same thing works so differently across different platforms in the same network. I even tried forwarding ports on my router - that didn’t change a thing: still, only Linux had green DHT indicator, and Windows was still having troubles getting content.

Overall

As much as I wanted to like it, as a user, I can’t say that I will use RetroShare every day or rely on it for something important. It could be that this is because I am still an unexperienced user, but it has been more than a week as I’m trying to get familiar with it, and now I am about to give up.

The idea is certainly great, no doubt about that, especially looking at how “normal” internet is going to shit, but implementation is certainly not perfect. Aside from inconsistent connectivity, there are random (but seldom) application crashes, GUI can freeze on certain actions, notification flags on tabs do not disappear even though there are no unread items left, etc - all that results in not a great user experience.

Retro Fireworks Mac Os Update

On the bright side, though, the repository is rather active, so hopefully it all will get better eventually. Maybe I will even find some time to help fixing those issues.

And as a developer, I must admit the fact that (despite the length of my article) RetroShare actually builds just fine on Mac OS, and almost all the troubles I had were coming from missing dependencies. Given the cross-platform nature and the size of the project, this is quite impressive, especially considering that Mac OS is not its primary target platform.

Here are magnet links for my RetroShare 0.6.6 builds on Mac OS:

Let me know if it fails to run on your system, because I suspect that macdeployqt doesn’t actually pack all the dependencies.