Building CopperSpice on modern Ubuntu distributions.

[rosbacke]

Hello!

I saw a couple of cppnow talks on Copperspice, Doxypress and Libguarded. It seemed promising so I've checked out the code. Especially liked the attitude with zero tolerance toward multi-threaded bugs and viewing modern C++ as a tool to get rid of them. Also the push to get a good documentation tool for C++. Nice work so far.
I got Copperspice built on Ubuntu 16.04 after some fiddling with packages using cmake. It was fairly straight forward. Got a simple hello world going showing a window and a 'about' requester.

Later on I tried it on Ubuntu 17.04 but ran into trouble. Boils down to gstreamer0.10 not being available in later Ubuntu so I never got past the configure step. It only offers version 1.0 while CopperSpice require 0.10. Checking out gstreamer they are currently working on 1.12. Checking out the code it seems Phonon is the part of Copperspice that needs gstreamer and current Copperspice Phonon version is 4.4. Checking out Phonon they are currently working version 4.9 which should build with QT 5.8. Phonon changed gstreamer to 1.0 at version 4.8.
I also tried building gstreamer 0.10 from source but ran into trouble. Assume it is due to a modern gcc (version 6).

So currently I can work with Ubuntu 16.04 but I'm curious if you have any plans or idea of how to move forward to more modern dependencies? Is it trying to get Phonon upgraded internally to e.g. 4.9, make it possible to disable the gstreamer depenency or replace it with something else? Mostly good to know if I start writing code toward this library.

tnx for the good work.

/ Mikael R

[ansel]

Hi Mikael,

First of all, thank you very much for looking at CopperSpice and your well-researched feedback. As you note, we currently support Ubuntu 14.04 LTS and 16.04 LTS, and our next supported version will be 18.04 LTS.

You mentioned having to fiddle with some packages for the cmake build on Ubuntu 16.04. Was there anything we can note on our "Getting started" guide, or are there any changes we can make to CopperSpice to help future users?

As to the current GStreamer situation, this particular issue is not only problematic on recent Ubuntu but on other bleeding edge Linux distributions as well. We have a three pronged strategy:

1. Allow disabling phonon and building CopperSpice without gstreamer
   (We have a contributor working on this as an interim solution for applications which do not need AV functionality)
2. Upgrade phonon to a newer version that supports both gstreamer 1.0 and 0.1
   (We have not yet been able to determine if phonon 4.9 gstreamer supports both, or only 1.0. Do you know if this is the case?)
3. Examine alternatives to the phonon gstreamer backend on Linux
   (Hopefully, will not be needed)

There is a similar issue on OS X, where OS X 10.12 has removed the QuickTime API (QTKit, no relation to Qt.) I was unable to find a backend plugin for Phonon that supports the new OS X framework, AV Foundation. It sounds like you have some familiarity with Phonon, do you know of any work in this direction?

Thank you again for your interest and your support,

Ansel Sermersheim
CopperSpice Co-Founder

[rosbacke]

I didn't look very hard at the getting started guide to be honest. The fiddling mostly consisted of trying to find proper Ubuntu *-dev packages to install to get cmake going. Not sure if its there, but a command line in the documentation such as:

For Ubuntu 16.04:
> sudo apt-get install <list of -dev packages>

I got to this one, but some might be missing since the installation wasn't fresh to start with:

sudo apt-get install git gitk cmake libxml2-dev libaudio-dev xorg-dev libgl1-mesa-dev libssl-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

It could make the first build a bit faster.

I'm not a Phonon developer myself but once I starting digging into the issue it seemed to some deeper issues there. Hence the post. My impresson of the git-code for Phonon was that they ported it to gstreamer 1.0 and left 0.10 behind. Hence a switch of Phonon for CS probably means upgrading gstreamer to 1.0. But do look into this a bit closer before pouring significant amount of work based on this. It was a quick look.
If support for both gstreamers would be needed with least amount of work, I would probably start with looking into having both phonon 4.9 and 4.4 with the distribution and then make it a build time switch which one is built. One other option could be to look through the changes from 4.4 to 4.9 and see what is needed to support gstreamer 1.0.
Good to know there are some thoughts on how to proceed in the future with this.

