linuxdcpp-team team mailing list archive

[cologic <1297688@xxxxxxxxxxxxxxxxxx>]

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