GXUI: A New Cross-Platform UI Library By Google

[caligula]

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.

Even if you use the worst possible algorithms, the GUI will work just fine today. The main reason is that computers are around 10^6 to 10^8 times faster than the first computers that had a multicolor mouse driven GUI and the graphical needs are only 25 times as big as in the 1980s. The next big reason is that even with a slow CPU and a very shitty language for high performance code (e.g. Python), you can still achieve good GUI performance on hardware like Raspberry Pi. The GPU is very powerful. The Raspberry is about as fast as Pentium 2 and people use it to run interpreted languages. Still it can easily display 1920x1080 truecolor graphics. The Raspberry Pi is about as fast as 486DX when you run non-jitted Python/Javascript on it. Still, it runs 1920x1080x24b @ 30 fps easily.

[sloth77]

Hard drives used to transfer max 5 MB/s when I was a kid.....

You lucky sod! When I was a kid, we had cassette drives that transferred 50 bytes per second!

(http://en.wikipedia.org/wiki/Commodore_Datasette)

[cb88]

I wrote a layout engine for fltk2 to remove any use of hard coded sizes and coordonates a while back (fltkl i think). I've been meaning to port/fork fltk2 over to use sdl2 as the backend, just need money and time (as usual).

gtk isn't so great cross platform and qt is definitely bloated. has serious problems with non orthogonality and definitely has plenty of surprises if you try to dig into it.

it's been a while since I tested but a few years back qt4 took 40 mins to compile. fltk2 compiles in 8 seconds flat on my dev machine, libraries, utilities, test programs and all.

gxgui will take some reading to see if they have any cool new enlightened ways of doing that boring gui thing no one ever seems to get right.

FLTK 2 is dead... completely don't every never use it

Instead use FLTK 1.3 and possibly in the future 3.x. But 1.3 is where it is at these days.

[SystemCrasher]

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.

There is one fancy thing though: REAL cross platform solutions do not require all this weird crap. You see, GTK based program runs anywhere as a matter of recompile. Qt does it even better and on even more plaftorms, with even more native look. Even SDL based game would do so. Java would do it as well (though crappy, but at least it works). So it usually takes Z-E-R-O changes to code. And whole need to change code completely screws up "write once, run everywhere" idea. Far harder than need to recompile source. Recompiling does not takes much effort and could be automated. Writing some extra code is not and it really creates dumbass problem out of nowhere. Only really insane devs would turn MS greed and their overall inability to think beyond Winduz into their own problems.

That said QtSharp is being developed https://github.com/ddobrev/QtSharp so that problem will solve itself within a short time.

There is only couple of probs:
1) It is not a native part of .NET, and so it would give extra headache to devs who will have to learn a lot of technical cruft about dotnet internals and how to plug their UI lib to .NET and how to supply it to user in usable way. If one thinks devs are in mood to have it as hard as that - good luck with it!
2) Somehow you're silly enough to assume devs can have uber-goal to use .NET at all costs. This is fucking wrong idea from MS zealots.

And from my experience, if one is real about about being cross-platform, first step is to completely forget about MS and their techs. They proven to be really hostile to cross-platform things, because they're inherently interested in vendor lock.

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.

Fortunately most devs are not insane enough to face all this "native" support from MS. All this "cross"platform support is so formal and third-rate they better to shut up with their marketing bullshit. It really suxx when marketing advertisements are better than actual software and it is what I hate about MS products.

[SystemCrasher]

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.

But you see, XFCE is not going for super-duper-plasmoids, mega-SQL-databases in separate processes to store all contacts and email (for couple of shitty apps on the whole planet) and so on. So XFCE works fine on 10 years old desktop. OTOH KDE suxx quite a lot on such hardware. And Java? Oh, you'll swear way too much using Java programs on 10 year old PCs.

[DanLamb]

Also Java IDEs can be slow (GUI wise).

- Java IDEs are slow because of all the stuff they are doing. They are mega applications. Visual Studio is often slow as well.
- Java GUI apps are pretty zippy and responsive. JavaFX is a nice choice.
- Almost no one is doing desktop client GUI applications any more. That has become an extreme niche field. Web browsers, chat clients, terminal apps, IDEs, content creation apps with sound+graphics, and games... That's mostly it.

[Luke_Wolf]

- Almost no one is doing desktop client GUI applications any more. That has become an extreme niche field. Web browsers, chat clients, terminal apps, IDEs, content creation apps with sound+graphics, and games... That's mostly it.

If nobody is doing desktop client gui applications any more then nobody was ever making them in the first place. The only real difference is that no cost alternatives have displaced commercial software in most sectors, otherwise the desktop GUI field is alive and well. Reports of the death of the desktop are, as always, greatly exaggerated.

[Luke_Wolf]

There is one fancy thing though: REAL cross platform solutions do not require all this weird crap. You see, GTK based program runs anywhere as a matter of recompile. Qt does it even better and on even more plaftorms, with even more native look. Even SDL based game would do so. Java would do it as well (though crappy, but at least it works). So it usually takes Z-E-R-O changes to code. And whole need to change code completely screws up "write once, run everywhere" idea. Far harder than need to recompile source. Recompiling does not takes much effort and could be automated. Writing some extra code is not and it really creates dumbass problem out of nowhere. Only really insane devs would turn MS greed and their overall inability to think beyond Winduz into their own problems.

So... using MVC as a design pattern for GUI applications is "weird crap" now, got it. Reality is there's two schools of thought when it comes to going cross platform, the first is that of writing the application including the interface one time for all platforms, this saves developer time with the result being an application that is tightly bonded to the GUI toolkit, this can work well in situations where the toolkit performs theme integration, but otherwise the application will look awful and out of place on every system (see most Java GUI applications). If we want to bring in games then that really isn't so much a problem, however if you want to write games in C# SDL is available through OpenTK, and MonoGame is an open implementation of XNA.

The other alternative is realizing that the GUI is in most cases a rather small part of an application and as a result that if the application is designed properly then the actual application logic effectively exists as a library that is then used by your GTK, Qt, Console, etc frontends. With it being quick and easy to bring up a new one. This has the advantage in that you're enforcing loose coupling, and your application is going to be specially integrated with the environment that it is targeting.

There is only couple of probs:
1) It is not a native part of .NET, and so it would give extra headache to devs who will have to learn a lot of technical cruft about dotnet internals and how to plug their UI lib to .NET and how to supply it to user in usable way. If one thinks devs are in mood to have it as hard as that - good luck with it!

Apparently plenty of people are doing just that otherwise Xamarin wouldn't exist as that is their entire business, GTK# wouldn't exist, and QtSharp wouldn't be being developed, OpenTK wouldn't be a thing, and on and on and on. But all that aside that has absolutely no impact whatsoever on the end developer who just takes a set of DLLs, likely that they didn't even have to manually install as opposed to getting off of nuget, and make sure it gets deployed with the application.

2) Somehow you're silly enough to assume devs can have uber-goal to use .NET at all costs. This is fucking wrong idea from MS zealots.

It's silly to assume that people want to use one of the most popular languages/platforms? What planet do you live on?

And from my experience, if one is real about about being cross-platform, first step is to completely forget about MS and their techs. They proven to be really hostile to cross-platform things, because they're inherently interested in vendor lock.


Fortunately most devs are not insane enough to face all this "native" support from MS. All this "cross"platform support is so formal and third-rate they better to shut up with their marketing bullshit. It really suxx when marketing advertisements are better than actual software and it is what I hate about MS products.

And well... this is simple blind zealotry...