Moving away from Win API to Multiplatform

[Spitfire]

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.

[Francisco Blas Izquierdo Riera (klondike) (klondike)]

Well there is EiskaltDC++ and the beta the guys at ApexDC are doing. So it's not such a bad world :P

[Spitfire (b13569b8)]

Not interested in EiskaltDC++ or ApexDC++ since they are not the drivers of Direct Connect better if the vanilla client took steps towards multiplatform instead

[poy (poy)]

for what it's worth, it was my new year resolution to pursue this. i still have a few months left! :)

[Spitfire (b13569b8)]

Im sure that if you talk to the other developers there are those that will dedicate their time to helpout and move the project in that direction so is this a valid future request ?

and im hopeful that there will be small steps taken in the future :) hell i can try betas if thats of any help

[Crise / MW (markuwil)]

Poy: out of curiosity how did you think about pursuing this? Port DWT or replace it?

Personally I think if you intend to seriously pursue this, you should start by eliminating #ifdefs in dcpp lib, use separate cpp files for platform specific code and share only headers. This would limit preprocessor branching to inline functions that are platform specific and even that could be addressed by the use of .inl files for the most part. Same applies to DWT if porting it is the way you consider.

I know there are some arguments against this type of compartmentalized structure, but in the long run the code is likely to remain more maintainable if done like this in my opinion. And perhaps most importantly it would automatically mean that a good hard look is taken at each platform specific section of code during this process.

[poy (poy)]

on the dcpp lib part, my first task a few months ago was to make it compilable using scons; "scons test=1" correctly builds the lib and runs tests.
instead of if-guarding too much, i prefer a wait&see approach here as Windows is rapidly getting up to par with Linux in terms of "advanced" C++ support: file IO already working through boost, but requires some tests with locales and such; sockets are done thanks to boost asio; threading (std::thread) support almost there.
therefore, i am not foreseeing any huge architectural change in the dcpp lib part unless it is meant to move to more recent C++ facilities.

regarding DWT, i plan on first trying the path arnetheduck initially suggested: bindings between DWT and GTK. not sure how workable that is but it would be awesome if that could advance. :) this would avoid having to re-write the GUI code for the most part. the fallback solutions are of course already known.

[Fredrik Ullner (ullner)]

The alternative would be to make sure that plugins would get *everything*. Then, you could build plugins for each specific task (or have a main "DC++ Windows UI" plugin), such as changing the UI for a particular item (say, the search frame) that can specialize in e.g. operating system.

[cologic (cologic)]

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/201...

[poy (poy)]

these are all points i have come across at some point but that must have been pushed to the back of my mind. i completely agree.

qt is the most advanced toolkit at the moment; using it would somehow render dwt meaningless. i'm curious about lower-level alternatives, more closely tied to X, such as Motif <https://sourceforge.net/projects/motif/>...

[Jacek Sieka (arnetheduck)]

One of my little pet projects is j2c which can translate java to c++.. I've used it to translate SWT to C++ and it actually works (their demo apps run with a gtk backend).. swt has of course been a source of inspiration for dwt, both being light weight and using native widgets as far as possible but trying to hide some of the ugliness.

I sort of agree that qt is better than gtk+ these days, specially for non-linux platforms, but it's also pretty heavy weight, which was one of the reasons I didn't use it (or wxwidgets) when we left wtl behind...I also never really liked their api, build (moc) and so on but that's mostly down to taste - last time I looked was around qt3 so I'm completely out of date here as well.

the swt translation of course requires a lot of work, but it's a fun option from a leisure programming point of view, and it could be used to grow dwt into something more generally useful...

https://code.google.com/a/eclipselabs.org/p/j2c/

[cologic (cologic)]

poy: one concern about Motif, and I'm not sure how important this will be in practice, is that Motif doesn't support Wayland at all. Major distributions such as Fedora [1] are aggressively trying to get Wayland to be the default windowing system. Within a couple of years X11's going to become a compatibility layer on both Fedora [1] and Ubuntu [2]. I wouldn't push back too strongly against an X11-only Linux solution, though: broadly available X11 support won't disappear in the next few years.

Also, someone actually is looking at implementing Motif on Wayland [3], but it began as an unexpectedly serious April Fools joke [4], so I don't anticipate much.

arne: j2c in general & SWT are indeed intriguing. From what I've read, SWT has a lot of advantages and is a more precisely targeted GUI toolkit than the eveything-compatibility-layer of Qt. You're not the only one with that idea, either: http://www.pure-native.com/swtcpp/ is a commercial version and http://nativeswt.sourceforge.net/ is a now-abandoned open source version.

Regarding Qt, most of what you say still applies. It still depends on a MOC to build [5]. It's still somewhat heavyweight (LXDE/LXQt/Razor-Qt developers, for example, found it routinely added 20MB memory consumption to their Gtk+ 2.x to Qt5 ported software). It's still a matter of taste, but Qt seems to have kept targeting about the same niche, so whatever issues you had with it in that regard likely still apply.

