Re: D Binding to GUI libraries
On 2018-10-22 12:06, Russel Winder wrote: Jacob, GitHub is currently making a total mess for me of our conversation on Issue 42, I see stuff then it goes away. Apologies if I have made a mess of that conversation for you. Yeah, I noticed that. GitHub had/still having some major issues [1]. Swing is, but JavaFX is now OpenJFX and a separate think to OpenJDK. JavaFX is shipped with Java 8 at least, the one I was running (I'm a bit behind). Indeed. But compared to Qt (and maybe GTK+ and wxWidgets) it is very much a niche framework. Why do you think that, besides from being written in Java? Or it has many native GUIs whereas Windows and macOS offer no choice? Haha, I guess you can look at it that way. I still think getting a Qt binding for D à la PyQt, PySide2, Rust-Qt, i.e. automated with minimal manual tweeks, would be a Very Good Thing™ for the D pitch in the desktop GUI applications arena. Sure, different toolkits for different needs. [1] https://status.github.com/messages -- /Jacob Carlborg
Re: D Binding to GUI libraries
On 2018-10-21 22:31, Patrick Schluter wrote: I like it and I'm looking forward that it gets beyond swt 3.4. I ported my Java GUI SWT program to D and it was a breeze to do. I didn't even require to change the structure of the app and the class hierarchy. There was only the file and string handling that I had to change, in fact make so much more readable and efficient. There were some difficulties because of compiler issues in version 2.7x, but those were resolved and everything went smooth after that. That's great to hear :) -- /Jacob Carlborg
Re: D Binding to GUI libraries
On Mon, 2018-10-22 at 16:23 +, Gregor Mückl via Digitalmars-d wrote: > […] > It's easy to go and proclaim a strategic goal such as this. What > actually matters is execution. And that requires some serious > developer time that someone (ideally a whole team) needs to > invest. I don't see this happening without some equally serious > financial backing. Agreed. And sadly a common facet of the D situation: all words and no action – including from me. > I, for one, won't have any time to work on such a thing in the > foreseeable future. In principle I could, but only as part of a team. This is not a one person project. > Does anyone have experience with bounty programs? I envision one > where bounties get posted with an open pool for each one. That > is, if you agree that one task should be done, you can put > additional money into its pool and make that particular bounty > more attractive. It won't help attract professional developers > but it might nudge some hobbyists to earn some money while taking > on an interesting challenge. This might work for all the small > things around D that lots of D users don't like and want improved. I am not in a position to receive income, so I work for love or large payments to charities I nominate. Currently I am a bit overly obsessed with DVB and DAB+ using GStreamer, so mostly programming for love – and hence very fickle about doing stuff that requires commitment. The QtGStreamer has just been declared unmaintained :-( -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On Sunday, 21 October 2018 at 17:15:03 UTC, Russel Winder wrote: On Sun, 2018-10-21 at 08:42 +, Paolo Invernizzi via Digitalmars-d wrote: […] Linux is not only the desktop, and Qt simply dominates in industrial, medical and automation sector, that's where the money is. Qt is pushing strongly on the embedded marked, bare metal or linux (kernel) based... Which means that D not having a good play in the Qt space is a big barrier to adoption. This means it ought to be a strategic goal to have a (and I think I mean one here) D binding to Qt and QML. It's easy to go and proclaim a strategic goal such as this. What actually matters is execution. And that requires some serious developer time that someone (ideally a whole team) needs to invest. I don't see this happening without some equally serious financial backing. I, for one, won't have any time to work on such a thing in the foreseeable future. Does anyone have experience with bounty programs? I envision one where bounties get posted with an open pool for each one. That is, if you agree that one task should be done, you can put additional money into its pool and make that particular bounty more attractive. It won't help attract professional developers but it might nudge some hobbyists to earn some money while taking on an interesting challenge. This might work for all the small things around D that lots of D users don't like and want improved.
Re: D Binding to GUI libraries
On Mon, 22 Oct 2018 03:49:44 -0400, Nick Sabalausky (Abscissa) wrote: > So I'm honestly *shocked* to hear this. I NEVER would've guessed. I'm > pretty sold on rolling-release at this point, but I'm intrigued enough > that I'm gonna have to give the latest Ubuntu a try, at least in a VM. The latest Ubuntu has Unity 7 as an option and defaults to GNOME, so you'd have to compile a Unity 8 prerelease from source.
Re: D Binding to GUI libraries
On Mon, 2018-10-22 at 03:49 -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > […] > Just to see what's up with this "Qt-based Ubuntu", which to me, is > much > like hearing of Mario on a Dreamcast, or Sonic on SNES... Canonical got heavily into Qt (well QML actually) when they were going to do a mobile phone. Lots of Go code. All dropped when the phone got dropped. Ubuntu is basically Debian with some proprietary stuff. So for a (usually, caveat freezes) more rolling release Debian Sid is fine. GNOME is the default but you can easily change to other GTK+ based UIs or the full KDE and Qt thing. I am guess Arch has a play in this game of rolling releases with GNOME or KDE. Fedora Rawhide like Debian Sid defaults to GNOME, but allows for a switch to KDE. However Fedora Rawhide is, like Debian Sid, only sort of a rolling release. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
Jacob, GitHub is currently making a total mess for me of our conversation on Issue 42, I see stuff then it goes away. Apologies if I have made a mess of that conversation for you. On Sun, 2018-10-21 at 20:24 +0200, Jacob Carlborg via Digitalmars-d wrote: > […] > There's probably a ton of business/enterprise applications that are > written in Java. Masses, but most Java is Web backend. JetBrains and Eclipse are the bastions of desktop Java applications. > But I don't care for that, that's why I'm using D :) I don't blame you. Whilst I like D, I fear I am being pulled more and more to Rust for GUI stuff. > Not sure what you mean with "ship" here. Swing and JavaFX are > shipped > with Java. Swing is, but JavaFX is now OpenJFX and a separate think to OpenJDK. > Eclipse itself is built using SWT. Indeed. But compared to Qt (and maybe GTK+ and wxWidgets) it is very much a niche framework. […] > > Linux doesn't have a "native" GUI in the same sense as macOS and > Windows. Or it has many native GUIs whereas Windows and macOS offer no choice? > […] > > Qt is not native, at least not on macOS. Are any of the Qt D > bindings > actually useful? wxD seems very old, D1 old, is that useable? I had thought Qt for Mac did indeed map down to the Cocoa layer. I fear qtD and dqt are not up to the task. I do not know about dqml. I have been told QtE5 is workable. wxD would need some serious work in that case. > When I said that DWT is basically the only native D toolkit, I failed > to > also include: up to date (as in working with the latest compiler), > working and cross-platform. :-) I still think getting a Qt binding for D à la PyQt, PySide2, Rust-Qt, i.e. automated with minimal manual tweeks, would be a Very Good Thing™ for the D pitch in the desktop GUI applications arena. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On 10/22/18 1:58 AM, Neia Neutuladh wrote: Unity 7 and prior for the desktop use Nux, an OpenGL-based widget toolkit. Unity 8 and all mobile versions of Unity use Qt. The application set that Ubuntu shipped with Unity was, I think, heavier on the GTK+ side. Fascinating. I'm actually shocked by this, TBH. I used to be an Ubuntu user, from back BEFORE Unity, back when Ubuntu used GNOME 2. My observation and experience had always been that both Ubuntu and Gnome 2 were trying to be an open-source imitation of OSX. Then, Gnome moved to v3 (and completely lost its mind) and Ubuntu responded by switching to its own brand-new still-GTK-based Unity. But that made Ubuntu feel all the *more* like an OSS OSX-clone, prompting me to migrate upstream to Debian, and eventually to Manjaro. Meanwhile, I observed Canonical lead Kubuntu to become nothing but more, and more, and more obscure and marginalized. And then there was the news of Canonical starting into desktop spyware territory, and by then I was already long gone... So I'm honestly *shocked* to hear this. I NEVER would've guessed. I'm pretty sold on rolling-release at this point, but I'm intrigued enough that I'm gonna have to give the latest Ubuntu a try, at least in a VM. Just to see what's up with this "Qt-based Ubuntu", which to me, is much like hearing of Mario on a Dreamcast, or Sonic on SNES...
Re: D Binding to GUI libraries
On 10/22/18 1:08 AM, Gerald wrote: On Monday, 22 October 2018 at 04:41:08 UTC, Nick Sabalausky (Abscissa) wrote: On 10/21/18 1:13 PM, Russel Winder wrote: [...] First of all, minor nitpick: Unless some bombshell news occurred that I managed to miss, Ubuntu pushes their own Unity, NOT Gnome. Yes, that's still GTK, but still...accuracy...FWIW. To be accurate, Ubuntu announced the dropping of Unity back in April 2017. Current versions of Ubuntu use Gnome. https://phoronix.com/scan.php?page=news_item=Ubuntu-Dropping-Unity Wow! I really am out of the loop then. That is SERIOUSLY *MEGATON*-level announcement. I'm shocked that I missed it. I would never have even guessed. Thanks for the input! Chalk me up as one who prefers Gnome over KDE. I like the clean UI that gnome provides and the adherence to a common HIG. KDE is way too fussy and busy for my taste. I also don't agree this is a minority viewpoint. Like Russell though I'm glad there is choice and people can use what they prefer be it Gnome, KDE, Mate, Cinnamon, XFCE, i3 or whatever. I would also be white happy to see D support Qt as well just to have more options. Fair enough. For me, I find GTK/Gnome to be chunky (ex: problematic overuse of margins/padding) and Apple-level "zee must conform!" (ie: under-use of configuration). That, and an outright bad file-chooser ;) But, it's possible I might agree with you if we were talking KDE's defaults - I don't actually use KDE's defaults. But that's kinda my point though: KDE is based around the philosophy of configurability, whereas Gnome (while admittedly does have a certain level of configurability) it very intentionally designed around a philosophy of conformity being superior to configurability. But more importantly than anything else, it seems we all clearly agree: The key (and beauty) of Linux is "user's choice", not "GTK vs Qt". Most distro maintainers want their distro to be as popular as possible. If KDE was a slam dunk like you imply they should be jumping over themselves to make it the default yet they do not. When Ubuntu dropped Unity they had a perfect opportunity to make KDE (or something else) the default yet they did not. Personally, I think you're underestimating the group-think factor in modern software management. From a managerial perspective, there are a LOT of VERY STRONG motivations for promoting conformity over configurability. Not the least of which is "That's the way of Apple/Facebook/etc, and Apple/Facebook/etc are extremely popular/successful". That, combined with both modern tech's current focus on "buzz" and "popularity", AND the practical software-dev-management benefits gained from disregarding the user as anything but collective commodity, creates a VERY potent motivator to prioritize similarly-minded projects over a purely population-driven decision.
Re: D Binding to GUI libraries
On Mon, 22 Oct 2018 00:41:08 -0400, Nick Sabalausky (Abscissa) wrote: > Ultimately, everything points to the same thing: Those who actually CARE > about GTK/Gnome/Unity vs Qt/KDE, typically prefer Qt/KDE. The rest are > just swing votes. Unity 7 and prior for the desktop use Nux, an OpenGL-based widget toolkit. Unity 8 and all mobile versions of Unity use Qt. The application set that Ubuntu shipped with Unity was, I think, heavier on the GTK+ side. I can't answer for "typical" users, but I've preferred GTK+ since 2005. Qt applications feel a bit off to me, and the standard themes were all weirdly bubbly. And while I've used probably a dozen window managers and at least four desktop environments, I've been on MATE for several years now. > As for the distros choice of "which do we make default?", that's really > no surprise and implies nothing significant: The tech industry's current > runway-fashion wind direction is clearly "The user should adapt to the > software", not the other way around. Thus fully explains GTK/GNOME/Unity > as the gatekeepers' current suggestions. Just like Win/Mac: "Actual user > opinions: not relevant." RedHat provides a lot of support and development for GNOME. That makes it a relatively attractive option for other distros.
Re: D Binding to GUI libraries
On 10/21/18 1:29 PM, Russel Winder wrote: No, D should not forget DWT. It's one of the few (they only?) D GUI toolkit that has a native look and feel. Apart from GtkD on GTK+ systems, and dqml, QtE5, qtD, and dqt on Qt, and wxD on wxWidgets. Qt and wxWidgets pride themselves on being able to use native frameworks underneath – I have no personal evidence as I only use GNOME, I am not a good data point. Qt is well-known for going to great lengths, and achieving at least a certain degree of success, to have a native look-n-feel. (Regardless of how well they may or may not have succeeded compared to wx). It is a key, deliberate goal for Qt. GTK, OTOH, is famous for its outright CONTEMPT for native look-n-feel. It's even true just on Linux itself: Qt makes attempts to fit in on Gnome/Unity. Gtk not only doesn't, but also unapologetically killed off the most popular and widespread Qt/KDE-compatability module in *a mere POINT RELEASE*. And then they proceeded to rationalize it. And not one of them ever did move one muscle to rectify it, or even acknowledge any possibility of making a questionable move. (And don't even get me started on the multi-decade clusterfuck that is the GTK file-chooser.) Qt makes effort for native look-n-feel. GTK is INFAMOUS for having outright CONTEMPT for native look-n-feel. There is NO comparison, whatsoever.
Re: D Binding to GUI libraries
On Monday, 22 October 2018 at 04:41:08 UTC, Nick Sabalausky (Abscissa) wrote: On 10/21/18 1:13 PM, Russel Winder wrote: [...] First of all, minor nitpick: Unless some bombshell news occurred that I managed to miss, Ubuntu pushes their own Unity, NOT Gnome. Yes, that's still GTK, but still...accuracy...FWIW. To be accurate, Ubuntu announced the dropping of Unity back in April 2017. Current versions of Ubuntu use Gnome. https://phoronix.com/scan.php?page=news_item=Ubuntu-Dropping-Unity But more importantly, "prefer" is vague a weasel word in this situation. The claim is that the distros "prefer" GTK over Qt. The *reality* is far more simple: The installers for the distros give you a choice between Gnome, KDE and (on Ubuntu) Unity, and Gnome/Unity just happen to often be the default. That's the *only* thing that "prefer" means in this context, so let's call a spade a spade: It's a common installer default. That's all. Furthermore, regardless of what distro you've installed, KDE can always be installed and used. And (unless things have changes since last I looked) every single one of the distros you mention maintain the full set of KDE packages in their repositories. So yes, saying that GTK "won" over Qt is hyperbolic nonsense. Does it have a slight dominance WRT Linux DE's? Yes. Unfortunately. But that's like claiming a victor between iOS and Android: BOTH still have significant user-bases. BOTH are still actively developed with no end even remotely in sight. BOTH are still relevant and will remain so for the foreseeable future. So long as they both coexist (and the GNU/Linux ecosystem actively promotes coexistence of competitors - which it does), any claim of a victor, or of one competitor "winning" over another, IS, yes, hyperbolic nonsense. Plus, as others have said, industry tends to take Qt more seriously than GTK anyway. So once again, hyperbolic nonsense to claim GTK "won". [...] I believe this is pretty much exactly my own point, too ;) Ie, regardless of the Win/Mac crowds unfortunate misconceptions, Linux is about choice, not about one option "winning" over another. Thus, for one competitor to defeat another in Linux, the loser would have to either cease to exist, or become extremely marginalized. Note that "extremely marginalized" is a far, far stronger notion than "not majority" or "not the default of the options given by the installer". [...] Ditto for Qt. Which again, is a key part of my point. But that said, out of all the people I've come across who use a GTK-based DE (ie, Gnome or Unity), very few of them, if any, do so because they like GTK apps better than Qt apps (Or the GTK-file chooser over the Qt file-chooser ;)). The vast majority of the time, it's simply because they *don't object* to Gnome/Unity and merely go along with it - *not* because they consider it superior to KDE, nor because they prefer GTK apps to Qt apps. Chalk me up as one who prefers Gnome over KDE. I like the clean UI that gnome provides and the adherence to a common HIG. KDE is way too fussy and busy for my taste. I also don't agree this is a minority viewpoint. Like Russell though I'm glad there is choice and people can use what they prefer be it Gnome, KDE, Mate, Cinnamon, XFCE, i3 or whatever. I would also be white happy to see D support Qt as well just to have more options. For that matter, out of those people I've come across who DO have a significant preference regarding "GTK app" vs "Qt app", the vast majority of people who actually care are on the "Qt UI" side. Out of the minority who prefer GTK apps, the majority are GTK or Gnome developers themselves. (BTW, Note, in ALL of this, I'm referring to GTK/Qt UI, not GTK/Qt API. Just to clarify.) On top of that, it's no secret that GNOME 3 triggered an exodus of GNOME developers, and for very well-known reasons. But there's no such equivalent for KDE. I have no doubt there *are* people out there who do consider GTK/Gnome/Unity superior to KDE/Qt, and Ihave no intention to claim that they are "wrong". But in my experience, such people account for a vast *minority* of GTK/Gnome/Unity users. Not in my experience. Ultimately, everything points to the same thing: Those who actually CARE about GTK/Gnome/Unity vs Qt/KDE, typically prefer Qt/KDE. The rest are just swing votes. As for the distros choice of "which do we make default?", that's really no surprise and implies nothing significant: The tech industry's current runway-fashion wind direction is clearly "The user should adapt to the software", not the other way around. Thus fully explains GTK/GNOME/Unity as the gatekeepers' current suggestions. Just like Win/Mac: "Actual user opinions: not relevant." Most distro maintainers want their distro to be as popular as possible. If KDE was a slam dunk like you imply they should be jumping over themselves to make it the default yet they do not. When Ubuntu dropped
Re: D Binding to GUI libraries
On 10/21/18 1:13 PM, Russel Winder wrote: On Sun, 2018-10-21 at 04:15 -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: […] That's pure nonsense: It's Linux - unless one option actually goes away (KDE is still actively used and developed), then there's no such thing as one "winning" over the other. Hardly nonsense. Debian, Ubuntu, Fedora all prefer GNOME over KDE, so GTK+ over Qt. First of all, minor nitpick: Unless some bombshell news occurred that I managed to miss, Ubuntu pushes their own Unity, NOT Gnome. Yes, that's still GTK, but still...accuracy...FWIW. But more importantly, "prefer" is vague a weasel word in this situation. The claim is that the distros "prefer" GTK over Qt. The *reality* is far more simple: The installers for the distros give you a choice between Gnome, KDE and (on Ubuntu) Unity, and Gnome/Unity just happen to often be the default. That's the *only* thing that "prefer" means in this context, so let's call a spade a spade: It's a common installer default. That's all. Furthermore, regardless of what distro you've installed, KDE can always be installed and used. And (unless things have changes since last I looked) every single one of the distros you mention maintain the full set of KDE packages in their repositories. So yes, saying that GTK "won" over Qt is hyperbolic nonsense. Does it have a slight dominance WRT Linux DE's? Yes. Unfortunately. But that's like claiming a victor between iOS and Android: BOTH still have significant user-bases. BOTH are still actively developed with no end even remotely in sight. BOTH are still relevant and will remain so for the foreseeable future. So long as they both coexist (and the GNU/Linux ecosystem actively promotes coexistence of competitors - which it does), any claim of a victor, or of one competitor "winning" over another, IS, yes, hyperbolic nonsense. Plus, as others have said, industry tends to take Qt more seriously than GTK anyway. So once again, hyperbolic nonsense to claim GTK "won". People coming from Windows or macOS are genreally unaware of the notion of choice when it comes to UI. That Linux provides a choice is clearly alien to them. That I have chosen GNOME over KDE is a personal choice, but I like having the choice: I like that others can choose KDE or Cinnamon or whatever. I believe this is pretty much exactly my own point, too ;) Ie, regardless of the Win/Mac crowds unfortunate misconceptions, Linux is about choice, not about one option "winning" over another. Thus, for one competitor to defeat another in Linux, the loser would have to either cease to exist, or become extremely marginalized. Note that "extremely marginalized" is a far, far stronger notion than "not majority" or "not the default of the options given by the installer". […] Programmers writing GUI apps often like GTK. Nobody else does. From a programmer standpoint, it may very well be nice. But that's irrelevant, because from the user standpoint, GTK is, and has always been, a steaming pool of diarrhea, even if you ARE using GNOME/Unity. GTK+ is fine and dandy. That you do not like it is your choice, and that is fine. Ditto for Qt. Which again, is a key part of my point. But that said, out of all the people I've come across who use a GTK-based DE (ie, Gnome or Unity), very few of them, if any, do so because they like GTK apps better than Qt apps (Or the GTK-file chooser over the Qt file-chooser ;)). The vast majority of the time, it's simply because they *don't object* to Gnome/Unity and merely go along with it - *not* because they consider it superior to KDE, nor because they prefer GTK apps to Qt apps. For that matter, out of those people I've come across who DO have a significant preference regarding "GTK app" vs "Qt app", the vast majority of people who actually care are on the "Qt UI" side. Out of the minority who prefer GTK apps, the majority are GTK or Gnome developers themselves. (BTW, Note, in ALL of this, I'm referring to GTK/Qt UI, not GTK/Qt API. Just to clarify.) On top of that, it's no secret that GNOME 3 triggered an exodus of GNOME developers, and for very well-known reasons. But there's no such equivalent for KDE. I have no doubt there *are* people out there who do consider GTK/Gnome/Unity superior to KDE/Qt, and Ihave no intention to claim that they are "wrong". But in my experience, such people account for a vast *minority* of GTK/Gnome/Unity users. Ultimately, everything points to the same thing: Those who actually CARE about GTK/Gnome/Unity vs Qt/KDE, typically prefer Qt/KDE. The rest are just swing votes. As for the distros choice of "which do we make default?", that's really no surprise and implies nothing significant: The tech industry's current runway-fashion wind direction is clearly "The user should adapt to the software", not the other way around. Thus fully explains GTK/GNOME/Unity as the gatekeepers' current suggestions. Just like
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 10/21/18 7:36 AM, Andre Pany wrote:
While talking about bindings, do not forget Delphi. It has still a good
eco system. Combining Delphi's advanced Runtime reflection capabilities
with D's advanced compile reflection capabilities opens this eco system.
I created a proof of concept and the results were really promising.
Using Delphi components is very easy and the wrapper code on D side is
very thin.
Even clicking together a Firemonkey ui in Delphi and writing all code in
D works fine.
Delphi is available for windows, Mac os, Android and IPhone. Linux
support is somehow planned. It is free for personal use.
See an example here
https://github.com/andre2007/delta-fmx-10-2-1/blob/master/examples/gui1/source/app.d
Due to very limited time resources I have no time to work on this
specific topic at the moment but everyone is free to use these base
research results.
Side remark: Lazarus (free pascal) is planning to add the same advanced
Runtime reflection capabilities as Delphi.
Interesting, thanks for the info. I'm somewhat ashamed to say I didn't
know Delphi was still around!
For those younger programmers out there, Delphi is a Pascal-based system
that was key in popularizing what we used to call "RAD" tools ("Rapid
Application Development") such as Visual Basic, and the modern
GUI-builder tools they've evolved (or devolved?) into.
I have to admit, I've somehow managed to write code all the way from the
late 1980's through today without ever learning or writing any Pascal.
But I do know Delphi was very respectable back in the day (with a
somewhat Basic-like, but more capable, syntax), so it's nice to know
it's still around and even supports modern mobile, which is really kinda
cool.
Re: D Binding to GUI libraries
On Sunday, 21 October 2018 at 18:24:30 UTC, Jacob Carlborg wrote: On 2018-10-21 19:29, Russel Winder wrote: But who apart from Eclipse and JetBrains uses Java for desktop GUI applications? There's probably a ton of business/enterprise applications that are written in Java. But I don't care for that, that's why I'm using D :) I do not have Eclipse to check, but the JetBrains IDEs (at least CLion, GoLand, IntelliJ IDEA, and PyCharm) ship Swing, SWT, and JavaFX in their systems. Not sure what you mean with "ship" here. Swing and JavaFX are shipped with Java. Eclipse itself is built using SWT. Swing, and I believe SWT, have somewhat old architectures for GUI frameworks where GTK+, Qt, and wxWidgets have moved on. But this may just be opinion rather than agreed "fact". I haven't use these other frameworks so I don't know what's consider old architecture and modern architecture. Apart from GtkD on GTK+ systems Linux doesn't have a "native" GUI in the same sense as macOS and Windows. , and dqml, QtE5, qtD, and dqt on Qt, and wxD on wxWidgets. Qt and wxWidgets pride themselves on being able to use native frameworks underneath – I have no personal evidence as I only use GNOME, I am not a good data point. Qt is not native, at least not on macOS. Are any of the Qt D bindings actually useful? wxD seems very old, D1 old, is that useable? When I said that DWT is basically the only native D toolkit, I failed to also include: up to date (as in working with the latest compiler), working and cross-platform. I like it and I'm looking forward that it gets beyond swt 3.4. I ported my Java GUI SWT program to D and it was a breeze to do. I didn't even require to change the structure of the app and the class hierarchy. There was only the file and string handling that I had to change, in fact make so much more readable and efficient. There were some difficulties because of compiler issues in version 2.7x, but those were resolved and everything went smooth after that.
Re: D Binding to GUI libraries
On 2018-10-21 19:29, Russel Winder wrote: But who apart from Eclipse and JetBrains uses Java for desktop GUI applications? There's probably a ton of business/enterprise applications that are written in Java. But I don't care for that, that's why I'm using D :) I do not have Eclipse to check, but the JetBrains IDEs (at least CLion, GoLand, IntelliJ IDEA, and PyCharm) ship Swing, SWT, and JavaFX in their systems. Not sure what you mean with "ship" here. Swing and JavaFX are shipped with Java. Eclipse itself is built using SWT. Swing, and I believe SWT, have somewhat old architectures for GUI frameworks where GTK+, Qt, and wxWidgets have moved on. But this may just be opinion rather than agreed "fact". I haven't use these other frameworks so I don't know what's consider old architecture and modern architecture. Apart from GtkD on GTK+ systems Linux doesn't have a "native" GUI in the same sense as macOS and Windows. , and dqml, QtE5, qtD, and dqt on Qt, and wxD on wxWidgets. Qt and wxWidgets pride themselves on being able to use native frameworks underneath – I have no personal evidence as I only use GNOME, I am not a good data point. Qt is not native, at least not on macOS. Are any of the Qt D bindings actually useful? wxD seems very old, D1 old, is that useable? When I said that DWT is basically the only native D toolkit, I failed to also include: up to date (as in working with the latest compiler), working and cross-platform. -- /Jacob Carlborg
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sun, 2018-10-21 at 12:54 +0200, Jacob Carlborg via Digitalmars-d wrote: > […] > As has been stated elsewhere, it's working on Windows and macOS but > looks very alien on macOS. When I was in school I wrote a program > using > C# (Mono) and GTK on macOS. GTK seemed to be the best alternative > (for > using with Mono) back then. During the development of that program a > beta or alpha version of GTK was released with support for a native > main > menu on macOS, the rest was non-native. Not sure how it looks like > now. I tried GTK+ on OSX (*) a few weeks back using all the stuff from Homebrew. It started an X server, so definitely not native GUI framework. At least not directly. (*) El Capitan. Apple in its infinite wisdom has decided my MBP is too old to have any OS more recent than that. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On Sun, 2018-10-21 at 12:49 +0200, Jacob Carlborg via Digitalmars-d wrote: > On 2018-10-21 09:33, Russel Winder wrote: > > > The SWT framework is being replaced with JavaFX, so should D forget > > DWT > > and do something similar? > > Where do you get that idea? SWT (and therefore DWT) is using the > native > drawing operations of the OS. But who apart from Eclipse and JetBrains uses Java for desktop GUI applications? I do not have Eclipse to check, but the JetBrains IDEs (at least CLion, GoLand, IntelliJ IDEA, and PyCharm) ship Swing, SWT, and JavaFX in their systems. Swing, and I believe SWT, have somewhat old architectures for GUI frameworks where GTK+, Qt, and wxWidgets have moved on. But this may just be opinion rather than agreed "fact". > No, D should not forget DWT. It's one of the few (they only?) D GUI > toolkit that has a native look and feel. Apart from GtkD on GTK+ systems, and dqml, QtE5, qtD, and dqt on Qt, and wxD on wxWidgets. Qt and wxWidgets pride themselves on being able to use native frameworks underneath – I have no personal evidence as I only use GNOME, I am not a good data point. I do know though that a decade ago I was a fan of wxWidgets exactly because it was a wrapper around native look and feel and better than Qt. GTK+ doesn't really play that game. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On Sun, 2018-10-21 at 08:42 +, Paolo Invernizzi via Digitalmars-d wrote: > […] > > Linux is not only the desktop, and Qt simply dominates in > industrial, medical and automation sector, that's where the money > is. > > Qt is pushing strongly on the embedded marked, bare metal or > linux (kernel) based... Which means that D not having a good play in the Qt space is a big barrier to adoption. This means it ought to be a strategic goal to have a (and I think I mean one here) D binding to Qt and QML. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On Sun, 2018-10-21 at 04:15 -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > […] > > That's pure nonsense: It's Linux - unless one option actually goes > away > (KDE is still actively used and developed), then there's no such > thing > as one "winning" over the other. Hardly nonsense. Debian, Ubuntu, Fedora all prefer GNOME over KDE, so GTK+ over Qt. > It IS a big problem that far too many people (mainly developers > coming > directly from the Windows world who have decided to half-ass a Linux > port) have decided to erroneously equate "Linux" with "GTK-based DE" > these days, but that's a far cry from saying that GTK/GNOME/Unity > "won > out" over Qt/KDE. People coming from Windows or macOS are genreally unaware of the notion of choice when it comes to UI. That Linux provides a choice is clearly alien to them. That I have chosen GNOME over KDE is a personal choice, but I like having the choice: I like that others can choose KDE or Cinnamon or whatever. […] > Programmers writing GUI apps often like GTK. Nobody else does. From > a > programmer standpoint, it may very well be nice. But that's > irrelevant, > because from the user standpoint, GTK is, and has always been, a > steaming pool of diarrhea, even if you ARE using GNOME/Unity. GTK+ is fine and dandy. That you do not like it is your choice, and that is fine. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: I've also realised that there are parts of C++ that are probably unstranslatable no matter what I do. This can be solved with good gui. It need to look like meld on linux where original cpp and translated d files are side by side and parts of untranslatable code visibly marked so the user can translate it by hand.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sunday, 21 October 2018 at 01:32:22 UTC, Nick Sabalausky (Abscissa) wrote: On 10/20/18 6:28 AM, Gregor Mückl wrote: Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. I think that may be doubly true in the case of D, given D's focus on efficiency. HTML-based interfaces (whether web or app) are notoriously rife with inefficiencies: That's likely to be a major turn-off for exactly the very same audiences that D would appeal to most. While talking about bindings, do not forget Delphi. It has still a good eco system. Combining Delphi's advanced Runtime reflection capabilities with D's advanced compile reflection capabilities opens this eco system. I created a proof of concept and the results were really promising. Using Delphi components is very easy and the wrapper code on D side is very thin. Even clicking together a Firemonkey ui in Delphi and writing all code in D works fine. Delphi is available for windows, Mac os, Android and IPhone. Linux support is somehow planned. It is free for personal use. See an example here https://github.com/andre2007/delta-fmx-10-2-1/blob/master/examples/gui1/source/app.d Due to very limited time resources I have no time to work on this specific topic at the moment but everyone is free to use these base research results. Side remark: Lazarus (free pascal) is planning to add the same advanced Runtime reflection capabilities as Delphi. Kind regards Andre
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 2018-10-20 11:25, Russel Winder wrote: GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. As has been stated elsewhere, it's working on Windows and macOS but looks very alien on macOS. When I was in school I wrote a program using C# (Mono) and GTK on macOS. GTK seemed to be the best alternative (for using with Mono) back then. During the development of that program a beta or alpha version of GTK was released with support for a native main menu on macOS, the rest was non-native. Not sure how it looks like now. -- /Jacob Carlborg
Re: D Binding to GUI libraries
On 2018-10-21 09:33, Russel Winder wrote: The SWT framework is being replaced with JavaFX, so should D forget DWT and do something similar? Where do you get that idea? SWT (and therefore DWT) is using the native drawing operations of the OS. No, D should not forget DWT. It's one of the few (they only?) D GUI toolkit that has a native look and feel. -- /Jacob Carlborg
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 2018-10-21 03:25, Nick Sabalausky (Abscissa) wrote: What about DWT? It seemed pretty good from what I could tell, though I still haven't ventured into D GUIs just yet myself. Are there issues people have with DWT? Or WxD? DWT is currently stuck at SWT version 3.4 and no macOS version is available yet. I'm working on a tool that will automatically port the Java code that will hopefully fix this. -- /Jacob Carlborg
Re: D Binding to GUI libraries
On Sunday, 21 October 2018 at 07:33:45 UTC, Russel Winder wrote: The GTK/Qt battle on Linux was won by GTK+2 hence GNOME over KDE as the default for Debian and Fedora. Whether this was right or wrong is left as a choice for the reader! Linux is not only the desktop, and Qt simply dominates in industrial, medical and automation sector, that's where the money is. Qt is pushing strongly on the embedded marked, bare metal or linux (kernel) based... - Paolo
Re: D Binding to GUI libraries
On 10/21/18 3:33 AM, Russel Winder wrote: On Sat, 2018-10-20 at 21:25 -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: I've heard a lot of very good things about GtkD, and honestly, I have no doubts about any of it. Unfortunately though, the main problem with GtkD is simply GTK itself :( The GTK/Qt battle on Linux was won by GTK+2 hence GNOME over KDE as the default for Debian and Fedora. Whether this was right or wrong is left as a choice for the reader! That's pure nonsense: It's Linux - unless one option actually goes away (KDE is still actively used and developed), then there's no such thing as one "winning" over the other. It IS a big problem that far too many people (mainly developers coming directly from the Windows world who have decided to half-ass a Linux port) have decided to erroneously equate "Linux" with "GTK-based DE" these days, but that's a far cry from saying that GTK/GNOME/Unity "won out" over Qt/KDE. I think GTK+3 is actually really quite nice, somewhat nicer than Qt. However if D had a Qt binding in play as good as the GtkD binding is to GTK+, then maybe I could be convinced to use Qt. No way am I going to use C++ for desktop GUI applications, and Rust is the only other option just now. Programmers writing GUI apps often like GTK. Nobody else does. From a programmer standpoint, it may very well be nice. But that's irrelevant, because from the user standpoint, GTK is, and has always been, a steaming pool of diarrhea, even if you ARE using GNOME/Unity.
Re: D Binding to GUI libraries
On Sat, 2018-10-20 at 21:25 -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > […] > > And KDE. Not entirely true, you can run KDE application on a GNOME system, and I assume GNOME application on a KDE system. > I've heard a lot of very good things about GtkD, and honestly, I have > no > doubts about any of it. Unfortunately though, the main problem with > GtkD > is simply GTK itself :( The GTK/Qt battle on Linux was won by GTK+2 hence GNOME over KDE as the default for Debian and Fedora. Whether this was right or wrong is left as a choice for the reader! I think GTK+3 is actually really quite nice, somewhat nicer than Qt. However if D had a Qt binding in play as good as the GtkD binding is to GTK+, then maybe I could be convinced to use Qt. No way am I going to use C++ for desktop GUI applications, and Rust is the only other option just now. […] > > What about DWT? It seemed pretty good from what I could tell, though > I > still haven't ventured into D GUIs just yet myself. Are there issues > people have with DWT? Or WxD? The SWT framework is being replaced with JavaFX, so should D forget DWT and do something similar? If yes the QtE5 or dqml are the way forward since the QML engine of Qt is the equivalent of JavaFX. Putting effort into wxD is the same sort of effort needed for either qtD or dqt, would it be better to back Qt or wxWidgets? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sat, 2018-10-20 at 16:37 +, Atila Neves via Digitalmars-d wrote: > […] > > It turns out that translating C++ is *hard*. Partly because the > language is huge and complicated, but also partly because > libclang isn't all it's cracked up to be. But... dpp is probably > a few full work days away from being to #include . > Hopefully with the translation actually working. This I can believe, but isn't the D-side problem only to be able to link to C++ libraries. Given previous emails this morning, clearly my current thoughts are creating D bindings for Qt and wxWidgets. > […] > > * std::is_reference is untranslatable: there are no reference > types in D. It's likely to get used with SFINAE, and while that > is translatable by hand, I have no idea how I'd write an > algorithm to figure out SFINAE when it happens and translate that > to template constraints in D. From what I hear at ACCU conferences, most C++ programmers can't handle SFINAE properly. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries
On Sat, 2018-10-20 at 23:38 +, Gregor Mückl via Digitalmars-d wrote: > […] > I don't want to judge, but I need to point out that we have > managed to make this discussion progress from outward-facing > marketing to technical difficulties and related pull requests. > This is not bad, but it is also a perfect example of how > inward-facing the community can be and that is a part of what > started this thread. Which is why I changed the Subject on this sub-thread to make it clear that the content had diverged from the original points. On the other hand, we seem to be teasing out a point or two relating to the original message. GUI desktop applications is clearly a place where D should excel. For those using GtkD (and GStreamerD) it clearly can and does. However the GTK+ "market" is quite small, and the Qt and wxWidgets "market" is much bigger. Thus to excel as a GUI programming tool more widely, D needs a Qt binding and a wxWidgets binding that is as of good quality as GtkD is. I know there are a number of other GUI frameworks cf. https://wiki.dlang.org/GUI_Libraries It is not clear what the order signifies, if anything. I believe most of them to be unmaintained. DWT as a port of SWT is far behind where Java has gone, which is JavaFX. JavaFX has a not dissimilar approach to QML. However that is all very much engine and observables based, which is fine if you like it. Clearly I did in the past as I worked on GroovyFX, a Groovy wrapper to JavaFX. Which of qtD or dqt to choose to progress if either? I have a feeling that whilst having many can be a good thing, D bindings to GUI frameworks is a space where having one is a good thing, cf. GtkD. Then there is dqml or QtE5 as a binding to QML. Should these be separate or should there be a single framework offering a D binding for the Qt and QML APIs? wxD is potentially interesting, if it could be progressed. Personally I ignore Tk as a GUI framework, even with the update from a decade or so ago. I am sure DlangUI will get a mention, but is there enough resource available within the community to create a viable competitor to Qt or wxWidgets so as to gain traction for D in the desktop GUI application arena. Currently I believe no. So to progress getting D used for desktop GUI applications, I would argue that some (fewest) of qtD, dqt, dqml, and QtE5, and wxD are the bindings to progress to a good state to show to the world that D is a strong competitor to C++, Rust, and Python in the field of desktop GUI applications. Assuming of course that: a) there is a market for desktop GUI applications; and b) D wants to compete in this space. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 10/20/18 6:28 AM, Gregor Mückl wrote: Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. I think that may be doubly true in the case of D, given D's focus on efficiency. HTML-based interfaces (whether web or app) are notoriously rife with inefficiencies: That's likely to be a major turn-off for exactly the very same audiences that D would appeal to most.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 10/20/18 5:25 AM, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. And KDE. I've heard a lot of very good things about GtkD, and honestly, I have no doubts about any of it. Unfortunately though, the main problem with GtkD is simply GTK itself :( D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? I really hope so! No idea personally though :( What about DWT? It seemed pretty good from what I could tell, though I still haven't ventured into D GUIs just yet myself. Are there issues people have with DWT? Or WxD?
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 22:19:48 UTC, 12345swordy wrote: On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: [...] It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. [...] There this pull request https://github.com/dlang/dmd/pull/8787 but apparently Manu is burn out from working on it I don't want to judge, but I need to point out that we have managed to make this discussion progress from outward-facing marketing to technical difficulties and related pull requests. This is not bad, but it is also a perfect example of how inward-facing the community can be and that is a part of what started this thread.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: [...] It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. [...] There this pull request https://github.com/dlang/dmd/pull/8787 but apparently Manu is burn out from working on it.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Gtk is clearly working on Windows from a technical point of view. Gimp on Windows is proof of that. But the look and feel are too different from what Windows users expect in my eyes and I did have a few unpleasant experiences with Gtk in the past. So I personally do not have any real desire to use it. My encounters with Qt were more involved and generally very pleasant and successful. I want to stress that this is only my personal view that I arrived at over the years. Any bias in it is purely mine. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. Qt did have very good bindings to Java in the form of Qt Jambi, which was commercially developed back in the day by (then) Trolltech. Unfortunately for me, they killed that product off just as it reached 1.0. But a lot of the generator code was reused for PySide which was started around that time. Qt really depends on the code generated by the moc preprocessor. Even though the generated code is not really all that complicated, filling in the same gaps in bindings for other languages is quite hard. I think that Python has such good bindings only because both PyQt and PySide were commercially backed from the start. I can't think of any other currently maintained language bindings that have that luxury. Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. D could be well suited for various kinds of applications in that area, especially those that have complex logic with some really performance critical parts and require rich user interfaces. Productivity, CAD, DCC and data processing/visualization would probably be among the extreme categories here. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] Excellent question! All I know is that Binderoo and dpp are two WIP projects that want to make binding to C++ easier. The authors are active in the forum, aren't they? It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. The namespace hack Walter suggested doesn't work in practice, but now that extern(C++, "ns") is a thing I just need to massively refactor the code and use that instead. I've also realised that there are parts of C++ that are probably unstranslatable no matter what I do. Hopefully a pragmatic "you can #include but you can't use std::is_reference from "* approach will let us call enough of C++ in practice. Right now I'm blacklisting several things in ... Atila * std::is_reference is untranslatable: there are no reference types in D. It's likely to get used with SFINAE, and while that is translatable by hand, I have no idea how I'd write an algorithm to figure out SFINAE when it happens and translate that to template constraints in D.
Re: D Binding to GUI libraries
On Saturday, 20 October 2018 at 14:24:56 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: […] I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt As a company that will be hosted in the QT booth at SPS IPC Drives 2018 in Nuremberg at the end of November, C++ dominates. We are calling a little D codebase from a QT application, but just to leverage some legacy old code. I've used PySide, years ago, but nowadays the performance of the C++ compilers, and the agility of QT Creator are closing the bridge for a fast edit/compile/test cycle... the big advantage of PySide is the tremendous amount of python libraries that you can use in your application. Said that, we are using QML, but I don't love it a lot... - Paolo
Re: D Binding to GUI libraries
On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: > […] > I mean it *may* work, but that isn't the problem if the > developers completely lack support for the platform. I can > download Qt with prebuilt libraries and it works out of the box > with MSVC. There's an obvious difference between the two > developers support. As someone else said GTK look like ass on > Windows, Qt is really the only crossplatform GUI API written in a > native-compile-able language out there that gets most things > right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Last time I tried to use GTK on windows I had to build i from source myself, from the looks of it that hasn't changed. It has a huge dependency list, and some of those dependencies have their own dependencies. They all have to be built their own different way on Windows. It's a pain in the ass to do, i tried and didn't bother after trying to compile cairo or whatever. Kind of odd they don't have any sort of build script, I guess they just use Mingw which not very many people use. It may work on Windows, but the amount of effort to set it up is not worth it at all. The developers of the library obviously don't care enough either to try to reduce that barrier. Why not provide a built shared library? Something tells me they haven't even bothered to compile it with MSVC themselves. Their guide to build with MSVC links to a 3+ year old Gnome article where someone not even affiliated with GTK wrote a powershell script to build it with MSVC. The other links to an article that is still using VS 2010 and 2008 for the build. I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Gtk is clearly working on Windows from a technical point of view. Gimp on Windows is proof of that. But the look and feel are too different from what Windows users expect in my eyes and I did have a few unpleasant experiences with Gtk in the past. So I personally do not have any real desire to use it. My encounters with Qt were more involved and generally very pleasant and successful. I want to stress that this is only my personal view that I arrived at over the years. Any bias in it is purely mine. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. Qt did have very good bindings to Java in the form of Qt Jambi, which was commercially developed back in the day by (then) Trolltech. Unfortunately for me, they killed that product off just as it reached 1.0. But a lot of the generator code was reused for PySide which was started around that time. Qt really depends on the code generated by the moc preprocessor. Even though the generated code is not really all that complicated, filling in the same gaps in bindings for other languages is quite hard. I think that Python has such good bindings only because both PyQt and PySide were commercially backed from the start. I can't think of any other currently maintained language bindings that have that luxury. Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. D could be well suited for various kinds of applications in that area, especially those that have complex logic with some really performance critical parts and require rich user interfaces. Productivity, CAD, DCC and data processing/visualization would probably be among the extreme categories here. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] Excellent question! All I know is that Binderoo and dpp are two WIP projects that want to make binding to C++ easier. The authors are active in the forum, aren't they?
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: > […] > I periodically look at how I can make use of D for small > projects. Most often, I shy away because I want to build a GUI > and none of the libraries that I can find look mature and well > maintained enough to put my faith in. For C++ there's Qt, which > is *phenomenally* good (despite some warts), but there's been at > least half a dozen attempts at creating D bindings for that, all > in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
