GXUI: A New Cross-Platform UI Library By Google

[rdnetto]

Please tell me this is gonna compete with Qt and GTK (and WPF)... I hate Qt and GTK, I hate them so fucking much! (GTK is ugly and outdated, Qt is pretty, but slow and a hardcore pain in the ass to learn and code in)

As someone who has done a fair bit of Qt programming, I disagree. Qt Creator is one of the best IDEs in Linux (probably one of the few that comes close to Visual Studio, and Qt itself is IMO superior to .NET in terms of functionality and design), and the Qt tutorials made it pretty easy to pickup. (Admittedly, I haven't done anything with it since Qt 5 became the standard, so that could have changed.) Having done some fairly low-level work with the signals and slots API, it's definitely not slow - they use some fairly impressive tricks to encode a lot of that information in low-level structures at compile-time.

[caligula]

As someone who has done a fair bit of Qt programming, I disagree. Qt Creator is one of the best IDEs in Linux (probably one of the few that comes close to Visual Studio, and Qt itself is IMO superior to .NET in terms of functionality and design), and the Qt tutorials made it pretty easy to pickup. (Admittedly, I haven't done anything with it since Qt 5 became the standard, so that could have changed.) Having done some fairly low-level work with the signals and slots API, it's definitely not slow - they use some fairly impressive tricks to encode a lot of that information in low-level structures at compile-time.

You know my first PC computer was from 1986 and had smooth 640x200x4b graphics. The computer was 8 MHz 16-bit system with 512 kB of RAM. It ran 16-bit DOS.

Now I have a fucking 64-bit 4 core, 8 thread machine that runs at 4 GHz. It can also do 256-bit math with AVX. I only have 32 GB of memory. The GPU sure has higher resolution, 2560x1600x24b, but the GPU's fillrate allows 17 000 fps! And there are 2048 cores and 4,6 teraflops of computing power inside the GPU. So you're really trying to say that you'll need to micro optimize these days to get full performance out of the GUI?? So much bullshit today.

[rdnetto]

Back when I was writing WPF in visual studio, the approach I took was to write WPF code (basically a script, Qt works similar, but I don't remember exactly what the UI script is called, either way in the QtCreator you can't manually edit it, it must be edited through the designer thing (a bit of a pain...)) and then just write C# code which I would refer to for the WPF's UI functions. I don't remember exactly how it went down but it was a simple arrengement, C# for any backend functionality, wpf for the front end, they interacted with each other pretty seamlessly. On the other hand in Qt I cannot do this. Qt wants me to use Qt libraries for all the commands to the point where they might as well just have made a new programming language from scratch instead of using c++. In Qt it's not "str", it's "QString" otherwise I will run into problems when trying to forward whatever my function or class wanted to spit out to the UI, I need to use Qt's specific objects for anything to bloody work, and I just hate that approach. I imagine GTK is the same way, but whether it is or not, GTK is ugly, and it's old. GTK3 I guess is just ugly (and besides, Qt supports so many more platforms than GTK) but really my gut has just always preferred Qt over GTK for some strange reason; I feel like there's something really major lacking in both of them but of course can't pinpoint what. Either way the reason Qt is a pain in the ass to learn is that you can't just jump in and use Qt for managing the GUI and C++ for managing whatever goes on under the hood, no you need to learn the Qt libraries like the back of your hand so that you know what to use instead of str or int or float (like QString and QFloat and QJunk), and I also think this is majorly to blame for any performance issues I've been having with Qt programs as an end user, although that's just a blind guess, it just seems like it to me.

That's a false comparison - WPF is part of the .NET Framework, which defines the basic types used by C#. If WPF needed additional features, they could (and were) just added to the language spec. (And even then, there are patterns like always subclassing EventArgs instead of just allowing distinct classes via generics.) Qt, being completely separate from C++, had no option but to define their own basic types (QObject, QString) if they wanted extend the functionality. I would argue that they were right to do so, because developing in C++ with Qt is way easier than doing so in plain C++ - it's about as easy to use as C#. There are also pretty well established functions for converting to/from std::string, such as the constructor and QString.toUtf8().constData(). QObject enabled signals/slots. QString improved handling of encodings, as well as having a much nicer API and arguably more function than std::string. QFloat does not exist, because there was no missing functionality.

If you think about it sufficiently, the approach you are arguing for is fundamentally flawed. If your code interacts with the GUI, then it needs to use the same types as it. Sure you could automatically convert from QString to char*, but that would be inefficient and slow. And it can't use the native types, because they are functionally deficient.

I think there is an argument to be made that now that Boost is part of the standard, some parts of Qt are redundant. But Boost was only added to the standard in C++11, and Qt has been around since 1995.

[rdnetto]

You know my first PC computer was from 1986 and had smooth 640x200x4b graphics. The computer was 8 MHz 16-bit system with 512 kB of RAM. It ran 16-bit DOS.

Now I have a fucking 64-bit 4 core, 8 thread machine that runs at 4 GHz. It can also do 256-bit math with AVX. I only have 32 GB of memory. The GPU sure has higher resolution, 2560x1600x24b, but the GPU's fillrate allows 17 000 fps! And there are 2048 cores and 4,6 teraflops of computing power inside the GPU. So you're really trying to say that you'll need to micro optimize these days to get full performance out of the GUI?? So much bullshit today.

Not at all. I used 'low-level' in the sense of a high-level language, since Qt actually uses macros to embed a list of null-terminated strings and integers in QObjects to represent the type info, in such a way that connecting signals and slots at runtime is O(1). That they do this in such a way as to be transparent to the programmer contradicts your argument that one needs to micro-optimize. (In fact, one could make the argument that Qt is actually quite good at putting that GPU to work by using OpenGL, though I won't as I'm not particularly familiar with it.)

Now, those techniques are certainly not going to be low-level compared to what was going on in the 80s, but it is true that an obvious/naive implementation (which would likely be O(n)) could result in significantly longer start-up times that the user would notice. For example, WPF .xaml files worked basically the same way that Qt's .ui files did, but when I tried using them in .NET 4.0, even a simple application took over a second to load.

You don't need to micro-optimize, but you absolutely do need to make some sane decisions about your design and algorithms if you care about performance.

[SystemCrasher]

You're joking right?

http://www.mono-project.com/news/

https://github.com/Microsoft/dotnet

http://blogs.msdn.com/b/dotnet/archi...en-source.aspx

It rather looks like if one of us being retarded to degree where he is unable to read. Maybe you failed to notice, but I've been talking about CROSS-PLATFORM UI. That is it. CROSS PLATFORM USER INTERFACE.

So where all this scrap you've listed offers CROSS PLATFORM UI? Are you kidding? WinForms? Basically win-only and bugged like hell and poorly looking in Linux. Not sure if it works anywhere else at all. Not to mention M$ patent promise does not covers it. WPF? Windows-only for sure. GTK#? Erm, it is not supported in Windows by "native" .NET.

So basically it is not possible to write cross-platform GUI program using .NET without some major headache. Not to mention its funny Google can get it right in months compared to MS idiocy which lasts for many years.

[SystemCrasher]

You know my first PC computer was from 1986 and had smooth 640x200x4b graphics. The computer was 8 MHz 16-bit system with 512 kB of RAM. It ran 16-bit DOS.

Now I have a fucking 64-bit 4 core, 8 thread machine that runs at 4 GHz. It can also do 256-bit math with AVX. I only have 32 GB of memory. The GPU sure has higher resolution, 2560x1600x24b, but the GPU's fillrate allows 17 000 fps! And there are 2048 cores and 4,6 teraflops of computing power inside the GPU. So you're really trying to say that you'll need to micro optimize these days to get full performance out of the GUI?? So much bullshit today.

That's why some clueless devs should be forced to test how their programs perform on 10 years old PCs. Otherwise users are swearing here and there when some idiot tested his program on super-duper configuration which exceeds 95% of computers and then surprised like a hell to read negative feedback from users who are not happy with how this horrible shit performs on THEIR systems. I'm sorry to inform you, but many users are really unhappy about idea to buy $1000 GPU and they also will have certain technical difficulties doing so on some notebook. Not to mention that even if some notebook comes with 4 cores, attempt to use all 4 cores at maximum speed would literally kill battery. But who cares? Sure, these losers can grab some generator to extend battery time, yeah?

[Luke_Wolf]

It rather looks like if one of us being retarded to degree where he is unable to read. Maybe you failed to notice, but I've been talking about CROSS-PLATFORM UI. That is it. CROSS PLATFORM USER INTERFACE.

So where all this scrap you've listed offers CROSS PLATFORM UI? Are you kidding? WinForms? Basically win-only and bugged like hell and poorly looking in Linux. Not sure if it works anywhere else at all. Not to mention M$ patent promise does not covers it. WPF? Windows-only for sure. GTK#? Erm, it is not supported in Windows by "native" .NET.

So basically it is not possible to write cross-platform GUI program using .NET without some major headache. Not to mention its funny Google can get it right in months compared to MS idiocy which lasts for many years.

If your GUI application is properly written (and not something like a CAD program that does significant computation in the UI) then the actual GUI code itself is minimal, and in fact you can pretty easily throw out a WPF, WinForms and GTK# frontend for it. That said QtSharp is being developed https://github.com/ddobrev/QtSharp so that problem will solve itself within a short time. Also GTK# IS in fact supported by native .NET hence why Monodevelop (on windows known as Xamarin Studio) can be run on the native .NET stack, and Mono usually isn't installed with it.

[Togga]

he only areas that C# isn't used is in the high performance sphere which is the stronghold of C and C++,

Then why use it at all? It just brings ju tons of baggage to bring along that's a pain for portability whatever new, interesting HW platform you want to run it on. Complete madness.

[Luke_Wolf]

Then why use it at all? It just brings ju tons of baggage to bring along that's a pain for portability whatever new, interesting HW platform you want to run it on. Complete madness.

Yeah! Why don't we all just write out all our problems in Machine Code? Performance is Everything for Every Program!.... Oh Wait.... no, no it's not. People choose to write in C# as opposed to C or C++ because they value safety and developer time over the raw performance of the binary (However it's worth noting that sometimes C# implementations of a concept are faster than C or C++ implementations of a concept, as seen here http://codicesoftware.blogspot.com/2...mark-test.html for example). Which is in all reality the right move because for most applications the performance difference is invisible, while an increase in developer productivity and safety is very visible. As it means less bugs and whole categories of security issues disappear.

Let's step back for a moment though and consider applications we run, what does "fast" really mean? Is it how fast a music player can process a song? Is it how fast the cursor blinks in our document editor? is it how quickly the loading bar displays it's animations? No... the "speed" of an application is generally speaking two things: Startup Time, and how quickly it performs the task we set it to do. For the latter what we really mean most of the time is "How responsive is an application?". Which effectively means will the program react as expected to user input within ~250ms (The time it takes for a human to react to something as per http://www.humanbenchmark.com/tests/...ime/statistics) if it wants to be perceived as instantaneous. This is actually a really long time for a computer: 750,000,000 cycles to be exact assuming a 3Ghz computer, as a result even languages that are actually slow (unlike C#) can handle this, as what most applications users use are not CPU bound in any way, but user input or disk bound.

Further C# is apparently fast enough for game development given that it's the exclusive platform for the PS Vita. The Playstation, Wii, and XBox all have it available as an actively used option, and Unreal considers it fast enough to supersede UnrealScript for scripting games. Once again as well Dust: An Elysian Tail, which is a C# and XNA game is certainly not slow, in fact it's been praised by well respected individuals such as TotalBiscuit for its extremely responsive combat system. If it's fast enough for games then it's fast enough for most applications, and with the advent of .NET Native allowing for the same kind of deep optimizations that C or C++ get... well.. we'll see how things look in the future.

On a further note, I fail to understand what you're talking about in regards to pain for portability, pure .NET code is in fact more portable than C or C++ because it's compiled into IL as opposed to a machine specific format, thus meaning that the only requirement is that you do whatever porting is necessary to make the CLR run on the target platform and then all your .NET code works just as it does on other platforms. Same goes for Java or Scripting languages and is one of the usual touted "strengths" of those platforms. Now if you depend on platform specific libraries then yes of course you're going to have problems, but that is a language independent problem.

[caligula]

That's why some clueless devs should be forced to test how their programs perform on 10 years old PCs. Otherwise users are swearing here and there when some idiot tested his program on super-duper configuration which exceeds 95% of computers and then surprised like a hell to read negative feedback from users who are not happy with how this horrible shit performs on THEIR systems. I'm sorry to inform you, but many users are really unhappy about idea to buy $1000 GPU and they also will have certain technical difficulties doing so on some notebook. Not to mention that even if some notebook comes with 4 cores, attempt to use all 4 cores at maximum speed would literally kill battery. But who cares? Sure, these losers can grab some generator to extend battery time, yeah?

To be honest my Haswell computer is already slowing down if I run 8 flash video applets at the same time. I don't know why since it can decode those videos at over 8x realtime easily. I also experience lag in KDE applications and the browsers seems a bit slow. Also Java IDEs can be slow (GUI wise). So I don't know. I'm using XFCE and quite happy with it. But still, the same desktop works happily even on a 10 year old PC.