Announcement

Collapse
No announcement yet.

GXUI: A New Cross-Platform UI Library By Google

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by mike4 View Post
    For example?
    An internal cousin of Azure for example.

    Comment


    • #22
      Originally posted by rabcor View Post
      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)
      It can't get any easier than coding with Qt which is much more than only GUI by the way ...

      Comment


      • #23
        Originally posted by mike4 View Post
        Probably Google is trying to leave Java on Android? Would make sense, also Java is slow as a turtle and C# is not much better.
        Java actually isn't that slow at this point, but it is very memory hungry. However Dalvik is very slow to the point where Mono is significantly faster due to sgen and such. RyuJIT is faster than mono but I'm not sure how it compares with HotSpot at this point. That said I also don't see why you think that Go would be faster than Java, the Debian language shootout certainly doesn't support this.

        Comment


        • #24
          Language bindings

          Why not just write Go language bindings for GTK or Qt instead?

          Comment


          • #25
            Originally posted by uid313 View Post
            Why not just write Go language bindings for GTK or Qt instead?
            Why write something that already exists:

            QML support for the Go language. Contribute to go-qml/qml development by creating an account on GitHub.

            Comment


            • #26
              Originally posted by DarkCloud View Post
              I 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.
              The 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.

              Comment


              • #27
                Originally posted by Luke_Wolf View Post
                Well... 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.
                c++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


                • #28
                  Originally posted by jonnor View Post
                  The 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.
                  Well... Actually that's wrong. Programming languages DO in fact carry with them factors that influence the performance of a program. Functional languages can for example be aggressively concurrent by the compiler, and the more dynamic a language the more has to be shoved off to being determined at run time causing additional slowdowns vs a more static language where more things can be determined ahead of time. Garbage Collection implies that every so often the program will effectively pause to mark and collect the garbage, move the current in memory items into their appropriate generations, and so on. Not to mention that certain languages make going about things certain ways more or less difficult which effects how one goes about developing the software. Beyond that still questions like "How toolable is language X?" have significant effects on both the number of bugs in a program and the speed at which a piece a software is developed.

                  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


                  • #29
                    Originally posted by Luke_Wolf View Post
                    If 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.
                    Whenever I have used Dolphin, it has been from within KDE. Right now I'm using Enlightenment which uses neither GTK nor Qt by default (EFL)

                    Comment


                    • #30
                      Originally posted by bnolsen View Post
                      c++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.
                      I fail to see how the language standards and a rather massive framework that effectively operates as a complete platform abstraction are comparable. That said I am well aware of the tight coupling issue. The problem is that without a built in equivalent to the .NET Framework or the Java Class Library, you're either bound to find a bunch of random libraries of varying levels of documentation to support your needs, or to marry yourself to a framework like Qt. It's effectively easier in most cases just to marry yourself to a framework and be done with it than to try to find what you need or in the worst case write it yourself. Meanwhile in the .NET or JVM cases you can keep things relatively loosely coupled because the built in framework minimizes your external dependencies.

                      Comment

                      Working...
                      X