[1] http://blogs.gnome.org/uraeus/2013/09/09/fedora-wayland-update/
[2] http://www.omgubuntu.co.uk/2014/03/mir-default-display-server-ubuntu-2016
[3] "Motif on Wayland", https://madhouse.github.io/motifway/
[4] http://asylum.madhouse-project.org/blog/2014/04/01/motif-on-wayland/
[5] http://qt-project.org/doc/qt-5/why-moc.html

[cologic (cologic)]

Oh, and to add something possibly constructive: I know little about https://docs.enlightenment.org/stable/elementary/ - but it's another option. It doesn't seem to be that well-documented on Stackexchange, etc. It does have the general widgets and containers one expects: https://docs.enlightenment.org/stable/elementary/widgetslist.html and https://docs.enlightenment.org/stable/elementary/containerslist.html

It also supports Wayland, at least; see https://phab.enlightenment.org/w/wayland/ and https://fosdem.org/2014/schedule/event/enlightenment_standalone_wayland_compositor/attachments/slides/462/export/events/attachments/enlightenment_standalone_wayland_compositor/slides/462/Enlightenment_Wayland_Compositor.pdf for details, and in general, seems quite actively maintained.

For all this, it could have a lot of the same issues as GTK+ for all I know (it doesn't really have an independent existence as a project outside of Enlightenment, just as GTK+ doesn't these days outside GNOME), etc. I hadn't been aware of it, and perhaps other people weren't, either. It doesn't show up in the usual lists-of-widget-toolkits, but I think worth being aware of.

[iceman50 (bdcdevel)]

Even though Qt is heavy, I don't think it being heavy should be a factor, DC++ includes the entirety of boost without trimming the proverbial 'fat' from it, so I don't think weight should be a determining factor.

[Steven Sheehy (steven-sheehy)]

Having worked with GTK+ for LinuxDC++, I would highly not recommend using it to replace DWT. It is a C based library and the impedance mismatch with using it in a C++ based language makes for very unwieldy code. There is a C++ wrapper called gtkmm which may alleviate that, but when LinuxDC++ was originally using gtkmm I heard it was slow and required extra compilation steps. This may have changed with the latest version though so it might be worth looking at gtkmm 3.

I think the concerns about GTK+ 3 being an unstable API are unwarranted. For the type of simple widgets that DC++ would be using, there would be very little chance of an API breakage. Having bugs when using those APIs would definitely be a possibility as there is still a lot of changes going on behind the API though.

I agree with poy and crise that std and boost libraries should be used as much as possible to avoid platform specific code. But if the latter is required then avoiding ifdefs and using separate implementation files would be the way to go.

Regarding DWT, I never understood why it was necessary to write a separate widget toolkit. Just an observation and not a knock against anyone since writing a toolkit is very hard, but it seems like a lot of the bugs I see you guys fixing are due to this layer of the stack and moving to a more well known toolkit may help alleviate the workload and allow for a better multi-platform experience. It would also allow LinuxDC++ to be integrated into DC++ (or for it to just disappear). I would suggest sticking with the two main toolkits (QT5 or GTK+3) as anything else will not have the financial backing behind it to be kept stable and up to date nor will they be supported very well on multiple platforms.

[poy (poy)]

to explain DWT: it was not written from scratch. it's just an evolution of Smartwin, a toolkit which appeared to be one of the best at the time for Windows. it probably ended up needing more tinkering with than initially thought, but the result is (in my mind) amazing.
the issue here is that Windows already offers a bunch of widgets, but exposed through a messed up C API. with the right ideas, one can design a C++ wrapper that exposes these various widgets and handles all the logic necessary to write a Windows GUI, while still remaining very lightweight. that is what DWT does.
in that same spirit, it would be nice to find a Linux set of GUI primitives and widgets one simply has to wrap around. hence GTK+ (even their C API) or some other low-level toolkit could fit.

[iceman50 (bdcdevel)]

Perhaps it might be worthwhile to look at <http://www.juce.com> for a cross platform api

[cologic (cologic)]

https://lwn.net/Articles/607563/ ("Shifting toward Qt") focuses only on GTK+ and Qt, rather than the other alternatives suggested in this bug, but between them concludes that:

"Nonetheless, it appears that, for the most part, there is growing technical frustration in the broader open-source community with GTK+; Qt seems to be gaining at least in part at GTK+'s expense. Portability, ease of development and reduced concerns about ABI breakage are some of the technical reasons expressed by many developers for choosing Qt over GTK+. It is far too soon to proclaim that Qt has achieved any sort of victory over GTK+, but Qt does appear to have the wind at its back at the moment."