Announcement

Collapse
No announcement yet.

Red Hat's New Graphics Engineer Is A Longtime AMD/ATI Linux Developer

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

  • Red Hat's New Graphics Engineer Is A Longtime AMD/ATI Linux Developer

    Phoronix: Red Hat's New Graphics Engineer Is A Longtime AMD/ATI Linux Developer

    Red Hat had been looking to hire another experienced open-source graphics driver developer and for that their newest member on their growing open-source graphics team is a longtime AMD/ATI developer...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Hopefully for him that job comes with some IBM stock options

    Hopefully for me Red Hat is interested in GPU control panels

    I first wrote that as Rad Het and thought y'all'd get a laugh out of my dyslexic vowels

    Does anyone know if the book "Bash and QT for GUIs for Artards" exists? I'd like to read that.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      Does anyone know if the book "Bash and QT for GUIs for Artards" exists? I'd like to read that.
      QT stands for QuickTime, Qt stands for Qt. Either way, I'm not sure why you want to combine it and bash. Qt GUIs are usually written in either QML or C++ but they can be e.g. Python but not Bash. Care to explain what you actually need?

      Comment


      • #4
        Originally posted by Tomin View Post
        Qt GUIs are usually written in either QML or C++ but they can be e.g. Python but not Bash.
        Sure you can in Bash too, look at Qarma.

        Comment


        • #5
          Originally posted by geearf View Post
          Sure you can in Bash too, look at Qarma.
          If dialog-style tools are sufficient, then KDE's kdialog is a much more widely installed alternative.

          That said, I get an inordinate sense of satisfaction surrounding Qarma's rationale for aiming to be a drop-in replacement for Zenity:

          Q: Why do you waste time cloning a perfectly fine tool?

          A: "The answer is that GTK+ is primarily intended to be used on the GNOME desktop" "GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second."
          See this LWN Article and this blog post.

          Be careful what you wish for, GNOME.
          Last edited by ssokolow; 12 October 2019, 11:49 AM.

          Comment


          • #6
            On the surface this sounds good. It is just the realization that AMD drivers “need work” that has me a bit worried. The best out come here is that we have more developers working on AMD drivers than before.
            Last edited by wizard69; 12 October 2019, 11:49 AM. Reason: Autocorrect.

            Comment


            • #7
              Originally posted by ssokolow View Post

              If dialog-style tools are sufficient, then KDE's kdialog is a much more widely installed alternative.
              Oh I did not know that one, that's awesome thank you!

              Comment


              • #8
                Originally posted by Tomin View Post

                Care to explain what you actually need?
                A simple way to map shell commands to various styles of graphical interfaces with something a little more powerful and less hackish feeling than what Zenity or Kdialog offer.

                Hallowed are the Ori.

                Comment


                • #9
                  Originally posted by geearf View Post
                  Sure you can in Bash too, look at Qarma.
                  Well, I would not compare anything zenity-like to proper Qt bindings that you get on Python for example. But yeah, sure you can call programs to do things and return values for you from shell languages and that can be considered programming.

                  Then again if you really need something more than what Zenity (or Qarma) can provide, you ought to use a proper programming language (even Python would suffice) rather than bash. In long run it will pay off to learn it.

                  Comment


                  • #10
                    Originally posted by geearf View Post
                    Oh I did not know that one, that's awesome thank you!
                    No problem. You may also want to check out two other tools usually already installed on systems with KDE stuff installed:
                    • kioclient allows your scripts to perform operations like ls, cat, copy, move, and remove on URLs in a network-transparent manner via the kioslaves system. (Wanna write scripts that work just as well over SSH or Samba as locally? Pair it with kdialog's --getopenurl and --getsaveurl)
                    • qdbus is a command-line D-Bus client built around Qt's D-Bus client abstraction that has the best support for complex data types of any shell script helper I've tried so far. (Not perfect, but pretty good.) It's also second only to qdbusviewer for interactively exploring your system's available D-Bus APIs using introspection.
                    kioclient and the precursor to qdbus (the equivalent tool for DCOP, KDE 3's ancestor to D-Bus) are two of the big reasons I chose KDE 3 when I came to Linux from Windows XP.

                    While not KDE-specific, another good little-known shell-script helper is the xdg-user-dir command for querying ~/.config/user-dirs.dirs which defines where those equivalents to things like "My Documents" actually live. (eg. MEDIA_ROOT="$(xdg-user-dir MUSIC)")
                    Last edited by ssokolow; 12 October 2019, 12:36 PM.

                    Comment

                    Working...
                    X