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 modules.) 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 more readily. > >> 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 Qt-based application) 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.) ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Pcmanfm-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
