Announcement

Collapse
No announcement yet.

KDE Introduces KCommandBar For HUD-Style Popups

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

  • #21
    Originally posted by StarterX4 View Post

    GTK3/4 isn't perfect as well. Touch-focused (unnecesarily) and full of bloat (CSD). At least gtk3-classic fixes the things a bit.
    GTK is not touch focused. Big buttons or margins doesn't mean something is focused on touch. I would say that Qt is even better focused for touch - there is support for Android, iOS, some mobile platforms were using Qt like Sailfish OS or Blackberry OS. So one would say that Qt is more focused on touch than GTK where most GTK applications are desktop applications.

    Also header bar and CSD are not the same things. Qt also supports CSD. You can also put widgets on title bar with Qt as well. On both toolkits it's optional feature. Why optional feature would be bloat?

    Comment


    • #22
      ngraham I know this isn't the best place to ask this question, but on and off for the past month I've been trying to get KDE to compile with kdesrc-build because I've noticed a few things I could actually contribute towards. Just documentation, help text, tool tips, and those sorts of things. I can't program but I do know how to write competently.

      I wanted to at least be able to get it all built and running on my own but dammit if I don't keep running into walls. I'm at the point now where I'm not sure if I'm having build issues due to being on Manjaro (bleeding edge OS issues), if it's because the code itself is bleeding edge and I start builds at bad times, or who knows what.

      Is there a distribution y'all recommend using kdesrc-build with or a distribution for KDE development in general. My assumptions are Neon Developer Edition, a SUSE variant, or FreeBSD.

      If I wasn't asking I'd install Ubuntu 20.04 and convert that over to Neon Developer Edition. I did that a year ago and it was really, really simple and worked like a charm. It just seems like a smart idea to have a backup and restore strategy like Zsys or Snapper in place when running potentially unstable development software. I just thought I'd ask before doing an OS install for the explicit purpose of wanting to work with the documentation.

      I tried this a year or two ago, ran into the same wall (same distribution), and hit a combination of give up and distracted by life. I don't want that to happen this time. I can't stress that enough. I'd appreciate it if yourself or anyone here who reads this can give me a swift kick in the rear to put me in gear every once and a while.

      Comment


      • #23
        Originally posted by curfew View Post
        You're probably still living in 1980s then.
        I wasn't even born yet in the 1980's, so I can't be “still” living in the 80's.

        Comment


        • #24
          Originally posted by dragon321 View Post

          GTK is not touch focused. Big buttons or margins doesn't mean something is focused on touch. I would say that Qt is even better focused for touch - there is support for Android, iOS, some mobile platforms were using Qt like Sailfish OS or Blackberry OS. So one would say that Qt is more focused on touch than GTK where most GTK applications are desktop applications.

          Also header bar and CSD are not the same things. Qt also supports CSD. You can also put widgets on title bar with Qt as well. On both toolkits it's optional feature. Why optional feature would be bloat?
          I think he's confusing GTK with GNOME. Now, even on GNOME you may argue that it's not touch-focused, but it does look more touch-focused than i.e. KDE, Deepin, etc. With regards to toolkits, you're right that Qt is more touch-focused.

          Comment


          • #25
            Originally posted by curfew View Post
            Sadly it looks shit as do all the other Qt-based widgets. They are perpetually stuck in 1990s and legacy UX. GTK is where the innovation happens and that's why I'm also migrating from developing Qt apps to dedicating my time for GTK.
            Still waiting for GTK to "innovate" up a filepicker with thumbnails. Remember that even Windows 98 had a filepicker with thumbnails. Also waiting for GTK programs to not look extremely out of place on my desktop.

            I guess whitespace + bloat + missing features = innovation.

            Comment


            • #26
              Originally posted by BesiegedAce View Post
              Still waiting for GTK to "innovate" up a filepicker with thumbnails. Remember that even Windows 98 had a filepicker with thumbnails. Also waiting for GTK programs to not look extremely out of place on my desktop.
              In my opinion GTK apps look great on every desktop whereas KDE apps look shit even on the KDE desktop. Besides GTK apps lacking proper shadows on KDE ("Kwin") is a KDE issue, if you happened to be talking about that.

              All toolkits have different theming and none of them can exactly replicate another, so there's always going to be a problem with achieving native look-and-feel with "competing" toolkits and apps.

              Comment


              • #27
                Originally posted by Vistaus View Post
                I wasn't even born yet in the 1980's, so I can't be “still” living in the 80's.
                It's written 1980s and '80s since we're on and about chattering nonsense now.
                Last edited by curfew; 23 May 2021, 09:59 PM.

                Comment


                • #28
                  Originally posted by Morty View Post
                  And with this "all QWidgets-based KDE apps that use our KXMLGui framework (which is to say, most of them) will automatically get this feature for free!", it clearly show how things is solved in a advanced modern toolkit. No more re-implementing it all over the place and tons of boilerplate code you get in lesser toolkits.
                  So it's forced upon all the apps without the permission of the developers. Sounds pretty grim and if this happened on Gnome, people would probably be flaming their torches up already. I'm not sure an irrelevant feature like this is really needed for each and every app. With KHamburgerMenu the argument was that it's completely opt-in, would be dumb to force it for every app. And now they're taking the polar opposite approach. Nothing in KDE seems to be consistent, not even their arguments.

                  (How is it even being triggered? Menu items and keyboard shortcuts are application-specific... They are not able to avoid conflicts with this approach.) Also plain vanilla Qt apps won't get it, which will be very confusing. Alright, let's assume "they get it for free" still means that they have to flick some boolean switch on first... So it's a free lunch but you still gotta tip the waitress.
                  Last edited by curfew; 23 May 2021, 10:02 PM.

                  Comment


                  • #29
                    Originally posted by skeevy420 View Post
                    ngraham I know this isn't the best place to ask this question, but on and off for the past month I've been trying to get KDE to compile with kdesrc-build because I've noticed a few things I could actually contribute towards. Just documentation, help text, tool tips, and those sorts of things. I can't program but I do know how to write competently.

                    I wanted to at least be able to get it all built and running on my own but dammit if I don't keep running into walls. I'm at the point now where I'm not sure if I'm having build issues due to being on Manjaro (bleeding edge OS issues), if it's because the code itself is bleeding edge and I start builds at bad times, or who knows what.

                    Is there a distribution y'all recommend using kdesrc-build with or a distribution for KDE development in general. My assumptions are Neon Developer Edition, a SUSE variant, or FreeBSD.

                    If I wasn't asking I'd install Ubuntu 20.04 and convert that over to Neon Developer Edition. I did that a year ago and it was really, really simple and worked like a charm. It just seems like a smart idea to have a backup and restore strategy like Zsys or Snapper in place when running potentially unstable development software. I just thought I'd ask before doing an OS install for the explicit purpose of wanting to work with the documentation.

                    I tried this a year or two ago, ran into the same wall (same distribution), and hit a combination of give up and distracted by life. I don't want that to happen this time. I can't stress that enough. I'd appreciate it if yourself or anyone here who reads this can give me a swift kick in the rear to put me in gear every once and a while.
                    Neon Developer works great as a dev platform, but is less ideal as a daily driver OS. openSUSE Tumbleweed works really well for both. I used it for several years, but switched to Fedora a few days ago for unrelated reasons. So far it's been solid too. A lot of KDE devs use basic Arch. I don't recommend Manjaro.

                    I'd be happy to help you overcome whatever build problems you're getting stuck on, but this is not really the right venue; check out https://community.kde.org/Get_Involv..._with_the_team. If after you're done, you want to update the relevant wiki page (https://community.kde.org/Get_Involved/development), please feel free.

                    Comment


                    • #30
                      Originally posted by curfew View Post
                      It's written 1980s and '80s since we're on and about chattering nonsense now.
                      I'm Dutch and we usually write ‘80's‘. I have to use 3 languages every day (Dutch, English and German) so sometimes typos happen. So excuuuuse me for making a typo, mr Teacher.

                      And thanks a lot for this wonderful contribution instead of actually addressing my point.

                      Comment

                      Working...
                      X