On 13-04-23 01:14 AM, PCMan wrote:
> Audacious is really perfect. However, it's core library is tight with
> Gtk+, so porting to Qt is quite difficult. I studied this earlier and
> had the conclusion.
> Fortunately, there are several nice Qt music players.
> Qmmp if you like WinAmp UI.
> Clementine is also a nice one.
> If you prefer xmms2, there exists some Qt UI frontends for it which
> are lightweight.
Unfortunately, I've already looked and been unable to find anything else
with the wide format and feature support I require.
Even ignoring features, I use almost every format plugin available for
Audacious AND I also use something (UADE) that should have been an
Audacious plugin but the developers are jerks. (They promised to break
the UADE API if the Audacious developers merged the plugin into
Audacious and the Audacious developers, like the Linux kernel
developers, weren't willing to hold up API improvements for external
I know most things support AAC, AC3, FLAC, ModPlug, MP3, Ogg Vorbis,
libsidplay, WavPack, AVI/FLV/MP4/WebM/mov/Real audio demuxing and
playback via ffmpeg and I THINK there's a GStreamer plugin for
libsndfile (.wav, .snd, .au, .voc).
However, I have yet to find anything that also does AdPlug, MIDI through
an external synthesizer, Game_Music_Emu (GBS, GYM, NSF/NSFE, and SPC at
minimum), PSF, and PSF2. (And those are just the formats/libraries I'm
using right now. I may decide to start also playing other types of
console chiptune rips like HSF or VGM tomorrow.)
...not to mention, most of them accomplish the more esoteric stuff
through plugins in the gst-plugins-bad/ugly bundles.
If I could, I'd LOVE to be running something more versatile like XMMS2
or MPD which can separate the core from the GUI and support streaming
>> On the plus side, at least the native Qt file dialogs have "Rename" and
>> "Delete" in the context menu, unlike the GTK+ ones. (but I can't
>> remember whether it was Qt4 or just the DolphinPart and the KDE 4 file
>> dialogs that play badly with my high-resolution mouse compared to Qt 3.)
> The Qt file dialogs are replaced by KDE if you're running KDE.
> Qt is extensible via plugins and it allowed overriding the file
> dialogs with your own plugins.
> If you want, we can even provide a file dialog with PCManFM.
> (Of course, someone needs to spend the time for it since it's not a
> trivial task)
I'm fine with the Qt file dialogs. Aside from a crash which I know is
specific to my system, they seem to be better than the GTK+ ones in
every way I care about. (I know the crash is on my end because, it
causes them to crash in response to ANY click, right or left, in any
Yeah, sure, it is a little weird to not have / be the root of the
virtual file system, but that's fine.
My only complaints with the KDE 4 file dialogs is that they add
unnecessary animations and extra widget clutter to the perfection that
was the KDE 3 versions, interpret shaky-handed clicks on high-resolution
mice as click-drags more readily than KDE 3 or GTK+, and don't let me
lock the icons in the places sidebar at 16x16px.
(Which means the icons change size and, therefore, throw off my muscle
memory for row height, depending on the length of the volume labels of
currently-available removable media.)
>> (And I do already have a fair few Qt apps. KRename, Filelight since
>> Baobab's radial view is a lazy afterthought, K3b since others are too
>> crash-happy or too spartan, Okular since Lubuntu's Evince doesn't do CHM
>> or offer bitmap/screenshot select-to-clipboard for PDF, GoldenDict, LyX,
>> and Skype, for example.)
> There exists many nice independent Qt applications.
> What they need is polishing, advertising, and grouped together.
> Just like what we did with LXDE, we can group some nice independent Qt
> apps as well.
For example, GoldenDict and LyX. The only major KDE applications I
really need are K3b, Tellico, and KDiff3... though I do like Okular much
more than ChmSee or xchm for reading CHM files.
> As the founder of the project, emotionally I'm a little bit reluctant
> to replace our work with others'. However, from the perspective of the
> whole free software community, merging the effort rather than
> divergence brings much more benefit to the world. So I support the
> change. :-)
I perfectly agree with the sentiment. One of my many "if I can ever find
the time" projects is to investigate the "rarfile" Python module as a
possible successor to my rar.py. (A partially-finished module for
listing files in rar archives without depending on the rar/unrar
binaries or linking against a GPL-incompatible library.)