Originally posted by mike4
View Post
Announcement
Collapse
No announcement yet.
GXUI: A New Cross-Platform UI Library By Google
Collapse
X
-
Originally posted by rabcor View PostPlease 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)
Comment
-
Originally posted by mike4 View PostProbably Google is trying to leave Java on Android? Would make sense, also Java is slow as a turtle and C# is not much better.
Comment
-
Originally posted by uid313 View PostWhy not just write Go language bindings for GTK or Qt instead?
Comment
-
Originally posted by DarkCloud View PostI don't know much about Gtk, but as far as Qt goes your the first person I ever heard refer to it as slow. Please elaborate. For the most part it gets compiled from C++ so don't know what you are comparing it to. As for learning I think you need to give it a few months of working with it (the same goes for any ToolKit). For starters the documentation and community for Qt are second to none.
Good performance is acheived through minimizing unnecessary computations, utilizing the right hardware (sometimes GPU, DSP, FPGA), keeping algorithmic complexity low, making good use of concurrency (both fine-grained like SIMD, coarse like multi-threading and distributing among cores/machines), minimizing and batching up I/O (disk and net), making efficient use of memory (including L1/L2 cache) and chosing the correct latency versus throughput characteristics.
Perceived performance can be enhanced through immediate and clear feedback to the user, including smart use of animations.
Different programming languages make various aspects of these tasks easier and harder, but the language alone solves *nothing*. That something is written in C++, C or ASM does not automatically mean it will perform well.
Comment
-
Originally posted by Luke_Wolf View PostWell... Qt is far more than just a GUI toolkit, it's effectively equivalent to the .NET Framework or the Java Platform libraries. It's a framework which you can build applications in, so comparing the two is pointless.
I've been burned too much by 2 different code bases in the past that heavily used qt throughout.
None of them were pretty and its easier to harm maintainability with too much coupling.
Comment
-
Originally posted by jonnor View PostThe programming language does not determine the performance of a software.
Good performance is acheived through minimizing unnecessary computations, utilizing the right hardware (sometimes GPU, DSP, FPGA), keeping algorithmic complexity low, making good use of concurrency (both fine-grained like SIMD, coarse like multi-threading and distributing among cores/machines), minimizing and batching up I/O (disk and net), making efficient use of memory (including L1/L2 cache) and chosing the correct latency versus throughput characteristics.
Perceived performance can be enhanced through immediate and clear feedback to the user, including smart use of animations.
Different programming languages make various aspects of these tasks easier and harder, but the language alone solves *nothing*. That something is written in C++, C or ASM does not automatically mean it will perform well.
It's nice to believe that everything is up to the craftsman and that the tools he uses don't matter, but the simple reality is that this is not true. A good craftsman values a good set of tools and both despises and avoids those that harm his productivity.
Comment
-
Originally posted by Luke_Wolf View PostIf you're running LXDE (or really anything not-KDE) as indicated by your talking about LXQT that would mean that of course GTK applications will load faster because the GTK toolkit is preloaded in memory whereas Dolphin or any Qt application has to load the Qt toolkit and perhaps KDELib into memory before it's able to run the program, resulting in a slight startup lag while it does so.
Comment
-
Originally posted by bnolsen View Postc++11 covers a lot of that functionality, c++14 even more.
I've been burned too much by 2 different code bases in the past that heavily used qt throughout.
None of them were pretty and its easier to harm maintainability with too much coupling.
Comment
Comment