Hi,

I am doing a presentation looking at DVB, GTK+, GStreamer, C, C++, gtkmm, D, GtkD, GStreamerD, Rust, gtk-rs, and gstreamer-rs in Norwich 2018-11-07. Anyone who wants to come and heckle about ditching D and switching to Rust is most welcome.

 https://www.meetup.com/Norfolk-Developers-NorDev/events/252504253/

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tuesday, 16 October 2018 at 03:42:13 UTC, Russel Winder wrote:
> Hi,
>
> I am doing a presentation looking at DVB, GTK+, GStreamer, C, C++, gtkmm, D, GtkD, GStreamerD, Rust, gtk-rs, and gstreamer-rs in Norwich 2018-11-07. Anyone who wants to come and heckle about ditching D and switching to Rust is most welcome.
>
>  https://www.meetup.com/Norfolk-Developers-NorDev/events/252504253/

Wish I could see this one, it would be very interesting to hear your thoughts on C++ vs D vs Rust in terms of working with GTK.

On Tue, 2018-10-16 at 16:31 +0000, Gerald via Digitalmars-d wrote: […]
> Wish I could see this one, it would be very interesting to hear your thoughts on C++ vs D vs Rust in terms of working with GTK.

I do not know if the sessions are recorded.

C++ and gtkmm sort of work but using C++ always seems to involve more pain than any project is worth. Also gstreamermm isn't as nice as it should be. A core problem seems to be that gtkmm and gstreamermm are hand coded bindings not generated from GIR files.

D + GtkD (inc GStreamerD) is really quite nice. The biggest downside is the documentation presenting all the C examples not D ones, and the lack of non- trivial examples of use. The biggest problem is really not enough different applications, and the need for more effort on the documentation and examples.

Rust + gtk-rs + gstreamer-rs is it seems the chosen future for GTK and GStreamer in their bid to not have to use C. Using it is really quite nice. D and Rust are very different, both have pluses and minuses,but int he end choosing either seems fine. That Rust is the chosen tool for gstreamer-rs is a big choice decider. There is still a documentation and examples problem analogous to the GtkD one, but it seems more people are using this combination and the changes and improvements are happening, and quite quickly.

Possibly the single biggest  D / Rust decider is that the gtk-rs people have created a futures/channels/executor system to make working with an event loop in a mult-threaded context wonderfully easy and straightforward. The way of achieving the goal in C++/gtkmm is byzantine, and they way it is done in D/GtkD is old-fashioned and very low-level.

I have a couple of D/GtkD projects which I'll still go with, but anything involving GStreamer has to be in Rust.

If I do any new GTK projects they will likely be in Rust – but there is an off chance they will be in D. What can definitely be said is that no way will I do them in C++, and C just isn't even an option on the table.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

A PS to the bit on D vs Rust:

The Rust plugin to CLion is managed by JetBrains and has resource assigned, the D plugin to CLion is a pure volunteer effort. The Rust development experience in CLion is really rather good. The D development experience in CLion is there, but clearly a WIP.

I mention CLion only here since that is the platform with GDB support,IntelliJ IDEA will never have that.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 17 October 2018 at 08:35:09 UTC, Russel Winder wrote:

> D + GtkD (inc GStreamerD) is really quite nice. The biggest downside is the documentation presenting all the C examples not D ones, and the lack of non- trivial examples of use. The biggest problem is really not enough different applications, and the need for more effort on the documentation and examples.

I can definitely see that. I wanted to write a GUI program some time ago and looked at GtkD. It wasn't easy to see where to start with GtkD, and I eventually ended up running a local web server and creating the GUI in the browser. This is a good example of the non-technical things holding D back, largely because of the small community.

On Wednesday, 17 October 2018 at 13:15:44 UTC, bachmeier wrote:

>
> I can definitely see that. I wanted to write a GUI program some time ago and looked at GtkD. It wasn't easy to see where to start with GtkD, and I eventually ended up running a local web server and creating the GUI in the browser. This is a good example of the non-technical things holding D back, largely because of the small community.

Same here. I once started a GUI program using JavaFX + D (JNI) and then switched to GtkD + Glade. I could find my way around (with some difficulty), reading the docs / examples in C and translating them to GtkD in my head. It worked, but I always had the feeling of "Is that best practice?". When I re-opened the project after 2 years or so, I just couldn't be bothered to go through all that again. I just used my JavaFX code again and extended the app in no time. It also made me realize a lot of things about D and its "small community". Something is rotten in the state of D...

PS No, I won't write GtkD docs myself (may the Universe forgive me!), because by the eternal DIY logic I would have had to implement D for ARM, write GtkD docs and whatnot...instead of using D to actually write programs.