Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

I think it is too early to make such a large decision. The current GTK+ situation is certainly less than ideal, but there are many major (non-GNOME) projects still using it. I personally think the GTK2 vs. GTK3 fragmentation will eventually be resolved by the non-GNOME community forking GTK+ and converging to some variant focused more on stability and cross-platform support than GNOME is. If that doesn't happen, and both current versions of GTK+ gather dust while GTK4 continues along with GNOME towards strange and novel designs, then porting to Qt might be an attractive alternative.

Hello,

I noticed those recent commits:

Fix build without GTK+:
http://redmine.audacious-media-player.org/projects/audacious/repository/revisions/2bb5bedd7a97de566a74f58123401793831289ce

Qt integration (WIP):
http://redmine.audacious-media-player.org/projects/audacious/repository/revisions/041706cac5f6aaa8337f8e3641f7810ed7834ade

Add --enable-qt option:
http://redmine.audacious-media-player.org/projects/audacious/repository/audacious-plugins/revisions/9a8628bc4081c752e2213bdbe0b1dc7035cf46bc

So, does that mean you are porting Audacious to Qt now?

Regards

Yes, but don't hold your breath. :)

The Qt port is maturing at a rapid pace. Here is a screenshot from today (August 21): https://www.dropbox.com/s/91thiq31lplei3b/Screenshot%202014-08-21%2019.58.53.png

Note how it looks like a native application. Yeah, that's something gtk+ never looked like outside of X11.

I'd appreciate some guidance with regard to this Qt based work. Can it be built and tested yet?

I've checked out git on Oct 7th, resulting in "audacious-3.5-beta1-375-g1f157d1.tar.bz2", updated Fedora 21's rpms for Qt 5 build requirements, added --enable-qt and built both Audacious and its plugins. It didn't even start afterwards. If I remember correctly, it started once because of my existing user config and --enable-gtk, but it crashed. After deleting the config file, something starts but doesn't display anything. Screen is empty. Audacious icon is active in the task switcher (GNOME Shell Alt+Tab), but selecting it doesn't show anything. Backtrace shows gtk/glib main loop running.

Maybe I need to drop --enable-gtk?

@
$ audacious --qt
WARNING plugin-init.cc:104 [start_single]: Winamp Classic Interface failed to start.
WARNING plugin-init.cc:121 [start_single]: GTK Interface failed to start.
ERROR plugin-init.cc:130 [start_single]: No interface plugin found.
(Did you forget to install audacious-plugins?)
Aborted (core dumped)

$ rpm -ql audacious-libs|grep qt
/usr/lib64/libaudqt.so.0
/usr/lib64/libaudqt.so.0.0.0
@

Both gtkui.so and skins.so are installed, too.

What about qtui.so, did that get installed? Keep in mind that you also need to build audacious-plugins with --enable-qt; it won't get the flag from audacious core.

Great! That lead to something. I had compiled it with the option outside the RPM spec file and then failed at taking over the modifications into the spec file. It now starts in Qt mode, at least.

As why I've not built it directly from within the .spec file, it is because Fedora's Qt 5 packages move "moc" and "uic" outside PATH and only provide moc-qt5 and uic-qt5 in /usr/bin. The packagers say "most distributions" do that, too:

https://lists.fedoraproject.org/pipermail/devel/2014-October/203408.html

I've had to spend some time on searching the packages, adjusting $PATH and to go through multiple attempts at compiling Audacious. Only afterwards I worked on creating src.rpms.

Does Fedora provide qtchooser¹? In theory, with qtchooser, you should only need to set $QT_SELECT rather than messing with $PATH.

[1] http://manpages.ubuntu.com/manpages/saucy/en/man1/qtchooser.1.html

It is provided in a separate package "qtchooser" and without a pointer in the no-documentation-at-all package qt5-qtbase-devel, which I needed for Audacious.

Apparently, it is also controversial among Fedora devs: https://lists.fedoraproject.org/pipermail/devel/2014-October/203421.html

