Announcement

Collapse
No announcement yet.

GTK Planning More Improvements In 2021 From Better Accessibility To Animation Framework

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

  • GTK Planning More Improvements In 2021 From Better Accessibility To Animation Framework

    Phoronix: GTK Planning More Improvements In 2021 From Better Accessibility To Animation Framework

    In addition to shipping the much anticipated GTK 4.0, this toolkit driven by the GNOME desktop environment is making more plans for an exciting 2021...

    http://www.phoronix.com/scan.php?pag...ments-For-2021

  • #2
    Among the GTK plans for calendar year 2021 include:
    - an animation framework for application developers
    - accessibility support on non-Linux platforms, such as Windows and macOS
    - a new UI design tool, integrated with GNOME Builder
    - improved portability
    - simpler installation and out-of-the-box developer experience
    - better documentation

    If they can get most of this done by the end of 2021 / 1st half of 2022 then something like Gnome Builder will truly become the Xcode or Delphi of Linux. It will also solidify the fact that Gnome is the default UI and UX of Linux and Gnome Builder it's IDE.

    I am also VERY excited to see that they are finally shooting Glade in the head and leaving it for dead and working on an integrated UI builder once again ala Xcode and Delphi. In fact the killing off of Glade in no uncertain terms became explicit with this post linked below from a Gnome developer.

    Glade Not Recommended


    If you are starting out with GTK development, you may have heard of a tool called Glade. Glade is a UI designer application for GTK projects, that allows you to create, modify, and preview UI files before writing code. In that sense, Glade is a very useful tool for GTK apps.
    With that said, I must implore that you do not use Glade.

    All of these elements combine to make Glade more harmful than helpful. So please, do not use Glade. If you are working with UI
    files write them by hand. An editor with code folding and syntax
    highlighting can be very helpful. If you need to mock something
    up, you can try sketching on a piece of paper or using our
    mockup resources. Whatever you choose, don’t use Glade.

    Whole post linked below with explicit reasons why NOT to use Glade

    https://blogs.gnome.org/christopherd...t-recommended/




    Comment


    • #3
      an animation framework for application developers
      Good. Providing something too enticing not to use is the proper way to get Just Works™ support for the "prefers reduced motion" accessibility setting.

      Originally posted by Jumbotron View Post
      All of these elements combine to make Glade more harmful than helpful. So please, do not use Glade. If you are working with UI files write them by hand.
      And they expect hand-writing XML to be more appealing than just constructing the widget tree directly in code?

      The only reason I use Qt UI files over just writing raw PyQt code is that Qt Designer is more convenient for rapid prototyping than doing method calls in Python... something which hand-written XML most certainly is not.

      That said, I agree that Glade is a mess. Hell, I migrated from GTK+ to Qt specifically because, having made heavy use of Python bindings to both, Qt provides nicer APIs, richer functionality, and better developer docs and, with the switch from GTK+ 2.x to GTK 3.x, I could no longer justify hammering GTK into shape as a cost of getting "the standard toolkit that feels native on all DEs".

      (As one example, this page should not need to exist. By 2010, PyGTK should not have required you to hack up a way for multi-select and drag-and-drop to coexist in the same tree view.)
      Last edited by ssokolow; 24 November 2020, 06:14 PM.

      Comment


      • #4
        «- a new UI design tool, integrated with GNOME Builder»

        That's been on my wish list for quite some time. You know, people said a lot of bad things about Visual Basic 6, but it really did make programming fun and easy for beginners and GtkBuilder with something like Glade integrated, I think would be a really great way to attract more beginners, but when done well, it's also a very productive way to do things.

        Comment


        • #5
          Originally posted by Jumbotron View Post
          Among the GTK plans for calendar year 2021 include:
          - an animation framework for application developers
          - accessibility support on non-Linux platforms, such as Windows and macOS
          - a new UI design tool, integrated with GNOME Builder
          - improved portability
          - simpler installation and out-of-the-box developer experience
          - better documentation
          It would be fantastic!
          With a DX like that, I'd love to try Gtk (again)
          I mean, it's kind of long overdue, but very welcome indeed.
          Awesome!

          That said, isn't it quite funny that the plan is to become a smaller Qt?
          By the way, I really hope they succeed.
          While I prefer C++ for UI code, it would be awesome if Gtk were to become more widespread for cross plaftorm development

          Comment


          • #6
            I think the issue here is the lack of staff. It is easy to say don't use XYZ because it is outdated but if your short staff you need to get work done as fast as possible. Likewise the GTK4 team seem to have the same resource allocation problem as they seem to miss the importance of rapid development or simply don't allocate the resources they do have to tools. At the rate they are going I really expect to see GTK development fall to the wayside in favor of quicker systems for app developers. That might mean a tool kit designed for Rust or Swift but hopefully not a tool kit like Electron. I just don't see a future for any system that primarily has developers in the C world.

            Comment


            • #7
              Originally posted by jo-erlend View Post
              «- a new UI design tool, integrated with GNOME Builder»

              That's been on my wish list for quite some time. You know, people said a lot of bad things about Visual Basic 6, but it really did make programming fun and easy for beginners and GtkBuilder with something like Glade integrated, I think would be a really great way to attract more beginners, but when done well, it's also a very productive way to do things.
              I really have to agree with this idea that we need the good things about Visual Basic 6 on Linux. However I really think it is time to leave the C/C++ worlds behind. As languages go for app development they are far less than ideal. In fact I'd have to say right now they are holding Linux back as far as app development is concerned. The problem of course is trying to map GTK onto a new language and actually leverage the features of that language and the associated modern technology. It very well might be a good time to start phasing out GTK and the other legacy programming systems.

              Comment


              • #8
                You have a point. How about something like AvaloniaUI?

                Comment


                • #9
                  Originally posted by wizard69 View Post
                  The problem of course is trying to map GTK onto a new language and actually leverage the features of that language and the associated modern technology. It very well might be a good time to start phasing out GTK and the other legacy programming systems.
                  I'd say GTK is ahead of the curve on that, given that it defines its APIs using GIR these days.

                  Heck, my perspective is "I love GObject APIs... I just wish I didn't have to use them with a toolkit that's become dominated by the concerns of the GNOME 3 HIG."

                  Comment


                  • #10
                    Originally posted by wizard69 View Post
                    I really have to agree with this idea that we need the good things about Visual Basic 6 on Linux. However I really think it is time to leave the C/C++ worlds behind. As languages go for app development they are far less than ideal. In fact I'd have to say right now they are holding Linux back as far as app development is concerned. The problem of course is trying to map GTK onto a new language and actually leverage the features of that language and the associated modern technology. It very well might be a good time to start phasing out GTK and the other legacy programming systems.
                    I would like to agree with you. But the problem with that line of thinking is that at this point in time, if you want a UI toolkit to support more than one programming language (or more accurately more than one language implementation, since e.g. supporting multiple JVM/CLR/browser languages is reasonably easy), then it must have a decent C API because that's the only sort of API that all popular programming languages agree on speaking.

                    This is the core reason why GTK&friends try so hard to shoehorn relatively high-level programming language concepts into a C API, even though the result is a mess that is not really usable without reversing the transformation in every language-specific binding by translating every C API back into a high-level API (which leads to fat bindings, and thus lots of effort duplication).

                    If you want to avoid this statu quo, you have three choices :
                    • Convince all developers to agree on a single programming framework for all their UI programming. From history, the odds of this happening are pretty low. But even if it could happen (say, Electron bloat-land manages to take over the world), hopefully we'll agree that this would not be an ideal scenario.
                    • Embrace UI toolkit fragmentation. Each programming language (implementation) gets its own UI toolkit that doesn't try to be usable by other languages, and then you get a fragmented patchwork of half-baked UI toolkits that don't look the same way, don't work the same way, don't interoperate well with one another, and eschew features which developers don't find exciting like documentation, multi-language support or accessibility because they're just too much starved from manpower due to effort duplication.
                    • Build a higher-level API standard than C and convince all major programming languages to support it. I personally think that this would be the best path in the long run, but in the short run the amount of technical and political effort that would be required to actually pull this off is so huge that no one has managed so far. For starters, it is really hard to achieve interoperability between things like automatic memory management schemes (RAII, reference counting, tracing GC...).
                    Last edited by HadrienG; 25 November 2020, 04:35 AM.

                    Comment

                    Working...
                    X