tnx,

--- Mikael R

[barbara]

Thanks for the suggestion about installing the required packages. We will add something like this to the CS Overview documentation.

We do need support for GStreamer 0.10 for Debian Jessie, Fedora 25, and Ubuntu 16.04 and then 1.0 to support target platforms like Ubuntu 17.04. I agree we need to take a closer look at this.

If you have other suggestions or ideas please feel free to let us know.

Barbara

[marlowa]

I didn't look very hard at the getting started guide to be honest. The fiddling mostly consisted of trying to find proper Ubuntu *-dev packages to install to get cmake going. Not sure if its there, but a command line in the documentation such as:

For Ubuntu 16.04:
> sudo apt-get install <list of -dev packages>

I got to this one, but some might be missing since the installation wasn't fresh to start with:

sudo apt-get install git gitk cmake libxml2-dev libaudio-dev xorg-dev libgl1-mesa-dev libssl-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

Thanks for this. When I supplied libxml2-dev libaudio-dev xorg-dev libgl1-mesa-dev libssl-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev to apt-get install then the copperspice configure started working for me. I am on linux mint.

[marlowa]

Thanks for the suggestion about installing the required packages. We will add something like this to the CS Overview documentation.
We do need support for GStreamer 0.10 for Debian Jessie, Fedora 25, and Ubuntu 16.04 and then 1.0 to support target platforms like Ubuntu 17.04. I agree we need to take a closer look at this.
If you have other suggestions or ideas please feel free to let us know.
Barbara

Yes, please announce what the plans are to support version 1.0 of GStreamer.

[barbara]

Yes, please announce what the plans are to support version 1.0 of GStreamer.

We are currently working on a major code refactoring to add support for Unicode strings and UTF-8.

There are a few other items in our queue and full support for GStreamer is one of them. We would like to encourage you and others to contribute a pull request for adding this support or maybe a bit of research to help us along.

Barbara

[marlowa]

Yes, please announce what the plans are to support version 1.0 of GStreamer.

We are currently working on a major code refactoring to add support for Unicode strings and UTF-8.
Barbara

Can you tell us any more about the refactoring? Internationalisation is a thorny problem and I haven't seen a solution I am happy with yet. I think that part of the trouble is that different OSs tackle the problem of accepting and handling international data in different ways. So this means that any solution needs to encapsulate these areas so that the solution is OS-neutral. The file system is usually covered but this is not the only place where a user might wish to enter international characters (e.g. they may have a u umlaut in their name). There is the registry. To be sure, there is only one OS with the infamous registry but a framework library that wraps access to it needs to be able to specify internationalised strings. Personally, I would use a class whose documentation makes it clear that UTF-8 is used. I would avoid implicit conversions between objects of that type and strings (either STL strings or const char*). I would totally wide character strings. IMO there are a failed experiment.

[barbara]

Can you tell us any more about the refactoring?

We developed a new open source library called CsString which handles Unicode strings using a policy class to define the encoding. We currently support UTF-8 and UTF-16. New policy classes can be added to support any definable string encoding. For more information about this library you can watch our video.

https://www.youtube.com/watch?v=nYzi0-VAXQM ( CsString - intro to Unicode )
https://www.youtube.com/watch?v=w_kD-qAkoH0 ( CsString - library design )

Along with this library we added new string handling in CopperSpice including QStringView and QRegularExpression. Both of these classes work on whatever encoding is specified in the string class.

Refactoring all of the CopperSpice libraries to use the new string classes has been an intense process which has involved removing a lot of undefined behavior as part of the legacy code.

Personally, I would use a class whose documentation makes it clear that UTF-8 is used. I would avoid implicit conversions between objects of that type and strings

CsString is almost a drop in replacement for std::string where the latter does not specify an encoding. We agree that implicit conversions from const char * and other string classes are a bad idea. We do provide implicit conversions from string literals. CsString can be linked directly with any C++14 application.

DoxyPress will benefit from move to UTF-8. Strings which contain surrogates or values outside the BMP will now work properly. The old string classes allowed surrogates but usually applications dropped them on the floor.

If you have more questions we have not answered please feel free to ask.

Barbara