I'm not impressed by the rather poor package summaries/descriptions I've run into. Truncated output:

$ yum search qtchooser
qtchooser.x86_64 : Qt Chooser

$ yum info qtchooser
Description : Qt Chooser

Hmm, in this case, I am not sure if depending on qtchooser is a good idea, but maybe it is fine if we outright document it during the build process.

Hello,
with the transition to QT, I noticed that the source base also migrated to C++11.
Is it really necessary?
I'm asking that because the minimum requirement declared by QT is C++98 and this change breaks the compilation on all systems with GCC3 and also previous GCC4 toolchains.

C++11 is a much more powerful language than C++98, that's all. And the C++11 version of Audacious can be compiled with GCC 4.7, which was released in early 2012. You would have other problems trying to install the latest version of Audacious on a system older than that. For example, Ubuntu 12.04 has GCC 4.6, which is just barely too old to compile C++11; but Ubuntu 12.04 users were already missing features with the release of Audacious 3.5 due to ffmpeg¹ and libsidplay being too old. If you're worried about the Windows port, MinGW has GCC 4.8 now, and the C++11 version of Audacious compiles fine there.

¹ I fixed the ffmpeg compatibility in 3.5.1, but the point stands.

Thanks for the reply... actually I also wanted to ask if the QT5 has to be the really minimum requirement for Audacious.
Lowering a bit the requirements would open the player to other new worlds like Haiku/BeOS, AmigaOS and other platforms including several embedded systems, which are still restricted to QT 4.8.x.
I must say that I did already a little experiment myself, because CYGWIN has GCC 4.8 but QT 4.8.3 in the official downloads (although QT5 is unofficially available from cygwin-ports).

The fixes are limited to:

- adjust the included files.
Instead of including every time QtCore/QtGui/QtWidgets, I included only libaudqt.h because it already provides all stuff we need. I think that it would be a good idea to do so even if you won't support QT4.
In QT5, the widgets have been separated from the core, but it can be fixed by simply doing:

#if QT_VERSION >= 0x050000
#include <QtWidgets>
#endif

inside libaudqt.h.

- Changed how the connect() calls are done.

- Disabled qtaudio if QT5 is not available because older QT Multimedia is lacking volume control.
In this case, audio output will be played from the usual plugins used until now, or it could be compiled anyways but with volume control disabled or made in software, if someone really wants (but I do not think it is worth to do so).

After doing these fixes, easy even for me that I never used QT ;-) I got Audacious working in CYGWIN with its official QT 4.8.3.

However, these fixes have a relative importance, if the C++11 requirement cannot be lowered, unfortunately.

I hope you will find all this useful.

I am not sure why you want to spend time targetting Cygwin when Audacious can be compiled natively for Windows with MinGW.

Running an application natively on Windows surely simplifies the life to the users a lot.

Somehow, CYGWIN is a posix environment, simply like linux, FreeBSD, etc, where Audacious could run on.
Under a point of view, it is worth to try something on it, because CYGWIN is not Windows, it's like having a different OS inside, a look and feel as another platform, especially when you run big stuff like KDE or GNOME. It may be also seen as a chance, because it makes possible to test/debug/develop stuff that normally never runs on Windows. That's why I don't dislike it.

The Qt port now supports hidpi.

William Pitcock wrote:

The Qt port now supports hidpi.

Thank you.
I installed QT 5.3.2, now it has been made available in the official repository.
As I expected, besides a little problem (not related to Audacious but probably a bug into newlib: feof() is declared as a macro rather than a function, so I had to add "#undef feof" in vfs.h and neon.cc as an hack), this time I was able to compile all sources, the player and its plugins, without troubles.
Unfortunately, it does not work (see attached screenshot).
Probably, there is still something to fix inside the QT5 for CYGWIN.

Cygwin is not a supported configuration of Audacious, as has been stated many times.

We have no interest in it, as we support building Audacious natively via mingw and within a year, MSVC once we finish the migration to Qt.