Audacious 4.0 released, switches from GTK to Qt 5
audacious-media-player.org
audacious-media-player.org
Today they might limit themselves to forced registration, SEO, and spamming business contacts with carefully crafted statements designed to stir fear, uncertainty, and doubt around free licenses by strongly suggesting (without actually claiming) that commercial use without a commercial license is illegal. But tomorrow? Also, keep in mind that a business partner who isn't already familiar with Qt and LGPL is going to be about 10x more susceptible to the FUD. That's the whole idea.
My guess: 30% chance of an ugly fork and lots of drama in the next few years. Then, absent a change in direction, another 30% chance in the few years after that, and so on.
https://dot.kde.org/2016/01/13/qt-guaranteed-stay-free-and-o...
We don't even use Qt. I was just evaluating it. A year before they "reached out."
I still see that as a strike against Qt, even though I understand that the existence of a technically free fork is effectively guaranteed.
That's charitable. The FUD is consistent, persistent, and targeted enough that I'd call it "intentionally deceptive."
Monetizing open source is hard. Maybe this is necessary, and if it is, maybe that's fair. But it's also fair to stay away because of it.
https://www.qt.io/download-open-source?hsCtaTracking=9f6a217...
So Macs are out of question... Can't be signed can they?
What if we get a commercial license? Apple disallowes GPL...
Can't support GTK either, Expat Licensed GUI alternatives please...(I suggest Godot but it comes with a bit of pain and some baggage as well)
There are also other corner cases that they might want to cover, with more documentation.(Not sure if I have missed something)
If anyone has more info pls do share it. :)
... you know that even Apple ships some GPL software on every Mac right ? GPL is 100% fine mac hardware. There are even GPL apps on the appstore. Signing does not prevent you to upload a new version of the app to your own device.
Are you sure they're GPL?
Maybe they're dual-licensed, and the Apple app store is using "the other licence"?
Seem you're right. :)
Am very surprised, after reports a while back of GPL (etc) apps not being approved.
Hopefully they continue to be approved (etc). :)
it was an issue until Xcode 7 : prior to that you had to pay 99$ to Apple for the right of uploading something to your own iDevice. Since Xcode 7 this is not necessary anymore.
To my knowlage and IANAL, this is only possible with older pre-v3 licenses. v3 licenses specifically prohibit tevoisation, something that Apple's App store TOS effectively mandates by placing restrictions on what App users are allowed to do. I believe this is why apple doesn't ship recent versions of Bash.
Feel free to correct me if I'm wrong.
there are no issues with modifying, recompiling a GPLv3 app and uploading & running it on your own iPhone, iPad or Mac - it's not tivoization.
* https://www.fsf.org/news/2010-05-app-store-compliance
* https://www.zdnet.com/article/no-gpl-apps-for-apples-app-sto...
If I'm mistaken please clarify.
> https://github.com/peter-iakovlev/Telegram/issues/157
> http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
> https://thenextweb.com/dd/2019/06/04/why-does-macos-catalina...
If this were the extent of the shenanigans, I wouldn't be mad. I like having a "help me sell this to my boss" page. But it isn't the extent of the shenanigans. They went around me to shake someone down on my behalf (as I perceive it). Last time it was my boss. Next time I choose a GUI framework for an open source side project, I'll primarily worry about it being my users.
Where does it say that? Can you mention what he is having trouble with? I just took a quick glance at that link in GP and it seems to spell out the obligations of the LGPL pretty clearly on the right side, which are somewhat specific and notably don't include a requirement for your program to be open source. That requirement is only for the GPL components, which is included in the small print on the left.
Making this inference requires you to not only have outside knowledge of open source licenses and the Qt licensing situation, but to be rather confident in said outside knowledge. That's what he had trouble with.
I think that detail about GPL could be easily missed because it's written in small print, but that's a different problem. There are a lot of Qt components so it doesn't make sense to list them all on that page. A full list that can be filtered by LGPL/GPL status is here: https://www.qt.io/features
I'm assuming by outside knowledge you mean the fine print of the license: how is any company supposed to prevent your boss from having to go over that with a lawyer? This isn't even an open source thing, it applies to anyone in the software business. And this is ignoring that the GPL is probably one of the better understood open source licenses at the moment.
The key piece of information is absent.
> it seems to do as good a job as a short marketing page probably could
It could have done better in a single short sentence by stating the key piece of information, rather than leaving it to be inferred laboriously from a pile of details.
> It's not a place where they can reasonably address every common misconception
No, but it could have addressed the single largest misconception. It chose not to.
A business partner has enough money to actually pay for licenses.
I'm currently close to prealpha, if you're interested. https://github.com/cztomsik/graffiti/
> To name just a few things you usually don't need: ... flawless i18n & accessibility
Lack of basic accessibility support is (or should be) a complete nonstarter for any serious project.
I can tell when an app uses Qt because it opens in a microscopic window on my Surface. VLC users have been waiting on a fix for Qt-related fractional DPI scaling issues on Windows for years.
Have you ever hooked a high-DPI laptop to a low-DPI second monitor? What a freaking headache that is.
Say what you want about MacBook owners being brand snobs, but they never have to deal with this nonsense.
MacBooks get the hardware DPI consistency sort of right, but multimonitor support is still flaming garbage to the point where I have to run caffeine 24/7 and use rigid window manager layouts configured per scenario (coding at my desk, pair programming at someone else's desk, meeting, presentation, etc.) to be able to efficiently context switch between the modes and keep the screensaver from mutilating my layout. Windows gets the window layout consistency between monitor configurations mostly right if you ignore chrome and Electron but multi-DPI support is flaming garbage. Linux is completely hit or miss for me depending on the monitor and drivers I've got configured but in a desktop you can at least make Linux reliably not flaming garbage.
I just now realized that my 20th anniversary with computing must have passed in the last few months and looking back, all I can remember is how much every operating system I've ever used has gotten in my way.
/rant
Similarly for grandparent post, VLC runs 100% fine on my 150% scaling Win10 laptop with a 4K screen
These bugs must be somewhat transient...
There's a registry option to double the scaling of Qt widgets, but that makes everything too big.
Erm, yes, and on Windows 10 it works just fine.
> Say what you want about MacBook owners being brand snobs, but they never have to deal with this nonsense
Not true, I think Windows 10's high-DPI support is fantastic - yes, better than MacOS.
At home I have a landscape 3K monitor daisychained to a portrait 1980x1200 monitor, and it works flawlessly on Windows 10 with both my desktop and 2 work laptops. It works on MacOS, until it doesn't - it sometimes crashes when I switch between the MBP screen and the external screens.
I have a similar setup at the office, but with 2 portrait displays - I have the same issue with my MBP.
The only OS where I have to deal with this nonsense is MacOS.
But everything I use seems to work just fine on Windows 10 across multiple monitors - Office, Visual Studio, Rider and a whole host of small applications (many old) that I doubt did anything specific to enable high DPI support.
Now Win32 and UWP are just two complementary sandboxed execution models, more so when Windows 10X gets released.
Everything, everything, looks scaled and blurry. Apps, installers, widgets, menus, everything. It's amazing how fundamentally terrible everything is, all the time.
Now that I think about it though, my first experience with Windows scaling was the text scaling in (I think) Windows 7. I had it set to 120% because I had my computer hooked up to my TV, but a game I was trying to play (SWTOR) would crash on launch every time if the text scaling wasn't set to 100%, making the text in Windows unreadable unless I went up to the TV.
I'm not sure if Microsoft just can't get their shit together at all, if getting their shit together would break too many apps, or if they have their shit together but Windows app developers are all wildly incompetent.
That's definitely not the normal experience. I only see this in specific applications that either predate DPI scaling or have poor DPI scaling support. Are you running your display at a non-native resolution or something?
> or if they have their shit together but Windows app developers are all wildly incompetent.
Game developers specifically seem to have an issue dealing with slightly unusual situations. I've seen games have issues with plugging in controllers after the game has started, the primary sound output changing mid-game, the user alt-tabbing, a second monitor existing (!), etc.
Contrary to macos you should only ever run a windows display at its native resolution (in macos this is “default for this display”), and use the scaling settings to make things the right size (typically 125% or 150%).
The OS fully supports mixed dpi, but many apps haven’t been updated. There are three categories: (1) apps that are fully up to date and always look right, a minority that includes office 365 but not office 2016; (2) apps that use the older scaling api’s and only look right on the primary screen at login (so to get them to look good on another screen you need to logout, switch primary, and login) which is the majority of apps; and (3) apps that look blurry on anything not 100% scaling (96 dpi), a minority which still includes most installers for some reason.
Microsoft pushed more of the work to developers because they can’t assume the hardware is powerful enough to do what apple did: render everything in a buffer at a multiple and scale it down to the display’s resolution.
I have an external 4K display that works flawlessly if I set it to default (that is 3840x2160 with 200% scaling). If I disable scaling completely (3840x2160 with 100% scaling) it still works well, but the text is a bit too small. With anything in between and there's a noticeable lag.
Interestingly enough, if the internal display uses non integer scaling (I sometimes use 1920x1200) with integer scaling on the external screen it still works ok.
I think it's related to the fact that MacOS draws everything at 200%, and using a non-integer scale over 1920x1080 ends up with a bigger resolution than 4k, whereas 4k at 100% is still 4k.
Because I'm also using a Windows laptop for work, with 125% / 150% scaling on my laptop (fullHD on 13" + 4K external screen on 125%) and it's very far from "everything".
All the browsers are fine, IntelliJ tools are fine, terminal tools are fine, all UWP apps are fine, Electron apps are fine, chat aps are fine... so can you please explain what this "everything" is?
I don’t get why things wouldn’t work?
Also, Dark Mode support on windows (and others) still doesn't work properly, though there are workarounds.
For Windows at least, the Dark Mode support in Qt seems to have someone now assigned to the task (last few days). So it might be better with the next major release.
https://doc.qt.io/qt-5/highdpi.html
I've used Qt successfully here with different DPI, and it works well once configured for the most part. It's still not perfect on Windows, but it's a lot better than it used to be when set up properly.
Feel a touch nostalgic for the uncomplicated time when I had music on my devices, regularly "organized my music library" and could play whatever whenever, and shared them with friends. I can still rummage through my old disks and spin up some of that music from time to time.
Mostly use cloud players these days; crazy to imagine that there's nothing I can do if my favorite song/recording today is not available ten years later!
This is rather widely available.
With music you buy, you are in control.
It's about quality over quantity.
This is the stuff to buy outright.
Exploratory listening without such a commitment (youtube, spotify, bandcamp) is of course very important, and is a blessing.
Death of a couple sites with not-widely-available music, in the past few years, has distinctly shown which of those two terabytes should be more closely guarded. ‘It's all on the web‘, I've been told—well, not quite so anymore unless I upload it somewhere first.
So I would bet that any major audio-oriented streaming service beats YouTube on quality.
I tend to think as YouTube as more useful for discovery. At that, it is very good. If I decide I like something I will listen to it elsewhere with better quality.
However, this whole discussion falls firmly under ‘suum cuique’, and quite pointless in the light of `youtube-dl` being not just for Youtube, as already mentioned.
When it's an official video, I guess it's only compressed twice and they use high quality masters but still, YouTube isn't hi-fi.
Converting this to MP3 means a lossy-to-lossy transcode which can only cause further deterioration, and increasing the bitrate to 256kbps (or anything else) isn't going to fix that -- at best you won't be able to notice any audible difference, apart from having larger files for no benefit.
Unless you need MP3 files for compatibility, instead of using the -x option to extract audio and converting to MP3, you'd probably be better off just using -f with the best audio format, and perhaps re-muxing in to a different container if required.
What a shame that it died.
If anyone is looking for a decent foobar2000 alternative, Foobnix (https://github.com/foobnix/foobnix) has worked really well for me. It has some rough edges and doesn't seem (that) actively maintained, but it gets the important stuff right. Haven't come across anything else quite like it for Linux yet, unfortunately.
If there was a foobar-like folder view plugin for Audacious, I'd switch to it in a heartbeat.
That said, most of my music listening these days has been pointing mpv at an internet radio steam.
People don't have to explain their preferences in a rational way, they will just switch away from GTK3. It's cheaper.
Successful developers will try to interpret these users' feedback in a self-critical, introspective and positive way, and tweak their product based on the feedback. As opposed to continually challenging the giver of the feedback to explain their opinion in more detail, as if by repeatedly digging deeper and deeper into an opinion, you will at some point find some fundamental logical contradiction in their views that will make them re-evaluate their life philosophy on why they just don't like GTK3.
I for one think the two opinions given above are perfectly clear ("GTK3 is becoming very GNOME3 specific", "As a user, I don't want them") and can't see why further clarification is being requested. If you really need clarification on these perfectly clear opinions, it is your problem.
What I stated was that development decisions, whatever they are, are up to the developers, including which frameworks they wish to use, and how they wish to use them. Saying in any form that you don't want developers to make decisions is nonsensical, as they would not be able to write anything then. Decisions have to be made, compromises chosen, and ultimately, not everyone will get their will.
If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself.
I suspect this of being as recent an attitude as "no, it's fine that a desktop chat client should take up nearly 4 GB doing absolutely nothing, memory is made to be used".
There are enough of us who lived through the days when, no, developers didn't need to make certain decisions for us on the Linux desktop. It wasn't a perfect time but it did exist — as recently as ten years to fifteen years ago in the days of GTK+2 and KDE 3.
Again, it wasn't perfect, but those days contradict your assertion. People shouldn't have their opinions discounted because they're no longer in vogue.
I also don't really appreciate being called a "fanboy" by the GP. I use Qt as well and I don't favor any framework over another. I'm sticking to the facts here: GTK supports building apps any way you want, not just in the GNOME style. Maybe the problem is that the apps you tried happen to all be GNOME-styled apps. That's a choice that the app developers have to make consciously and has nothing to do with GTK. If there is something else you mean by "locked into GNOME" then please elaborate, because I am having trouble understanding what you're referring to.
If the user is able to spot the choice of toolkit just by using the application, I'd suspect that design decisions have been coupled to code decisions, which would be a smell by itself. I mean, what exactly would you do if the code guy says, GTK fits the code best, and the design guy says, Qt fits the design best? The answer would be "the Qt look-and-feel for design, and the GTK API for code", but you can't do that when you have coupled these decisions.
In Qt it's absolutely possible for applications to force client-side decorations and force a certain stylesheet. Maybe it's not common in the apps you use, but again, it's up to the app developer if they want to make use of those things or not.
They also break them at every release.
Regardless of that I don't see anything based on "cascading styles" as lending itself to a stable theming system anyway. The CSS is probably going to change any time a widget is added/refactored/bugfixed, this holds true on the web as well once you build up a complex library of React components or whatever. The point of it is that there are multiple styles from multiple sources that can cascade together. It's powerful but it can result in a lot of complexity, anyone who's had to add !important directives can attest to that. It needs to be strictly managed by the developers to really work correctly and to prevent the style overrides from getting out of hand. Allowing custom user CSS is only for power users who understand the caveats.
From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
Applications run as part of a system that provides certain shared system-wide features and is configured by the user. They should slot into that system.
KIO vs GVFS? :)
Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.
The only thing that has become supported in GTK fairly recently is a common appearance for them. If you notice more app developers happening to use them lately, that's a different issue driven by design trends, not by what some toolkit decides to support. Technically speaking, CSD is not exactly a new thing and has been the norm on Windows and Mac for quite a long time now. Design-wise, the practice of putting widgets into the title bar is what app developers are wanting now. Have you noticed the UI in the newest Chrome? Or iTunes? All the topmost widgets are moved up into the title bar. This is where we are headed at the moment.
And making your window override-redirect, and implementing window motion, resizing, and so on by yourself, since the window manager doesn't do it for you, and dealing with all of the ICCCM and EWMH conventions, and...
I can't stress this enough: this kind of thing was already supported for quite a long time and app developers were doing it long ago. The only thing GTK3 added was a common look and feel for it. Qt also has that now too.
Relying on GTK to be a cross-platform GUI toolkit is very risky given its current direction.
[1]: https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html
>Their developers stated on more than one occasion that GTK is a GNOME-first toolkit.
I have not heard this. I've actually seen great pains being taken to preserve Windows and Mac support in GTK4. For the record I actually think removing something because GNOME doesn't support it would be very valid and wouldn't make them a GNOME-first toolkit. A proper cross-platform toolkit would consider all the supported platforms equally and would support things that can work correctly across all of them, and in this case GNOME happens to be one of those platforms. Remember that they've also deprecated and removed things in the past that didn't work on Windows, such as all the X11-centric stuff that was present in GTK1 and GTK2.
No, they've deprecated and removed far, far more than that. They've obsoleted and dropped fundamental containers and widgets which have been present right from the 1.x days. These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly.
And they even broke compatibility with their UI file formats, with no upgrade path.
Upgrading now requires hand-editing huge piles of XML. They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. Or you have to hand-edit all of your sources. Either way, it's painful and with zero added value.
I don't expect a competently-maintained library to indulge in such huge breaking changes without a really, really good reason. The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. It's a huge "screw you" to their actual userbase: application developers.
>The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind.
I see these kinds of things being said all the time but at the end of the day, nobody seems to want to pick up the slack and start maintaining all those legacy widgets for eternity. There is a maintenance cost there too and the upstream developers don't want to foot the bill, and neither do you, so stuff gets dropped on the floor. If you don't want to deal with this then you use flatpak/snap and you pin your application to a specific toolkit version forever. Do you have any better proposals? Do we as an industry have any better proposals besides throwing money at the problem? Because I assure you GTK is not the first (or last) library in existence to break ABI.
>They could have written some simple XSLT transforms to provide an upgrade path, but they didn't.
They did. In GTK4 there is an automated tool to update the XML. It doesn't really work perfectly right now, but GTK4 is still pre-alpha. https://developer.gnome.org/gtk4/stable/ch31s02.html#id-1.6....
For whatever reason, the cross-platform UI story seems dire as ever if you don’t count web.
Other toolkits like wxWidgets are perfectly serviceable, but they are not nearly as complete.
Here is a talk when Subsurface decided to go Qt from Gtk: https://youtu.be/ON0A1dsQOV0
But something about the fonts and the UI layout always puts me off (primarily) Linux targeted (or developed) applications. Even Windows 10 doesn’t use good fonts, IMO. I don’t know why developers can’t use good native fonts or bundle some good free fonts with the application, while also having better laid out UIs. We live in the age of 4K monitors (though most people are still on 1080p or lower) and smartphones with pretty good screens that many users are used to, and yet we have applications that look like they were developed two decades ago. Even large efforts like LibreOffice aren’t immune to these deficiencies. I’m not arguing for form over function, but definitely see a need for getting more UI designers into FOSS (I’m not one, so my contributions are limited to monetary donations to projects I like or use).
To reiterate, this is not to put down the humongous efforts (which many a times remain thankless or not adequate for putting food on the table) of FOSS developers.
They definitely prefer functionality over looks.
FYI anyone reading this, take a backup of your $HOME/.config/audacious before trying the new version. It did something funny there and no files would play on the old version anymore...
How do Qt projects look + feel when ported to Mac OS X? Do they look near native or can you tell it's a Qt project and not a Cocoa project?
not dead but... here's for instance how Wireshark looked on macOS when it was using GTK :
https://blog.wireshark.org/wp-content/uploads/2013/10/osx-x1...
and here's how it looks now that it is using Qt :
https://news-cdn.softpedia.com/images/news2/wireshark-3-0-re...
But, the trend is towards Electron, which also integrates poorly with the OS -- so, I'm not sure how much looking native matters any more.
And for example AFAIK the new Apple Music app is using a web view for some parts of itself, and as much as I like having "light" apps, I generally prefer interacting with Electron UIs over most QT apps.
They're in the uncanny valley.
I don't really mind, since osx happens to be my daily driver since about a year, but whenever people claim that osx is visually coherent I can't shake the feeling they are stuck in 1998 and Mac os 8.
The problem is that Qt and other cross-platform frameworks tend to look glitchy, as in their differences are non-intentional and jarring.
They also tend to just look pretty old-fashioned, because these frameworks are pretty old now and the controls, layouts, and workflows they provide are a bit old-fashioned.
So the first impression you get for software using Qt is old and glitchy. Which isn't great.
honest question, is that the impression you get from using the Blizzard launcher (https://media.mmo-champion.com/images/news/2013/june/launche...) or stuff like Substance ? (https://www.awn.com/sites/default/files/image/featured/10157...)
I just finally got switched to Windows 10 on my work computer. Every time I start up a simple calculator, it takes up most of the space on my gigantic 27" QHD screen! Do they think I'm blind or something? The old Windows 7 calculator looked just fine and was an appropriate size.
I think people tend to assume that software that looks old-fashioned is likely to be unmaintained or buggy.
Despite rooting for GTK, I think this is where it is going.
A lot of criticism as of late was that GTK is turning from a Gimp ToolKit into a Gnome ToolKit, and you can see how dramatic was the drop in mindshare has been since that trend started.
Just like Gnome didn't really survive the 3.0 transition because the project been really stolen by thew few people who force fed Gnome Shell onto the wider community, the GTK did not survive the transition from GimpTK to GnomeTK.
I'm thrilled to see that fork attract enough new talent to apparently maintain itself and meet the needs of what's a relatively small fraction of linux desktop users.
I haven't seen any cross-platform toolkits that abide by Mac standards. Funny enough, the closest is Mozilla's toolkit. Other than that, there are always telltale signs—e.g. no one seems to grok Mac's toolbars even though they're organized by the basic laws of proximity and grouping. Qt apps have the lazy grid toolbars just crammed from left to right, occasionally with extra-large icons for the ‘designy’ look, and always with colorful icons unless something app-specific is made (like in Calibre). Plus the noisy dividers.
Also, since Qt handles all the graphics and input, it has to reimplement everything high-level that the systems provide out of the box, and presumably to track changes in all of that. Hence the past bugs of one-pixel offsets between elements where they can't be in the system. And the present non-support for system-wide key rebinding on Mac—e.g., home/end instead of cmd-left/right.
But yeah, Qt is better than something like not-obsessively-tuned Swing. As for GTK, it seems to depend a lot on the author specifically not forgetting to bundle the native-look theme.
- Ubuntu - Fedora - OpenSUSE - Debian - CentOS - ...
GTK+ since version 3 is really neat. They rust re-did the site as well: https://www.gtk.org
https://audacious-media-player.org/news/32-audacious-3-6-rel...
https://redmine.audacious-media-player.org/boards/1/topics/1...
Which reminds me, foobar2000's Mac port seems to be chugging along—though not open-source.
Qt is one.
Would it be better us every platform I use it in had an equally high quality fully native port with full feature parity across platforms? Sure, but I also understand the huge extra commitment of resources that would require, so I’m content to let them choose the trade off that works for them.