Since he has never mentioned anything about compile lengths, why do you think that's connectd to his "point"?
And no, I have not in the last few years. Then again, why would someone working on KDE or GNOME need to rebuild Gtk or Qt anyway?
I mean, yes, if you are working on kdelibs you will need to work with qt-copy for a period, but that's a tiny fraction of desktop development.
In any case, as I said, I don't see a connection to anything he wrote.
Well, thank you for confirming that KDE and Qt developers are bigoted idiots.
How did I do that? I have not been involved in KDE since version 2!
I am just a PyQt hobbyist nowadays.
"Why they dropped Qt#?"
No idea, ask the author. Qyoto exists.
Using libsmoke it *is* easy to bind Qt. You can sing nyah, nyah with your fingers in your ears if you want. That is easy too.
The number of KDE developers is growing. The number of GNOME developers is stagnant. That is a more interesting metric for ease of development than your repeated assertions.
Developing in C++/Qt is simply not horrible (even if I prefer PyQt myself!).
About 95% of GNOME *is* currently developed in a horrible environment.
That is simply not the case with KDE.
Why would that not cause an emphasis in bindings on the GNOME side? It's a simple, rather obvious thing, you just dismiss because of your pigheaded C preference, when it doesn't even mater to the point at hand.
C# bindings are libsmoke-based, called Qyoto, and part of kdebindings.
I don' t know bindings for the other languages you mention, but I haven' t looked, either. In any case, that's not an indication of a difficulty in binding them. It could even be a signal that coding in C++ is so much nicer than doing it in C, that there are not enough desperate developers.
The Python bindings predate libsmoke, are mostly automatically generated, and work, so noone bothered doing a libsmoke version.
There are also bindings for Lua, and PHP, also libsmoke-based.
As usual, all along this thread, you are wrong.
If C++ is a dead end, so is C and your GNOME preference makes no sense.
Binding Qt to other languages is actually easier than binding Gtk nowadays (check libsmoke).
The Python Qt bindings are awesome, so you are, in the best case, giving a personal opinion that Gtk's are better (in my opinion they aren't)..
So all your position boils down to is "I like pygtk better"?
In short, you just keep saying things, without backing up anything, except by obviously silly, purely subjective or misleading statements.
No, it's not circular. Qt is a GUI toolkit. It's written in C++. It's awful nice.
Obviously, you have neither taste nor experience with real object systems. Like most Qt/KDE developers, you're just ignorant.
What are you, a LISPer?
Are you actually, seriously pushing forward GObject as a real object system preferred by developers of discerning taste? Are you drunk?
It's weird that you go on and on making arguments that hurt your own case, though.
You don't know what you're talking about.
That was specifically aimed at your silly concept that Apple preferring Objective C instead of C++, and MS dropping C++ for C# is somehow a validation of C+Glib+GObject.
C was not even running in that race. C was the dead horse from which they made the glue to attach the plaque to the trophy of that race.
No, it's not circular. Qt is a GUI toolkit. It's written in C++. It's awful nice. Ergo, you can have a nice C++ GUI toolkit. It's pretty straightforward, really.
You seem to have this idea about Qt being written in some language that is not C++. Let me disabuse you of that notion: Qt is written in C++. The proof is in the pudding: C++ compilers love its code.
And please, go educate yourself about Qt's metaobject system. It's not what you seem to think it is.
If C++ is a dead end, so is C, since it is noticeably *worse*. As you said, Apple rejected C too! and Microsoft abandoned it ages ago! For C++, even!
It's weird that you go on and on making arguments that hurt your own case, though.
1) Indeed I have only one ctrl key in my netbook.
Taskbar.
Then "I want my minimized windows on the dektop, so I have to click a two-handed shortcut and THEN click to unminimize them" ?
It' s obvious you have no clue:
GNOME never eliminated C++: they just never got there.
Glib, Gobject and others reimplement most of that "overhead" you mention.
C++ is very suitable for GUI development: example Qt!
It does have this "feature", and you don't even need any addons.
Add the "task manager" plasmoid to your desktop.
Then in its settings select "show only minimized windows". Tweak for multirows if that floats your boat.
OTOH, this is an incredibly useless feature (yeah, I want my minimized windows on the desktop so I have to minimize the other windows to unminimize them! Really, not that smart)
That way you end up with 4 half-assed HTML libraries in use (gtkhtml, gtkhtml2, webkit and mozembed).
If you use a folder view, you have icons in your desktop. How the hell is that not icons ON the desktop?
You actually want to have to move your mouse to another monitor to switch to an app in the first monitor? Because that's what is going to happen with a two-monitor taskbar.
It's really quite nuts as a request.
OTOH, if you want a taskbar n each monitor with each monitor's apps, that would make *some* sense but is not what you wrote.
Not C#, but there is no reason you couldn' t do it using C# too. And I must say it's a heck of a demo!
Let's see:
1) GNOME wraps C libs for C# and Python
2) KDE wraps C++ for C# and Python
And from that data, you reach the conclusion that KDE is weighted down by the legacy of lots of C++ code (why isn't GNOME weighted down by the legacy of lots of C code then?).
Sir, you have an excepcional brain.
All extremists should be taken out and shot.
