On Monday, 9 September 2013 at 09:31:59 UTC, Joseph Rushton
Wakeling wrote:
On 09/09/13 10:29, Russel Winder wrote:
It also appears that Microsoft are beginning to think the
whole CLR
thing is on it's last legs.
The whole "all non-Windows users have to hate C#" thing has
some basis
in fact but also had a lot of FUD associated with it. The
"Mono hatred"
stemmed from that. So will Microsoft go after Mono with patent
suits if
they are not themselves using C# and CLR? They possibly might
as an
income stream, but it is unlikely to be profitable and so may
be not.
I think the Mono hatred/fear stemmed from a particular time in
Linux history which involved a combination of Novell's role as
a major driver of Mono in GNOME, Microsoft's very aggressive
patent posturing (although no actual lawsuits), and the close
relationship between Novell and Microsoft that culminated in
their patent agreement.
I don't think Microsoft would ever bother suing over Mono
patents just for money -- the concern was always that Novell's
pushing of Mono was a Trojan Horse that would enable Microsoft
to take down the wider Linux community and Novell to clean up
on the business Linux side.
Without solid support from Microsoft the C#F#/CLR culture is
unlikely to
remain strong, despite the serious success F# has had in
making people
interested in CLR. And C# is not a bad language, in many ways
much
better than Java. But Java has staying power in ways C#/F# do
not.
First-mover advantage, cross-platform for longer, less patent
fear ...
I gave Mono-D a whirl, but as I don't do any C# or F#, it has
brought in
a huge amount of dependencies. My problem is I do not
understand how the
"Solution" system is the same or different to everyone else's
"Project"
system. I guess I do not have much enthusiasm to find out as I
can just
use Emacs.
Yes, the number of dependencies is very, very annoying if you
don't want to work with C#/F#.
GNOME vs. Qt may be religious to certain parties, but most
people choose
either GNOME or KDE for the desktop and then load the other
widget set
as well. I use GNOME but I have a many Qt-based things on here
and
indeed develop PySide and PyQt5 based systems since GNOME is a
non-starter on Windows and OS X. Pragmatism is the order of
the day here
not religious fervour.
Yes, GNOME vs. KDE is the issue, not GTK vs Qt. Installing a
specifically GNOME or KDE app will pull in a ton of
dependencies from the other desktop, installing a purely Qt- or
GTK-based app is much less heavy (it's almost unavoidable I'd
say to have both Qt- and GTK-based code on your system).
I found this out recently when trying to install kcachegrind,
which wanted to pull in a ton of stuff from the KDE desktop
that really didn't seem necessary. It does apparently include a
"qcachegrind" package that's purely Qt-based, but it's not
packaged separately for Debian or Ubuntu :-(
I think that now that Qt has escaped from
Microsoft^H^H^H^H^H^H^H^H^HNokia, it will return to being one
of the two
primary system for cross-platform GUI systems, wxWidgets being
the
other. Thus I think QtD (fot Qt4 and Qt5) should be seen as an
essential
component of the D milieu. wxD should also get some presence.
It is
great we have GtkD, but I cannot see it ever having any
cross-platform
traction.
I think that move is already happening and has been for some
time -- in fact I think the resurgence of Qt has been happening
ever since it was LGPL'd. My impression is that GTK/GNOME won
out historically because the Qt GPL/commercial dual licence
meant that there were licensing compatibility issues even for
free software, and that there was a single commercial
gatekeeper for proprietary software. That was an undesirable
situation to have for the core graphical toolkit of an
operating system, so GTK was preferred.
I completely agree that QtD should be a priority project -- I
think Qt's importance is only going to grow.
Perhaps this is a nice point to re-iterate my earlier plea for
consideration of Qt Creator as a potential cross-platform D
IDE? :-)
Personally I think that phobos contains some parts that are in Qt
base, so a wrapper isn't a perfect solution for D. It's certainly
the fastest way to extend the D framework and add a GUI library,
but Qt phylosophy doesn't match perfectly with D. Just take a
look to moc, in D it's possible and preferable to do without it.
That why we started DQuick to create a complete adaption of
QtQuick to D, this is much hard to do but DQuick has the
potential to be much more suitable for D.
