Audacious 4.0 released, switches from GTK to Qt 5(audacious-media-player.org)
audacious-media-player.org
Audacious 4.0 released, switches from GTK to Qt 5
https://audacious-media-player.org/news/45-audacious-4-0-released
175 comments
GTK integration in terms of look and feel on windows and macos has been so bad for so long that I think the only valid use case for it is if you're targeting gnome specifically.
Switching to Qt isn't automatically a slam dunk on Windows.
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.
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.
All Qt developers have. I wouldn’t put all the blame squarely on Qt. Windows high DPI support is just awful on top of Qt’s neglect.
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.
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.
As someone who regularly uses a 15" MacBook Pro (for work) and a workstation desktop + Thinkpad X1 Extreme with Windows 10/several Linux distros (for hardware and software personal projects, respectively) with lots of expensive brand hardware for both laptops, I loathe them all with a passion.
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
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
If you're willing to switch desktop environments, Cinnamon seems to at least consistently remember monitor layouts between different configurations. Mixed DPI is still garbage though; I think it's basically a poor underlying model with X11, but I'm no expert on the implementation.
I have been running two 1440p displays on my Retina (on 150% scale) laptop and they've been playing nicely for as long as I've had this job. It works quite well for me, no need to run any special WM programs except for Divvy
Similarly for grandparent post, VLC runs 100% fine on my 150% scaling Win10 laptop with a 4K screen
These bugs must be somewhat transient...
Similarly for grandparent post, VLC runs 100% fine on my 150% scaling Win10 laptop with a 4K screen
These bugs must be somewhat transient...
I dunno. I've got 150% scaling on my Surface Go with a 10 inch screen. The VLC UI is a mixture of partially scaled elements for me right now: https://imgur.com/a/1j4wWUd
There's a registry option to double the scaling of Qt widgets, but that makes everything too big.
There's a registry option to double the scaling of Qt widgets, but that makes everything too big.
I have a Windows laptop for work (my first time using Windows as a daily driver since I think 2003), and wow is it awful.
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.
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.
It sounds like you are on a non-native resolution because most apps should be fine on your primary screen at least.
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.
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.
MacOS renders everything at the highest resolution and then downscales? Does that mean there are no performance benefits from using a lower resolution (or even potentially a performance hit from the downscaling)?
My experience with an older MBP (Late 2013 15" with dedicated GPU) is that there's a performance hit for non integer scaling.
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.
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.
yes. but also the graphics library and windows library is also a little bit better than on windows.
> Everything, everything, looks scaled and blurry
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.
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.
Would you mind listing what "EVERYTHING" in your list is?
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?
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?
> Have you ever hooked a high-DPI laptop to a low-DPI second monitor? What a freaking headache that is.
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.
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.
I agree that Windows 10 is better, but I would note that it’s only truly good for apps updated to the Windows 10 API (which differs from the Windows 8.1 one, which differed from 8.0), so I haven’t seen wide support outside whatever we’re calling UWP apps these days.
I don't use any "Windows App Store Apps" if that's what you mean by UWP apps (I did a lot of Windows desktop dev on WinForms, then some on WPF, but haven't kept up since then).
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.
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.
UWP is the modern replacement for Win32, stuck in Windows XP cryogenic state, it is not only for the store since MSIX package format got released two years ago.
Now Win32 and UWP are just two complementary sandboxed execution models, more so when Windows 10X gets released.
Now Win32 and UWP are just two complementary sandboxed execution models, more so when Windows 10X gets released.
Huh? I know for a fact Qt 5 itself supports fractional scaling because it works on Linux and especially KDE.
I don’t get why things wouldn’t work?
https://doc.qt.io/qt-5/highdpi.html
I don’t get why things wouldn’t work?
https://doc.qt.io/qt-5/highdpi.html
The DPI Scaling may be down to using earlier versions of Qt or being misconfigured.
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.
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.
Yeah..
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.
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.
VLC does not look like using Qt, at least on macOS.
Qt's license and cost is another valid reason to continue developing on GTK
All the important parts of Qt are available under LGPLv3. This only makes a difference to you if you want to do Tivoization of your software (Gtk uses LGPLv2, this being the only major difference AFAIK). In which case you still have the option to buy a commercial license.
Yeeeeahhh.... at the moment. They have gotten really aggressive about commercial licensing recently, and even a conservative extrapolation should give one pause.
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.
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.
Qt will be free because there is agreement with KDE Free Qt Foundation
https://dot.kde.org/2016/01/13/qt-guaranteed-stay-free-and-o...
https://dot.kde.org/2016/01/13/qt-guaranteed-stay-free-and-o...
The Qt Company went over my head and tried to deceive my boss (as I perceive it).
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.
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.
Yes, there is a lot of FUD about the licensing for Qt when you search online, definitely not helped by how unclear the Qt site's explanation of it is (to me at least)
> unclear
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.
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.
I don't find this unclear at all. I'm not sure what you would do to make it clearer. Thoughts?
https://www.qt.io/download-open-source?hsCtaTracking=9f6a217...
https://www.qt.io/download-open-source?hsCtaTracking=9f6a217...
My boss looks at this page, he sees that open source programs can use Qt for free and that commercial programs need to pay. That's not the case, but the page is carefully worded to prevent him from confidently coming to the correct conclusion.
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.
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.
>he sees that open source programs can use Qt for free and that commercial programs need to pay.
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.
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.
So, by your own admission, the critical piece of information my boss cares about must be inferred from the fact that it is absent from a sizeable pile of relatively technical details and from the fact that no detail (especially the GPL sub-component callout) implies it in turn.
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.
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.
No, my point is that it doesn't have to be inferred, and that the relevant information does seem to be all there. IANAL and this is only based on my own understanding of those licenses, but it seems to do as good a job as a short marketing page probably could. It's not a place where they can reasonably address every common misconception about the LGPL that someone might have. Your boss can't be helped if he is going to assume the worst just from reading what amounts to a single powerpoint slide.
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.
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 relevant information does seem to be all there
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.
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.
Wouldn't it be logical to expect someone to consult a lawyer when making such a decision?
Are you being sarcastic?
> Make "open" consumer devices
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. :)
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. :)
> So Macs are out of question... Can't be signed can they?
... 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.
... 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.
> There are even GPL apps on the appstore.
Are you sure they're GPL?
Maybe they're dual-licensed, and the Apple app store is using "the other licence"?
Are you sure they're GPL?
Maybe they're dual-licensed, and the Apple app store is using "the other licence"?
Interesting. Event though some of the repos listed didn't seem to have licensing info in any obvious place, several of the GPL* ones did.
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). :)
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). :)
Only works if you are the sole copyright holder, and not using code from someone else.
> 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...
> 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...
> Apple ships some GPL software on every Mac right [..] re are even GPL apps on the appstore.
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.
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.
https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...
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.
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.
I believe there are issues and serious ones at that. The lawyers at the FSF seem to agree:
* https://www.fsf.org/news/2010-05-app-store-compliance
* https://www.zdnet.com/article/no-gpl-apps-for-apples-app-sto...
* https://www.fsf.org/news/2010-05-app-store-compliance
* https://www.zdnet.com/article/no-gpl-apps-for-apples-app-sto...
While users are still allowed to run software of their choosing on the Mac I would think it would be perfectly acceptable to provide software that could be built and run outside of the mac app store.
If I'm mistaken please clarify.
If I'm mistaken please clarify.
LGPL != GPL
How dare them, wanting to be paid for their work!
A business partner has enough money to actually pay for licenses.
A business partner has enough money to actually pay for licenses.
Qt being C++ also makes creating language bindings often harder so not all languages will let you build a Qt interface. GTK is C so it's more straightforward.
Update you. Qt has been LGPL many years.
Both reasons are why I'm trying to develop an OSS alternative with easiness & platform-independence of the web but much lower system requirements than what electron has.
I'm currently close to prealpha, if you're interested. https://github.com/cztomsik/graffiti/
I'm currently close to prealpha, if you're interested. https://github.com/cztomsik/graffiti/
Under project scope, there's this statement:
> 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.
> 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'd demand better than basic accessibility support!
https://www.youtube.com/watch?v=GwSh0dAaqIA
https://www.youtube.com/watch?v=GwSh0dAaqIA
you can join the effort and help me, the scope is limited to something I can do myself in reasonable time :-)
This is ultimately why I went with gtk in a recent Rust project. Qt bindings are a pain, and the license stuff was coming out. But most of the native Rust GUI libraries don't even try. Maybe its a maturity thing and they'll get there but I picked GTK for now
Note though that GTK has no accessibility support on Windows and Mac. If you're only targeting GNOME, then that's fine. For something that's more or less accessible cross-platform, I'd go with wxWidgets or something Web-based.
A friend and I were just wishing something like this existed. "pre-prealpha" is a bit too early for me, but I definitely wish you luck in this.
I thought the license issue was one of the past?
Back in the day when I used desktop music players on linux I cycled through a whole bunch: Audacious, Rhythmbox, Banshee, Amarok, Songbird(Mozilla!), Moc(Oh, so minimal!), Cmus, mpd (server/client), and probably more that I'm forgetting now.
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!
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!
Buy music, don't rent it. Pay for downloadable files, or for physical media if you are into it.
This is rather widely available.
This is rather widely available.
It's significantly more expensive if you listen to a wide range of music. Buying albums, or even just individual songs, can very quickly surpass the $10/month you pay for Spotify. Maybe that's worth it to you, but I can't blame most people for just paying for a subscription.
The issue is control. Albums are regularly disappearing from the Spotify catalogue, sometimes reappearing later. Sometimes specific albums in a band's history are missing because that particular label doesn't have an agreement with Spotify. And you never know if it's a crappy modern brickwalled remaster. Not to mention the woefully bad curation, mixed up artists, incorrect genres/years, you name it.
With music you buy, you are in control.
It's about quality over quantity.
With music you buy, you are in control.
It's about quality over quantity.
Same with video streaming. With Netflix you aren't guaranteed the show won't suddenly just disappear before you finish it -- happened multiple times for me. I've been partly going back to Blu-ray for better availability and picture quality. Netflix is still very good for exploratory watching though, but Blu-ray is very very good for stuff like classic HBO series and BBC nature documentaries.
I've seen some people suggest buying one album per month and then pirating everything else (or streaming everything else). Best of both worlds, sort of.
If you listen to a wide variety of music, likely some of it is more important for you, something you don't want to lose.
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.
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.
I bought my first music on Bandcamp a couple of days ago (they had a day when 100% of sales went to the artists). That seems like one of the best ways to support artists while still having a cloud-hosted library.
If your library of favorites doesn't amount to a couple terabytes like in, ahem, some cases, then it's pretty easy to dump the selected bunch with `youtube-dl`.
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.
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.
Last I checked audio on YouTube is very low bitrate and sounds a lot worse than what popular online mp3 stores will give you.
256k mp3 using youtube-dl. Works for me. To me 192k is borderline, 96k is very low. Prefer high quality lame vbr encoded, but I'll take what I can get :-)
Youtubes's best available audio is usually either 128kbps AAC-LC or 160kbps Opus -- both these codecs usually sound substantially better than MP3, and at these bitrates should be "transparent" with most material, (aside from whatever other processing YouTube does, or what was done before it was uploaded to them).
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.
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.
It can be super bad because the YouTube video is a slideshow with a mp3, compressed before being uploaded to YouTube, and compressed by YouTube again.
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.
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.
`youtube-dl` downloads from many more sites than just YouTube. As for the quality, people listening to streaming music probably tend to not pay much attention to that. As indicated by the popularity of music uploads on YouTube.
Well, higher quality audio is feasible to stream from a technical perspective. It's just that YouTube does not prioritize that. They likely care more about video experience.
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.
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.
Youtube in HD modes often has AAC at 192 kbps. Bandcamp, which I'd guess is a music-oriented service, for non-bought tracks seems to give me mp3 at 128 kbps. So yeah, sounds like Youtube is quite alright for discovery until you're ready to part with the money (though Bandcamp is much lighter on the cpu overall).
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.
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.
Wow, Banshee.
I liked it so much and no other player managed to replace it for me.
What a shame that it died.
What a shame that it died.
Audacious is pretty slick (especially with this latest release), but lacks the features that foobar2000 has that I need (namely, a directory/folder view that can replace the active playlist when clicked).
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.
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.
I just run foobar2000 under wine. The font rendering is a bit iffy (some lines of text get clipped horizontally and vertically, as if the calculated dimensions are smaller than the rendered dimensions), but it doesn't bother me enough to investigate.
That said, most of my music listening these days has been pointing mpv at an internet radio steam.
That said, most of my music listening these days has been pointing mpv at an internet radio steam.
Yeah, foobar2000 has worked well under Wine for me in the past. It doesn't work as well when playing music from my NAS via NFS, though..
Have you tried DeaDBeeF Player? It was supposedly created as an alternative to Foobar2000
https://github.com/DeaDBeeF-Player/deadbeef
https://github.com/DeaDBeeF-Player/deadbeef
Try clementine
Kind of a tangent, but why switch from GTK to Qt 5? Or rather, why Qt 5 rather than some other cross platform UI framework or even GTK 3? Is it ease of porting it for new features compared to something else? And/or is Qt just that much nicer to use?
Qt 5 is just the best in class for cross-platform GUI development. It's huge and slightly idiosyncratic in places, but developing cross platform UIs (and even lots of platform specific UI patterns) is pretty straightforward. The standard UI controls are very flexible and powerful. Bugs due to differences between platforms are really rare.
Other toolkits like wxWidgets are perfectly serviceable, but they are not nearly as complete.
Other toolkits like wxWidgets are perfectly serviceable, but they are not nearly as complete.
GTK3 is becoming very GNOME3 specific, while Qt5 is still agnostic and easy to port on different platforms.
Can you elaborate? If you're talking about the client-side decorations in GTK, those are up to the app developer to choose if they want them or not.
They deprecated functionality that no longer fit GNOME's workflow even if it is when it's still needed on other desktops and operating systems (see systray icons[1]). Their developers stated on more than one occasion that GTK is a GNOME-first toolkit.
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
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
I don't see how that follows and I think your explanation is a bit mixed up. That functionality was deprecated precisely because it WASN'T cross-platform, and there was no way to make it work correctly on all platforms because of how much it was tied to legacy behavior. It never even worked on Mac, and it won't work now on Wayland either, so that's why it's got deprecated and removed.
>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.
>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.
> functionality was deprecated precisely because it WASN'T cross-platform
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.
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.
>These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly.
>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....
>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....
As a user, I don't want them, and I don't want the app developer to make that choice for me.
The developers makes every decision on how an application works and looks (It's part of the code). The top row of pixels is no different.
It feels like everyone someone voices an opinion about GTK3 explaining why they don't like it, some GTK3 fanboy has to chime in questioning the opinion and implying it isn't rational. Yeah, this makes me want to stick with GTK3 even less.
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.
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.
I agree. Asking for deep details is like asking “what’s wrong with you” instead of the reverse. Another show stopper for gtk is pretty trivial: it’s a real pain in the ass to get a working set of dlls on windows. The most sane way I know is to incrementally cut it from msys2 installation. That’s plain stupid and is killing an already half-dead framework, which was pretty good at the 2.x days. It locked itself into gnome, which is not even a crushing leader on linux desktops.
I haven't tested it but I believe there is a "gtk" package in vcpkg that can be used. Windows support should still work fine, but improving the experience there has never really been a priority simply because of lack of developer interest. Unlike Qt, there is no company behind it, it's open source managed by a non-profit and anyone can work on it. Right now there are only ~2 developers contributing full-time and they work for Red Hat. So unless someone else wants to hire developers to work on it, that's who is calling the shots and they are going to focus on their platform.
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.
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.
No clarification at any point was necessary. Despite your rant here, I made no claims as to which was better, or whether a users opinion on that particular aspect was valid. Beauty is in the eye of the beholder, so one cannot claim right or wrong.
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.
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.
> 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 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.
As someone who isn't following the Qt vs. GTK debate closely, this makes me ask myself why the choice of a code library -- which should be based on how well it fits into application code and similar criteria -- affects the user at all?
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.
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.
The developers of Qt applications do not force how the UI will look like. Users can customize it with local style sheets (usually from the desktop environment).
You can do that under Gtk3 too, but like with Qt5 it only allows small adjustments in line with how the developers built the UI. You can affect layout and style of certain components, but that's it.
From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
GTK also supports customization via local style sheets.
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.
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.
> GTK also supports customization via local style sheets.
They also break them at every release.
They also break them at every release.
That's just plain FUD. The only release I remember breaking CSS was 3.20, and that was because all the CSS was refactored to allow for way more theming possibilities.
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.
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.
[deleted]
What about the filesystem drivers? Should each application developer pick those?
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.
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.
What shared services that are available differs from system to system, just like which are supported differ from applucation to application. Filesystem access may be through an xdg-portal, may support KIO or GVFS integrations, may use framework internal pickers, and so forth. Many decisions for the developers to make.
Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.
Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.
> What about the filesystem drivers? Should each application developer pick those?
KIO vs GVFS? :)
KIO vs GVFS? :)
A toolkit unfortunately can't enforce that. You have to ask the app developers to change their design.
Sure it can. Until fairly recently, client side decorations were simply unsupported, and things worked better.
No, they were always supported in the sense that it has always been possible to make a frameless window and draw your own decorations. In the old days this was even a highly desired thing for Audacious/Beep/XMMS because of compatibility with Winamp skins, which all included their own graphics for window decorations.
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.
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.
It's been theoretically possible for a while, but hard to do, as well as being considered antisocial. It's quite a new regression on Mac as well.
It was not hard to do, it's as trivial as drawing 2 buttons and some text. If this is such an issue then take it up with all the app developers. See for yourself how well they respond to accusations of being "antisocial" just for the act of moving some buttons up 30 pixels. This isn't a new thing or a regression on Mac, they always had CSD, even in the pre-OS X days. What is trendy there now is the merging of the toolbar and titlebar, which is different.
> It was not hard to do, it's as trivial as drawing 2 buttons and some text.
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...
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...
All of that was already implemented by the toolkit. The way programs used to do it is by simply calling those 3-4 toolkit functions to move and resize. You can verify this by looking in the code to old versions of Audacious/XMMS/Beep/etc, which still used GTK/GDK to handle those things.
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.
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.
And it's a pretty annoying regression.
Because Qt has fantastic documentations and intuitive examples. Gtk is notorious for lacking proper documentations and unstable feature changes.
Here is a talk when Subsurface decided to go Qt from Gtk: https://youtu.be/ON0A1dsQOV0
Here is a talk when Subsurface decided to go Qt from Gtk: https://youtu.be/ON0A1dsQOV0
Curious, what would you choose?
For whatever reason, the cross-platform UI story seems dire as ever if you don’t count web.
For whatever reason, the cross-platform UI story seems dire as ever if you don’t count web.
Audacious has been a loong-time GTK project (2005?) and at some point had a GTK3 port, which was then abandoned. The authors provide some explanation here: https://audacious-media-player.org/news/32-audacious-3-6-rel... & here https://redmine.audacious-media-player.org/boards/1/topics/1...
I always appreciate the perseverance and dedication of FOSS developers and teams. They bring a lot to the table for a whole lot of people.
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.
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.
Most FOSS contributors are devs, and might even despite design.
They definitely prefer functionality over looks.
They definitely prefer functionality over looks.
Any screenshots?
I just built it on ubuntu 18.04. It looks pretty much identical to the native 3.9 version, except for icons.
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...
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...
there's one on the front page: https://audacious-media-player.org/
According to the filename, that is an old version of Audacious (3.6).
Seems like the Qt5 front-end is just set as the default one, and the GTK front-end will be deprecated. There wasn't really any noticeable difference between both from the usability comparison in my opinion.
Looks like this is moving from GTK2, not GTK3 ( latest ).
Does this mean GTK2 and GTK3 are... to be avoided for new projects / dead?
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?
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?
> Does this mean GTK2 and GTK3 are... to be avoided for new projects / dead?
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...
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...
Yeah, nobody set a theme for GTK in that screenshot, and GTK themes tend to look different from the native theme on non-Linux OSes regardless.
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.
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.
Eeh. It might be perception, but I feel like it was the other way around — around the time iPhone came out, a lot of apps eschewed compliance in favour of achieving clearer identity. I think that cleared the way for electron — I actually vaguely remember some people talking about using html-based apps because they made achieving a specific visual design easier, not because of the portability benefits.
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.
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.
Here is how a gtk app looked in 2014 on macOS: https://i.imgur.com/1e669Tp.png
I like the first one more, am I weird?
The first one isn't Mac like --- the menu bar doesn't go on the top of the window. I don't necessarily think that's great, but that's the way it should be on a Mac.
not bad-looking for gtk?
Qt was always the better practical choice, and its license issues were sorted out decades ago. Couple that with a world where choosing C over C++ makes less and less sense (compilers having got a lot better) and the writing has been on the wall for years now.
> How do Qt projects look + feel when ported to Mac OS X?
They're in the uncanny valley.
They're in the uncanny valley.
a lot of apps look non-native on os X, with apple starting the trend of ignoring their own HIGs about 5 years ago.
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.
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.
Looking different is ok.
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.
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.
> So the first impression you get for software using Qt is old and glitchy.
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...)
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...)
What's wrong with something looking "old-fashioned"? That seems to be better from my point of view.
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 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.
> What's wrong with something looking "old-fashioned"?
I think people tend to assume that software that looks old-fashioned is likely to be unmaintained or buggy.
I think people tend to assume that software that looks old-fashioned is likely to be unmaintained or buggy.
Hmm. When I look at the (as far as I know) native apps that I have running on my Mac at this moment -- Safari, Day One, Numbers, Soulver, Terminal, MailMate, BBEdit -- there's a pretty obvious shared visual language between them. They all look "native Mac" in a way that Slack, Visual Code, LibreOffice, and Calibre don't. (To be fair, Calibre's UX goes out of its way not to fit in with any desktop environment on this planet, so it's probably not a good benchmark.)
> How do Qt projects look + feel when ported to Mac OS X?
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.
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.
wx seems to be sufficiently Mac-like...
Alas, can't speak in regard to that, because I've never seen a Wx app aside from a few smallish Python projects— which I think I only passed by on Github, nodding appreciatively and then not running any of them.
Btw, I'm saying the above while myself having made a small Python project with Wx about eleven years ago. That was the closest I've come to a Wx app—but it was on Windows and amounted to little more than a single button, so not much knowledge gained.
[deleted]
Doesn't wx just use GTK under the hood?
On Linux, yes. On Mac it uses Cocoa and on Windows - Win32 API. i.e. it is a wrapper for native controls.
I think GTK3 will still be viable for a least a few more years. It's currently in maintenance mode -- no new features will be added, and all feature development is happening in git master in preparation for the GTK4 release. The first release of GTK4 is currently planned for this fall.
Qt5 can be made to look pretty close to a native Mac app, but one thing I haven't figured out yet is if there's a way to get that "bouncy" effect you get when you scroll to either end of a list.
Is this "bouncy" effect the elastic one pulling against the end, snapping the list back to position when you release it, or is it the the one where the scroll ricochets off the end when you apply great force in order to quickly scroll to the end? The former is a very nice UI cue, but who on earth thought the latter was a good idea? As an Android user, I wish there was a way to disable the ricochet on all apps.
I am referring to both styles of "bounce". Would be nice to have the former to implement "pull to refresh"
Well if that's the means to an end, then this world has gone just crazy.
They don't look quite native, but I feel the trend is moving away from native-looking apps anyway (like via electron, or forgoing an UI at all and just doing a web UI).
> GTK3 are... to be avoided for new projects / dead?
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.
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.
It's more like the gnome people picked up abandoned torches.
The existence of MATE indicates the torches were never abandoned.
Only if you conflate the users with the existing pool of GTK/GNOME developers and maintainers of the time.
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'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.
Didn't survive? The most popular desktop distro, Ubuntu, switched their DE from Unity to Gnome.
NO. GTK has really been getting more and more import for FLOSS as the Librem 5 and the vast majority (Ubuntu switched to GNOME by default, so GNOME is now the default on
- Ubuntu - Fedora - OpenSUSE - Debian - CentOS - ...
GTK+ since version 3 is really neat. They rust re-did the site as well: https://www.gtk.org
- Ubuntu - Fedora - OpenSUSE - Debian - CentOS - ...
GTK+ since version 3 is really neat. They rust re-did the site as well: https://www.gtk.org
They did have a GTK3 port at one point (audacious 3.5) but walked back from it:
https://audacious-media-player.org/news/32-audacious-3-6-rel...
https://redmine.audacious-media-player.org/boards/1/topics/1...
https://audacious-media-player.org/news/32-audacious-3-6-rel...
https://redmine.audacious-media-player.org/boards/1/topics/1...
It's alive!
Which reminds me, foobar2000's Mac port seems to be chugging along—though not open-source.
Which reminds me, foobar2000's Mac port seems to be chugging along—though not open-source.
Natural selection in action.
If you don't put enough effort for your framework to catch up modern language features and design principles, users would consider something else.
just posting to say thank u and share some love for audacious
Cross-platform toolkits are the lazy way. Good quality graphical apps are available in derivatives that match the interface guidelines and optimum toolkits/APIs of their platforms.
Good quality graphical apps sounds great, but do those exist for every single use case? Unfortunately not. It doesn’t matter how great the native graphical sketching apps on MacOS and Windows are, that isn’t going to help me when what I want to do is analyse packet captures. That’s when I reach for Wireshark, and do so full of appreciation to the devs for the excellent tool they have provided.
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.
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.
I think I have a similar preference, but lazy and good are not mutually exclusive
In this case, though, they are. There are no good cross platform UI kits, and there probably never will be.
> There are no good cross platform UI kits
Qt is one.
Qt is one.