While GTK might have been a good path forward when arne suggested it, it's worth re-evaluating whether GTK+ should be the default choice of backend. Since arne suggested that, Wireshark [1], Linux Torvald's diving application Subsurface [2, 3], and the desktop environment LXDE [4] have all either switched from GTK+ to Qt or have begun currently doing so.
The main reasons cited are: (1) GTK+, especially GTK+ 3, has become tightly tied to GNOME. GNOME developer Benjamin Otte even stated directly during GUADEC 2013 that "GTK+ is primarily intended to be used on the GNOME desktop, using X11 as the backend" and that while "he was not trying to keep those projects out; rather, since GNOME developers do the majority of the GTK+ coding, their decisions push GTK+ in their direction." [5] Since even GTK+ 2, which w has been aesthetically suboptimal on anything but Linux, managed to push Wireshark away due to its ugly UI on OS X and Windows [1], such a GNOME-centric Gtk+ 3 doesn't encourage rational optimism. Meanwhile, GTK+ 2.x gradually becomes a dead, unmaintained project. (2) Intel developer and Subsurface co-developer with Torvalds found that he "shared the same view as many with dealing with upstream GTK/GNOME developers being tough, frequent abuse and flame-wars, and accusations from the developers that 'you're doing it wrong.'" [2, 3]. More broadly, as a result of this Gtk+ increasingly being viewed by GNOME 3 developers are their private toolkit, they've proven relatively unwilling to engage constructively with non-GNOME developers' GTK+ needs. For example, apparently because GNOME 3 developers fundamentally dislike theming as they perceive it to undermine their brand, they've repeatedly broken theme compatibility in minor 3.x releases [6], ensuring that e.g., Ubuntu currently has exactly one packaged Gtk+ 3 theme [7], the rest not finding it . (3) More generally, GTK+ 3.x, the only long-term viable version, simply doesn't have a commitment to API stability, even beyond arguably superficial theming concerns; LWN reports that Benjamin Otte stated during GUADEC 2013 that: "Eventually, he said, he hopes that GTK+ will reach a point where the bold experiments are done. This will be after the scene graph and gesture support, but it is hard to say when it will be. Afterward, however, Otte hopes to make a GTK4 major release, removing all of the deprecated APIs, and settling on a GTK2-like stable and unchanging platform. The project is not there yet, he said, and notably it will keep trying to be bold and add new things until application developers "throw enough rocks" to convince them to stop. The rapidly-changing nature of GTK3 is a headache for many developers, he said, but it has to be balanced with those same developers' requests for new features like gesture recognition and Clutter integration. " [5] Waiting for GTK4 isn't going to suffice if one were to start seriously porting DC++ or DWT to GTK+ this year, so I would suggest reconsidering whether GTK+, either 2.x or 3.x, should serve as a default DWT backend given its shift in direction since arne last looked at each project. [1] "We’re switching to Qt.", https://blog.wireshark.org/2013/10/switching-to-qt/ [2] "The Biggest Problem With GTK & What Qt Does Good", http://www.phoronix.com/scan.php?page=news_item&px=MTU2ODM [3] "Gtk to Qt - a strange journey [linux.conf.au 2014]", https://www.youtube.com/watch?v=ON0A1dsQOV0 [4] “The future of Razor and LXDE-Qt”, http://blog.lxde.org/?p=1046 [5] "GTK++, stability, and the uncluttered future", https://lwn.net/Articles/562856/ [6] "GNOME (et al): Rotting In Threes", https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ [7] http://packages.ubuntu.com/saucy/gtk3-engines-oxygen -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to DC++. https://bugs.launchpad.net/bugs/1297688 Title: Moving away from Win API to Multiplatform Status in DC++: New Bug description: Isnt it time to move away from Win API to multi-platform so every platform can enjoy the vanilla client without using mods. Currently im running DC++ under Wine and there are alot of missing features under Wine since they are windows specific and not working proper under Wine and that got me thinking why.. More and more are moving away from Windows these days since the introduction of Windows 8 to other platforms and the development of LinuxDC++ seems really low more dead to be fair so why not fill the void with small steps towards true multi-platform. and without starting to talk about what windows manager to use etc im more or less talking about core features but if i can suggest something that seems ok, its QT5 i truly hope this feature request at least gets some proper consideration and discussion at the top level. To manage notifications about this bug go to: https://bugs.launchpad.net/dcplusplus/+bug/1297688/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : linuxdcpp-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp